Как включить разрешительный режим в узловой базе Розницы
Приветствую.
Имеется отраслевая конфигурация на базе розницы версии 2.3.22.3501.
Имеется РИБ.
В центральной базе и в узле одинаково настроена маркировка. На днях пришло письмо с Роспотребнадзора, что у нас не применяется разрешительный режим. Проблема в точке, где установлена узловая база. По точке с центральной базой ничего не говорится.
Марки сканируем, чеки печатаем и там и там. ККТ везде прошиты.
Разница только в версии драйвера ККТ, и в обработке обслуживания ККТ в 1С. Сегодня еще раз специалисты смотрели ККТ на точке с узловой базой - сказали, что проблема в 1С, нужно включить разрешительный режим. Т.е. претензий к ККТ и драйверу нет.
Во вложении часть письма и окна настроек по маркировке. CDN площадки обновление (забыл сделать скриншот).
Как можно включить разрешительный режим (по идее он включен)? Возможно в узловой базе какая-то настройка не подгрузилась с центральной.
Так же во вложении фото чека, где отмечено, что марка вроде прошла проверку.
Также есть скриншоты по данным драйверов ККТ на 2-х рабочих местах.
Есть вероятность, что замена драйвера и обработки обслуживания поможет (не факт, т.к. долго мучался с обновлением обработки в центральной базе - ее загрузил, но работать невозможно - ошибки при загрузки компоненты).
Дополнение:
- в узле СУЗ НЕ настроен (он только в центральной).
- сертификаты не добавлены (на узле можно использовать только МЧД, основная в центральной базе - сертификат и токен).
Имеется отраслевая конфигурация на базе розницы версии 2.3.22.3501.
Имеется РИБ.
В центральной базе и в узле одинаково настроена маркировка. На днях пришло письмо с Роспотребнадзора, что у нас не применяется разрешительный режим. Проблема в точке, где установлена узловая база. По точке с центральной базой ничего не говорится.
Марки сканируем, чеки печатаем и там и там. ККТ везде прошиты.
Разница только в версии драйвера ККТ, и в обработке обслуживания ККТ в 1С. Сегодня еще раз специалисты смотрели ККТ на точке с узловой базой - сказали, что проблема в 1С, нужно включить разрешительный режим. Т.е. претензий к ККТ и драйверу нет.
Во вложении часть письма и окна настроек по маркировке. CDN площадки обновление (забыл сделать скриншот).
Как можно включить разрешительный режим (по идее он включен)? Возможно в узловой базе какая-то настройка не подгрузилась с центральной.
Так же во вложении фото чека, где отмечено, что марка вроде прошла проверку.
Также есть скриншоты по данным драйверов ККТ на 2-х рабочих местах.
Есть вероятность, что замена драйвера и обработки обслуживания поможет (не факт, т.к. долго мучался с обновлением обработки в центральной базе - ее загрузил, но работать невозможно - ошибки при загрузки компоненты).
Дополнение:
- в узле СУЗ НЕ настроен (он только в центральной).
- сертификаты не добавлены (на узле можно использовать только МЧД, основная в центральной базе - сертификат и токен).
Прикрепленные файлы:
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6) Показывает - см. фото.
Вчера во время тестирования (узнал сегодня) 2 чека прошли по разрешительному режиму (позже буду разбираться, как так получилось), остальные нет.
На фото видно, что во обоих случаях в ОФД уходят данные по маркам. Качество фото не очень, но основные данные видны.
Вчера во время тестирования (узнал сегодня) 2 чека прошли по разрешительному режиму (позже буду разбираться, как так получилось), остальные нет.
На фото видно, что во обоих случаях в ОФД уходят данные по маркам. Качество фото не очень, но основные данные видны.
Прикрепленные файлы:
Обновление.
На скриншоте с операциями проверки КМ очень мало операций. Во время тестирования 1С отображает, что идет подключение к ЧЗ при проверке марки. Много раз делал продажу и возвраты со сканированием и проверки марок - в журнале эти операции вообще не отобразились.
В настройках интеграции есть колонка "Запрет продажи марок". По воде дата НЕ была установлена. Установил - не помогло решить проблему.
Включил даже новое РМК, установил флаг "Продажи маркированной продукции", как в инструкции от 1С: , сделал продажу/возврат (проверка марок отображалась при сканировании) - тоже ничего, в журнал эти операции не попали.
Включил лог запросов (в новой РМК есть такое) - тоже прикрепляю. Сам посмотрел, ничего не увидел. В нем заменил только данные организации. Отформатировал json. Читать снизу вверх.
Единственное, что странного увидел в логе (тоже читать блоками снизу вверх вроде):
Запрос КМ на ККТ:
<?xml version="1.0" encoding="UTF-8"?>
<RequestKM GUID="f9e1a545-ac24-40f1-833a-9c6daf9c45ac" WaitForResult="True" NotSendToServer="False" MarkingCode="MDEwNDY0MDAxMzUxMDE4NzIxNWpTY1EpUjYob3MuUB05M0d
Локальный ответ ККТ на запрос КМ:
<?xml version="1.0"?>
<RequestKMResult Checking="false" CheckingResult="false"/>
Ответ ОИСМ на запрос КМ:
<?xml version="1.0"?>
<ProcessingKMResult GUID="f9e1a545-ac24-40f1-833a-9c6daf9c45ac" Result="true" ResultCode="15" StatusInfo="1" HandleCode="0"/>
Как будто ККТ в ОИСМ проверка проходит, а ККТ говорит, что нет (не знаю пока, как интерпретировать это).
Локальный модуль не настроен.
На скриншоте с операциями проверки КМ очень мало операций. Во время тестирования 1С отображает, что идет подключение к ЧЗ при проверке марки. Много раз делал продажу и возвраты со сканированием и проверки марок - в журнале эти операции вообще не отобразились.
В настройках интеграции есть колонка "Запрет продажи марок". По воде дата НЕ была установлена. Установил - не помогло решить проблему.
Включил даже новое РМК, установил флаг "Продажи маркированной продукции", как в инструкции от 1С: , сделал продажу/возврат (проверка марок отображалась при сканировании) - тоже ничего, в журнал эти операции не попали.
Включил лог запросов (в новой РМК есть такое) - тоже прикрепляю. Сам посмотрел, ничего не увидел. В нем заменил только данные организации. Отформатировал json. Читать снизу вверх.
Единственное, что странного увидел в логе (тоже читать блоками снизу вверх вроде):
Запрос КМ на ККТ:
<?xml version="1.0" encoding="UTF-8"?>
<RequestKM GUID="f9e1a545-ac24-40f1-833a-9c6daf9c45ac" WaitForResult="True" NotSendToServer="False" MarkingCode="MDEwNDY0MDAxMzUxMDE4NzIxNWpTY1EpUjYob3MuUB05M0d
Локальный ответ ККТ на запрос КМ:
<?xml version="1.0"?>
<RequestKMResult Checking="false" CheckingResult="false"/>
Ответ ОИСМ на запрос КМ:
<?xml version="1.0"?>
<ProcessingKMResult GUID="f9e1a545-ac24-40f1-833a-9c6daf9c45ac" Result="true" ResultCode="15" StatusInfo="1" HandleCode="0"/>
Как будто ККТ в ОИСМ проверка проходит, а ККТ говорит, что нет (не знаю пока, как интерпретировать это).
Локальный модуль не настроен.
Прикрепленные файлы:
Здравствуйте!
У меня как-то тоже были проблемы с проверкой КМ и оказалось, что не стояла дата РР.
Я добавляла дату в колонку РР Розничная продажа в центральной базе, а в распределенные выгружалось при обмене.
У меня как-то тоже были проблемы с проверкой КМ и оказалось, что не стояла дата РР.
Я добавляла дату в колонку РР Розничная продажа в центральной базе, а в распределенные выгружалось при обмене.
Прикрепленные файлы:
9.
ivan.shatrykin@mail.ru
21.01.26 16:45
Сейчас в теме
1С же пишет - таймаут - значит нет ответа от сервера. Нет соединения. Драйвер точно нужный? Сейчас в драйвере настраивается сервер маркировки, порты и т.л. Касса сама по себе, а 1С отдельно запросы шлет.
И еще проверьте в 1С признак предмета расчета у товара. Странно в чеке печатается ТМ.
И еще проверьте в 1С признак предмета расчета у товара. Странно в чеке печатается ТМ.
Проблема оказалась в том, что это отраслевая конфигурация на базе розницы - Розница.Баня. Сауна. Тарифицируемые услуги, редакция 2.3.
Там есть документ "Заказ клиента" (основной для работы), и если в нем есть маркируемый товар, и закрывать это заказ (чек печатается из него, но создается документ Чек ККМ), то по ЧЗ эта продажа не пройдет по разрешительному режиму.
Проблема, как оказалась, вовсе не в узловой базе.
Пока не решил эту проблему, списался с разработчиками.
Временное решение - закрываем заказ без печати чека, далее переходим в созданный ЧекККМ и печатаем чек из него - тогда все Ок.
Там есть документ "Заказ клиента" (основной для работы), и если в нем есть маркируемый товар, и закрывать это заказ (чек печатается из него, но создается документ Чек ККМ), то по ЧЗ эта продажа не пройдет по разрешительному режиму.
Проблема, как оказалась, вовсе не в узловой базе.
Пока не решил эту проблему, списался с разработчиками.
Временное решение - закрываем заказ без печати чека, далее переходим в созданный ЧекККМ и печатаем чек из него - тогда все Ок.
(10) ждите автоштраф на гос услугах. Ваше описание проблемы намного глубже, чтоб ее решать на форуме. все описание проблемы не имеет реальной действительности как сейчас должна работать маркировка. Ни один ответ тут не дал сути. через токен уже нельзя пробивать маркировку, а первого октября его использование будет прекращено
11.
nedomolkov.ivan
232
29.08.26 07:50
Сейчас в теме
(10) Ваш вывод, похоже, верный, и его можно подкрепить документами. Сразу оговорюсь:
отраслевой Баня.Сауна у меня нет, всё ниже собрано по открытым источникам ЧЗ и 1С,
так что это "скорее всего так", а не "проверено у меня".
Механика, из-за которой печать из Заказа не проходит РР.
Запрос проверки шлёт не касса и не драйвер, а само кассовое ПО - методом codes/check
в ГИС МТ. Результат кладётся в чек отраслевым реквизитом, тег 1260, внутри 1265
с UUID и временем ответа. В методичке ЧЗ прямым текстом: если проверки не было или
ответ не получен, весь тег 1260 не заполняется. Дальше чек уходит в ОФД, ГИС МТ
видит пустой 1260 и считает продажу непроверенной. Именно на этих данных строит
претензию Роспотребнадзор, а не на том, что показывает 1С.
Точки, где 1С вызывает проверку, в описаниях названы две: сканирование КМ в РМК
и форма подбора и проверки маркированной продукции в документе продажи. Это
обработчики сценария продажи, а не событие проведения и не команда печати.
Отраслевая печать чека из Заказа клиента их не проходит, поэтому codes/check
не формируется и тег 1260 остаётся пустым. Документированного правила
"РР работает только через РМК" я не нашёл, так что это вывод из механики,
а не цитата.
Самое полезное: проверить, вылечил ли ваш обходной путь проблему, можно
не дожидаясь второго письма, и не в 1С, а в личном кабинете Честного знака.
Раздел Чеки, открыть чек, кнопка Запустить проверку - статус будет
"Проверен онлайн", "Проверен офлайн" или "Не проверен". Ограничения: чек
не старше 7 дней, ФФД 1.2 и без ИНН покупателя. Плюс в главном окне ЛК есть
карточка Статистика отклонений с выгрузкой фискальных документов, по которым
отклонения выявлены. Пробейте один чек по вашей схеме, через Чек ККМ,
и посмотрите статус. Это ответ за минуты и он же готовое доказательство для РПН.
Три следа из обсуждения, которые можно вычеркнуть.
1. Пустой журнал проверок сам по себе не доказательство. В нём по умолчанию
пишутся только ошибки, за успешные отвечает флажок "Хранить успешные операции
при разрешительном режиме", и в Рознице 2.3 запись успешных появилась только
в 2.3.20.38. У вас 2.3.22, флажок есть - вот если он включён, а операций
по продажам всё равно нет, тогда да, запросы не уходят.
2. Таймаут в логе РМК - штатная ситуация, а не причина. Ответа ждут
1,5 секунды, и если он не пришёл, продавать разрешено - это прямо написано
и в методичке ЧЗ, и у 1С. Отсутствие запросов таймаут не объясняет.
3. "1С показывает подключение к ЧЗ при сканировании" тоже ничего не доказывает:
это может быть проверка статуса кода, старый механизм, бывший ещё до РР.
Тег 1260 она не заполняет. И отдельно: в чеке два разных слоя - РР через HTTP
из 1С (тег 1260) и проверка КМ средствами ККТ по ФФД 1.2 (тег 2106, через
драйвер и ОФД). В логе они соседствуют, и Checking=false из ККТ
к разрешительному режиму отношения не имеет.
Что дать разработчикам отраслевой, чтобы чинили не гадая: закрытие Заказа
клиента должно проходить через тот же механизм проверки, что и форма Чека ККМ,
до фискализации. И приложите два статуса из ЛК ЧЗ - чек из Заказа и чек из Чека ККМ.
Разница в одну строку убеждает быстрее описания.
отраслевой Баня.Сауна у меня нет, всё ниже собрано по открытым источникам ЧЗ и 1С,
так что это "скорее всего так", а не "проверено у меня".
Механика, из-за которой печать из Заказа не проходит РР.
Запрос проверки шлёт не касса и не драйвер, а само кассовое ПО - методом codes/check
в ГИС МТ. Результат кладётся в чек отраслевым реквизитом, тег 1260, внутри 1265
с UUID и временем ответа. В методичке ЧЗ прямым текстом: если проверки не было или
ответ не получен, весь тег 1260 не заполняется. Дальше чек уходит в ОФД, ГИС МТ
видит пустой 1260 и считает продажу непроверенной. Именно на этих данных строит
претензию Роспотребнадзор, а не на том, что показывает 1С.
Точки, где 1С вызывает проверку, в описаниях названы две: сканирование КМ в РМК
и форма подбора и проверки маркированной продукции в документе продажи. Это
обработчики сценария продажи, а не событие проведения и не команда печати.
Отраслевая печать чека из Заказа клиента их не проходит, поэтому codes/check
не формируется и тег 1260 остаётся пустым. Документированного правила
"РР работает только через РМК" я не нашёл, так что это вывод из механики,
а не цитата.
Самое полезное: проверить, вылечил ли ваш обходной путь проблему, можно
не дожидаясь второго письма, и не в 1С, а в личном кабинете Честного знака.
Раздел Чеки, открыть чек, кнопка Запустить проверку - статус будет
"Проверен онлайн", "Проверен офлайн" или "Не проверен". Ограничения: чек
не старше 7 дней, ФФД 1.2 и без ИНН покупателя. Плюс в главном окне ЛК есть
карточка Статистика отклонений с выгрузкой фискальных документов, по которым
отклонения выявлены. Пробейте один чек по вашей схеме, через Чек ККМ,
и посмотрите статус. Это ответ за минуты и он же готовое доказательство для РПН.
Три следа из обсуждения, которые можно вычеркнуть.
1. Пустой журнал проверок сам по себе не доказательство. В нём по умолчанию
пишутся только ошибки, за успешные отвечает флажок "Хранить успешные операции
при разрешительном режиме", и в Рознице 2.3 запись успешных появилась только
в 2.3.20.38. У вас 2.3.22, флажок есть - вот если он включён, а операций
по продажам всё равно нет, тогда да, запросы не уходят.
2. Таймаут в логе РМК - штатная ситуация, а не причина. Ответа ждут
1,5 секунды, и если он не пришёл, продавать разрешено - это прямо написано
и в методичке ЧЗ, и у 1С. Отсутствие запросов таймаут не объясняет.
3. "1С показывает подключение к ЧЗ при сканировании" тоже ничего не доказывает:
это может быть проверка статуса кода, старый механизм, бывший ещё до РР.
Тег 1260 она не заполняет. И отдельно: в чеке два разных слоя - РР через HTTP
из 1С (тег 1260) и проверка КМ средствами ККТ по ФФД 1.2 (тег 2106, через
драйвер и ОФД). В логе они соседствуют, и Checking=false из ККТ
к разрешительному режиму отношения не имеет.
Что дать разработчикам отраслевой, чтобы чинили не гадая: закрытие Заказа
клиента должно проходить через тот же механизм проверки, что и форма Чека ККМ,
до фискализации. И приложите два статуса из ЛК ЧЗ - чек из Заказа и чек из Чека ККМ.
Разница в одну строку убеждает быстрее описания.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот