![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Змеи, жабы и бухгалтерия.
Nov. 5th, 2007 01:32 amПериодически знакомые сисадмины всячески убеждают меня, что программирование бухгалтерии - это несерьезно, мол "это кто-угодно напишет на коленке" и вообще, "надо использовать 1С".
Объяснять им, что я освоил большую часть программерских заморочек, именно пытаясь нормально выразить бухгалтерские ужасы в виде программного кода, лень. Нормально - это значит, поддерживаемо в условиях, когда законодательство меняют вчера, бухгалтера звонят по выходным, а прокладываемые проводки сведут с ума любого аудитора.
Вот убил три дня на исправление алгоритма ведомости. Был простейший красивый алгоритм - фильтр на проводки в двух вариантах, сводящихся к двум-трем логическим функциям, группировка по счетам до заданного уровня в дереве и по кодам аналитики.
Если бы холера с трасцей и змеи в голове меня не дернули сделать обработку так называемых "транзитных" счетов с помощью неадекватных проводок. Неадекватных в таком плане:
Есть две проводки:
Д68/субсч1/код1 Ктранз +Сумма
Д68/субсч2/код2 Ктранз -Сумма
Такими проводками можно перебросить сумму с одного субсчета/кода аналитики на другой, не увеличивая обороты по счету в итоге. Соответственно, бухгалтера их всячески используют.
А у меня при импорте проводок транзитный счет исключается, и получается проводка: Д68/субсч1/код1(+) Д68/субсч2/код2(-). И вот эти проводки ВСЮ бухгалтерию ставят с ног на голову. Если счета в половинах проводки совпадают, это еще не так страшно - в большинстве случаев они друг друга закрывают, но вот при несовпадении возникают такие чудовищные змеи в алгоритмах, что просто мрак. Все логические функции фильтров учетверяются в размерах, таблицы истинности этих фильтров рисуются только обкурившись сушеными пауками, отображение этих проводок в бухгалтерских ведомостях требует потом объяснений по телефону бухгалтерам со ссылками на лямбда-исчисление, Секо Асахару и арахнофобию.
А правильно было бы изначально отказаться закрывать транзитные счета и импортировать их как есть - тогда правильно проложенные проводки закрылись бы сами при суммировании, а с остальными бы бухгалтера сами бы разбирались, как хотели. Но для этого все эти алгоритмы надо было проектировать и писать полгода-год, а не за месяц "срочно надо сделать".
Объяснять им, что я освоил большую часть программерских заморочек, именно пытаясь нормально выразить бухгалтерские ужасы в виде программного кода, лень. Нормально - это значит, поддерживаемо в условиях, когда законодательство меняют вчера, бухгалтера звонят по выходным, а прокладываемые проводки сведут с ума любого аудитора.
Вот убил три дня на исправление алгоритма ведомости. Был простейший красивый алгоритм - фильтр на проводки в двух вариантах, сводящихся к двум-трем логическим функциям, группировка по счетам до заданного уровня в дереве и по кодам аналитики.
Если бы холера с трасцей и змеи в голове меня не дернули сделать обработку так называемых "транзитных" счетов с помощью неадекватных проводок. Неадекватных в таком плане:
Есть две проводки:
Д68/субсч1/код1 Ктранз +Сумма
Д68/субсч2/код2 Ктранз -Сумма
Такими проводками можно перебросить сумму с одного субсчета/кода аналитики на другой, не увеличивая обороты по счету в итоге. Соответственно, бухгалтера их всячески используют.
А у меня при импорте проводок транзитный счет исключается, и получается проводка: Д68/субсч1/код1(+) Д68/субсч2/код2(-). И вот эти проводки ВСЮ бухгалтерию ставят с ног на голову. Если счета в половинах проводки совпадают, это еще не так страшно - в большинстве случаев они друг друга закрывают, но вот при несовпадении возникают такие чудовищные змеи в алгоритмах, что просто мрак. Все логические функции фильтров учетверяются в размерах, таблицы истинности этих фильтров рисуются только обкурившись сушеными пауками, отображение этих проводок в бухгалтерских ведомостях требует потом объяснений по телефону бухгалтерам со ссылками на лямбда-исчисление, Секо Асахару и арахнофобию.
А правильно было бы изначально отказаться закрывать транзитные счета и импортировать их как есть - тогда правильно проложенные проводки закрылись бы сами при суммировании, а с остальными бы бухгалтера сами бы разбирались, как хотели. Но для этого все эти алгоритмы надо было проектировать и писать полгода-год, а не за месяц "срочно надо сделать".
