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

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

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

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

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

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

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

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

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

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

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

Это замечтельно, что вы знаете php.
Форум расположен на площадке userecho и может быть модифицирован с применением пользовательских инструментов, которые предоставляет userecho. Я не заметил среди этих инструментов возможности внесения изменений в исходники форума.

Для тех кто "минусит" это сообщение Николая,  ссылка на первоисточник: ответ Роструда