Не передаются данные по маркировке
Добрый день, коллеги! УТ 10.3, сильно переписанная. Маркировка сигарет. Из УТ на кассу уходит xml
Чек успешно печатается и передается в ОФД, но БЕЗ признака маркировки. Надо понять, на чей стороне проблема 1с или Штрих-М. По словам ККМ-щиков, касса прямую передачу тега (без кодирования) поддерживать должна.
<CheckPackage>
<Parameters PaymentType="1" TaxVariant="5" CashierName="Мария Ивановна" CustomerEmail="" CustomerPhone="">
<AgentData/>
<PurveyorData/>
</Parameters>
<Positions>
<FiscalString Name="Сигареты Бонд Compact кнопка МРЦ 127 (шт)" Quantity="1" PriceWithDiscount="127" SumWithDiscount="127" DiscountSum="0" Department="2" Tax="none" SignMethodCalculation="4" SignCalculationObject="1" TaxSum="">
<GoodCodeData MarkingCode="RE0EMHcZcDZpVDNXTyU7QUI+OCAg"/>
</FiscalString>
</Positions>
<Payments Cash="127" ElectronicPayment="0" Credit="0" AdvancePayment="0" CashProvision="0"/>
</CheckPackage> ПоказатьЧек успешно печатается и передается в ОФД, но БЕЗ признака маркировки. Надо понять, на чей стороне проблема 1с или Штрих-М. По словам ККМ-щиков, касса прямую передачу тега (без кодирования) поддерживать должна.
По теме из базы знаний
- Одна ККТ для розничного магазина и Интернет-сайта
- Маркировка лекарств - как передать код маркировки при продаже через ККТ Штрих-М
- Интеграции с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али, ЛаМода для 1С:УНФ, УТ, КА, ERP
- Обмен 1С с Честным Знаком для УТ11, УНФ, КА2, ERP, Розница: Расширение для работы с СУЗ, ГИС МТ, ЦРПТ
- API-интеграция 1С с маркетплейсами ОЗОН, WildBerries, Я.Маркет, СберМегаМаркет, Стройландия, Леруа Мерлен, Hoff, AliExpress для УТ11, КА2, ERP2, УНФ, БП3, Розница, УТ10, УПП1.3
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
У Вас код не в квадратных скобках. И он, насколько я понимаю, должен быть в base64 формате.
Т.е.GTIN и серийный номер кодируются base64. Base64 получается длиннее, чем исходные 31 символ.
Поэтому у Вас в коде что-то короткое и из base64 нормально не декодируемое, в онлайне попробовал.
Может, Вы пример кода нереальный разместили?
(4) Спасибо за ответ! В примере xml который 1с отправляет на кассу при продаже реальной пачки сигарет. По поводу
Это же устаревший параметр? т.е. в кассы с новой прошивкой код уходит как он есть, без разбития, кодирования и т.п. Во всяком случае, смотрел код БПО - там так.
MarkedGoodTypeCodeЭто же устаревший параметр? т.е. в кассы с новой прошивкой код уходит как он есть, без разбития, кодирования и т.п. Во всяком случае, смотрел код БПО - там так.
(5)
base64 кодирование вряд ли могли отменить. Оно давно, с 1990-х годов используется для пересылки данных по интернету, потому что в нем используются только символы английского алфавита и не возникает ошибок из-за спецсимволов.
А как раз серийный номер, который после гтина, очень насыщен всякими спецсимволами.
Я во многих местах видел, что маркировка так кодируется. Да и Вы прислали как раз похожее. GTIN ведь - это одни цифры.
Если б не кодировался, в начале было бы 15 цифр.
В последнем драйвере Атола 10.8.0.0 тоже предлагается ввести отдельно ГТИН и отдельно сер.номер и указать тип товара (!), чтоб пробить чек с маркировкой.
Тест драйвера Штриха не смотрел, но, они тоже должны были что-то подобное добавить на вкладку пробития чека.
в кассы с новой прошивкой код уходит как он есть, без разбития, кодирования
base64 кодирование вряд ли могли отменить. Оно давно, с 1990-х годов используется для пересылки данных по интернету, потому что в нем используются только символы английского алфавита и не возникает ошибок из-за спецсимволов.
А как раз серийный номер, который после гтина, очень насыщен всякими спецсимволами.
Я во многих местах видел, что маркировка так кодируется. Да и Вы прислали как раз похожее. GTIN ведь - это одни цифры.
Если б не кодировался, в начале было бы 15 цифр.
В последнем драйвере Атола 10.8.0.0 тоже предлагается ввести отдельно ГТИН и отдельно сер.номер и указать тип товара (!), чтоб пробить чек с маркировкой.
Тест драйвера Штриха не смотрел, но, они тоже должны были что-то подобное добавить на вкладку пробития чека.
(5)
Недавно посмотрел вебинар от Атола, на котором говорилось, что на кассе код выглядит как 444D+GTIN+серийный номер в некодированном виде и сам убедился, когда увидел именно такой код в электронном чеке у себя у ОФД. Поэтому вопрос о кодировании base64 не понятен, когда и где оно производится или не производится
без разбития, кодирования и т.п.
Недавно посмотрел вебинар от Атола, на котором говорилось, что на кассе код выглядит как 444D+GTIN+серийный номер в некодированном виде и сам убедился, когда увидел именно такой код в электронном чеке у себя у ОФД. Поэтому вопрос о кодировании base64 не понятен, когда и где оно производится или не производится
Еще вспомнил, что недавно я купил обработку обслуживания кассы Атол Карпова на Инфостарте и как раз спрашивал его, что совершает base64 кодирование его обработка или УТ10.3
Он ответил, что УТ10.3, т.е. подтвердил, что оно совершается.
Он ответил, что УТ10.3, т.е. подтвердил, что оно совершается.
(13) На последней УТ 11.4.13.275 и с последним драйвером Атол (10.0.9.4) все работает. Марки проверяются прям при продаже в РМК (пришлось конечно по потеть но все взлетело), так что пробуйте все работает спустя месяц гемороя.....
- эта тема направит на правильный ход мысли....
у меня всё завелось на новом релизе Розницы.
Небольшая инструкция:
1. Обновляетесь до 2.3.9.42
2. Устанавливаете драйвер версии 10.0.9.4 с сайта Атол.
3. Добавляете в справочник драйверов свою версию драйвера атол, подгружаете архив из папки _component который находится в папке 1C ранее скаченного архива с сайта Атол.
4. Настраиваете подключаемое оборудование с использованием ранее установленной компоненты.
5. В 1С, в ИСМП, в "Настройка сканирования кодов маркировки" отключаете контроль марок.
Пока я не попробовал 5 пункт, пробитие чека с маркой постоянно выдавало ошибку "Код маркировки не проверен".
После, при сканировании кода появляется форма, что маркировка проверяется средствами ККТ (хотя опцию я наоборот отключил, мб баг). В итоге чек пробивается как нужно, с тегом [М+]. Посмотрел лог драйвера, код маркировки в него успешно передался.
P.S. На встроенной в конфигурацию компоненте не заведется, там до сих пор версия 10.0.6.2
- эта тема направит на правильный ход мысли....
у меня всё завелось на новом релизе Розницы.
Небольшая инструкция:
1. Обновляетесь до 2.3.9.42
2. Устанавливаете драйвер версии 10.0.9.4 с сайта Атол.
3. Добавляете в справочник драйверов свою версию драйвера атол, подгружаете архив из папки _component который находится в папке 1C ранее скаченного архива с сайта Атол.
4. Настраиваете подключаемое оборудование с использованием ранее установленной компоненты.
5. В 1С, в ИСМП, в "Настройка сканирования кодов маркировки" отключаете контроль марок.
Пока я не попробовал 5 пункт, пробитие чека с маркой постоянно выдавало ошибку "Код маркировки не проверен".
После, при сканировании кода появляется форма, что маркировка проверяется средствами ККТ (хотя опцию я наоборот отключил, мб баг). В итоге чек пробивается как нужно, с тегом [М+]. Посмотрел лог драйвера, код маркировки в него успешно передался.
P.S. На встроенной в конфигурацию компоненте не заведется, там до сих пор версия 10.0.6.2
(14)Добрый день, а в ОФД видны в кодах марок префикс 444D?
Перевел кассу на ФФД 1.2, в ОФД уходит код марки, но он уходит как есть:
Раньше было: Товар КТ 444d462......
Сейчас так: Товар КТ 010462...
и по новой схеме, мы в Честном знаке не видим движение по нашей марке...
Это Обувь.
Перевел кассу на ФФД 1.2, в ОФД уходит код марки, но он уходит как есть:
Раньше было: Товар КТ 444d462......
Сейчас так: Товар КТ 010462...
и по новой схеме, мы в Честном знаке не видим движение по нашей марке...
Это Обувь.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот