Чеки. Чеки ФФД 1.05-1.1 и УВРМТ ФФД 1.2. Док v1.4. Ффд 05 1 Поиск чеков в Kibana
 Скачать 3.32 Mb.
|
|
ФФД 1.05 / 1.1 Поиск чеков в Kibana: https://ofd.rc.mdlp.crpt.ru login: callservice password: cheiSh1w Нажимаем на кнопку в виде компаса:  Добавляем фильтры для поиска нужного чека: Кнопка Add Filter Выбираем поле для поиска. На картинке выбран «receipt.userinn» - ИНН организации продавца Выбираем оператор сравнения. IS – совпадение Value – значение, которое требуется найти нажимаем «Save»  При поиске по одному фильтру может быть очень много результатов. На примере 782984 чека  Добавляем дополнительные фильтры, также на кнопку Add Filter:  После нахождения чека нажимаем на стрелку слева от чека, а затем на JSON:  ВАЖНО! Чеки хранятся только 2 недели. Старые чеки найти не получится. ВАЖНО! Дата в чеках хранится в формате Unix time, для перекодировки можно воспользоваться любым ресурсом, например: https://www.cy-pr.com/tools/time/ Пример: Дата: 13 Июля 2020 15:41:00 GMT В формате Unix time выглядит так: 1594654860 Как конвертировать:  Далее необходимо убедиться, что в JSON имеются все необходимые поля и что они заполнены правильно. Далее в инструкции имеется пример корректного чека. Дополнительная документация: Формат записи данных о выбытии в ФФД: https://честныйзнак.рф/upload/iblock/644/Format-zapisi-dannykh-o-vybytii-LP-v-FFD.pdf Протокол информационного обмена ОФД: https://честныйзнак.рф/upload/iblock/b66/Protokol_informatsionnogo_obmena_OFD.pdf SGTIN в чеке зашифрован особым образом, подробная инструкция по расшифровке в разделе Расшифровка поля «productCode». Пример корректного JSON чека: { "_index": "receipt", "_type": "_doc", "_id": "URCPT00000000000000042407-4752", "_version": 1, "_score": 0, "_source": { "receipt": { "code": 3, "fiscalDriveNumber": "9281000100274131", "kktRegId": "0000661721044784", "userInn": "7901537298", "fiscalDocumentNumber": 187115, "dateTime": 1595245320, "fiscalSign": 0, "shiftNumber": 742, "requestNumber": 54, "operationType": 1, "totalSum": 24130, "properties": { "propertyName": "mdlp", "propertyValue": "sid00000000206992&" }, "items": [ { "productCode": "AAMEL16ndHBJM0RTSDRVMDAwUjBJ", "propertiesItem": "mdlp&", "name": "1/1 Сбор грудной N1 (фитопектол) 35г", "price": 7980, "quantity": 1, "sum": 7980, "nds": 6, "ndsSum": 0 } ], "cashTotalSum": 0, "ecashTotalSum": 24130, "taxationType": 4, "fiscalDocumentFormatVer": 2, "ndsNo": 24130, "indicationfiscalSign": 0, "user": "ООО \"Бира-Фарм\"", "retailPlace": "Аптечный пункт N 5", "retailAddress": "679016, ЕАО, Биробиджан г, Димитрова ул, 19, к. 1, пом. 2, 3", "ofdINN": "9715260691" } }, "highlight": { "receipt.properties.propertyName": [ "@kibana-highlighted-field@mdlp@/kibana-highlighted-field@" ], "receipt.userInn": [ "@kibana-highlighted-field@7901537298@/kibana-highlighted-field@" ], "receipt.properties.propertyValue": [ "@kibana-highlighted-field@sid00000000206992@/kibana-highlighted-field@&" ], "receipt.properties.propertyName.keyword": [ "@kibana-highlighted-field@mdlp@/kibana-highlighted-field@" ], "receipt.items.propertiesItem": [ "@kibana-highlighted-field@mdlp@/kibana-highlighted-field@&" ] } } Пример чека с соотношением полей в JSON:  Расшифровка поля «productCode». Поле: "productCode": "AAMEL16ndHBJM0RTSDRVMDAwUjBJ" Декодируем из Base64:  (скрин из NotePad)Последние 13 знаков – это серийный номер, больше с ними ничего делать не требуется Все, что перед последними 13 знаками переводим из ASCII в HEX: Выделяем  Конвертируем из ASCII в HEX  Получаем:  Откидываем первые знаки перед «04…» и копируем:  Перекодируем HEX в 10 систему (Dec):   Можно использовать любой конвертер, но если используете калькулятор, не забывайте ставить потом ведущий ноль Соединив обратно, получаем SGTIN: 04601498006640I3DSH4U000R0I Особенности: «ndsSum» должен быть равен сумме НДС. Если НДС не облагается, то должен быть равен не 0, а полной сумме расчета. Чеки с «ndsSum» на текущий момент проходят Тег «buyerInn» означает продажу ЛП другому юр. лицу. Чеки с этим тегом не проходят в МДЛП. Это сделано специально. При продаже другому юр. лицу необходимо использовать 415/416. Покупатель может рассчитаться через ККТ, но в МДЛП необходимо подать сведения по 415/416. На текущий момент чек может попасть в МДЛП даже без наличия всех обязательных тегов. При этом система, как правило, фиксирует нарушение "Нарушение формата чека" ("violationReasons": [5]) и помещает SGTIN в реестр ожидания. Если от участника поступают вопросы по ЛП со статусом "Продан в розницу с отклонением от требований в части выбытия ЛП" без видимых на то причин и присутствует документ 10511, необходимо сверить следующие данные: 1. Указан ли в документе идентификатор места деятельности или же присутствует регистрационный номер участника (в чеке может отсутствовать МД) 2. Сверить хронологию местонахождения ЛП, на каком МД находился sgtin и с какого МД производился вывод 3. Перекодировать sgtin в "productCode" и найти в кибане чек, сверить все поля в чеке 4. В реестре ожидания должна быть ошибка "Нарушение формата чека" ("violationReasons": [5]) Если в чеке отсутствуют необходимые теги, направить соответствующий ответ участнику. Проверка квитанции чека. Для этой проверки нужен номер квитанции ЦРПТ вида: UTXMNGR00000000000000311331-8217 (1 линия запрашивает в отбивке). Участник может найти ее в ЛК ОФД или обратившись напрямую в ОФД. Переходим по ссылке (нужен VPN CRPT_VIP): https://tx-manager.prod01.rtng.crpt.tech/api/v1/transactions/UTXMNGR00000000000000311331-8217 Зеленым цветом выделено то, что нужно заменить на свой номер квитанции. Должен получиться ответ типа:  Копируем его в NotePad++, форматируем по типу JSON:  По квитанции можно найти чек в Kibana, также ее необходимо прикладывать для передачи обращений на 3 линию, если вопрос в обработке чеков. Если получена ошибка следующего типа: { "resultDocId": "UTXMNGR00000000000000431960-9083", "resultDocDate": 1619870684063, "sourceDocId": "URCPT00000000000000427877-7785", "sourceDocDate": 1619870681021, "state": "FAILED", "code": 1, "description": "Document processing was failed", "operations": [ { "operationId": "432ff0d9-6611-49d7-ac84-c30914b9c3ca", "operationType": "RECEIPT_VALIDATION", "operationDate": 1619870681033, "details": { "ofdInn": "9715260691", "successful": "true", "documentType": "TICKET", "documentNumber": "2450", "documentDateTime": "1619881500" } }, { "operationId": "1d9e5cc7-0aa3-4a52-9d39-ccd797c2bd9b", "operationType": "RECEIPT_ROUTED", "operationDate": 1619870681097, "details": { "errors": [ { "code": 60, "error": { "ProductNotExists": { "details": null } }, "data": { "productCodes": [ "RE0EL/MR8nhLMjA5MUoxMzQySzk3" ] } } ], "successful": "false" } } ] } То проверяем наличие GTIN в справочнике: POST http://gtin-registry.apps.prod01.gismt.crpt.tech/api/v3/gtin-registry/gtin Content-Type: application/json;charset=UTF-8 {"data": ["04603988013688"]} Если получаем такой ответ: [ { "data": "04603988013688", "tg-id": "100500", "tg-name": "unknown" } ] То пишем письмо на Полуянова d.poluyanov@crpt.ru (предварительно проверяем, что такой GTIN имеется в МДЛП). Альтернативный способ получения чека (требуется VPN CRPT_VIP): http://storage.prod01.rtng.crpt.tech/documents/URCPT00000000000000601596-9863 получаем JSON чека, аналогично как квитанцию (на случай если кибана не работает) Примеры отбивок (будет дополняться): Отсутствуют необходимые теги: В полученном чеке отсутствуют обязательные теги: 1191 - propertiesItem 1084 - properties 1085 - propertyName 1086 - propertyValue Обратитесь к поставщику кассового оборудования, для прошивки кассы. С документацией по формированию чеков для ФГИС МДЛП можно ознакомиться по ссылкам: Формат записи данных о выбытии в ФФД: https://честныйзнак.рф/upload/iblock/644/Format-zapisi-dannykh-o-vybytii-LP-v-FFD.pdf Протокол информационного обмена ОФД: https://xn--80ajghhoc2aj1c8b.xn--p1ai/upload/iblock/34f/Protokol_informatsionnogo_obmena_OFD.pdf Участник спрашивает на каком основании должны быть эти теги: Регулятором в сфере обращения лекарственных средств является Минздрав РФ. Значения реквизитов тегов 1191 и 1084 определяются Минздравом России (МЗ) в следующем порядке: 1.1. Значения реквизитов ФД «дополнительный реквизит пользователя» (тег 1084) и «дополнительный реквизит предмета расчета» (тег 1191), согласно примечаниям No12 к таблице 19 и No3 к таблице 20 Приказа ФНС от 21 марта 2017 г. N ММВ-7-20/229@(далее–Приказ ФНС), не определяются ФНС России, а определяются «с учетом особенностей сферы деятельности». 1.2. Согласно пункту 32 постановления Правительства РФ N 1556 от 14.12.2018, форматы данных, направляемых участниками в ИС МДЛП, определяются Оператором системы по согласованию с МЗ РФ. 1.3. На основании вышеизложенного, порядок заполнения реквизитов ФД «дополнительный реквизит пользователя» (тег 1084) и «дополнительный реквизит предмета расчета» (тег 1191) определяется Оператором ИС МДЛП в настоящем документе, согласовывается с МЗ РФ и публикуются на сайте Честный ЗНАК.РФ в разделе «Маркировка лекарств», в подразделе «Документы», в блоке «Разработчикам». 2. Версии настоящего документа, утратившие актуальность при публикации новой версии, размещаются Оператором ИС МДЛП на сайте ЧестныйЗНАК. РФ в разделе «Маркировка лекарств», в подразделе «Документы», в блоке «Документы, утратившие актуальность». https://честныйзнак.рф/upload/iblock/644/Format-zapisi-dannykh-o-vybytii-LP-v-FFD.pdf Неправильно закодирован SGTIN: В полученном чеке неправильно закодирован SGTIN. Серийный номер указан перед GTIN. Поле 1162 -"productCode": "AAMEL16ndHBJM0RTSDRVMDAwUjBJ" При расшифровке получается: FK63898544F3504603988016757 (GTIN выделен полужирным) Правильный SGTIN: 04603988016757FK63898544F35 (GTIN выделен полужирным) Обратитесь к поставщику кассового оборудования, для доработки кассы. С документацией по формированию чеков для ФГИС МДЛП можно ознакомиться по ссылкам: Формат записи данных о выбытии в ФФД: https://честныйзнак.рф/upload/iblock/644/Format-zapisi-dannykh-o-vybytii-LP-v-FFD.pdf Протокол информационного обмена ОФД: https://xn--80ajghhoc2aj1c8b.xn--p1ai/upload/iblock/34f/Protokol_informatsionnogo_obmena_OFD.pdf 3. В чеке имеется тег «buyerInn»: Тег «buyerInn» означает оптовую продажу лекарственных препаратов (ЛП) другому юридическому лицу. Аптеки без оптовой лицензии не могут осуществлять оптовую продажу ЛП и, следовательно, тег «buyerInn» не используют. ЛП для собственных нужд организации закупают в розницу. Если имеется оптовая лицензия: При продаже ЛП организации с фарм./мед. лицензией через ККТ: в чеке указывается тег «buyerInn», из-за чего он не попадает в ФГИС МДЛП. Сведения передаются с помощью схем 415/416. 2. При продаже ЛП организации не имеющей фарм./мед. лицензий через ККТ: В чеке НЕ указывается тег «buyerInn» и в ФГИС МДЛП формируется схема продажи ЛП в розницу (10511). Дополнительных действий производить не требуется. 4. В теге "quantity" указано значение отличное от 1 Ошибка связана с тем, что в теге 1023 "quantity" указано некорректное значение. Для товарной группы лекарственных препаратов в данном теге з Обратитесь к поставщику кассового оборудования, для прошивки кассы. С документацией по формированию чеков для ФГИС МДЛП можно ознакомиться по ссылкам: Формат записи данных о выбытии в ФФД: https://честныйзнак.рф/upload/iblock/644/Format-zapisi-dannykh-o-vybytii-LP-v-FFD.pdf Протокол информационного обмена ОФД: https://xn--80ajghhoc2aj1c8b.xn--p1ai/upload/iblock/34f/Protokol_informatsionnogo_obmena_OFD.pdf Продажу SGTIN из данного чека можете произвести с помощью 511 схемы, но для осуществления последующих продаж необходимо доработать кассовое оборудование. Доп ресурсы: http://gtin-registry.apps.prod01.gismt.crpt.tech проверка GTIN (ожидаем от Полуянова пример запроса для получения информации) Контакты ОФД:
ФФД 1.2 Новая Kibana: https://ellie.rtng.crpt.tech Для входа нужен VPN CRPT_VIP Логин/пароль: выдача доступов в процессе. Пока доступов нет – обращаться к Панкратовой Татьяне или Пичужкину Никите Позволяет искать JSON чеков по ФФД 1.05/1.1 и квитанции по ФФД 1.05/1.1/1.2 Особенность: чеки и квитанции только новые, старые искать в старой кибане. В 10511 / 10522 по ФФД 1.2 указывается номер квитанции нового образца. Квитанция старого образца: UTXMNGR00000000000000327737-3127 Квитанция нового образца: 55694abe-d5cc-49ba-aae1-35ba20514186  Квитанции все также можно скачивать по ссылке (нужен VPN CRPT_VIP) как старого, так и нового образца (ПРОД): https://tx-manager.prod01.rtng.crpt.tech/api/v1/transactions/55694abe-d5cc-49ba-aae1-35ba20514186 то, что выделено желтым цветом меняем на свой номер. Для песочницы: https://tx-manager.int01.rtng.crpt.tech/api/v1/transactions/517d240d-d376-47e8-8b80-388ce02f60d5 Пример квитанции:  JSON чека / уведомления по его номеру можно скачать по ссылке (нужен VPN CRPT_VIP)(ПРОД): http://storage.prod01.rtng.crpt.tech/documents/5b379bce-7a02-4aec-898d-2f8703248e45 то, что выделено желтым цветом меняем на свой номер. Можно использовать как номер чека, так и номер уведомления. Пример номера чека: URCPT00000000000000324760-3916 Пример номера уведомления: 5b379bce-7a02-4aec-898d-2f8703248e45 Для песочницы: https://storage.int01.rtng.crpt.tech/documents/d23bbd38-9eb9-4abd-af20-dd35d7ed4e82 Пример уведомления по ФФД 1.2: Контур: Песок Квитанция: dcce9e01-9779-4c82-ad53-06860142b1a9 Док: 0fd7cb75-7a7a-48b3-8e42-71e3fc9e6009 Желтым цветом выделены номера тегов (это для удобства, в самом JSON этих номеров нет) { "receipt": { 1022? "code": 82, 1012 "dateTime": 1629449760, 2002 "fiscalDocumentNumber": 22, 1041 "fiscalDriveNumber": "9999078902008018", 1018 "userInn": "3106006713 ", 1009 "retailAddress": "", 1055 "taxationType": 1, "ofdId": "ofd05_t", 1037? "kktRegId": "", 2116 "indicationfiscalSign": 1, 1189?1190? "fiscalDocumentFormatVer": 4, 1054 "operationType": 1, 1042 "requestNumber": 22, 1261 "additionalProperties": [], 1059? "items": [ { 2000 "codeString": "010460702776893521000000013JBSF\u001D91xuza\u001D92dGVzdGifC5FkjETjJhotf7m8rsjQHeoNyxcpaEIZfDQ=", 2100 "productCodeType": 3, 2101 "productId": "010460702776893521000000013JBSF", 2102 "productCodeProcessingMode": 0, 2110 "productStatus": 1, 2106 "productCheckResult": 5, 1214 "paymentType": 4, 1030 "name": "1.Гепарин 30 РјРі в„– 20(РЈРџРђРљ)", 1079 "price": 12000, 1043 "sum": 12000, 1199 "nds": 5, 1260 "additionalProperties": [ { 1262 "foivId": "020", 1264 "documentNumber": "1556", 1263 "documentDate": "14.12.2018", 1265 "industryDetails": "tm=mdlp&sid=12121212121212&" } ], 1023 "quantity": 1.0, 2108 "productUnitMeasure": 0, 1162? "productCode": "RE0EMKhA7mcwMDAwMDAwMTNKQlNG", 1293,1294 "propertiesItem": "mdlp", "valid": true, "found": true, "verified": false, "validationMessage": "AI 91 for [010460702776893521000000013JBSF\u001D91xuza\u001D92dGVzdGifC5FkjETjJhotf7m8rsjQHeoNyxcpaEIZfDQ=] is invalid" } ], ДАННЫЙ БЛОК ФОРМИРУЕТСЯ АВТОМАТИЧЕСКИ НА ОСНОВАНИИ ТЕГА 1260 1017? "ofdINN": "7704211201", 1084 "properties": { 1085 "propertyName": "mdlp", 1086 "propertyValue": "sid12121212121212" }, "hasIncorrectCodes": true } } На текущий момент, если попадется вопрос по ФФД 1.2, нам также нужен чек. Из чека нам нужны рег. Номер фискального накопителя (он же ФН, он же fiscalDriveNumber) и время ("dateTime"). Номер фискального документа (он же ФД, он же fiscalDocumentNumber) – НЕ ПОДХОДИТ!! В ФФД 1.2 ФД у чека не совпадает с ФД уведомления! Можно сопоставлять ФД из уведомления и квитанции, но НЕЛЬЗЯ сопоставлять ФД из уведомления и чека (чек, который выдается на кассе). По ФН и дате можно найти квитанцию в новой кибане, а в квитанции номер уведомления и скачать по ссылке. Также косячные уведомления можно поискать в кафке. Также потребуется ФН, ФД, ИНН, дата. Для поиска в кафке обращаться к Соколову Юрию или Панкратовой Татьяне. Вебинар ФФД 1.2: https://честныйзнак.рф/lectures/videoarhiv/?ELEMENT_ID=237111&STREAM=1 Поиск чеков по ФФД 1.2 Для поиска новых чеков в старой кибане необходимо: Первый способ – перевести sgtin в поле productCode и искать в фильтре по параметру receipt.items.productCode:  Второй способ – фильтровать по ИНН и полю dateTime Просмотр чеков в Kibana за определённый промежуток времени. Заходим на сайт: https://www.cy-pr.com/tools/time/ Находим пункт «Unix дата начала и конца года, месяца или дня» В показать год/месяц/день выбираем нужный период, за который нужно просмотреть чеки Иные временные промежутки за определённые даты и время можно сгенерировать самому в пункте «Конвертивание эпохи Unix в человекопонятную дату(human readable date)»  После нажатия на кнопку «Преобразовать» копируем значение строк «Начало периода» и «Конец периода», после чего переходим в Кибану.  Нажимаем на «Add filter». В поле «Field» указывается значение «receipt.dateTime», в поле «Operator» указывается «is between», после чего в левой строке выбирается значение начала периода, а в правой конца периода. После нажатия кнопки «Save» отобразятся все чеки за указанный период. Наработка кейсов по ФФД 1.2: 10511 сформирована с sys_id вместо МД, в уведомлении не заполнен тег «additionalProperties» (этот тег должен быть заполнен для каждой позиции товаров – выделено желтым, а не общий на уведомление – выделено красными крестами).  Ответ участнику: В полученном уведомлении отсутствуют обязательные теги: 1262 - идентификатор ФОИВ 1263 - дата документа основания 1264 - номер документа основания 1265 - значение отраслевого реквизита Обратитесь к поставщику кассового оборудования / программного обеспечения, для доработки кассы. Формат записи данных о выбытии в ФФД: https://честныйзнак.рф/upload/iblock/644/Format-zapisi-dannykh-o-vybytii-LP-v-FFD.pdf |