Универсальный API для получения информации по чекам +31

Привет жителям Хабра.

В данной статье хотелось бы рассказать про API для получения чеков, которое нам не предоставила всеми любимая ФНС.

Когда только появились QR-коды на чеках я подумал «Вау, как круто! Ты сканируешь код и видишь если не всю инфу по чеку, то ссылку на него». И какого же было мое разочарование, когда просканировав такой код я увидел что-то вроде

t=20180518T220500&s=975.88&fn=8710000101125654&i=99456&fp=1250448795&n=1

Но расстраиваться я не стал и подумал, что ФНС позаботилась о нас и предоставила API для получения такой информации. Погуглив некоторое время я понял, что ФНС нам предоставила только мобильное приложение для проверки чека и просмотра той информации, что поступила к ним от магазина.

Но! Между магазином и налоговой имеется ещё одно звено — ОФД — те, кто обрабатывают информацию по чекам, полученную от магазинов, и отправляют в налоговую. Вот они то и предоставляют API для получения нужной нам информации. Не все. И не всегда бесплатно.

Судя по информации из википедии по состоянию на 1 марта 2018 зарегистрировано 17 ОФД. Допустим 10 из них предоставляют открытое и бесплатное API. Учитывая то, что мы не знаем с каким ОФД работает конкретный магазин, нужно будет пройтись по API 10 операторов фискальных данных. Далеко не лучший вариант.

Спустя какое-то время, я случайно наткнулся на приложение (не от ФНС), которое по QR-коду с чека получает информацию по чеку. Не будут же они «пробегать» по всем ОФД и собирать оттуда информацию — подумал я. Снова отправился в гугл и наткнулся на такой ответ.

Казалось, после этого ответа можно заканчивать импровизированное расследование, но у меня оставались ещё вопросы:

  • Что будет, если использовать другие заголовки?
  • Что делать, если пользователь не зарегистрирован? Скачивать мобильное приложение и регистрироваться? (Сайт ФНС не предоставляет возможности зарегистрироваться в этом контексте)
  • А если забыл пароль?

Запустив Android Device Monitor и SoapUI я начал разбираться. Выкладываю здесь всю обобщенную информацию, что удалось получить. ФНС предоставляет следующее публичное API:

Регистрация
POST
https://proverkacheka.nalog.ru:9999/v1/mobile/users/signup
Content-Type: application/json; charset=UTF-8

Содержимое:

{"email":"some@mail.com","name":"SomeName","phone":"+79991234567"}

Все параметры обязательные.

Если результат успешен, то пользователь создается, СМС с паролем отправляется на указанный номер, а в ответ возвращается 204 No content.

Если пользователь уже существует, то возвращается 409 Conflict и сообщение «user exists».
Если номер телефона некорректный, то возвращается 500 Internal Server Error и сообщение «failed with code 20101».

Если адрес электронной почты некорректный, то возвращается 400 Bad Request и сообщение "[«Object didn't pass validation for format email: <адрес электронной почты, который вы указали>»]".
Если адрес электронной почты уже используется, а телефон нет, то ошибок не возникает и регистрация проходит успешно.

Логин
GET
https://proverkacheka.nalog.ru:9999/v1/mobile/users/login

В заголовке передается Pre-emptive Basic Authorization, где в качестве username передается номер телефона, в виде "+79991234567", а в качестве пароля — код, полученный в смс при регистрации или восстановлении пароля.

Если все хорошо, то вернется 200 OK и сообщение в виде json

{
   "email": "<адрес электронной почты, указанный при регистрации>",
   "name": "<имя, указанное при регистрации>"
}

Если указать некорректный номер телефона или пароль, то вернется 403 Forbidden и сообщение «the user was not found or the specified password was not correct».

Если не указать номер телефона и/или пароль, то не вернется ничего.

Восстановление пароля
POST
https://proverkacheka.nalog.ru:9999/v1/mobile/users/restore
Content-Type: application/json; charset=UTF-8

Содержимое:

{"phone":"+79991234567"}

Если номер телефона найден, то возвращается 204 No Content и на телефон приходит СМС с новым паролем.

Если номер телефона не найден или номер некорректный, то возвращается 404 Not Found и сообщение «the user was not found».

Проверка существования чека
GET
https://proverkacheka.nalog.ru:9999/v1/ofds/*/inns/*/fss/<номер ФН>/operations/1/tickets/<номер ФД>?fiscalSign=<номер ФПД>&date=2018-05-17T17:57:00&sum=3900
Где

  • Номер ФН (Фискальный Номер) — 16-значный номер. Например 8710000100518392
  • Номер ФД (Фискальный документ) — до 10 знаков. Например 54812
  • Номер ФПД (Фискальный Признак Документа, также известный как ФП) — до 10 знаков. Например 3522207165
  • (Мои догадки) В качестве единицы используется параметр с QR-кода в чеке, помеченный в начале статьи, как n=1
  • Дата — дата с чека. Формат может отличаться. Я пробовал переворачивать дату (т.е. 17-05-2018), ставить вместо Т пробел, удалять секунды
  • Сумма — сумма с чека в копейках

Если чек найден, то вернется 204 No Content.
Если чек не найден, то вернется 406 Not Acceptable.
Если дата/сумма некорректная или не совпадает с датой/суммой, указанной в чеке, то возвращается 406 Not Acceptable. При этом секунды не учитываются.
Если не указать параметр дата/сумма, то возвращается 400 Bad Request и сообщение "[«Missing required property: <property_name>»]".

Получение детальной информации по чеку
GET
https://proverkacheka.nalog.ru:9999/v1/inns/*/kkts/*/fss/<Номер ФН>/tickets/<Номер ФД>?fiscalSign=<Номер ФПД>&sendToEmail=no
Где

  • Номер ФН (Фискальный Номер) — 16-значный номер. Например 8710000100518392
  • Номер ФД (Фискальный документ) — до 10 знаков. Например 54812
  • Номер ФПД (Фискальный Признак Документа, также известный как ФП) — до 10 знаков. Например 3522207165
  • (Мои догадки) В качестве единицы используется параметр с QR-кода в чеке, помеченный в начале статьи, как n=1

Также обязательно указать хотя бы пустые заголовки device-id и device-os
Если указаны некорректные данные пользователя, то возвращается 403 Forbidden и сообщение «the user was not found or the specified password was not correct».

Если не указать номер телефона и/или пароль, то ничего не вернется.

Если чек не найден, то возвращается 406 Not Acceptable. Также чек может быть не найден, если он был получен достаточно давно. ФНС не хранит информацию по чекам за все время. На момент написания этой статьи ФНС хранила детальную информацию порядка 2-3 месяцев.

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

Если в параметре «sendToEmail» попытаться подставить значение «yes», то вернется 500 Internal Server Error и сообщение «connect ECONNREFUSED 127.0.0.1:465». При попытке подставить другие значения («true», 1 и т.д.) вернется 400 Bad Request и сообщение "[«No enum match for: <значение, которое пытались передать>»]".

Если всё хорошо, то вернется 200 ОК и содержимое в формате json примерно такого вида:

{"document": {"receipt": {
   "operationType": 1,
   "fiscalSign": 3522207165,
   "dateTime": "2018-05-17T17:57:00",
   "rawData": "AwAzAREEEAA4NzEwMDAwMTAwNTE4MzEzDQQUADAwMDExOTM1MTQwNDE0MDUgICAg+gMMADc4MjU3MDYwODYgIBAEBAAJ2gAA9AMEAGzC/Vo1BAYAMQTSDyLSDgQEABYBAAASBAQAogAAAB4EAQAB/AMCADwPPAQPAD0EAwCKrqQ+BAQARzYzNyMERQAGBCcAKjM0OTIyNzcgTkVTVC6MruAuTUFYSUIukZKQgJeAkoWLLjE0MKyrNwQCAJ8P/wMEAAZAQg8TBAIAnw9PBAIAbAH9Aw4AhK6ro+PopaKgIICtraAHBAIAPA85BAEAAE8EAgBsARgEDACAo+Cu4q7goyCOjo7xAyoANjIwMDE3LCCjLiCFqqDipeCoraHj4KMsIOOrLiCAp6itoCwgpC4gMTimHwQBAAE=",
   "totalSum": 3900,
   "nds10": 364,
   "userInn": "7825706086",
   "taxationType": 1,
   "operator": "<Данные кассира>",
   "fiscalDocumentNumber": 54812,
   "properties": [   {
      "value": "G637",
      "key": "Код"
   }],
   "receiptCode": 3,
   "requestNumber": 162,
   "user": "Агроторг ООО",
   "kktRegId": "0001193514041405",
   "fiscalDriveNumber": "8710000100518392",
   "items": [   {
      "sum": 3999,
      "price": 3999,
      "name": "*3492277 NEST.Мор.MAXIB.СТРАЧАТЕЛ.140мл",
      "quantity": 1,
      "nds10": 364
   }],
   "ecashTotalSum": 0,
   "retailPlaceAddress": "620017, г. Екатеринбург, ул. Азина, д. 18ж",
   "cashTotalSum": 3900,
   "shiftNumber": 278
}}}

Где

  • все суммы указаны в копейках
  • данные кассира в разных магазинах имеют разные форматы (в одном случае может вернуться «Фамилия Имя», в другом «Фамилия И. должность»
  • порядок элементов может меняться
  • разные магазины используют разные наборы параметров и, если какой-то параметр возвращается в чеке от одного магазина, то не факт, что этот параметр будет в чеке от другого магазина
  • формат адреса магазина может различаться

Ещё один пример возвращаемого чека
{"document": {"receipt": {
   "cashTotalSum": 0,
   "fiscalSign": 1301551154,
   "nds18": 4859,
   "operationType": 1,
   "userInn": "7728029110",
   "dateTime": "2018-05-18T22:05:00",
   "fiscalDocumentNumber": 12654,
   "receiptCode": 3,
   "ecashTotalSum": 97588,
   "nds10": 5976,
   "requestNumber": 395,
   "retailPlaceAddress": "г.Екатеринбург, ул.Сулимова, д.50",
   "fiscalDriveNumber": "871000010459859",
   "taxationType": 1,
   "user": "АО ТД Перекресток",
   "operator": "<Данные кассира>",
   "items":    [
            {
         "sum": 3799,
         "quantity": 1,
         "price": 3799,
         "name": "18074 Укроп пакет 100г",
         "nds10": 345
      },
            {
         "sum": 7490,
         "quantity": 0.872,
         "nds18": 1143,
         "name": "2000339 Яблоки СЕЗОН.ПРЕДЛОЖЕНИЕ 1кг",
         "price": 8590
      }
   ],
   "totalSum": 97588,
   "rawData": "AwD5BREEEAA4NzEwMDAwMTAxMzM3NjU5DQQUADAwMDEyNDg4ODgwNDkzNDEgICAg+gMMADc3MjgwMjkxMTAgIBAEBAAocAEA9AMEAAxO/1o1BAYAMQRNlDKEDgQEAAYBAAASBAQAiwEAAB4EAQAB/AMDADR9ASMEMwAGBBYAMTgwNzQgk6rgrq8gr6CqpeIgMTAwozcEAgDXDv8DAwAD6AMTBAIA1w5PBAIAWQEjBEEABgQkADIwMDAzMzkgn6GrrqqoIJGFh46NLo+QhYSLjoaFjYiFIDGqozcEAgCOIf8DAwADaAMTBAIAQh1OBAIAdwQjBD4ABgQiACozMDc3NDA0IJGPryCBoKOl4iDhIKrjrabj4q6sIDE1MKM3BAIAxwP/AwMAA9AHEwQCAI4HTwQBALAjBDkABgQcADMyMjYzMTQgjKDhq64giJCBiJKRio6FIDE4MKM3BAIA7ir/AwMAA+gDEwQCAO4qTwQCAOcDIwQ5AAYEHQAqMzIyNjQzNCCKoODiruSlq+wg4KCtraipIDGqozcEAgDGB/8DAwAD5gMTBAIAwgdPBAEAtSMENQAGBBkAKjMyMjY0NDAgi+OqIJCFj5eAkpuJIDGqozcEAgDGB/8DAwADWAETBAIArQJPBAEAPiMENwAGBBoAKjMyMjczOTEgg+Dj6KggipCAkY2bhSAxqqM3BAIAPx//AwMAA2IBEwQCABALTgQCALABIwQyAAYEFQAzMjI3NDAzIICvpavs4ait6yAxqqM3BAIArx3/AwMAA14CEwQCAP0RTgQCAL4CIwQ9AAYEIAAzMjU1MjQ4IIyu4Kquouwgr64tqq7gpanhqqggMTAwozcEAgBkMv8DAwADRgETBAIAbRBOBAIAgQIjBDsABgQeADMzMzAzNjggkayl4qCtoCAyMCUgr6sv4eIgNDAwozcEAgCmHf8DAwAD6AMTBAIAph1PBAIAsgIjBD8ABgQiADMzMzkxMjYgiq6q4qWpq+wgl5OEjiCYjoqOi4CEIDk2MKM3BAIAGyX/AwMAA+gDEwQCABslTwQCAGADIwRCAAYEJgAzMzgzNTY4IIDgoOWo4SBOQVRVUkZPT0RTIKag4KWt66kgMTAwozcEAgA3Y/8DAgADyBMEAgDYE04EAgAHAyMEPwAGBCMAkzM0MTQzOTMgiqXkqOAggYWLm4UgkI6RmyAzLDIlIDUwMKM3BAIANAj/AwMAA+gDEwQCADQITwQBAL8jBD0ABgQgADM0MjYyNjgggq6koCCXhZCNjoOOi46CkYqAnyAxLDWrNwQCAC0J/wMDAAPoAxMEAgAtCU4EAgBmASMEMAAGBBMAMzQyNzU5OCCMrquuqq4gMCw5qzcEAgCkC/8DAwAD6AMTBAIApAtPBAIADwEjBD0ABgQgADM0NDMwOTMgkqKu4K6jIIiQgYiSkYqIiSCMhyAzNTCjNwQCABki/wMDAAPoAxMEAgAZIk8EAgAaAyMEMAAGBBQAMzQ0NTIxOCCPpeLg4+iqoCA1MKM3BAIAlwj/AwMAA+gDEwQCAJcITwQBAMgjBDoABgQdADM0ODQzMTUgn6nmriCKkJODi5uJIIOOhCAxMOjiNwQCAPcR/wMDAAPoAxMEAgD3EU8EAgCiASMEQAAGBCMAMzQ5NTA4MCCCrqSgIEpFWUVBIENSWVNUQUxOQVlBIDAsNas3BAIAsxT/AwMAA+gDEwQCALMUTgQCACgDIwQ9AAYEIAAzNTAzMzY2IIqu4qul4usgipCTg4ubiSCDjoQgNDUwozcEAgBXG/8DAwAD6AMTBAIAVxtPBAIAfAIjBDkABgQdADM2MDExMjIgiuDjr6Agn5eNhYKAnyD8MiA4MDCjNwQCAGcG/wMDAAPoAxMEAgBnBk8EAQCV/QMUAJHj5aDgpaKgII4goOHhqOHipa3iBwQBAAA5BAMANH0BTgQCAPsSTwQCAFgXGAQRAICOIJKEII+l4KWq4KXh4q6q8QMhAKMuhaqg4qXgqK2h4+CjLCDjqy6R46uorK6ioCwgpC41MB8EAQAB",
   "shiftNumber": 262,
   "kktRegId": "0001248888049341"
}}}



Особого смысла в логине я не вижу, но он используется в их мобильном приложении. Возможно, в дальнейшем он для чего-нибудь пригодится.

Кому интересен пример реализации подключения к этому API, вот ссылка на гитхаб проект библиотеки, написанной на C#.

По всем вопросам или замечаниям прошу в комментарии.

UPD После небольшой проверки выяснилось, что ФНС не хранит детальную информацию по всем чекам. По крайней мере у меня 22.05.2018 не удалось получить полный чек от декабря 2017, января и февраля 2018, при том, что у ОФД эта информация имеется и мобильное приложение ФНС сообщает, что чек корректен. За март 2018 чек получить уже удалось.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (61):

  1. d-stream
    /#11364252

    Не исключено, что в дальнейшем чек, в котором присутствует тэг 1008 будет сверяться и при несовпадении — не отдаваться… То бишь нельзя будет посмотреть «чужие» чеки.

    • SDKiller
      /#11364258

      ФНС это надо? Для подтверждения одного из обоснований введения онлайн-касс они приложение запилили, что-то как-то работает, не думаю что в обозримом будущем будут какие-то изменения — на это просто не будет предусмотрен бюджет.

      • d-stream
        /#11364260

        Типа «безопасность»)

        С какой стати мол мой чек будет изучать Вася Пупкин, коль они не работники органов и ФМС…

        Ну и это существенно может разгрузить сервера фнс — если не будет возможности массово «вытягивать» чеки — api потеряет привлекательность для сторонних сервисов

        • aakolov
          /#11364398

          Внутри организации проверку чеков может проводить бухгалтерия, к примеру, или внутренний аудит/контроль.

          • d-stream
            /#11364430

            Если речь о своих чеках — то для этого у них есть «X» и «Z» отчеты в ккм и само-собой доступ к админке ОФД

            • aakolov
              /#11364470

              Я о чеках, предоставляемых сотрудниками в подтверждение расходов. Командировки, мелкие покупки и т.п.

              • d-stream
                /#11364488

                Ну это тоже разовые, легальные действия. И вероятнее всего через web-морду сайта налоговой.

                • aakolov
                  /#11364500

                  В маленькой компании это так. В большой логичнее было бы это автоматизировать — сканировать все чеки и проверять их с использованием API, чтобы было быстрее (сейчас проверка одного чека занимает несколько секунд) или чтобы не задерживать сотрудника (пока он сканирует чеки, система в фоне их проверяет).

                  Я к тому, что пока не очень понимаю, в каких еще сценариях этот API может пригодиться.

                  • d-stream
                    /#11364506

                    Ну как вариант сценария — навороченный документооборот большого предприятия, где сотрудник владивостокского филиала заполняет электронную форму отчета о командировке, сканируя туда чеки, система валидирует и калининградская головная компания принимает отчет к расходам…
                    Но как мне кажется тут подсуетятся те же ОФД или кто-то наподобии и за небольшую денежку будут предоставлять подобный сервис…

                    Окажись это такском и т.п. — они с фнс договорятся, а кто-то просто с улицы — увы и скорее всего получит палки в колеса…

                    • aakolov
                      /#11364510

                      Главное, чтобы 1С договорился ;)

                      • d-stream
                        /#11364514

                        Ну после этого уже будет «на всех торрентах» )

                    • balamutang
                      /#11365008

                      я работаю в компании федерального уровня, в тч с филиалами за границей и QR код наших бухгалтеров никак не интересует. им важно чтоб были соблюдены другие требования (например наличие печати на чеке/товарнике и тп), которые QR кодом никак не контролируется (но наличие которых требуется для правильной отчетности).

                      кроме чеков есть еще например бланки строгой отчетности, в которых нет никакого QR кода. поэтому QR код не может быть основой учета.

                      ну и в завершении добавлю что большие компании все расчеты в основном ведут по безналу, обычно на основании договора и в рамках заранее запланированного бюджета, поэтому чеков не будет настолько много что их потребуется автоматизировать.

                      • d-stream
                        /#11365858

                        Это один из вариантов. У меня есть клиенты платящие за распознавалку паспортов, ву, стс при потоке клиентов 3-5-10 в день.
                        Своего рода гики. Вот там иногда фанатзия по автоматизации бьет фонтаном (небесплодным).

    • IvanG
      /#11364404 / +1

      не нашел в статье, о каком теге 1008 идет речь?

      • d-stream
        /#11364422 / +1

        В статье про него нет. Это один из атрибутов «Формата Фискальных Данных» — этакого стандарта передаваемых данных от софта в ккм и из ккм в офд. Конкретно он звучит как «абонентский номер и (или) адрес электронной почты покупателя (клиента) в случае передачи ему кассового чека (БСО) в электронной форме ». Обычно если таковой тэг будет заполнен — от оператора фискальных данных прилетит на этот адрес/телефон «электронный чек».

        Ну и собственно при наличии этих данных напрашивается та самая фильтрация «кому показывать чеки».

        • IvanG
          /#11364434

          спасибо за объяснения, уверен, что данный тип «защиты» явно внедряться не будет, т.к. зависит от корректности заполнения данных со стороны продавца, а на текущий момент допускаются гораздо более существенные нарушения 54 ФЗ.

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

          • d-stream
            /#11364448

            Собственно в 54ФЗ и тем более в его реализациях сырости — воз и маленькая тележка…
            Притом фнс тут вообще не последняя инстанция. По идее они ведь просто переправляют к одному из офд (по данным чека), у каждого из которых может быть или не быть уникальный api

            • IvanG
              /#11364520

              я считал, и до сих пор считаю, что ОФД высылают данные в ФНС, а не наоборот.
              При обращении к апи фнс, полагаю данные напрямую из базы налоговой берутся.

              • d-stream
                /#11364526

                Физически цепочка ккм->офд->налоговая

                Но вот является ли она окончательным хранилищем или же все-таки ОФД выступают в виде «распределенной БД» — точно не скажу. То что мне попадалось в публикациях звучало именно в виде «налоговая перенаправляет на конкретного офд»

        • areht
          /#11364616

          То есть для просмотра чека мне нужен не только номер чека, но электронная почта, телефон, прописка и справка от нарколога? Что-то сомневаюсь.

          Тогда уж сразу разрешать покупки только после авторизации в госуслугах

          • d-stream
            /#11364738

            Пока только номер фискального накопителя, регистрационный номер ККТ, ИНН, ФД и ФПД

            И если что — это не я )

            • areht
              /#11367546

              «номер фискального накопителя, регистрационный номер ККТ, ИНН, ФД и ФПД» — это cтруктурированный глобальный идентификатор документа, не более того.

              Только последовательность правильнее ИНН-ККТ-ФП-ФД+ФПД

              • d-stream
                /#11368156

                Тут сложно говорить о правильной последовательности. Разные ОФД идентифицируют чек по-разному:
                1-ofd просит ФН, ФД, ФПД
                ofd — ФН+Рег№ККТ+ИНН+ФД+ФПД
                такском — ФПД+сумма
                офд-я — Рег№ККТ+ФПД

                На форуме разработчиков одного из ККМ на тему уникальности чека в рамках ккм/организации/глобально — вообще разброд и шатания )

                • areht
                  /#11368180

                  > На форуме разработчиков одного из ККМ на тему уникальности чека в рамках ккм/организации/глобально — вообще разброд и шатания )

                  Ну вот как раз комплект ИНН-ККТ-ФП-ФД должен быть уникальным, по построению

                  • d-stream
                    /#11368208

                    Теоретически — да.
                    На практике — стоит ориентироваться на то, что в чеке в «уголках»:
                    дата-время, сумма, Рег№, ФН№, ФД№, ФПД

                    Серийник ккт + №ФН — неплохо уникализируют аппаратку, а ФПД — вообще хэш транзакции

                    buhexpert8.ru/wp-content/uploads/2017/12/image006-23.png

                    • areht
                      /#11368302

                      Вы таки хотите сказать, что «Рег№, ФН№, ФД№, ФПД» могут дублироваться с разными датой-временем?

                      Если кто-то решает идентифицировать по хешу — ну, это их проблемы. Наверное, они знают что делают, но я бы не стал. А вот добавить некое контрольное число в полноценный ID — это нормально.

                      • d-stream
                        /#11368358

                        Вы таки хотите сказать, что «Рег№, ФН№, ФД№, ФПД» могут дублироваться с разными датой-временем?
                        нет

    • and7ey
      /#11364420

      Что такое «тэг 1008»?

      Для проверки чека нужны Фискальный Номер, Фискальный документ, ФПД — подобрать эту комбинацию, как я понимаю, невозможно. Так что без чека проверить чужой чек — уже невозможно.

      • d-stream
        /#11364458

        Кстати глянул в первые попавшиеся чеки, точнее что разные ОФД просят:
        — такскому достаточно ФПД и суммы
        — офд-я — рег номера ккм и фпд
        — офд.ру — аж пать полей с чека

  2. Z55
    /#11364332

    Не удивлюсь, если завтра это заблокируют или просто изменят формат ответа

    • zelenin
      /#11364498

      сломав всех клиентов этого апи

      • IvanG
        /#11364522

        Коих, судя по всему, не мало. Из популярных — различные сервисы кэшбека за товары из чеков.

        Интересно — они такую же серую схему использования API применяют? И при том не заботятся имитацией официального приложения?

  3. Nosgoth
    /#11364402

    Т.е. хоть данные и обезличенные в целом — они передаются 3м лицам. Это просто замечательно.

    • IvanG
      /#11364414

      Не понял, кого под третьими лицами имеете в виду?

    • Sabubu
      /#11364476

      В чеке ведь нет вашей фамилии, все, что вы можете узнать, даже если подберете номер — что кто-то в таком-то магазине в такое-то время что-то купил. Если вы в очередь встанете, вы и так сможете увидеть, что он покупает.

      • alexkbs
        /#11364908

        Нет проблем! Вы можете указать любой номер телефона, никакой проверки отправкой SMS магазины не делают.

  4. IvanG
    /#11364410

    (Мои догадки) В качестве единицы используется параметр с QR-кода в чеке, помеченный в начале статьи, как n=1
    тоже на уровне догадок, но по-моему это флаг, приход/расход, в обычных чеках только приход.
    Расход можно найти если сделать возврат товара (пробивается «возвратный» чек).

    Получить «чужие» чеки из фнс практически невозможно, требуются поля, на основании которых вычисляется ФПД, по этим данным (номер чека, рег номер, дата-время, сумма + возможно, та самая n=1), до получения чека налоговой она и устанавливается валидность документа.
    Некоторые ОФД требуют меньше данных для проверки и получения тела чека, вот это уже серьезней.

    Не видел стандарта формата, но по собственной базе чеков находил очень интересные поля, такие как:
    — частичный номер банковской карты которой выполнялась оплата
    — флаг, что товар бонусный / акционный
    и еще много других, но заполненных как попало (были и грубые нарушения — пустой НДС в позициях, но с данными на тотале/заголовке чека).

    • d-stream
      /#11364442

      Насколько я понимаю: 4 последние цифры банковской карты — часто печатается на месте расчетов, но вот в тэгах для отправки — не встречал.
      Бонусный, акционный и всяческие выигрыши в лотерею — пока частично и опционально, вот как ФФД1.1 будет принят — там пожестче.

      Просто для представления: www.garant.ru/products/ipo/prime/doc/71540610

      Если совсем коротко:
      цена, количество, сумма, наименование + виды оплат (нал/электронные) — совсем обязательно, а аванс/задаток/итп, товар/услуга/тара, классификаторы — пока еще не совсем

    • x1ca4064
      /#11364646

      n=1 — это код системы налогообложения, 1 это ОСН(Общая система налогообложения)

      • IvanG
        /#11364752

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

        • x1ca4064
          /#11365894

          Согласен. Почему-то повторил эту ошибку — засело в голове, что это СНО.

  5. Sabubu
    /#11364482

    Не понимаю, зачем привязка к номеру телефона и еще email? Что мешает проверять чек без них?

    • d-stream
      /#11364492

      Там не привязка, а «куда отправлять электронный чек». А привязка — это мое лишь предположение. Ну чисто исходя из злокозненности фискалов)

      p/s/ хотя если посмотреть на методы регистрации/авторизации многих ресурсов — при утере доступа к e-mail — можно считать аккаунты там потеряными… ну и сложившиеся практики против ботов («то ли email то ли пароль неверны»)

    • IvanG
      /#11364516

      Для получения полного содержимого чека? Это просто авторизация, апи то закрытое.
      Проверить, что чек валиден, можно и без этого (но содержимое так не получить).

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

      • d-stream
        /#11364554

        Да это пока и не надо. А вот более адекватные оценки вмененного дохода — это к бабке не ходить. Притом для большинства регионов окажется что «патенты» подорожают, так как фактические показатели дохода (на основе регистрации по чекам) окажутся заметно выше прошлых виртуальных оценок из которых вычислялась стоимость патента…

        А расходы граждан — это надо внедрять систему подоходного налога наподобии американской: большая ставка и море понижающих условий — тогда у самих граждан будет стимул регистрировать свои расходы для вычетов.

      • vozhd99
        /#11365274

        Зря вас минусуют. В целом, вы правильно говорите, но не надо паранойи. Тут скорее всего удобство отслеживания государством или же банками на основе БигДата ваших предпочтений и предсказаний того, что и как у вас дальше будет. Банкам проще в случае безнала, так как они знают номер чека (он передаётся, что выяснили в другой статье), а настроив парсер, смогут забирать и другие данные, по которым будут выстраивать «модель клиента», на основании которого можно будет предлагать ему индивидуальные тарифы и услуги.

  6. EdvLav
    /#11364690

    Являясь автором приложения для учета расходов под андроид, тоже реализовал у себя загрузку чеков с сервера ФНС. Исходники можно глянуть на гитхабе .

    В целом согласен, что данный сервис не несет угроз безопасности, так как, по сути, выдает цифровую копию бумажного чека, который должен быть у вас уже на руках.

    • inoyakaigor
      /#11367208

      Вы не пробовали в своём приложении вытащить все чеки из ФНС? Это вообще возможно?

      • EdvLav
        /#11367272

        Насколько я понял, ФНС не предоставляет такой возможности. Даже их приложение этого не может.

      • EdvLav
        /#11368046

        Был не прав, их приложение это умеет. Мое пока нет.

  7. Gorodnya
    /#11364808

    В посте комментарий с ссылкой на чек натолкнул меня на мысли, что по некоторым реквизитам можно перебирать и получать чеки даже без авторизации на ОФД-порталах.

    На 06.08.2017 из 12 ОФД публичный API для проверки кассовых чеков есть у 9 (отсюда):
    Первый ОФД (Ашан, Виктория, Пятёрочка, BILLA, Магнит)
    Платформа ОФД (Дикси, Крошка-картошка)
    Такском (Карусель, KFC)
    OFD.RU (Связной) — потребуется ручной ввод РН ККТ и ИНН с чека
    ОФД-Я (Перекрёсток) — потребуется ручной ввод РН ККТ с чека (ИНН необязателен)
    Астрал ОФД
    ОФД Яндекс
    СБИС
    КОРУС ОФД

    Думаю, перебор и получение персональных данных чеков/клиентов всё же возможны, но нахожусь в Украине и не могу проверить это, так как попросту не имею чеков.

  8. gzdzie
    /#11365002

    Не совсем понимаю опасения комментаторов выше про безопасность «кражи информации о чеках». Чеки не содержат персонализированную информацию(касающуюся покупателя) и самое страшное что там можно увидеть — это товар, им приобретенный.

    • Gorodnya
      /#11365244

      Та в том-то и дело, что есть: пример. В чеке может быть указан e-mail или телефон покупателя.

    • vozhd99
      /#11365286

      А ещё можно номер карты увидеть, если оплата картой. А дальше — дело техники, особенно для банков.

      • d-stream
        /#11365328

        Не, данных карты туда не летит. По крайней мере таких тэгов мне не попадалось ни в описании ФФД атрибутов ни в полях драйвера ккм

  9. Mixalych
    /#11365636

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

  10. ErgoZru
    /#11366680

    sendToEmail=no — а не пробовали передать туда сам имейл? или массив имейлов (судя по ошибке может и такое быть)

    • Apollon_Diamed
      /#11366742

      Судя по ошибке «No enum match for...» там перечисление и yes, для этого перечисления как раз подходит. Почту попробовал туда ввести возвращает то же самое "[«No enum match for: some@mail.com»]".
      Подозреваю, что оно у них просто не настроено и падает, тем более, что их приложение этим, вроде бы и не пользуется.

      • ErgoZru
        /#11367458

        просто предположил, учитывая что вроде как есть функционал для отправки на имейл, если мне не изменяет память. Спасибо за ответ. Надо бы пакет для go по-быстрому себе накатать)))

        • Apollon_Diamed
          /#11367502

          В организации, в которой я работаю, за отправку чеков на почту (телефон) отвечает атол. Возможно ошибаюсь и за это отвечает ОФД, но я точно уверен, что это делает не ФНС.

          • ErgoZru
            /#11369060

            Вполне возможно и так. Тем более учитывая апдейт к статье, что фнс не долго хранит инфу о чеке…