Розница 2.3.18.13, ошибки разрешительного режима и все с этим связанное
Здравствуйте, имеем на текущий момент Розницы 2.3.18.13, с последними патчами, выставленной датой разрешительного режима, включенными режимами проверок и всем остальным. Сигареты сканируются, проверки идут, но по итогу в Честном знаке ошибки связанные с разрешительным режимом продолжают накапливаться. Это у всех так? Возможно ли дело в кассовых аппаратах Атол, что там какой то особенный тег появился?
Найденные решения
(46) заменил ЗаписьXML.ЗаписатьАтрибут("WaitForResult", ?(ПараметрыОперации.ОжидатьПолучениеОтветаОИСМ, "True", "False"));
на ЗаписьXML.ЗаписатьАтрибут("WaitForResult", "True");
теперь атол принудительно проверку делает, и в чеках м+
на ЗаписьXML.ЗаписатьАтрибут("WaitForResult", "True");
теперь атол принудительно проверку делает, и в чеках м+
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(196) Спасибо, проверим
По поводу тега 1260, вот нашел на сайте ЧЗ:
Значения реквизитов, входящие в реквизит «отраслевой реквизит предмета расчета» 1260, имеют значения по умолчанию:
Значение реквизита «идентификатор ФОИВ» (тег 1262): 030;
Значение реквизита «дата документа основания» (тег 1263): 16.06.2022;
Значение реквизита «номер документа основания» (тег 1264): 174;
Значение реквизита «значение отраслевого реквизита» (тег 1265): crpt=mrk;
По поводу тега 1260, вот нашел на сайте ЧЗ:
Значения реквизитов, входящие в реквизит «отраслевой реквизит предмета расчета» 1260, имеют значения по умолчанию:
Значение реквизита «идентификатор ФОИВ» (тег 1262): 030;
Значение реквизита «дата документа основания» (тег 1263): 16.06.2022;
Значение реквизита «номер документа основания» (тег 1264): 174;
Значение реквизита «значение отраслевого реквизита» (тег 1265): crpt=mrk;
Добрый день! Подскажите, пожалуйста, как исправить: если откладываем чек, то при его продолжении коды маркировки запрашивает снова (раньше откладывали и потом пробивали без проблем)... Ситуация, например, такая, очередь... пробиваем несколько упаковок воды, у покупателя не хватает денег..... откладываем чек, пока он ходит за другой картой, чтобы обслуживать дальше.... он возвращается, и приходится всю маркированную продукцию сканировать снова....в итоге, злая очередь, недовольный покупатель ...
Такая же фигня. На УТ 10.3. Разрешительный режим запущен, токен записан, прописаны площадки CDN, и прочие параметры. Проверка идёт при сканировании. А на чеке [М]. В ОФД ссылочка на чек(и), якобы не получен ответ от ЧЗ и т.д.. В ЧК ЧЗ всё отражено и обработано. Но есть отклонения "Продажа товара без проверки КМ".
фрагмент чека в TLV
1059": [
{
"1023": 1,
"1030": "Максим Серая пачка (лайт) МРЦ-100-00",
"1043": 14000,
"1079": 14000,
"1163": {
"1306": "010460165303005321r5Yn5KY"
},
"1199": 6,
"1212": 31,
"1214": 4,
"1260": {
"1262": "030",
"1263": "21.11.2023",
"1264": "1944",
"1265": "UUID=49d9831e-b2ee-44f2-8783-df1d9f59d9e0&Time=1712743594644"
},
"2102": 0,
"2106": 0,
"2108": 0
*****************************
фрагмент чека в JSON
"Items": [
{
"Name": "Максим Серая пачка (лайт) МРЦ-100-00",
"Price": 14000,
"Quantity": 1,
"Total": 14000,
"CalculationMethod": 4,
"SubjectType": 31,
"ProductCode": {
"Code_KMK": "010460165303005321r5Yn5KY"
},
"NDS_Rate": 6,
"ProductCheckResultDetails": 0,
"ProductUnitOfMeasure": 0,
"IndustryPropertyFOIV": "030",
"IndustryPropertyDocDate": "21.11.2023",
"IndustryPropertyDocNumber": "1944",
"IndustryPropertyValue": "UUID=49d9831e-b2ee-44f2-8783-df1d9f59d9e0&Time=1712743594644"
1059": [
{
"1023": 1,
"1030": "Максим Серая пачка (лайт) МРЦ-100-00",
"1043": 14000,
"1079": 14000,
"1163": {
"1306": "010460165303005321r5Yn5KY"
},
"1199": 6,
"1212": 31,
"1214": 4,
"1260": {
"1262": "030",
"1263": "21.11.2023",
"1264": "1944",
"1265": "UUID=49d9831e-b2ee-44f2-8783-df1d9f59d9e0&Time=1712743594644"
},
"2102": 0,
"2106": 0,
"2108": 0
*****************************
фрагмент чека в JSON
"Items": [
{
"Name": "Максим Серая пачка (лайт) МРЦ-100-00",
"Price": 14000,
"Quantity": 1,
"Total": 14000,
"CalculationMethod": 4,
"SubjectType": 31,
"ProductCode": {
"Code_KMK": "010460165303005321r5Yn5KY"
},
"NDS_Rate": 6,
"ProductCheckResultDetails": 0,
"ProductUnitOfMeasure": 0,
"IndustryPropertyFOIV": "030",
"IndustryPropertyDocDate": "21.11.2023",
"IndustryPropertyDocNumber": "1944",
"IndustryPropertyValue": "UUID=49d9831e-b2ee-44f2-8783-df1d9f59d9e0&Time=1712743594644"
(202) Насчет [М] и [М+] ЧЗ сказал что все равно что пишет, [М+] это отголосок уведомительного режима, когда касса проверяет марку.
Насчет тайм-аута попробуйте установить больше времени "ожидание ответа от ГИС МТ" по умолчанию там стоит 1.5 сек
Не знаю как в УТ10.3, но в Розницах и УТ11.5 в подключаемом оборудовании в журнале операций нужно поставить галку "хранить успешные операции при разрешительном режиме", было обсуждение в телеграмме насчет таких чеков. И было сказано что проверке нужно будет показать что проверка была, но от серверов ГИС МТ не было получено ответа.
Насчет тайм-аута попробуйте установить больше времени "ожидание ответа от ГИС МТ" по умолчанию там стоит 1.5 сек
Не знаю как в УТ10.3, но в Розницах и УТ11.5 в подключаемом оборудовании в журнале операций нужно поставить галку "хранить успешные операции при разрешительном режиме", было обсуждение в телеграмме насчет таких чеков. И было сказано что проверке нужно будет показать что проверка была, но от серверов ГИС МТ не было получено ответа.
Доброго дня, при пробитии товаров в 1с РОзница 2.3, не проходит проверка кодов, после настройки разрешительного режима, на чеке печатается (м), хотя в честном знаке товар списывается, в чем может быть проблема, дравера кассы атол обновлены до последней версии
(203) Смотрите в офд теги 1260-1265, а так же скачивайте чек из ЧЗ и смотрите передается туда данные теги. Прошивка АТОЛ должна быть 5.8.1 а дальше все равно и драйвера 10.9.3.1 так как интеграционная компонента 10.9.3.1. Насчет М в чеке можете почитать ответы там был ответ насчет что при РР хватает в чеке М.
у меня есть кассы с прошивкой 5.8.1.20 и 5.8.1.100 все передается.
у меня есть кассы с прошивкой 5.8.1.20 и 5.8.1.100 все передается.
EF_00_00622672: Обычная: Ошибка инициализации модуля: EF_00_00622672 ОбщийМодуль.ОборудованиеЧекопечатающиеУстройстваРФКлиентСервер.Модуль
по причине:
{EF_00_00622672 ОбщийМодуль.ОборудованиеЧекопечатающиеУстройстваРФКлиентСервер.Модуль(37,10)}: Недостаточно фактических параметров (EF_00_00622672_КодЕдиницыИзмеренияПоККТКоду)
Возврат <<?>>EF_00_00622672_КодЕдиницыИзмеренияПоККТКоду();
[ОшибкаКомпиляцииВстроенногоЯзыка]
Вот такая ошибка
по причине:
{EF_00_00622672 ОбщийМодуль.ОборудованиеЧекопечатающиеУстройстваРФКлиентСервер.Модуль(37,10)}: Недостаточно фактических параметров (EF_00_00622672_КодЕдиницыИзмеренияПоККТКоду)
Возврат <<?>>EF_00_00622672_КодЕдиницыИзмеренияПоККТКоду();
[ОшибкаКомпиляцииВстроенногоЯзыка]
Вот такая ошибка
Бью пиво, 7 литров на остатке. Продаю 6. Следующий чек опять 6 литров, ну думаю сейчас касса блокирует продажу, остаток по марке литр должен быть, и выбить лишнего касса не даст. Хрен там, никакого блока, да и остаток по марке смотрю те же 7 литров, ничего не уменьшилось. Оказалось закончилось время 10-и часового токена. Актуализировал. Сразу всё ок, остаток литр. Вообще не могу понять как всё это работает, и для чего тогда вообще нужен токен из ЧЗ.
Вчера настраивал розницу + патчи с кассой штрих. В итоге там все чеки с [м+]. Никаких доп настроек. Так же настроено по этой ссылке
Кто-нибудь добился такого же результата на атол?
Такое ощущение, что это косяк прошивок атол.
Кто-нибудь добился такого же результата на атол?
Такое ощущение, что это косяк прошивок атол.
Прикрепленные файлы:
Добрый день!
Розница редакция 2.3 (2.3.18.17)
Разрешительный режим включен, проверка проходит в журнале код 200 и вся нужная информация, печатаются чеки с М+, данные есть в ЧЗ.
Но все чеки без тега 1260... И соответственно копятся отклонения
Куда копать, почему он не берет данные из проверки и не вставляет их в тег 1260.
ККТ Штрих
Розница редакция 2.3 (2.3.18.17)
Разрешительный режим включен, проверка проходит в журнале код 200 и вся нужная информация, печатаются чеки с М+, данные есть в ЧЗ.
Но все чеки без тега 1260... И соответственно копятся отклонения
Куда копать, почему он не берет данные из проверки и не вставляет их в тег 1260.
ККТ Штрих
(221) Меня тоже раньше интересовал этот вопрос, только всё было почти наоборот. Разрешительный режим активен, проверки в журнале или false или вообще ничего нет. Чеки (М), в ЧЗ всё ровно. Отклонений нет, тег 1260 присутствует.Задал им вопрос по этому поводу. Ответили что (М+) при РР не обязателен.
(220) При РР не важно будет стоять [М+] или будет [М], [М+] - это отголосок УР. Ответы ТП ЧЗ насчет М и М+ главное что бы теги 1260-1265 передавались, если хотите что бы печаталась М+ в этой теме на первой странице есть расширение которое даст возможность печатать М+.
(229) Ответ был дан и ЧЗ и самими разработчиками которые бывают в том канале телеграмма что М+ при РР не важно, М+ относится к уведомительному режиму - это другой режим и к РР не относится. При РР важны теги 1260-1265 которые формирует ПО и передает в ОФД, а затем в ЧЗ.
нужно ли М+ на разливном Пиве?
или только штучные ?
кто подскажет по коду..
у меня в обработке стоит закомменированным строка
а в требованиях к драйверам 1С написано
Обязательное наличие в структуре ДА
Quantity Да double Количество
или только штучные ?
кто подскажет по коду..
у меня в обработке стоит закомменированным строка
// ДЛЯ НОВЫХ РЕДАКЦИЙ ФН с 2024 года
//Если СокрЛП(Стр.MeasureOfQuantity)="41" Тогда
// // Только количества <> 1
// ЗаписьМаркиXML.ЗаписатьАтрибут("PlannedStatus", ?(СуммаВсехВидовОплаты>0,"2","4"));
// //ЗаписьМаркиXML.ЗаписатьАтрибут("Quantity", XMLСтрока(0));а в требованиях к драйверам 1С написано
Обязательное наличие в структуре ДА
Quantity Да double Количество
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот