Округление чека

[Alexander]

Это техническая проблема, диктуемая 54-ФЗ (разрешающим отброс копеек) и КоАП РФ (запрещающим отступление от госрегулируемых цен на определенные категории товаров).
Чтобы строго блюсти КоАП, нельзя округление применять, как скидку (то есть нельзя влиять на итоговую цену товара).
В товароучетном ПО, к сожалению, игнорируется эта ситуация.
Но для кассы тут все строго соответствует текущему законодательству.

[Troglodit]

Я не про цены. Я про ваше же поле 13 в транзакции 11.
Там уже сумма по позиции со скидкой.Если нельзя в него,в другое,отдельное поле, раз по другому не получается.
Главное, чтобы сумма этих полей была равна сумме чека как в кассе,так и в КИС, и построчно также чтобы совпадали и в кассовом ПО и КИС, а сейчас это не так.

[Alexander]

Главное, чтобы сумма этих полей была равна сумме чека

Так я про то и говорю, что она не может совпадать в случае отброса копеек.

[Troglodit]

Я говорю лишь, что если например для 11-й транзакции в поле 19 будет отброшенные копейки никакого нарушения не будет.
при этом данную выгрузку можно загрузить в exel и по сумме транзакций 11 получить и сравнить с бумажной лентой, если вдруг что пошло не так.
Просто когда одно рабочее место работает или большой наплыв покупателей непонятно, то ли округление или это мелкий чек не учелся. Проверять каждый раз очень долго.

[Alexander]

А чем проверка по 55-й транзакции не угодила? Там точная сумма чека с учетом округления. Если по ней обнаружено расхождение - можно уже углубляться в 11-е транзакции.

[Troglodit]

1. Во первых транзакция может быть 56 при реально пробитом чеке,
возникает когда программа не понимает что чек прошел, тогда чтобы не потерять позиции, чек отменяется, код транзакции корректируется при загрузке в КИС.
2.Мне кажется это логично, я уже писал выше когда на входе и выходе в разных системах одни и те же данные, а не так как сейчас. В чеке 50, в дэнси 50,5 в КИС 50.
Я не настаиваю, нет так нет, сделаю костыли.