Описание протокола взаимодействия между ККТ и ИС ОФД - Форум по новому порядку применения контрольно-кассовой техники - Все форумы ФНС

# Описание протокола взаимодействия между ККТ и ИС ОФД

SSergey , 20 Feb 2016 10:57
протокол офд ккт описание ккт-офд

### #1 SSergey

SSergey

Newbie

- moderator_ca
- 8

- Пол: Мужчина

20 February 2016 - 10:57

Для обсуждения представляем обновленную редакцию документов:

1 - проект Описания протокола взаимодействия между контрольно-кассовой техникой и информационной (автоматизированной) системой оператора фискальных данных, предназначенного для обеспечения совместимости программно-аппаратных средств при взаимодействии между контрольно-кассовой техникой и автоматизированной системой оператора фискальных данных

2 - протокол уровня представления данных, форматы фискальных документов.

С изменениями и дополнениями к документу, опубликованному 20.02.2016 в этой же теме.

####

- Форматы ФД в1_0.pdf 1019.72kb 158
- Описание протокола ККТ-ОФД в1_0.pdf 1.22mb 177

### #2 Nataly_73

Nataly_73

Newbie

- Members
- 3

- Пол: Женщина
- Город: Ярославль

04 March 2016 - 14:58

Добрый день!

Прошу ответить на вопросы по документу "Описание протокола ККТ-ОФД".

Вопросы, требующие ответа:

1) Написано: Сообщения передаются в защищенном виде с обеспечением свойств аутентификации источника данных.
Как это осуществлять? По номеру ККТ? А если пользователь зарегистрировал ее самостоятельно, то надо делать запрос в Налоговую?
2) Можно ли получить пример ПКЗ с описанным протоколом взаимодействия.
3) Можно ли получить протокол Оператор -> Налоговая.

### #3 Nataly_73

Nataly_73

Newbie

- Members
- 3

- Пол: Женщина
- Город: Ярославль

10 March 2016 - 12:44

Добрый день!

1. Что такое "Клиент ФН" (фискальный накопитель), кто производит? Где взять для разработки?

2. Что такое ПКЗ-Сервера, кто производит, где взять для разработки, где получить интерфейс взаимодействия?

3. Как настраиваются (связаны между собой) Клиент ФН и ПКЗ-Сервер.

4. Где взять описание протокола взаимодействия между ОФД и ФНС? Какие данные и как именно передает ОФД в ФНС России?

5. Где получить требования к пользовательским интерфейсам пользователя ККТ и полкупателя, который захочет проверить чек.

6. Где взять формат/протокол регистрации ККТ в ФНС?

7. Где можно получить для целей разработки и тестирования ККТ? Есть ли какой-то тестовый клиент?

8. Где взять формат и печатную форму нового кассового чека?

### #4 VGPAVLOV

VGPAVLOV

Newbie

- Members
- 2

16 March 2016 - 15:07

Добрый день.

На время тестирования новых решений для участия в эксперименте тестовую площадку предоставлял ГНИВЦ.

К кому сейчас обращаться по вопросам тестовой площадки для отладки протокола ККТ-ОФД?

### #5 SSergey

SSergey

Newbie

- moderator_ca
- 8

- Пол: Мужчина

21 March 2016 - 10:47

*update*

В первом сообщении темы обновлены проекты документов.

### #6 Yatoba

Yatoba

Member

- Members
- 12

12 April 2016 - 00:01

А не подскажете где брать актуальные документы, так сказать, из первых рук?
Основное: в самом документе Формата ФД не хватает примера исходного сообщения в виде HEX дампа и его разобранного аналога.
Тсюда вытекают следующие моменты:
1. если поле имеет тип ASCII и при этом допустимо не полная длина, то как определить когда заканчивается даное поле? (перед строкой будет ее длина или будет \0 вконце строки или еще какие-нибудь варианты)
2. если поле необязательное, то как определить что началось другое поле? Предусмутрены ли маркеры-разделители, если да то нужно их описать, если нет то нужно описание способа распознавания
3. для типов данных "структура" поле максимальная длина указывает на количество допустимых повторений или размер именно одной записи данной структуры?
4. из п.3 если же для одной записи, то например, для реквизита товара сумма полей в структуре будет 172 без учета поля "дополнительный реквезит", а с ним - 400. Тогда либо нужны правки, либо разъяснения что как высчитывать.
5. в документах указано, что кассовый чек и БСО не могут превышать размера в 32Кб, следовательно из предыдущих пунктов, в кассовом чеке нельзя будет передать больше примерно 180 позиций (если опускать поле "дополнительный реквезит"). Как будет себя вести ТТК при 200 позициях в чеке, когда предел будет переполнен?
В таблице 6 по кассовому чеку в строке, где описывается формат поля "сообщение оператору" указано, что источником данных и структуры являются одновремено и ККТ и ФН, как это понимать?

### #7 Viktor_S

Viktor_S

Member

- Members
- 22

14 April 2016 - 10:54

> А не подскажете где брать актуальные документы, так сказать, из первых рук?
> Основное: в самом документе Формата ФД не хватает примера исходного сообщения в виде HEX дампа и его разобранного аналога.
> Тсюда вытекают следующие моменты:
> 1. если поле имеет тип ASCII и при этом допустимо не полная длина, то как определить когда заканчивается даное поле? (перед строкой будет ее длина или будет \0 вконце строки или еще какие-нибудь варианты)
> 2. если поле необязательное, то как определить что началось другое поле? Предусмутрены ли маркеры-разделители, если да то нужно их описать, если нет то нужно описание способа распознавания
> 3. для типов данных "структура" поле максимальная длина указывает на количество допустимых повторений или размер именно одной записи данной структуры?
> 4. из п.3 если же для одной записи, то например, для реквизита товара сумма полей в структуре будет 172 без учета поля "дополнительный реквезит", а с ним - 400. Тогда либо нужны правки, либо разъяснения что как высчитывать.
> 5. в документах указано, что кассовый чек и БСО не могут превышать размера в 32Кб, следовательно из предыдущих пунктов, в кассовом чеке нельзя будет передать больше примерно 180 позиций (если опускать поле "дополнительный реквезит"). Как будет себя вести ТТК при 200 позициях в чеке, когда предел будет переполнен?
> В таблице 6 по кассовому чеку в строке, где описывается формат поля "сообщение оператору" указано, что источником данных и структуры являются одновремено и ККТ и ФН, как это понимать?

1. если поле имеет тип ASCII и при этом допустимо не полная длина, то как определить когда заканчивается даное поле? (перед строкой будет ее длина или будет \0 вконце строки или еще какие-нибудь варианты)

В структуре STLV, применяемой для формирования фискальных документов или их отдельных реквизитов существует понятие «длина» и 　значение «L» (length) указывает полное число байтов, отсчитанных от заголовка STLV-структуры и содержащих значение реквизита.

В тех случаях, когда применяется элемент данных с фиксированной длиной для кодирования значений реквизитов, допускающих переменную длину (например, ИНН), то способ указания значения реквизита определяется типом реквизита. Если специально не оговаривается способ кодирования, рекомендуется придерживаться традиционно способа с выравниванием по левому краю и дополнением справа символами пробела до необходимой длины.

Для кодирования реквизита типа ASCII следует использовать значения символов, перечисленных явным образом в таблице в кодировке CP866.

Вы можете завершить строку знаком \0 (c-string), но тем самым Вы включите символ \0 в строку, как отдельный символ. Данный способ не определяется спецификаций

2. если поле необязательное, то как определить что началось другое поле? Предусмутрены ли маркеры-разделители, если да то нужно их описать, если нет то нужно описание способа распознавания

Выделение отдельных элементов данных в структуре STLV, и содержащих значения реквизитов, производится по элементам «TL» (tag-length). При таком способе кодирования разделители не применяются. Необязательный реквизит может быть указан нулевой длиной (пустое значение) или полным отсутствием при передаче всей структуры STLV.

3. для типов данных "структура" поле максимальная длина указывает на количество допустимых повторений или размер именно одной записи данной структуры?

4. из п.3 если же для одной записи, то например, для реквизита товара сумма полей в структуре будет 172 без учета поля "дополнительный реквезит", а с ним - 400. Тогда либо нужны правки, либо разъяснения что как высчитывать.

Поле структура (сложный элемент) может содержать простые поля в форматеSTLV. Когда в таблицах документа указано значением «максимальная длина» речь идет о полной длине данных именно этой структуры.

При использовании вложенныхSTLV-структур каждая вложенная структура должна иметь свой заголовок и каждый заголовок вложенной структуры должен указывать длину только этой структуры данных.

5. в документах указано, что кассовый чек и БСО не могут превышать размера в 32Кб, следовательно из предыдущих пунктов, в кассовом чеке нельзя будет передать больше примерно 180 позиций (если опускать поле "дополнительный реквезит"). Как будет себя вести ТТК при 200 позициях в чеке, когда предел будет переполнен?

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

В случае достижения предельной длины при формировании чека ККТ должна показать кассиру, что достигнута максимальная длина чека. Если кассир продолжит выбивать чек – касса вправе выдать код ошибки и прекратить работу с данным чеком. Поэтому кассиру, при индикации предельной длины чека рекомендуется разбить длинный чек на несколько более коротких.

В таблице 6 по кассовому чеку в строке, где описывается формат поля "сообщение оператору" указано, что источником данных и структуры являются одновремено и ККТ и ФН, как это понимать?

Применение поля «Сообщение оператору» на сегодня не формализовано. Это поле зарезервировано, как канал передачи данных об определенных событиях, источником которых, в разных ситуациях, могут выступать, как ККТ, так и ФН.

### #8 multisoft

multisoft

Newbie

- Members
- 1

14 April 2016 - 12:14

Добрый день!

Возникли вопросы по документации версии 1.0:

1. Является ли применение контрольной суммы обязательной и кому принадлежит инициатива включения режима с контрольными суммами?
2. Контейнер криптопротокола (поля "Служебные данные 1" и "Служебные данные 2"). Всегда ли содержится поле "служебные данные 2" (данные криптопротокола) в заголовке контейнера? Как выглядит сообщение в случае, если данных криптопротокола нет? Первое поле заполняется нулями, второе отсутствует, а бит 2 в флагах содержит значение "0"?
3. Каково поведение ОФД в случае отсылки только сообщения S-протокола, без полезной нагрузки в виде контейнера?
4. Кто формирует значения флагов 5-4? Клиент ККТ? По какому алгоритму?
5. Как выглядит контейнер для данных криптопротокола ("Служебные данные 1", "Служебные данные 2") в ответе от ФН?
6. Что означают константы 0xA5 / 0x5A в поле "Тип сообщения протокола"? В каком случае какая из них применяется? Кто определяет значение этого поля?
7. Зачем нужно поле "Код типа ФД"? Эти данные уже имеются в TLV, передаваемых в контейнере. Почему размер этого поля 1 байт, а не 2?
8. Почему поле "Номер ФН" (Заводской номер фискального накопителя) имеет размер 8 байт? По документации, номер ФН - 16 байт, ASCII. Что подразумевается под машинным представлением? BCD?
9. Подтверждение оператора имеет максимальную длину 362 байта. При этом в Таблице 14 суммарная длина полей фиксированной длины составляет 4 + 18 + 169 = 191 байт. При добавлении не обязательного поля "сообщение оператора для ККТ" (216 байт) суммарная длина составит 407 байт (и это без учета возможных повторов).
Вопрос: как интерпретировать ограничение максимальной длины в 362 байта?
10. Так же входящее в состав подтверждения оператора поле "Сообщение оператора для ФН" имеет максимальную длину 169 байт в Таблице 15 суммарная длина полей фиксированной длины составляет 1 + 12 + 144 = 157 байт. Если поле "параметр настройки" будет повторен, то максимальная длина будет превышена.
Как интерпретировать ограничение длины в 169 байт?
11. Таблица 11, поле "Сообщение оператору" имеет фиксированную максимальную длину 328 байт. При этом в таблице 12 у полей длины строк не фиксированы. Причем суммарный максимальный объем одного сообщения будет равен 320 байтам.
12. Каким образом интерпретировать несоответствия максимальных длин запросов и указание фиксированных длин полей?

### #9 Yatoba

Yatoba

Member

- Members
- 12

15 April 2016 - 11:58

В приложении 4, там где приводятся примеры типов данных нудно поправить пример для FVLN, там либо результат должен быть "1234567.89" либо байты должны быть другими "0x02 0x4E 0x61 0xBC"

### #10 Yatoba

Yatoba

Member

- Members
- 12

15 April 2016 - 15:54

Дополнительно в пункте 3.5 дублируется реквизит "сообщение оператору" с разным описанием, скорее всего первый лишний

### #11 К_Николай_А

К_Николай_А

Newbie

- Members
- 1

18 April 2016 - 10:16

Добрый день!

Yatoba <<Основное: в самом документе Формата ФД не хватает примера исходного сообщения в виде HEX дампа и его разобранного аналога.>>

Присоединяемся к автору с пожеланием увидеть пример запроса. Можно даже просто логи, даже без комментариев )).

### #12 Yatoba

Yatoba

Member

- Members
- 12

24 April 2016 - 23:56

Еще, в соседней ветке "Проект протокола взаимодействия между ОФД и ФНС России" в документе "Протокол ОФД-ИРККТ3(ФНС).pdf" в JSON вариантах, отправляемых в ФНС есть пример:

"taxationType": 8, // 1062 система налогообложения. битовая строка, смотри описание ниже

а в форматах данных тег с кодом 1062 отмечен как "зарезервированный", расхожденьице.

UPD:

появилась неоднозначность - в описании формата "Отчет о фискализации" есть реквизит "системы налогообложения", при этом не совсем ясно какой тег под это подходит.

Отсюда требование-пожелание: перестроить форматы с явным указанием номеров тегов.

###

Открытые форумы → Форум по новому порядку применения контрольно-кассовой техники →

#### Описание протокола уровня представления данных. Форматы фискальных документов

06 Jun 2016 Протокол, ФД, фискальныеданные

- 8
- 421

- Yatoba
- 16 Jun 2016

Открытые форумы → Форум по новому порядку применения контрольно-кассовой техники →

#### Проект протокола взаимодействия между ОФД и ФНС России

21 Mar 2016 протокол, офд, ирккт, офд-фнс

- 4
- 1166

- Yatoba
- 16 Jun 2016

####

###

- Политика Конфиденциальности