УТ - расчет чека от суммы, а в ККМ - от цены #798886

В чеке 4 штуки по 290,00 рублей предоставлена скидка 70,18% итого 345,91 в ККМ рисует цену 86.48 умножает на 4 сумма = 345.92 в итоге итог по чеку на 2 копейки больше, чем получено наличных это нормально?

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

согласно "Требования к разработке драйверов подключаемого оборудования." и описанию структуры CheckPackage твоя строка в XML должна выглядеть так Price - Цена единицы товара без учета скидок/наценок Amount - Конечная сумма по позиции чека (с учетом всех скидок/наценок) Если строка в XML выглядит по-другому, отлаживай. Какой релиз УТ?

тогда такой вопрос - если строка выглядит не так чем это черевато?

если вместо 220 включил в 380 - чем чревато? Отлупом...

как это "отлуп" проявляется? - где смотреть?

ибо - клиент деньги заплатил, фискальник чек напечатал что делать... что делать?

отлаживай. Если строка выглядит по-другому, отлаживай УТ. Какой релиз? Если совпадает, пиши в поддержку этого оборудования. Вероятно не соблюдается стандарт. Какой модели ККТ?

да поотлаживаю ... УТ 11.3.3.145 мне интересно - а какие последствия? - где смотреть что у нас все плохо - где флаг кторый показывает, что с кассой что-то не то творится

в чеке скидки напечатаны 4х86.48=345.92 скидка 814.09 возврат (делал чек для примера) 4х86.48=345.92 скидка 0.01 на ОФД чеки эти есть проблема в том, что итог по чеку в ККМ на две копейки больше, чем посчитала УТ - денег взяли с пациента на две копейки меньше соответственно у кассира недостача переписывать алгоритм расчета итога? или? т.е. сейчас в УТ берем сумму, делим на количество - получаем цену - все а надо получить цену, округлить её до копеек, и пересчитать сумму еще раз - цена * количество ?

а чек выбился на 9561.80

Я тожк сталкивался с такой проблемой и решил ее так. Все строки в чеке передаю обычным текстом. И в конце посылаю количество = 1 и общую сумму документа. В результате ККМ ничего не вычисляет. Данные все идут.

Примерно так ПечатьСтроки("Хлеб 2 х 50, Скидка 10%", Сумма = 90); ПечатьСтроки("Схара 1 х 300 = 300"); ПечатьЧека(1,390);

О, как вывернулся... Молодец!

- я не думаю, что УТ выдает что-то не так, поэтому - пока не смотрел что она там в ККМ шлет но вот то, что УТ считает от суммы, а ККМ пересчитывает от цены - это вроде как факт никто не сталкивался с таким ? у всех всегда чек по суммам сходится?

и что у тебя в ОФД после этого?

9561.80

самое интересное - нет отказа по тому, что сумма оплаты меньше суммы чека

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

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

вопрос - как правильно исправить переписывать УТ - сделать расчет от цены?

Мы пока в ККТ считаем скидку о суммы, а не от цены.

+ для розницы там обход этой ситуации в ответе 9

эта эбота от фирмы 1С. во всех конфах так сикдка считается и не правильность этого алгоритма проявилась с появлением фз 54

а в этой последней строке как номенклатура называется? а то как бы это обязательный теперь реквизит

да не сходится конечно.. изворачиваемся.

как то так:

вопрос еще - как отловить программно такие чеки ибо на пользователей надеяться ... "все врут" по сути вроде как есть электронный чек который должен/может хранится в базе для последующей отправки покупателю

по идее офд должен отправлять чеки покупателю. Если вы сами будете отправлять, то это будет туфта.

а я не за пересчёт скидки от цены, а за деление товара на 2 строки: 1) 50.02 руб, 2) 50.03

так сложнее

это не сработает если весовой товар.

это как посмотреть. Я бы на первое время вставил костыль в момент формирования XML CheckPackage, чем разбираться в механизме автоматических, ручных скидок и их пересечении.

аналогично

хотите сказать CheckPackage невозможно скорректировать под весовой товар?

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

и куда там костыль вставлять?

я бы как-то заранее преобразовал массив ОбщиеПараметры.ПозицииЧека. Процедура ПолучитьXMLПакетДляФискализацияЧека оставил без изменения. судя моей логики, надо разбивать на 133 и 1 грамм с разными ценами - похоже больше на бред)))

в вы писали про ответ 9. это мой ответ. так вот в нашей столовой есть эти самые окорочка  и весят они как правило меньше кг. но ошибки не было еще ни разу с ними связанными. есть подозрение что тут высокая математика кроется, для дробных количеств меньше 1 как раз не бывает этой ошибки в 1 копейку.

в цене вроде как передается цена без скидки сейчас т.е. фискальник сам высчитывает "значения реквизита «цена за единицу предмета расчета с учетом скидок и наценок» (тег 1079)," потом округляет и считает "Значение реквизита «стоимость предмета расчета с учетом скидок и наценок» (тег 1043)" т.е. что передать фискальнику что бы было правильно?

передать надо так что бы сумма деленная на количество давала число с (ровно) 2-я знаками.

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

посмотри тут цена передаётся без скидки, всё верно

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

Учитывай ещё автоматические скидки. Сегодня их нет, завтра появились. Реализуя правку на уровне пакета CheckPackage получится универсальное решение, которое подойдёт для всех конфигураций этой версии БПО.

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

само собой, только для штучных товаров.

и изменение суммы в драйвер фискальника внесли, чтобы не выдавать ошибку по условию расхождения суммы от произведения на больше чем 1 копейку вместо отказа, фискальник просто исправляет "Значение реквизита «стоимость предмета расчета с учетом скидок и наценок» " как бы правильное решение - нет остановки кассы просто чек не сходится с внешним калькулирующим устройством и да - наверное проверка и корректировка путем разбиения на две строки именно внутри этого условия будет более правильной

а разве не наоборот, чтобы количество * цена и округлить до 2х знаков равнялось бы сумме?

но у нас есть и дробное количество - будет ли оно попадать в ошибки? - как его корректировать?

вот поэтому мы откатили на версию драйвера, при которой скидка считается от суммы, а не от цены. Да, с некоторого времени так будет делать нельзя, но ждём реализации на уровне 1С или ПО ККТ

типа так?

не уж-то вам хочется ломать функцию ПолучитьXMLПакетДляФискализацияЧека? Ну создайте отдельный модуль, передавайте параметром всю структуру ОбщиеПараметры и там уже обрабатывайте массив структур ОбщиеПараметры.ПозицииЧека по реализации ничего не скажу, тестируйте, отлаживайте)

Пофиксили, описал тут