Обновить

Как я парсил банковские платёжки всех российских банков на Python: история боли, костылей и XML-матрёшек

Время на прочтение17 мин
Охват и читатели6.4K
Всего голосов 9: ↑9 и ↓0+10
Комментарии25

Комментарии 25

Прямо ЦБшный УФЭБС не могут отдавать? Каждый придумывает свой велосипед?

Такой прикол документооборота, получил бумажку сначала сам, а потом передал 1С. Я так же задавался вопросом почему та))

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

Очень странно для кредитной организации не реализовывать УФЭБС в своём клиент-банке, если они и так обязаны общаться (наверное, всё ещё в КБР-Н) посредством оного с подразделениями ЦБ.

Всё верно, согласен с вами, но зато спасибо им за крутой кейс))

Насколько бы упростилась жизнь разработчиков и программистов, если бы все отдавали документы по одному стандарту))))

Ох, знакомо. Скажите спасибо, что Вам ещё бинарный .doc не достался, но советую на всякий случай готовиться :)

А ещё бывают банковские выписки, там тоже кто во что горазд (Excel с десятком-другим скрытых столбцов? объединённые вдоль и поперёк ячейки? по ячейке на каждую букву? - легко).

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

Документооборот через файлики в клиентбанке - он для людей, не для машин. Для машин у банков есть API / H2H механизмы обмена. Их и надо было использовать, а не решать задачу в лоб.

Как я понимаю, это Сизов труд, поскольку никто не даёт гарантий на структуру документа и может менять её хоть каждый день. Не говоря о том, что изменения будут настолько маленькими, что парсер не сломается, но его результатом будет ошибки Хотя ситуация, где какой-то человек сверяет 2 изображения (как охранник на проходной) похоже останется ещё на коды

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

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

К сентябрю появится УПД - универсальный платёжный документ, который вроследствии может повлечь коренную перестройку всех документов...

Что за бред я только что прочитал? Буквально у всех российских банков есть интеграция с 1С из коробки.
Что автор парсил? в чем суть задачи?

Вы, видимо, не дочитали статью (или прочитали только заголовок), поэтому поясню суть задачи.

Речь не про «загрузить выписку в 1С через стандартный обмен с банком». Это действительно умеет каждый банк из коробки, и статья совсем не об этом.

Задача: на вход приходит готовый документ (PDF, WORD, RTF) - банковская выписка, в которой лежат от 10 до 10 000 платёжных поручений. Нужно:

  1. Распарсить таблицу выписки - вытащить структурированные данные по каждой платёжке (дата, номер, сумма, назначение и т.д.).

  2. Найти в этом же документе страницу с конкретным платёжным поручением и вырезать её в отдельный файл.

  3. Вернуть всё это в 1С как JSON с base64-документами.

Зачем это нужно, если «есть интеграция из коробки»? Потому что это решение делалось не под ИП «Ромашка», а под крупную корпорацию, которая мигрировала с SAP. У них годами выстроенные бизнес-процессы, в которых работают именно с оригинальными документами банков - в том виде, в котором банк их сформировал. Им нужны оригиналы платёжек как отдельные документы, привязанные к распарсенным данным. Стандартная интеграция банк-клиента с 1С этого не делает - она загружает транзакции, а не парсит банковские PDF/DOCX/RTF с сохранением оригиналов.

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

Не совсем понимаю, что такое "оригиналы платежек как отдельные документы". Это прям бумажные документы которые ваши контрагенты распечатали, ногами принесли в банк и отдали на оплату? Или все-таки электронные?

Стандартная интеграция банк-клиента с 1С этого не делает - она загружает транзакции, а не парсит банковские PDF/DOCX/RTF с сохранением оригиналов

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

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

Такое делается не от хорошей жизни, а под требования крупного заказчика, мигрирующего с SAP: у них бизнес-процессы завязаны именно на банковских документов в том виде, как их сформировал банк. Никакая «интеграция из коробки» этого не даёт - она транзакции грузит, а не PDF-ки режет.

Странно, что это приходится объяснять вам. Сходите к условной Марье Петровне и объясните ей. Я разработчик который демонстрирует на Хабре, как на площадке кейсы, а размышлять о смыслах дело уже других...

Девушка хочет цветы, а вы ей шлёте эмодзи тюльпанчика, 2026 год же на дворе))))

Какая разница крупный заказчик или нет и с какой программы переходит? В чем ваша Цель резать PDF-ки или загрузить в базу информацию, которая соответствуют платежным поручениям, отправленными вашим контрагентом?
Если цель загрузить информацию, то вы идете не по той дороге. Скорее всего, когда внедряли SAP не существовало личных кабинетов в банках и , вероятно, был какой-то смысл в парсинге.

Девушка хочет цветы, а вы ей шлёте эмодзи тюльпанчика, 2026 год же на дворе))))

В аналогии можно играть вдвоем.

В вашем случае заказчик пересел с телеги в автомобиль и понял, что ему нужно ездить в темное время суток.
Решаем проблему: сажаем на велосипед чувака с фонарем и отправляем вперед.

Никто же не сказал, что можно просто включить фары.

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

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

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

Цифровизация она такая.

Зачем у вас дома лежит паспорт, можно же избавиться от всех бумаг, цифровизация)))

Мой паспорт хранится у меня дома как физическое, верифицированное государством, отражение информации хранящейся в электронном виде на серверах государства. Я не предъявляю бумажный паспорт при запросе документов в электронном виде. Да и вы тоже. Электронный документ, заверенный электронной же подписью, равнозначен бумажному, подписанному собственноручно.

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

В итоге бы получилась задача куда проще: на вход приходит готовый документ в едином формате для любого банка (например, XML в формате ISO 20022) - банковская выписка, в которой лежат от 0 (выписка может быть пустой, но с балансом) до ХХХ платёжных поручений. Нужно:

  1. Сформировать печатную форму по шаблону и сохранить в файл.

  2. Вернуть всё это в 1С как JSON с base64-документами.

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

Марья Петровна, другого мнения))) Она считает, что бумага должна быть в том стиле который ей даёт конкретный банк, в том стиле в котором у неё в физическом архиве лежат распечатки... Ну и так далее, копия физического с маппиная с json данными из общей банковской выписки из одного скаченного дока в ЛК банка. Почему напали на меня я не понимаю, основывайте свою компанию и делайте там как удобно вам. Везде свои приколы)) Я лишь демонстрирую реализацию просьбы клиента

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

Я напал не на вас, я напал на идею решать этот бизнес-процесс таким способом.

За усилия - уважуха, разобраться с этим зоопарком дорогого стоит.

Ну с такими приколами и живём, не поступали бы такие задачи, не о чем писать бы было)))

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

Шёл 2026й год.

Банки уже давным давно обзавелись API, H2H сервисами или настроили себе интеграцию через типовой 1С.ДиректБанк.

На рынке есть решения позволяющие унифицировать обмен с любым банком на основе стандартизированного API, работающего через XML ISO 20022.

Но люди предпочитают парсить файлики. Это печально.

Также, ответ на ваш комментарий можете прочитать выше

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации