|
![]() |
#1 |
Участник
|
Нашлось ли решение ошибки? Мучаюсь с такой же. Отладчик закипает
![]() |
|
![]() |
#2 |
Участник
|
Проблема как мне кажется выявлена.
Суть в том, что без этой модификации при наличии разницы округления добавляется запись в LedgerTrans с суммой погрешности установленной только в основной валюте! Т.е. валюта операции в проводке по округлению (LedgerTrans.AmounrCur) нулевая (как видно из начала поста). При этом основные проводки в ГК (т.е. тот набор, что делается обычно без проводок по 99.99 счету округления) идут в двух суммах AmountCur и AmountMST. На практике это выливается в то, что метод класса LedgerBondServer_RU addCheckBalance() X++: protected void addCheckBalance(LedgerTrans _ledgerTrans, Sign _sign = 1) { void addKey(TransDate _transDate, CurrencyCode _currencyCode, Amount _amount) { str key = strfmt("@SYS76785", _transDate, _currencyCode); if (balanceMap.exists(key)) { balanceMap.insert(key, balanceMap.lookup(key) + _amount); } else { balanceMap.insert(key, _amount); } } if (! balanceMap) { balanceMap = new Map(Types::String, Types::Real); } addKey(_ledgerTrans.TransDate, _ledgerTrans.CurrencyCode, _ledgerTrans.AmountCur * _sign); addKey(_ledgerTrans.TransDate, mstCode, _ledgerTrans.AmountMST * _sign); addKey(_ledgerTrans.TransDate, mstSecondCode, _ledgerTrans.AmountMSTSecond * _sign); } Решение - либо менять алгоритм наполнения и проверки balanceMap (ключ делать разный для валюты операции и основной валюты), либо заносить (при совпадении этих валют) в проводку по округлению значение суммы в валюте операции. Что и было сделано в первом сообщении поста. Остается только нюанс. Может еще нужна проверка на совпадение валют? Просто не помню и неохота разбираться, в описанном случае может быть ситуация, когда основная валюта и валюта операции не совпадут и тогда суммы по округлению могут быть разные... Последний раз редактировалось Romb; 19.04.2013 в 03:32. |
|
![]() |
#3 |
Британский учённый
|
Вот еще какая может быть причина
Цитата:
One possible cause of this issue is the duplication of number sequences. In Project management and accounting, there are separate number sequence setups available for On-Account Invoice, Invoice, On-Account Credit Note and Credit Note document types. If the number sequences are not uniquely defined, in the posting process, when the records are fetched from the projProposalJour\ProjInvoiceJour it is possible that posting a credit would fetch the corresponding invoice with the same number sequence and vice versa. This would then result in a situation where the merger of the documents results in an out of balance transaction, and then you would receive the error: "The transactions on voucher xxxxxxx do not balance as per xx/xx/xxxx. (Company currency: -x.xx - secondary currency: x.xx)".
To resolve this issue, you have a few options: 1.Uniquely define the number sequences with a character segment specific to each document type. 2.Use the same number sequence for the document types. 3.You could also resolve the error by bumping up the next number to something that would not be a duplicate. However, this would be a temporary solution as you would likely run into the error in the future on other documents.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|