2.2.10.10 от 11.10.2021 новое в версии: ФФД 1.2
Добавлено: 11 окт 2021, 23:29
2.2.10.10 от 11.10.2021 новое в версии: ФФД 1.2
Добавлена поддержка ФФД 1.2 для некоторых ККТ
Протокол АТОЛ (Платформа 5) (ФФД 1.2):
Протокол ШТРИХ-М (ФФД 1.2):
Протокол RR-Electro (ФФД 1.2):
Протокол РИТЕЙЛ (ФФД 1.2):
Протокол Paykiosk.ru (ФФД 1.2):
Протокол Dreamkas (Viki Print) (ФФД 1.2):
На подходе Протокол КИТ (КАСБИ).
Изменения в API маркировки:
Код маркировки для ФФД 1.2 нужно передавать в точности такой какой он пришел со сканера!
Пример: BarCode: "0104300943734342212413195240818240640291ffd092MDEwNDMwMDk0MzczNDM",
При этом сканер не должен "Съедать" управляющие символы.
Вы можете протестировать свой сканер здесь: https://xn--80ajghhoc2aj1c8b.xn--p1ai/barcode/
В JSON структуре "Register" фискальной строки изменено поле - структура:
Добавлено Поле "AcceptOnBad" для ККТ работающих по ФФД 1.2:
Смысл: если какой-то код маркировки не прошел проверку в ККТ то чек все равно можно напечатать.
В строке в чеке будет знак [-M] - который это и означает.
ОФД не будет такой код маркировки выводить из оборота.
Добавлена новая команда "ValidationMarkingCode" для ККТ работающих по ФФД 1.2
Данной командой можно проверить коды маркировки в ККТ
При этом некоторые коды (которые в себе содержат крипто-подпись)(например обувные) будут проверены ККТ офлайн.
А все другие коды будут проверятся ККТ через ОФД.
Что соответственно будет занимать некоторое время.
Пример команды:
Вернется вот такой ответ:
Состояния битов в значении реквизита "ValidationResult" (тег 2106)
Логика работы такая (по мнению авторов ФЗ-54):
1. Перед регистрацией чека Вы должны подать команду "ValidationMarkingCode" в которой передать все коды маркировки которые есть в чеке.
2. kkmserver через ККТ проверяет эти коды и возвращает Вам результат проверки.
3. Если есть коды маркировки которые не прошли проверку Вы должны спросить у покупателя согласен ли он на это.
4. Если Да то Вы передаете эти коды маркировки в чек с пометкой в поле "AcceptOnBad: true".
Тогда чек напечатается.
ЗЫ: Коды маркировки в команде регистрации чека не проверяются если они ранее проверены командой "ValidationMarkingCode"
После регистрации чека все проверенные коды маркировки сбрасываются из памяти ККТ
Но вот мне кажется вы не будете работать по такой схеме. Поэтому:
Поэтому можно без команды "ValidationMarkingCode" передать все коды маркировки сразу в чек.
И в зависимости от "AcceptOnBad" коды маркировки не прошедшие проверку применятся или не применятся.
И соответственно весь чек или будет зарегистрирован или не будет.
Вообще это нарушение закона (без вопроса покупателю) - на Ваше усмотрение.
Изменения в API подачи команд на терминал:
Добавлено поле ИНН для поиска.
Если "" или не указано то ищется только по NumDevice,
[/code]InnKkm: "1234567890"[/code]
В настройках терминала можно ввести этот ИНН.
Но если в настройках терминала указана ККТ где будут печататься слип-чеки то ИНН терминала возьмётся оттуда (если он явно не указан в "InnKkm"
Изменился механизм привязки лицензии:
Теперь при покупке лицензии нужно указать ИНН на который регистрировала ККТ.
Тогда новые версии kkmserver будут автоматически получать такие лицензии без email-а и пароля.
Соответственно если лицензия на ИНН - то с ней могут работать не ограниченное количество kkmserver привязанными в них ККТ с этой ИНН.
И если к одному kkmserver-у настроено несколько ККТ с одним ИНН - то все они будут работать по одной лицензии.
А вот ККТ с разными ИНН-ми будут требовать соответствующего количества лицензий по ИНН.
При установке новой версии вместо старой, на которой была получена лицензия по email-у и пароля - произойдет привязка таких лицензий к ИНН и далее лицензия будет получатся автоматом даже после переустановки kkmsrver.
Для клиентов у которых сублицензирование:
Вы с лицензиями продолжаете работать через email.
Но клиентские ПК будут привязываться не через серийник а через ИНН ККТ.
Все это сделано для того чтобы уйти вообще от получения лицензии в kkmserver.
Для Эвоторов лицензия вообще не нужна будет.
Добавлена поддержка ФФД 1.2 для некоторых ККТ
Протокол АТОЛ (Платформа 5) (ФФД 1.2):
Протокол ШТРИХ-М (ФФД 1.2):
Протокол RR-Electro (ФФД 1.2):
Протокол РИТЕЙЛ (ФФД 1.2):
Протокол Paykiosk.ru (ФФД 1.2):
Протокол Dreamkas (Viki Print) (ФФД 1.2):
На подходе Протокол КИТ (КАСБИ).
Изменения в API маркировки:
Код маркировки для ФФД 1.2 нужно передавать в точности такой какой он пришел со сканера!
Пример: BarCode: "0104300943734342212413195240818240640291ffd092MDEwNDMwMDk0MzczNDM",
При этом сканер не должен "Съедать" управляющие символы.
Вы можете протестировать свой сканер здесь: https://xn--80ajghhoc2aj1c8b.xn--p1ai/barcode/
В JSON структуре "Register" фискальной строки изменено поле - структура:
Добавлено Поле "AcceptOnBad" для ККТ работающих по ФФД 1.2:
Код: Выделить всё
GoodCodeData: {
// штрих-код маркировки товара со сканера
BarCode: "0104300943734342212413195240818240640291ffd092MDEwNDMwMDk0MzczNDM",
// Проверять содержит ли ШК кода маркировки идентификатор экземпляра товара (если вообще не указать - true)
// Для некоторых товаров нужно передавать ШК EAN-13, тогда это поле устанавливайте в 'false'
ContainsSerialNumber: true
// Все равно регистрировать чек даже если код маркировки не прошел проверку
// Только для работы по ФФД 1.2
AcceptOnBad: true
}
В строке в чеке будет знак [-M] - который это и означает.
ОФД не будет такой код маркировки выводить из оборота.
Добавлена новая команда "ValidationMarkingCode" для ККТ работающих по ФФД 1.2
Данной командой можно проверить коды маркировки в ККТ
При этом некоторые коды (которые в себе содержат крипто-подпись)(например обувные) будут проверены ККТ офлайн.
А все другие коды будут проверятся ККТ через ОФД.
Что соответственно будет занимать некоторое время.
Пример команды:
Код: Выделить всё
{
// Команда серверу
Command: "ValidationMarkingCode",
//***********************************************************************************************************
// ПОЛЯ ПОИСКА УСТРОЙСТВА
//***********************************************************************************************************
// Номер устройства. Если 0 то первое не блокированное на сервере
// Не рекомендовано для использования.
// Рекомендуем для поиска ККТ задавать InnKkm и TaxVariant !!!!!!
NumDevice: NumDevice,
// ИНН ККМ для поиска. Если "" то ККМ ищется только по NumDevice,
// Если NumDevice = 0 а InnKkm заполнено то ККМ ищется только по InnKkm
InnKkm: "",
// Система налогообложения (СНО) для поиска ККТ, Можно не указывать, или = "" - любое СНО
TaxVariant: "",
// Заводской номер ККМ для поиска. Если "" то ККМ ищется только по NumDevice,
KktNumber: "",
// **********************************************************************************************************
// Список кодов маркировки
"GoodCodeDatas": [
{
// Наименование товара - справочно, можно не передавать
"Name": "Тестовый товар 1",
// штрих-код маркировки товара со сканера (нужно настроить сканер так чтобы не проглатывал управляющие символы)
// Поддерживаются ШК:
// Без идентификатора экземпляра товара: EAN8, EAN13, ITF14
// С идентификатором экземпляра товара: GS1, ШК шуб, ШК табачной продукции., ЕГАИС-2, ЕГАИС-3
"Barcode": "010460708021818721&dAIMqnpEQnQ!\u001d910058\u001d921gx+7D2jIWGSo6LLr1FMGiETo7Ez6k4ag9D8FZwEmJqIWtivlAGjqEP8OspoVeIKiP4OkzmSCzRXmEUygvkKQw=="
},
{
// Наименование товара - справочно, можно не передавать
"Name": "Тестовый товар 2",
// штрих-код маркировки товара со сканера (нужно настроить сканер так чтобы не проглатывал управляющие символы)
// Поддерживаются ШК:
// Без идентификатора экземпляра товара: EAN8, EAN13, ITF14
// С идентификатором экземпляра товара: GS1, ШК шуб, ШК табачной продукции., ЕГАИС-2, ЕГАИС-3
"Barcode": "01046100301415342100000!&\u001d8005106000\u001d93yikZ"
},
],
// Уникальный идентификатор команды. Любая строка из 40 символов - должна быть уникальна для каждой подаваемой команды
// По этому идентификатору можно запросить результат выполнения команды
IdCommand: "g34344gs4ws",
}
Код: Выделить всё
{
"MarkingCodeValidation": [
{
"Name": "Тестовый товар 1",
"BarCode": "010460708021818721&dAIMqnpEQnQ!\u001d910058\u001d921gx+7D2jIWGSo6LLr1FMGiETo7Ez6k4ag9D8FZwEmJqIWtivlAGjqEP8OspoVeIKiP4OkzmSCzRXmEUygvkKQw==",
// Результат проверки КМ в ФН (тег 2106)
"ValidationResult": 16,
"DecryptionResult": "[М] Проверка КП КМ не выполнена, статус товара ОИСМ не проверен (ККТ функционирует в автономном режиме); ФН не содержит ключ проверки кода проверки этого КМ"
},
{
"Name": "Тестовый товар 2",
"BarCode": "01046100301415342100000!&\u001d8005106000\u001d93yikZ",
// Результат проверки КМ в ФН (тег 2106)
"ValidationResult": 16,
"DecryptionResult": "[М] Проверка КП КМ не выполнена, статус товара ОИСМ не проверен (ККТ функционирует в автономном режиме); КМ данного типа не подлежит проверке в ФН"
}
],
"Command": "ValidationMarkingCode",
"Error": "",
"Warning": "",
"Message": "",
"Status": 0,
"IdCommand": "",
"NumDevice": 7
}
Код: Выделить всё
0 бит: "0" - код маркировки не был проверен ФН и (или) ОИСМ
"1" - код маркировки проверен
1 бит: "0" - результат проверки КП КМ отрицательный или код маркировки не был проверен
"1" - результат проверки КП КМ положительный
2 бит: "0" - сведения о статусе товара от ОИСМ не получены
"1" - проверка статуса ОИСМ выполнена
3 бит: "0" - от ОИСМ получены сведения, что планируемый статус товара некорректен или сведения о статусе товара от ОИСМ не получены
"1" - от ОИСМ получены сведения, что планируемый статус товара корректен
4 бит: "0" - результат проверки КП КМ и статуса товара сформирован ККТ, работающей в режиме передачи данных
"1" - результат проверки КП КМ сформирован ККТ, работающей в автономном режиме
5 бит: - 7 Заполняются нулями
Логика работы такая (по мнению авторов ФЗ-54):
1. Перед регистрацией чека Вы должны подать команду "ValidationMarkingCode" в которой передать все коды маркировки которые есть в чеке.
2. kkmserver через ККТ проверяет эти коды и возвращает Вам результат проверки.
3. Если есть коды маркировки которые не прошли проверку Вы должны спросить у покупателя согласен ли он на это.
4. Если Да то Вы передаете эти коды маркировки в чек с пометкой в поле "AcceptOnBad: true".
Тогда чек напечатается.
ЗЫ: Коды маркировки в команде регистрации чека не проверяются если они ранее проверены командой "ValidationMarkingCode"
После регистрации чека все проверенные коды маркировки сбрасываются из памяти ККТ
Но вот мне кажется вы не будете работать по такой схеме. Поэтому:
Поэтому можно без команды "ValidationMarkingCode" передать все коды маркировки сразу в чек.
И в зависимости от "AcceptOnBad" коды маркировки не прошедшие проверку применятся или не применятся.
И соответственно весь чек или будет зарегистрирован или не будет.
Вообще это нарушение закона (без вопроса покупателю) - на Ваше усмотрение.
Изменения в API подачи команд на терминал:
Добавлено поле ИНН для поиска.
Если "" или не указано то ищется только по NumDevice,
[/code]InnKkm: "1234567890"[/code]
В настройках терминала можно ввести этот ИНН.
Но если в настройках терминала указана ККТ где будут печататься слип-чеки то ИНН терминала возьмётся оттуда (если он явно не указан в "InnKkm"
Изменился механизм привязки лицензии:
Теперь при покупке лицензии нужно указать ИНН на который регистрировала ККТ.
Тогда новые версии kkmserver будут автоматически получать такие лицензии без email-а и пароля.
Соответственно если лицензия на ИНН - то с ней могут работать не ограниченное количество kkmserver привязанными в них ККТ с этой ИНН.
И если к одному kkmserver-у настроено несколько ККТ с одним ИНН - то все они будут работать по одной лицензии.
А вот ККТ с разными ИНН-ми будут требовать соответствующего количества лицензий по ИНН.
При установке новой версии вместо старой, на которой была получена лицензия по email-у и пароля - произойдет привязка таких лицензий к ИНН и далее лицензия будет получатся автоматом даже после переустановки kkmsrver.
Для клиентов у которых сублицензирование:
Вы с лицензиями продолжаете работать через email.
Но клиентские ПК будут привязываться не через серийник а через ИНН ККТ.
Все это сделано для того чтобы уйти вообще от получения лицензии в kkmserver.
Для Эвоторов лицензия вообще не нужна будет.