У drebedengi данные тянутся с разношёрстных форм ОФД, а не с сервера налоговой. Хотя есть и преимущество — не нужна регистрация и фиксация чеков через приложение налоговой.
Жуткого вида башевый скрипт
Для использования скрипта нужны номер телефона и пароль полученный при регистрации по СМС. Умеет вытаскивать конкретный документ по 3 параметрам: ФН (номер фискального накопителя), ФД (номер фискального документа) и ФП (подпись фискального документа). При запуске без параметров вытягивает все зарегистрированные через официальное приложение документы.
Теперь ждём скорой поломки «неофициального API»…
К сожалению, любое благое начинание сходит на нет при хромающей на обе ноги реализации. Сам пытаюсь использовать новые «блага» и смотреть с некоторой долей оптимизма на нововведения, но опыт разработчика кассового ПО осаживает на бренную землю и не даёт однозначно положительно оценивать изменения.
Открытого API нет, но запросы сниффером легко анализируются. Свои чеки выгружаю простеньким скриптом. Главное иметь регистрационные данные и регистрировать чеки через приложения, хотя и это можно реализовать самостоятельно при определённой мотивации.
После начала эксплуатации аналогичного WCF-сервиса столкнулись с тем, что порт, по которому происходит обмен слушает не приложение/служба, а какой-то системный процесс. Сначала это вызвало некоторый диссонанс при настройке файрвола, а позже выяснилось, что ещё и сниффер (Wireshark) не видит этих пакетов, даже будучи запущенным из под администратора. Сталкивались вы с такими «особенностями»?
Тоже работаю на нижнем уровне ради кроссплатформенности, но отказываться от поддержки каких-то производителей не позволит огромная клиентская база. Да и в конечном счёте даже у хвалённого мной Пирита вылазят всякие новые неожиданности вроде успешного закрытия документа, даже если команда закрытия завершилась с ошибкой.
Сбербанк на конференциях, абсолютно не стесняясь, рекламирует себя как обработчика BigData, а "Data" у них ну прям очень "Big". В этой ситуации меня удивляет не сам факт слива статистических данных, а тот факт, что они позволяют зарабатывать на ней сторонним конторам вроде гугла.
Я, даже покупая квартиру, не снимал наличку для этого, а перевёл с Тинькова по межбанку на нужный счёт в том же Сбербанке, открытый на моё имя для сделки. Без комиссий. Расскройте пожалуйста секрет зачем в современных реалиях снимать миллионы наличкой физ. лицу (кроме мутных схем конечно).
Речь же идёт не о локальной подмене скрипта, а о возможности подмены его со стороны "метрик", не принадлежащих сбербанку. Эта ситуация не может быть проконтролирована ни пользователем, ни Сбербанком без глубокого анализа, т.к. сертификат Сбербанка фактически здесь не участвует, а данные (скрипты) со стороны "метрик" будут выглядеть вполне легитимными, будучи подтвержденными их (метрик) сертификатами. Вот и получается ситуация, когда без особого привлечения внимания можно поменять скрипт на пару дней для сбора "нужных данных".
Портировали в своё время своё кассовое ПО на мобильную ARM-based систему. Проблемы начинаются с китайских toolchain'ов с криво реализованными драйверами оборудования, на исправление которых китайские товарищи слегка забивают, а исправить самостоятельно не выйдет, т.к. все допилы GPL-ного ядра тупо закрыты и к их открытию отношение производителя однозначное — «ФИГ» (<sarcasm>я так понял это по китайски GPL</sarcasm>). А окончательно проект хоронится после обнаружения, что с терминалом банка X можно работать только через ПО, скомпилированное под x86.
PS На самом деле все проблемы в итоге были решены, но в процессе мучительного «решения» заказчик потерял интерес к железке, видимо насмотревшись как огребают разработчики.
Да там всё в открытом виде — отреверсить не проблема. Вопрос только в телефоне для регистрации и получения пароля для обмена с налоговой.
Для использования скрипта нужны номер телефона и пароль полученный при регистрации по СМС. Умеет вытаскивать конкретный документ по 3 параметрам: ФН (номер фискального накопителя), ФД (номер фискального документа) и ФП (подпись фискального документа). При запуске без параметров вытягивает все зарегистрированные через официальное приложение документы.
Теперь ждём скорой поломки «неофициального API»…
А не тянет ли это на заявление в прокуратуру в связи с отсутствием ответа по существу заявления от гос. органа в установленный законодательством срок?
Сбербанку мало данных смертных — нужно ещё больше, попутно подзаработав и на торговцах: https://news.rambler.ru/business/37147373-sberbank-predlozhil-predostavit-bankam-vozmozhnost-okazyvat-uslugi-virtualnyh-kass/
Я прям заинтригован кто же первый получит на эту "деятельность" лицензию и останется фактическим монополистом пока через пару лет кто нибудь не поднимет шумиху и не вынудит ФАС разбираться...
Сбербанк на конференциях, абсолютно не стесняясь, рекламирует себя как обработчика BigData, а "Data" у них ну прям очень "Big". В этой ситуации меня удивляет не сам факт слива статистических данных, а тот факт, что они позволяют зарабатывать на ней сторонним конторам вроде гугла.
Данный кейс имеет право на жизнь, просто он не про меня. Спасибо за конкретный пример.
Я, даже покупая квартиру, не снимал наличку для этого, а перевёл с Тинькова по межбанку на нужный счёт в том же Сбербанке, открытый на моё имя для сделки. Без комиссий. Расскройте пожалуйста секрет зачем в современных реалиях снимать миллионы наличкой физ. лицу (кроме мутных схем конечно).
Речь же идёт не о локальной подмене скрипта, а о возможности подмены его со стороны "метрик", не принадлежащих сбербанку. Эта ситуация не может быть проконтролирована ни пользователем, ни Сбербанком без глубокого анализа, т.к. сертификат Сбербанка фактически здесь не участвует, а данные (скрипты) со стороны "метрик" будут выглядеть вполне легитимными, будучи подтвержденными их (метрик) сертификатами. Вот и получается ситуация, когда без особого привлечения внимания можно поменять скрипт на пару дней для сбора "нужных данных".
PS На самом деле все проблемы в итоге были решены, но в процессе мучительного «решения» заказчик потерял интерес к железке, видимо насмотревшись как огребают разработчики.