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

Я просто не понимаю методологически в чем необходимость выплаты аванса уволенному?
Кажется что в этом случае бухгалтер бежит впереди паровоза и посчитал увольнение тому, кого увольнять еще было рано. Ну типа 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);
   

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

Игорь, как вы себе представляете разбивку обезличенной суммы в кассе по КВН если не включен "новый режим кассовых ведомостей"? Это уже даже не зачатки ИИ, это полноценный оракул должен быть.
Если не включен режим новых ведомостей - каждую ведомость формируете отдельно на каждый вид дохода. Либо программа должна при подготовке кассовых ведомостей сделать такую разбивку.
Только "приблизительность" в кассовых ведомостях она дороже стоит, чем "приблизительность" в банковских таблицах. Потому что кассовые ведомости вообще-то "кассу" в ЛС генерят и проводки соответствующие.

Во-первых не факт что люди хотят видеть "кассы" по КВД в ЛС, во-вторых не факт что бухгалтера вот так сразу готовы мыслить с разбивкой выдачи в рамках КВД. И я сомневаюсь что им сильно про это надо думать. Это не для бухгалтера нужно, это нужно банкам.

В общем я пока не очень понимаю какой волшебный механизм вы ждете от нас без использования "нового" режима ведомостей.