Отсутствие корреспонденции при наличии округления

[KiselevSA]

Версия DAX 4.0 Kernel: 4.0.2501.116 Application: 4.0.2501.122
При разноске закупки, по которой возникли округления (цены и стоимости тянутся в строки закупки из другого источника, а не вводятся вручную), с завидной постоянностью создаются неоткорреспондированные проводки. Счет учета округлений настроен в системных счетах.
Самое простое решение - округлять значения при вставке в строки. Но может быть кто-нибудь подскажет, где искать кривой код или настройку.

[b_nosoff]

Происходит это потому, что проводка округления создается только с суммой в основной валюте, в то время как валютная сумма равна нулю. Кривой код, как мне кажется, в LedgerBondServer_RU.addBondMSTDiff(). Непонятно, какой был смысл вложен в нулевую валютную сумму...

[RVS]

Цитата:

Сообщение от b_nosoff

Происходит это потому, что проводка округления создается только с суммой в основной валюте, в то время как валютная сумма равна нулю. Кривой код, как мне кажется, в LedgerBondServer_RU.addBondMSTDiff(). Непонятно, какой был смысл вложен в нулевую валютную сумму...

Даже ненулевая сумма в валюте не всегда спасет. Пример: округление в валюте компании (рубль) = 0.0001 коп. Чему равно округление в долларах?

Цитата:

Сообщение от KiselevSA

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

И оно, похоже, правильное. Все, как в реальной жизни. Хотя - и тут возможны грабли, с частичными поставками - оплатами...

[b_nosoff]

Цитата:

Сообщение от RVS

Даже ненулевая сумма в валюте не всегда спасет. Пример: округление в валюте компании (рубль) = 0.0001 коп. Чему равно округление в долларах?

Я не говорил, что надо делать пересчет из одной валюты в другую. Я бы, например, брал непосредственно ошибку округления в валюте.

Цитата:

Сообщение от belugin

А можете ситуацию смоделировать?
Конкретные шаги для воспроизведения?

У нас в закупке смоделировалось чисто случайно:
10.0100 168338,75
10.0800 347,46
19.0600 30363,50
60.0101 -199049,70

[RVS]

Цитата:

Сообщение от b_nosoff

Я не говорил, что надо делать пересчет из одной валюты в другую. Я бы, например, брал непосредственно ошибку округления в валюте.

Вы поругали Аксапту, сказав, что не понимаете, почему валютная сумма в проводке нулевая.
Я сказал, что даже если она и будет ненулевая - возможны ситуации, когда это не спасет.

Цитата:

Сообщение от b_nosoff

У нас в закупке смоделировалось чисто случайно:
10.0100 168338,75
10.0800 347,46
19.0600 30363,50
60.0101 -199049,70

Если честно, не понял, что это... Чуть подробнее, с расшифровкой - кто есть who - можно?

[b_nosoff]

Цитата:

Сообщение от RVS

Вы поругали Аксапту, сказав, что не понимаете, почему валютная сумма в проводке нулевая.

Я, может быть из-за недостаточного своего опыта, считаю проводки с неуказанной валютной суммой неправильными. При текущей реализации механизма обработки расхождений других проводок не генерируется. Механизм корреспонденции рассчитан на совпадение обеих сумм (валютной и MST). И на мой взгляд есть два выхода - либо исправить механизм обработки расхождений, либо мириться с неполным ручным сопоставлением проводок.

Цитата:

Сообщение от RVS

Я сказал, что даже если она и будет ненулевая - возможны ситуации, когда это не спасет.

Лично к вам у меня претензий не было. Извините, что заставил вас оправдываться. И абсолютно с вами согласен, что возможно всё.

Цитата:

Сообщение от RVS

Если честно, не понял, что это...

Это проводки в ваучере по накладной. Сумма дебетовых больше кредитовой на одну копейку. Эта копейка и является ошибкой округления.

Цитата:

Сообщение от belugin

тут либо валюты надо указать с курсами, либо не балансирует, либо я чего-то не понимаю

извиняюсь, забыл указать проводку по расхождению Z000.40 -0,01

[belugin]

А можете ситуацию смоделировать?
Конкретные шаги для воспроизведения?

[belugin]

тут либо валюты надо указать с курсами, либо не балансирует, либо я чего-то не понимаю

[KiselevSA]

Я понимаю, что некоторые торгуют и покупают только штуками с круглой ценой. Но предположите ситуацию, когда есть плановая сумма закупки, которая рассчитывается от суммы продажи по обратной рентабельности, например, в 30%. А фактическая стоимость закупки фиксируется как плановая плюс отклонение факта от плана.
Системный EDT Amount имеет приличную размерность в десятичных знаках и отображает 12 из них, а вот EDT AmountCur может быть настроен, например, на отобржение только 2 знаков после запятой.
Как повторить ошибку? Попробуйте с помощью SQL указать в LineAmount сумму с множеством знаков после запятой. Обработайте накладную. Думаю вы получите тот же результат, что и у меня. "Тупит" именно корреспонденция, т.к. при международной функциональности просто создается проводка по счету ошибок округления без поиска "второй" половины.

[belugin]

Есть ли возможность воспроизвести ситуацию в рамках стандартного функционала?

[KiselevSA]

Цитата:

Сообщение от belugin

Есть ли возможность воспроизвести ситуацию в рамках стандартного функционала?

Я думаю, что можно. Для этого придется у EDT AmountCur увеличить количество знаков после запятой. А вот порядок округления в валюте оставить прежним (общее округление и округление по покупке). Протестировать сейчас не могу.

[belugin]

под стандартным функционалом я имею ввиду немодифицированное приложение

[KiselevSA]

Цитата:

Сообщение от belugin

под стандартным функционалом я имею ввиду немодифицированное приложение

1. В региональных настройках компьютера установить для чисел четыре знака после запятой;
2. В округлениях для валюты в Аксапте установите общее округление и округление закупки до двух знаков.
3. Создайте закупку и в строке закупки для суммы установите сумму с четвертым знаком после запятой (для немодифицированного приложения для AmountCur установлено кол-во знаков Auto, т.ч. четыре знака должно быть доступно).
4. Проведите разноску.
Думаю, что Вы отловите ошибку (проверить в офисе перечисленную последовательность не могу).

[RVS]

Цитата:

Сообщение от KiselevSA

Думаю, что Вы отловите ошибку (проверить в офисе перечисленную последовательность не могу).

Извините. Но это вы - думаете...

Дайте живую последовательность действий, при которых ситуация гарантированно воспроизводится.

До этого - вряд ли кто-нить этим подробно заниматься будет

[b_nosoff]

Наконец-то поймана

Есть закупка на 210 единиц некой номенклатуры по цене 19,57.
Поставщик выписал накладную на сумму 4110,17.
Закупка маркирована с продажами на количества 21 + 44,1 + 47 + 11 + 2,9 + 84.
И аксапта при подсчете суммы по складским проводкам получает 4110,18

[b_nosoff]

На мой взгляд есть два пути решения: либо сломать проверку корреспонденции, чтобы она проверяла только на остаток в основной валюте (но тогда будут отклонения в валютных суммах), либо все таки писать валютную сумму в проводку с отклонением (что работает, и мне кажется правильным).

[belugin]

А можно все-таки получить список проводок до корреспонденции с параметрами:
- валюта проводки
- основная валюта
- вторичная валюта

для каждой проводки:
- счет
- суммы в этих валютах

и, как я понимаю, ошибка возникает при обработке накладной поставщика?

[b_nosoff]

Цитата:

Сообщение от belugin

А можно все-таки получить список проводок до корреспонденции с параметрами:
- валюта проводки
- основная валюта
- вторичная валюта

для каждой проводки:
- счет
- суммы в этих валютах

Валюта проводки и основная валюта - рубли. Вторичной нет.

Цитата:

Сообщение от belugin

и, как я понимаю, ошибка возникает при обработке накладной поставщика?

именно так

UPD: на текущий момент мы выбрали второй вариант, т.е. указание валютной суммы в проводке с отклонением.

[belugin]

А если отключить корреспонденцию, такое разносится? По-моему тут проблема не в корреспонденции, а в том, что в валюте проводки суммы не балансируют - может, надо просто поправить алгорим распределения сумм при обработки маркировки, чтобы ошибка округления отнеслась на одну из проводок?

[b_nosoff]

Цитата:

Сообщение от belugin

А если отключить корреспонденцию, такое разносится?

разносится. Только потом и ручной корреспонденцией ничего не добиться - копейки так и мешают.

Цитата:

Сообщение от belugin

По-моему тут проблема не в корреспонденции, а в том, что в валюте проводки суммы не балансируют - может, надо просто поправить алгорим распределения сумм при обработки маркировки, чтобы ошибка округления отнеслась на одну из проводок?

Я даже могу указать на источник зла это вычисление суммы по проводке в методе UpdateNow класса InventUpd_Financial

this.parmCostAmountCur(Currency::amount(saveCostAmount * transQty / financial));

тут-то он и наворачивает копейки по округлению на товарный счет.

Не знаю даже, есть ли смысл тут пытаться сломать...

UPD: похоже источнег зла - модификация интегратора...