Comments 84
Не исключено, что в дальнейшем чек, в котором присутствует тэг 1008 будет сверяться и при несовпадении — не отдаваться… То бишь нельзя будет посмотреть «чужие» чеки.
ФНС это надо? Для подтверждения одного из обоснований введения онлайн-касс они приложение запилили, что-то как-то работает, не думаю что в обозримом будущем будут какие-то изменения — на это просто не будет предусмотрен бюджет.
Типа «безопасность»)
С какой стати мол мой чек будет изучать Вася Пупкин, коль они не работники органов и ФМС…
Ну и это существенно может разгрузить сервера фнс — если не будет возможности массово «вытягивать» чеки — api потеряет привлекательность для сторонних сервисов
С какой стати мол мой чек будет изучать Вася Пупкин, коль они не работники органов и ФМС…
Ну и это существенно может разгрузить сервера фнс — если не будет возможности массово «вытягивать» чеки — api потеряет привлекательность для сторонних сервисов
Внутри организации проверку чеков может проводить бухгалтерия, к примеру, или внутренний аудит/контроль.
Если речь о своих чеках — то для этого у них есть «X» и «Z» отчеты в ккм и само-собой доступ к админке ОФД
Я о чеках, предоставляемых сотрудниками в подтверждение расходов. Командировки, мелкие покупки и т.п.
Ну это тоже разовые, легальные действия. И вероятнее всего через web-морду сайта налоговой.
В маленькой компании это так. В большой логичнее было бы это автоматизировать — сканировать все чеки и проверять их с использованием API, чтобы было быстрее (сейчас проверка одного чека занимает несколько секунд) или чтобы не задерживать сотрудника (пока он сканирует чеки, система в фоне их проверяет).
Я к тому, что пока не очень понимаю, в каких еще сценариях этот API может пригодиться.
Я к тому, что пока не очень понимаю, в каких еще сценариях этот API может пригодиться.
Ну как вариант сценария — навороченный документооборот большого предприятия, где сотрудник владивостокского филиала заполняет электронную форму отчета о командировке, сканируя туда чеки, система валидирует и калининградская головная компания принимает отчет к расходам…
Но как мне кажется тут подсуетятся те же ОФД или кто-то наподобии и за небольшую денежку будут предоставлять подобный сервис…
Окажись это такском и т.п. — они с фнс договорятся, а кто-то просто с улицы — увы и скорее всего получит палки в колеса…
Но как мне кажется тут подсуетятся те же ОФД или кто-то наподобии и за небольшую денежку будут предоставлять подобный сервис…
Окажись это такском и т.п. — они с фнс договорятся, а кто-то просто с улицы — увы и скорее всего получит палки в колеса…
Главное, чтобы 1С договорился ;)
я работаю в компании федерального уровня, в тч с филиалами за границей и QR код наших бухгалтеров никак не интересует. им важно чтоб были соблюдены другие требования (например наличие печати на чеке/товарнике и тп), которые QR кодом никак не контролируется (но наличие которых требуется для правильной отчетности).
кроме чеков есть еще например бланки строгой отчетности, в которых нет никакого QR кода. поэтому QR код не может быть основой учета.
ну и в завершении добавлю что большие компании все расчеты в основном ведут по безналу, обычно на основании договора и в рамках заранее запланированного бюджета, поэтому чеков не будет настолько много что их потребуется автоматизировать.
кроме чеков есть еще например бланки строгой отчетности, в которых нет никакого QR кода. поэтому QR код не может быть основой учета.
ну и в завершении добавлю что большие компании все расчеты в основном ведут по безналу, обычно на основании договора и в рамках заранее запланированного бюджета, поэтому чеков не будет настолько много что их потребуется автоматизировать.
не нашел в статье, о каком теге 1008 идет речь?
В статье про него нет. Это один из атрибутов «Формата Фискальных Данных» — этакого стандарта передаваемых данных от софта в ккм и из ккм в офд. Конкретно он звучит как «абонентский номер и (или) адрес электронной почты покупателя (клиента) в случае передачи ему кассового чека (БСО) в электронной форме ». Обычно если таковой тэг будет заполнен — от оператора фискальных данных прилетит на этот адрес/телефон «электронный чек».
Ну и собственно при наличии этих данных напрашивается та самая фильтрация «кому показывать чеки».
Ну и собственно при наличии этих данных напрашивается та самая фильтрация «кому показывать чеки».
спасибо за объяснения, уверен, что данный тип «защиты» явно внедряться не будет, т.к. зависит от корректности заполнения данных со стороны продавца, а на текущий момент допускаются гораздо более существенные нарушения 54 ФЗ.
Если ФНС озаботиться закрытием доступа к API, я думаю они просто усложнят протокол, аутентификацию и т.д., чтобы было более сложно «эмулировать» приложение (а энтузиастов интересующихся этой проблемой не так много), но и это маловероятно, похоже, что они поставили приложение и бэкэнд «на паузу».
Озаботиться вопросом безопасности их может заставить только сильный резонанс в СМИ.
Если ФНС озаботиться закрытием доступа к API, я думаю они просто усложнят протокол, аутентификацию и т.д., чтобы было более сложно «эмулировать» приложение (а энтузиастов интересующихся этой проблемой не так много), но и это маловероятно, похоже, что они поставили приложение и бэкэнд «на паузу».
Озаботиться вопросом безопасности их может заставить только сильный резонанс в СМИ.
Собственно в 54ФЗ и тем более в его реализациях сырости — воз и маленькая тележка…
Притом фнс тут вообще не последняя инстанция. По идее они ведь просто переправляют к одному из офд (по данным чека), у каждого из которых может быть или не быть уникальный api
Притом фнс тут вообще не последняя инстанция. По идее они ведь просто переправляют к одному из офд (по данным чека), у каждого из которых может быть или не быть уникальный api
То есть для просмотра чека мне нужен не только номер чека, но электронная почта, телефон, прописка и справка от нарколога? Что-то сомневаюсь.
Тогда уж сразу разрешать покупки только после авторизации в госуслугах
Тогда уж сразу разрешать покупки только после авторизации в госуслугах
Пока только номер фискального накопителя, регистрационный номер ККТ, ИНН, ФД и ФПД
И если что — это не я )
И если что — это не я )
«номер фискального накопителя, регистрационный номер ККТ, ИНН, ФД и ФПД» — это cтруктурированный глобальный идентификатор документа, не более того.
Только последовательность правильнее ИНН-ККТ-ФП-ФД+ФПД
Только последовательность правильнее ИНН-ККТ-ФП-ФД+ФПД
Тут сложно говорить о правильной последовательности. Разные ОФД идентифицируют чек по-разному:
1-ofd просит ФН, ФД, ФПД
ofd — ФН+Рег№ККТ+ИНН+ФД+ФПД
такском — ФПД+сумма
офд-я — Рег№ККТ+ФПД
На форуме разработчиков одного из ККМ на тему уникальности чека в рамках ккм/организации/глобально — вообще разброд и шатания )
1-ofd просит ФН, ФД, ФПД
ofd — ФН+Рег№ККТ+ИНН+ФД+ФПД
такском — ФПД+сумма
офд-я — Рег№ККТ+ФПД
На форуме разработчиков одного из ККМ на тему уникальности чека в рамках ккм/организации/глобально — вообще разброд и шатания )
> На форуме разработчиков одного из ККМ на тему уникальности чека в рамках ккм/организации/глобально — вообще разброд и шатания )
Ну вот как раз комплект ИНН-ККТ-ФП-ФД должен быть уникальным, по построению
Ну вот как раз комплект ИНН-ККТ-ФП-ФД должен быть уникальным, по построению
Теоретически — да.
На практике — стоит ориентироваться на то, что в чеке в «уголках»:
дата-время, сумма, Рег№, ФН№, ФД№, ФПД
Серийник ккт + №ФН — неплохо уникализируют аппаратку, а ФПД — вообще хэш транзакции
buhexpert8.ru/wp-content/uploads/2017/12/image006-23.png
На практике — стоит ориентироваться на то, что в чеке в «уголках»:
дата-время, сумма, Рег№, ФН№, ФД№, ФПД
Серийник ккт + №ФН — неплохо уникализируют аппаратку, а ФПД — вообще хэш транзакции
buhexpert8.ru/wp-content/uploads/2017/12/image006-23.png
Что такое «тэг 1008»?
Для проверки чека нужны Фискальный Номер, Фискальный документ, ФПД — подобрать эту комбинацию, как я понимаю, невозможно. Так что без чека проверить чужой чек — уже невозможно.
Для проверки чека нужны Фискальный Номер, Фискальный документ, ФПД — подобрать эту комбинацию, как я понимаю, невозможно. Так что без чека проверить чужой чек — уже невозможно.
Не удивлюсь, если завтра это заблокируют или просто изменят формат ответа
Т.е. хоть данные и обезличенные в целом — они передаются 3м лицам. Это просто замечательно.
(Мои догадки) В качестве единицы используется параметр с QR-кода в чеке, помеченный в начале статьи, как n=1тоже на уровне догадок, но по-моему это флаг, приход/расход, в обычных чеках только приход.
Расход можно найти если сделать возврат товара (пробивается «возвратный» чек).
Получить «чужие» чеки из фнс практически невозможно, требуются поля, на основании которых вычисляется ФПД, по этим данным (номер чека, рег номер, дата-время, сумма + возможно, та самая n=1), до получения чека налоговой она и устанавливается валидность документа.
Некоторые ОФД требуют меньше данных для проверки и получения тела чека, вот это уже серьезней.
Не видел стандарта формата, но по собственной базе чеков находил очень интересные поля, такие как:
— частичный номер банковской карты которой выполнялась оплата
— флаг, что товар бонусный / акционный
и еще много других, но заполненных как попало (были и грубые нарушения — пустой НДС в позициях, но с данными на тотале/заголовке чека).
Насколько я понимаю: 4 последние цифры банковской карты — часто печатается на месте расчетов, но вот в тэгах для отправки — не встречал.
Бонусный, акционный и всяческие выигрыши в лотерею — пока частично и опционально, вот как ФФД1.1 будет принят — там пожестче.
Просто для представления: www.garant.ru/products/ipo/prime/doc/71540610
Если совсем коротко:
цена, количество, сумма, наименование + виды оплат (нал/электронные) — совсем обязательно, а аванс/задаток/итп, товар/услуга/тара, классификаторы — пока еще не совсем
Бонусный, акционный и всяческие выигрыши в лотерею — пока частично и опционально, вот как ФФД1.1 будет принят — там пожестче.
Просто для представления: www.garant.ru/products/ipo/prime/doc/71540610
Если совсем коротко:
цена, количество, сумма, наименование + виды оплат (нал/электронные) — совсем обязательно, а аванс/задаток/итп, товар/услуга/тара, классификаторы — пока еще не совсем
n=1 — это код системы налогообложения, 1 это ОСН(Общая система налогообложения)
Не понимаю, зачем привязка к номеру телефона и еще email? Что мешает проверять чек без них?
Там не привязка, а «куда отправлять электронный чек». А привязка — это мое лишь предположение. Ну чисто исходя из злокозненности фискалов)
p/s/ хотя если посмотреть на методы регистрации/авторизации многих ресурсов — при утере доступа к e-mail — можно считать аккаунты там потеряными… ну и сложившиеся практики против ботов («то ли email то ли пароль неверны»)
p/s/ хотя если посмотреть на методы регистрации/авторизации многих ресурсов — при утере доступа к e-mail — можно считать аккаунты там потеряными… ну и сложившиеся практики против ботов («то ли email то ли пароль неверны»)
Для получения полного содержимого чека? Это просто авторизация, апи то закрытое.
Проверить, что чек валиден, можно и без этого (но содержимое так не получить).
Еще как одна из функций — большой брат привязывает чеки к номеру телефона. В общую схему цифровизации и шпионажа государства / спец служб за гражданами отлично вписывается (единственное пока недостаток — гражданин сам должен зарегистрироваться и заливать чеки)
Проверить, что чек валиден, можно и без этого (но содержимое так не получить).
Еще как одна из функций — большой брат привязывает чеки к номеру телефона. В общую схему цифровизации и шпионажа государства / спец служб за гражданами отлично вписывается (единственное пока недостаток — гражданин сам должен зарегистрироваться и заливать чеки)
Да это пока и не надо. А вот более адекватные оценки вмененного дохода — это к бабке не ходить. Притом для большинства регионов окажется что «патенты» подорожают, так как фактические показатели дохода (на основе регистрации по чекам) окажутся заметно выше прошлых виртуальных оценок из которых вычислялась стоимость патента…
А расходы граждан — это надо внедрять систему подоходного налога наподобии американской: большая ставка и море понижающих условий — тогда у самих граждан будет стимул регистрировать свои расходы для вычетов.
А расходы граждан — это надо внедрять систему подоходного налога наподобии американской: большая ставка и море понижающих условий — тогда у самих граждан будет стимул регистрировать свои расходы для вычетов.
Зря вас минусуют. В целом, вы правильно говорите, но не надо паранойи. Тут скорее всего удобство отслеживания государством или же банками на основе БигДата ваших предпочтений и предсказаний того, что и как у вас дальше будет. Банкам проще в случае безнала, так как они знают номер чека (он передаётся, что выяснили в другой статье), а настроив парсер, смогут забирать и другие данные, по которым будут выстраивать «модель клиента», на основании которого можно будет предлагать ему индивидуальные тарифы и услуги.
Являясь автором приложения для учета расходов под андроид, тоже реализовал у себя загрузку чеков с сервера ФНС. Исходники можно глянуть на гитхабе .
В целом согласен, что данный сервис не несет угроз безопасности, так как, по сути, выдает цифровую копию бумажного чека, который должен быть у вас уже на руках.
В целом согласен, что данный сервис не несет угроз безопасности, так как, по сути, выдает цифровую копию бумажного чека, который должен быть у вас уже на руках.
В посте комментарий с ссылкой на чек натолкнул меня на мысли, что по некоторым реквизитам можно перебирать и получать чеки даже без авторизации на ОФД-порталах.
На 06.08.2017 из 12 ОФД публичный API для проверки кассовых чеков есть у 9 (отсюда):
Первый ОФД (Ашан, Виктория, Пятёрочка, BILLA, Магнит)
Платформа ОФД (Дикси, Крошка-картошка)
Такском (Карусель, KFC)
OFD.RU (Связной) — потребуется ручной ввод РН ККТ и ИНН с чека
ОФД-Я (Перекрёсток) — потребуется ручной ввод РН ККТ с чека (ИНН необязателен)
Астрал ОФД
ОФД Яндекс
СБИС
КОРУС ОФД
Думаю, перебор и получение персональных данных чеков/клиентов всё же возможны, но нахожусь в Украине и не могу проверить это, так как попросту не имею чеков.
На 06.08.2017 из 12 ОФД публичный API для проверки кассовых чеков есть у 9 (отсюда):
Первый ОФД (Ашан, Виктория, Пятёрочка, BILLA, Магнит)
Платформа ОФД (Дикси, Крошка-картошка)
Такском (Карусель, KFC)
OFD.RU (Связной) — потребуется ручной ввод РН ККТ и ИНН с чека
ОФД-Я (Перекрёсток) — потребуется ручной ввод РН ККТ с чека (ИНН необязателен)
Думаю, перебор и получение персональных данных чеков/клиентов всё же возможны, но нахожусь в Украине и не могу проверить это, так как попросту не имею чеков.
Не совсем понимаю опасения комментаторов выше про безопасность «кражи информации о чеках». Чеки не содержат персонализированную информацию(касающуюся покупателя) и самое страшное что там можно увидеть — это товар, им приобретенный.
Та в том-то и дело, что есть: пример. В чеке может быть указан e-mail или телефон покупателя.
А ещё можно номер карты увидеть, если оплата картой. А дальше — дело техники, особенно для банков.
Не по теме, конечно, но интересно — есть ли у них защита от фрода при запросе нового пароля — восстановления? Если нет, то можно в своих целях использовать как бесплатное уведомление по смс о какой-либо ситуации (понятное дело, что будет приходить новый пароль, но это можно имитировать как триггер некоего события), при условии, что сам сервис проверки чеков не нужен.
sendToEmail=no — а не пробовали передать туда сам имейл? или массив имейлов (судя по ошибке может и такое быть)
Судя по ошибке «No enum match for...» там перечисление и yes, для этого перечисления как раз подходит. Почту попробовал туда ввести возвращает то же самое "[«No enum match for: some@mail.com»]".
Подозреваю, что оно у них просто не настроено и падает, тем более, что их приложение этим, вроде бы и не пользуется.
Подозреваю, что оно у них просто не настроено и падает, тем более, что их приложение этим, вроде бы и не пользуется.
406 получаем у свежего чека. Через некоторое время он появляется в налоговой.
Реализация на java
«daily limit reached for the specified user» через 10-15 запросов. Так что забейте, пишите парсеры на формы проверки чеков.
Так всё-таки, из этой информации непонятно, чек содержит полную информацию, или только частичную? Например, 20 товаров в супермаркете или блюд кафе в одном чеке — будет информация про все 20 или только общая сумма?
Если все позиции, то это же не стыкуется с приватностью вообще.
В полученном чеке содержится вся информация, но приватность не нарушается, так как для доступа к ней нужен выданнный чек, который получает только тот, кто и так знает, что в нём.
Если реквизиты человек решит разделить с третьей стороной, то да, третья сторона может получить полную информацию.
Поэтому с приватностью здесь всё хорошо.
UFO just landed and posted this here
Ну так есть разные уровни приватности, ОФД немного и у них довольно обезличенная информация, так просто привязать её к человеку не просто. Плюс это лицензируемая деятельность, так что уверенности в сохранности чуть больше.
UFO just landed and posted this here
Я не совсем тогда понимаю, в чём именно вы видите нарушение приватности в осуществлении торговой сделки:
продавец знает, что вы купили и за сколько; ОФД знает, что купили, но не знает кто; банк знает за сколько купили, но не знает что.
Возможно ФНС может сопоставить платёж и чек, но я в этом сомневаюсь.
На мой взгляд баланс между требованиями ФНС и приватностью соблюдён.
UFO just landed and posted this here
54-ФЗ не предусматривает передачу данных, полученых ОФД третьим лицам.
А ОФД нужны, потому что у нас капитализм: у нас по многим позициям создаются посредники, которые реализуют нужные для государства функции и при этом участвуют в товарно-денежных отношениях с гражданами и организациями. Идея, как мне кажется, в том, чтобы такие организации конкурировали между собой и улучшали качество получаемых от государства услуг.
UFO just landed and posted this here
Я больше верю математике, чем законам ))
Государство ведь выступает как регулятор, а математика это лишь технические меры, которыми оно может поручить использовать. Поэтому у него ничего кроме законов нет.
И да, как тогда работает всё это API?
А это не ОФД выдаёт, а ФНС обладателю чека, здесь нет третих лиц.
UFO just landed and posted this here
Далеко не все. Более того, список тегов которые уходят в ОФД довольно небольшой, количество данных в них тоже жестко лимитировано. Потому что они хранятся внутри ФН который имеет ограниченный объем. По крайне мере сейчас ФНС просто интересует контроль финансовых потоков в цепочке поставки товаров. Что бы тратить как можно меньше сил при начислении налогов/сборов/поборов продавцам. И своей цели они добились, собираемость сильно повысилась. Онлайн кассы сейчас можно видеть даже на простых овощных лотках на улице.
В мобильном приложении одного банка есть замечательная функция.
Если нажать на операцию по карте aka «покупка в супермаркете», то можно увидеть список купленных товаров. Т.е. банк прекрасно знает, что и за сколько я купил.
Если нажать на операцию по карте aka «покупка в супермаркете», то можно увидеть список купленных товаров. Т.е. банк прекрасно знает, что и за сколько я купил.
В полученном чеке содержится вся информация
Нет, не вся. Есть ряд реквизитов чека которые позволяют его однозначно идентифицировать. При этом расширенная информация ОФД оператором может у себя храниться, а может и не храниться. В налоговую же уходят только данные не выходящие за значение тегов описанных в спецификации ФФД. А там довольно небольшой объем данных.
Частичную. Налоговую интересуют только поступившие суммы и используемый режим для автоматического расчета налогов. Поэтому ни состава заказа, ни тем более названия конкретных товаров там нет.
Все на столько плохо в плане полноты инфы, что когда делаешь сверку чеков которые есть в ОФД (и налоговой), то сопоставить их со своими реальными чеками проблематично. На столько, что пришлось ID заказа писать в тег 1086. Ни во что другое его вписать невозможно в принципе.
Выложили свою библиотеку для Питона для работы с официальным апи ФНС:
pypi.org/project/fnsapi
pypi.org/project/fnsapi
Sign up to leave a comment.
Универсальный API для получения информации по чекам