Похоже на баг. Проверю.

Мы можем сделать настройку, но переплата уволенному в этом случае целиком и полностью вина бухгалтера.

Я просто не понимаю методологически в чем необходимость выплаты аванса уволенному?
Кажется что в этом случае бухгалтер бежит впереди паровоза и посчитал увольнение тому, кого увольнять еще было рано. Ну типа 10 июня прилетел приказ уволить 20 июня Иванова?
Так считать надо не когда приказ прилетел, а когда наступил день увольнения. Тогда и проблем с авансом никаких не возникает. До 20 июня столько всего произойти может...
С учетом 100500 разных настроек каждую из которых надо потом учитывать, поддерживать тестировать... я не сторонник добавления настроек которые поощряют методологический хаос :)

Может быть мы чего-то не видим и расчет увольнения сотруднику до наступления даты увольнения это хорошо?

для нас это такая же тайна как и для вас.
Осмелюсь предположить ревизоры еще не решили как они отреагируют.
Если форма реестра (печатная) утверждена банком, то самовольно странно ее менять. Может быть кто-то несет ее в печатном виде. Хочется увидеть новый формат от банка.

Если печатной формы реестра нет, наверное мы можем печатать какую-то упрощенную форму реестра.

Изменения готовим. Работе вроде бы это не должно сильно мешать.
Если вы подпадаете под действия закона, можете не платить.
Если вдруг не будете платить уже за май,. то после выхода поставки надо будет пересчитать май, сменив текущий месяц на май. Чтобы состояние в ЛС соответствовало тому что вы заплатили. Иначе потом будет путаница с тем сколько надо заплатить.

Не очень понятно в чем проблема выгрузить таблицу в dbf-файл и на другом месте сделать импорт из dbf-файла для объединения данных?

Юлия выкладывайте требования, если вам банк их передал.

проверим. исправим

Может быть проблему могла решить возможность делать свои ведомости? Заранее настроить на набор видов и сказать - вот эта ведомость всегда формируется с таким то КВН(КВД). Но в любом случае останется проблема с "выделением алиментов". В каждую ведомость алименты будут либо попадать всегда все начисленные к текущему моменту (что исказит картину в банке), либо их включать только в итоговую ведомость, что опять же будет "искажать" картинку... либо искусственно в качестве алиментов считать Х% от суммы (если конечно в ЛС мы найдем действующую строку алиментов).
Но тут тоже много вопросов:
* вообще-то алименты правильно рассчитывать по принадлежности, а тут мы точно будем считать по начислению.
* как-то надо свести "примерные" суммы алиментов рассчитванные в ведомостях как Х% с итоговой суммой начисленных алиментов в ЛС. А для этого как раз хорошо подходят idved (новый режим касс)

что от совместительства известно? Внешний код?
extCombine в параметры
Код видоизменить (в начало вставить):

FillDayTabel(&Dat1, &Dat2, &simv, &na_simv, extCombine )
{
   int IDCombine=ExtCombineToInt(extCombine);
   var tmp=CreateObject("TmpCurCombine");
   tmp.Init(IDCombine);
   

старый код...