Как бороться с ошибками при округлении

[Tony Green]

При сопоставлении проводок по подотчетным лицам можно придумать ситуацию, когда возникают ошибки округления и выражается это в возникновении лишних проводок по курсовой разнице.
Простой пример: основная валюта - RUR, вторичная - USD, курс 29 р за бакс. дата проводок одна и таже.
1. авансовый отчет на 100 USD
2. платеж из кассы на 2000 р.
3. платеж из кассы на 900 р.
При сопоставлении возникает проводка по курсовой разнице на 13 копеек, что не есть правильно.

в методе SettleEmployee класса EmplSettle_RU вместо решения проблемы вставлен вот такой веселый кусочек кода (SP3 CU1):

PHP код:

        // PTR 4204 Small coins, for future release
        /*
        if (debitCurDiff || creditCurDiff)
        {
        }
        */ 


где переменные debitCurDiff и creditCurDiff содержат ошибки округления...

ВОПРОС: Как правильно поступить с этими цифирками? Кидать на системные счета? Какие ещё могут быть варианты?

[BOAL]

Посмотрите как это сделано в сопоставлении по клиентам

CustVendSettle и CustVendSettle_Cust

Это сопоставление как должно быть и у персонала.
Счас в персонале жалкий сублимат, который что-то "автосопоставляет".

Оно в принципе и не нужно - можно написать курсовые разницы по персоналу отдельно.

Но если бухгалтера все же настаивают, чтоб в АО были суммы имено выданные под этот отчет, а не общая сумма долгов или вообще левые документы "за 2001год", то пишите сопоставление сами.

Для этого нужно просто откопировать весь набор таблиц и классов Cust, заменив его на Empl - если утрировано, то все

Данный (самописный) блок сопоставления я в свое время имел на ах2.5, но переносить его на ах30 не стали - повелись на "новое". А потом убедили бухов, что АО и без списка доков хорош.... и сопоставление по персоналу вообще не используется (пока... тфу-тфу-тфу...)

А потом появились АО по разным кассам... и "родное " сопостовление вообще не рассматривается, тк все одно переделывать полностью, если припрет.

ЗЫ Кусок кода особо порадовал - спасибо!

[Tony Green]

Сопоставление в расчетах с клиентами и поставщиками действительно монстровое
Этот механизм не очень хочется брать как основу для подражания, т.к. во-первых: он достаточно нетривиален и здоров по размерам, а во-вторых: часть этого механизма уже явно устарела и её можно не дублировать за ненадобностью - это значит, что тупым копированием дело не обойдется со всеми вытекющими... Я говорю о механизме формирования проводок по курсовым разницам, который использует такие понятия как реализованные и нереализованные курсовые разницы – их сейчас, насколько я знаю, уже достаточно давно не используют.
В подотчетниках все на порядок проще. Я попробую обойтись легкой модификацией класса EmplSettle_RU (метод SettleEmployee). На мой взгляд, этот способ выглядит гораздо менее трудоемким решением, чем дублирование структур таблиц модулей «Расчеты с клиентами/поставщиками» с соответствующими изменениями в классах...

PS: Также приложу максимум усилий, чтобы обойтись без формирования проводок на системные счета с суммами ошибок округления... от лукавого это все