УТ 10.3 Печать ЧекККМ, скидки, округление #772569

Появилась задача скидки прикрутить в ЧекККМ. Прикрутил. Стало интересно, как остальные это реализовывали. Постоянно натыкался примерно на вот такую реализацию. В обработке ТОСервер, модуль обработки: Функция ПечатьЧека(...             1,             СуммаСоСкидкой1С,             0, Ну и собственно вопрос. А что мешает сразу передавать нужную сумму и пусть фискальный регистратор сумму скидки сам считает печатает? Т.е. примерно так: В драйвере соответственно просто брать переданную сумму (Позиция.Сумма) и ни чего не пересчитывать. Плюсы от такого решения вижу как минимум следующие: - в печатной форме рисуется количество равное реальному, а не 1; - отображается реальная цена; - отображается реальная стоимость без скидки; - отображается сумма скидки в рублях и копейках. Какие минусы?

А в ответ тишина.... Может непонятно вопросы задал, что-то пояснить...

Специалистов нет сегодня....

Телепатов, скорее. Если у тебя СуммаСоСкидкой1С не совпадает с СуммаСоСкидкойФР, только тогда ты идешь по второй ветке, а иначе, в большинстве случаев, по первой. Это делается для того, чтобы расхождения 1С с ФР отловить до начала печати.

А если передавать сразу сумму, то не с чем расходиться. Не пойму что ловить. Максимум что будет, это скидка наценка величиной в +-0.01 рубль. Ну с точки зрения фискального регистратора так и есть. И это только в том случае если в 1С округление НЕ совпадает с округлением в фискальном регистраторе. Если же совпадают, то такого никогда не будет.

Ну и будет при несовпадении табличка, что данные 1С расходятся с данными ФР. Оно кому надо? Если есть такое страшное желание, передавай в эту функцию всегда нулевую скидку, а цену пересчитывай. И будет как ты хотел. Тогда в печатной форме никакой скидки не будет, а будет цена уже со скидкой.

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

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

Понятно. Если объяснений нет, то это значит так исторически сложилось. Я нашел объяснение. Например для АТОЛ ранее функция печати чека передавала цену количество и скидку. Сейчас цену количество и сумму с учетом скидки. Соответственно у кого какая версия драйвера. У Штихов в старых версиях драйвера могла возникать ошибка вида "Сумма всех типов оплаты меньше итога чека" за счет округления. На текущей версии драйвера эта ошибка не возникает нет. Проверял только что на почти последней 4.12.0.439 с цифрами на которых возникало у народа. По сему если версия драйвера нормальная, то в рабочем месте кассира надо по умолчанию округление как в ФР, т.е. математическое округление (не знаю есть ли ФР с настраиваемым округлением) и расхождений никогда не будет. И скидка наценка будет возникать только там где она физически есть. Если есть противоположные доводы, рад буду услышать.