Comments 25
Прямо ЦБшный УФЭБС не могут отдавать? Каждый придумывает свой велосипед?
Такой прикол документооборота, получил бумажку сначала сам, а потом передал 1С. Я так же задавался вопросом почему та))
Я предполагаю, что это, скорее всего, недоработки коммуникации менеджмента/бухгалтерии заказчика и кредитных организаций.
Очень странно для кредитной организации не реализовывать УФЭБС в своём клиент-банке, если они и так обязаны общаться (наверное, всё ещё в КБР-Н) посредством оного с подразделениями ЦБ.
Насколько бы упростилась жизнь разработчиков и программистов, если бы все отдавали документы по одному стандарту))))
Ох, знакомо. Скажите спасибо, что Вам ещё бинарный .doc не достался, но советую на всякий случай готовиться :)
А ещё бывают банковские выписки, там тоже кто во что горазд (Excel с десятком-другим скрытых столбцов? объединённые вдоль и поперёк ячейки? по ячейке на каждую букву? - легко).
Вот кстати да, больная тема и полный абсурд. XML широко распространён уже 25 лет. На собесе в средний банк спросят про кручение деревьев, но при этом их электронный документооборот вот такой прекрасный. Не так должна выглядеть цифровизация.
Как я понимаю, это Сизов труд, поскольку никто не даёт гарантий на структуру документа и может менять её хоть каждый день. Не говоря о том, что изменения будут настолько маленькими, что парсер не сломается, но его результатом будет ошибки Хотя ситуация, где какой-то человек сверяет 2 изображения (как охранник на проходной) похоже останется ещё на коды
По этому и разрабатывался, алгоритм который может и при смене структуры всё правильно разложить (ведь он же работает на разных банках, а делался по сути для 3-х а сейчас на нём крутят 10), и плюс ко всему эти платёжки не менялись 10 лет, вряд ли за следующие 10 что-то с ними изменится, ведь банки во многих отношениях староверы.
Что за бред я только что прочитал? Буквально у всех российских банков есть интеграция с 1С из коробки.
Что автор парсил? в чем суть задачи?
Вы, видимо, не дочитали статью (или прочитали только заголовок), поэтому поясню суть задачи.
Речь не про «загрузить выписку в 1С через стандартный обмен с банком». Это действительно умеет каждый банк из коробки, и статья совсем не об этом.
Задача: на вход приходит готовый документ (PDF, WORD, RTF) - банковская выписка, в которой лежат от 10 до 10 000 платёжных поручений. Нужно:
Распарсить таблицу выписки - вытащить структурированные данные по каждой платёжке (дата, номер, сумма, назначение и т.д.).
Найти в этом же документе страницу с конкретным платёжным поручением и вырезать её в отдельный файл.
Вернуть всё это в 1С как JSON с base64-документами.
Зачем это нужно, если «есть интеграция из коробки»? Потому что это решение делалось не под ИП «Ромашка», а под крупную корпорацию, которая мигрировала с SAP. У них годами выстроенные бизнес-процессы, в которых работают именно с оригинальными документами банков - в том виде, в котором банк их сформировал. Им нужны оригиналы платёжек как отдельные документы, привязанные к распарсенным данным. Стандартная интеграция банк-клиента с 1С этого не делает - она загружает транзакции, а не парсит банковские PDF/DOCX/RTF с сохранением оригиналов.
Собственно, вся статья - про то, как каждый банк генерирует эти документы по-своему, и как со всем этим зоопарком справляться. Если изволите прочитать - увидите.
Не совсем понимаю, что такое "оригиналы платежек как отдельные документы". Это прям бумажные документы которые ваши контрагенты распечатали, ногами принесли в банк и отдали на оплату? Или все-таки электронные?
Стандартная интеграция банк-клиента с 1С этого не делает - она загружает транзакции, а не парсит банковские PDF/DOCX/RTF с сохранением оригиналов
Собственно стандартный банк-клиент создает документы в которых сохранены и номер платежки и назначение платежа из ориганальной платежки, которую ваш контрагент отправил в банк.
Пока что я вижу, что вы придумали себе проблему на ровном месте и героически с ней справились. Штош, поздравляю!
Такое делается не от хорошей жизни, а под требования крупного заказчика, мигрирующего с SAP: у них бизнес-процессы завязаны именно на банковских документов в том виде, как их сформировал банк. Никакая «интеграция из коробки» этого не даёт - она транзакции грузит, а не PDF-ки режет.
Странно, что это приходится объяснять вам. Сходите к условной Марье Петровне и объясните ей. Я разработчик который демонстрирует на Хабре, как на площадке кейсы, а размышлять о смыслах дело уже других...
Девушка хочет цветы, а вы ей шлёте эмодзи тюльпанчика, 2026 год же на дворе))))
Какая разница крупный заказчик или нет и с какой программы переходит? В чем ваша Цель резать PDF-ки или загрузить в базу информацию, которая соответствуют платежным поручениям, отправленными вашим контрагентом?
Если цель загрузить информацию, то вы идете не по той дороге. Скорее всего, когда внедряли SAP не существовало личных кабинетов в банках и , вероятно, был какой-то смысл в парсинге.
Девушка хочет цветы, а вы ей шлёте эмодзи тюльпанчика, 2026 год же на дворе))))
В аналогии можно играть вдвоем.
В вашем случае заказчик пересел с телеги в автомобиль и понял, что ему нужно ездить в темное время суток.
Решаем проблему: сажаем на велосипед чувака с фонарем и отправляем вперед.
Никто же не сказал, что можно просто включить фары.
Документы, предоставляемые банками по каналам интеграции, это оригиналы документов в электронном, структурированном виде - каждая выписка, полученная по каналу интеграции содержит электронную подпись банка.
Из полученных в электронном виде оригинальных документов вы можете сформировать их печатное отображение в том виде, в котором вам это требуется, без вот всей этой возни с парсингом зоопарка реликтовых форматов, вырезкой чего-то откуда-то, чтобы положить куда-то.
Просто крупная корпорация завязла в своём болоте, а специалист решил решать задачу в лоб, без аналитики, не посмотрев на то, что сейчас есть на рынке и теперь будет гордо поддерживать этот зоопарк.
Цифровизация она такая.
Зачем у вас дома лежит паспорт, можно же избавиться от всех бумаг, цифровизация)))
Мой паспорт хранится у меня дома как физическое, верифицированное государством, отражение информации хранящейся в электронном виде на серверах государства. Я не предъявляю бумажный паспорт при запросе документов в электронном виде. Да и вы тоже. Электронный документ, заверенный электронной же подписью, равнозначен бумажному, подписанному собственноручно.
Вам стоило объяснить заказчику, что получать и обрабатывать надо не файлики выгруженные из банка, а полученную напрямую, по интеграционным каналам, структурированную информацию.
В итоге бы получилась задача куда проще: на вход приходит готовый документ в едином формате для любого банка (например, XML в формате ISO 20022) - банковская выписка, в которой лежат от 0 (выписка может быть пустой, но с балансом) до ХХХ платёжных поручений. Нужно:
Сформировать печатную форму по шаблону и сохранить в файл.
Вернуть всё это в 1С как JSON с base64-документами.
Этим вы как минимум сняли бы с пользователей необходимость выгружать эти файлики из клиент-банка, а как максимум стали бы драйвером цифровизации )))
Марья Петровна, другого мнения))) Она считает, что бумага должна быть в том стиле который ей даёт конкретный банк, в том стиле в котором у неё в физическом архиве лежат распечатки... Ну и так далее, копия физического с маппиная с json данными из общей банковской выписки из одного скаченного дока в ЛК банка. Почему напали на меня я не понимаю, основывайте свою компанию и делайте там как удобно вам. Везде свои приколы)) Я лишь демонстрирую реализацию просьбы клиента
Ну вы смешные, автор вам одно, вы ему другое, было бы, да кабы, есть разнице между тем как можно и как нужно в рамках запроса заказчика...
Шёл 2026й год.
Банки уже давным давно обзавелись API, H2H сервисами или настроили себе интеграцию через типовой 1С.ДиректБанк.
На рынке есть решения позволяющие унифицировать обмен с любым банком на основе стандартизированного API, работающего через XML ISO 20022.
Но люди предпочитают парсить файлики. Это печально.
Как я парсил банковские платёжки всех российских банков на Python: история боли, костылей и XML-матрёшек