Да нету у них квалификации, чтобы во всех хитросплетениях разобраться.

Если у них нет квалификации спрятать минусы, то с такими бухгалтерами и подавно применять автоматическое сокрытие минусов опасно, так как именно такие бухгалтера любят сказать "это не мы виноваты, это программа".

На мой взгляд нужно сперва объединять по сроку уплаты 120й строке и по типу доходов 100й строке. Затем между собой то, что осталось, пока не избавимся от минусов окончательно.

Осталось дело за малым. Попасть в Думу или Минфин и оформить свой взгляд хотя бы в виде Письма Минфина.

171-ый вид. 4-ый столбец специальной таблицы входимости. Стоит 2 "Не пересчитывать рабочее время если оно уже было заполнено". Поэтому и не пересчитывается.

int Flags=CL_SOURCE|CL_MV|CL_M

Настройка -> 4.  Настройки параметров расчета -> 4. >>> Настройки для больничных -> 1. Настройки расчета больничного листа -> Вид панели параметров больничного - поставить 1

GetShifrZatrSumIC(code,absm) или GetShifrZatrSumC1(row,absm)

code - внутренний код вида (полный), absm - абсолютный месяц для которого хотим вычислить ШЗ для этого вида.

Только если расчетчики уже независимо "нафигачили" должностей у себя в базах, то при переносе справочника от одного расчетчика другому "дворник" неожиданно может стать "начальником". Справочник то другой, а в кадровой части скорее всего у вас сейчас сохраняется ID штатной единицы. После подмены справочника эта ID может начать соответствовать совсем другой штатной единице.

В частности поэтому есть смысл уйти от старого форума. Слишком долго приходится ждать, пока его "поднимут". 

З.Ы. Но мы специально не роняли :)

Скорее всего, такое рукоблудие отследит появившаяся в 597.13 проверка файла по xsd-схеме ФНС (в меню действия с отчетом будет доступен пункт "проверить отчет")