Перейти к содержимому
VC
Кейс 17 из 33 · B2B / Финансы

Конвертер выписок Федерального Казначейства в 1С: 2–3 часа → 5 секунд

Бухгалтер госконтрактной компании каждую неделю обрабатывал XML-выписки ГИС Казначейство руками, конвертируя их в формат для 1С. Написал на Python разбор двух версий протокола — вместо ручной рутины один запуск.

Отрасль
Бухгалтерия госконтрактной компании
Стек
Python · xml.etree · Win-1251
Сроки
≈ 3 рабочих дня
Итог
2–3 часа → 5 секунд
01 · Боль

Часы ручного разбора XML, повторяющиеся каждый месяц

Бухгалтер госконтрактной компании еженедельно получал XML-выписки от ГИС «Электронный бюджет» / Федерального Казначейства. Каждая выписка — это структурированный XML-документ с десятками вложенных тегов: реквизиты получателя, ОРФК, юр.лица, суммы зачислений и списаний, балансовые позиции по каждому лицевому счёту.

Чтобы попасть в 1С, эти данные нужно было перенести в формат 1CClientBankExchange — текстовый формат банк-клиента в кодировке Windows-1251 с жёсткой структурой секций СекцияДокумент=… и десятками обязательных полей на каждый платёж.

На практике это выглядело так: открыть XML в редакторе, вручную скопировать каждое поле в таблицу соответствия в Excel Платёжка_Казначейство_1С_сопоставление.xlsx, сверить контрагентов, проверить суммы по контрольным точкам, конвертировать в нужную кодировку, сохранить файл — и так по каждому платежу из выписки.

02 · Решение

Разбор двух версий протокола на Python → прямой импорт в 1С

Архитектура простая и односторонняя — отсюда и надёжность. Один скрипт из командной строки читает XML-файл, определяет версию протокола, достаёт все нужные поля, сопоставляет их по таблице и пишет готовый файл 1CClientBankExchange в правильной кодировке.

01
XML-выписка

Файл от ГИС Казначейство: V3 (TSE_BalanAcc_D13) или V4 (TSE_BalanAcc2_D13)

02
Разбор файла

xml.etree.ElementTree, версия определяется автоматически по корневому пространству имён

03
Сопоставление полей

BasicRequisites, ORFK, LegalEntity, balance_items → поля 1С

04
Сериализация

Шаблон 1CClientBankExchange, Windows-1251 кодировка

05

Прямая загрузка через стандартный модуль банк-клиента

Две версии XML — один интерфейс

ГИС Казначейство использует параллельно два формата выписки: V3 (TSE_BalanAcc_D13) и V4 (TSE_BalanAcc2_D13). Структура полей и пространства имён различаются. Скрипт определяет версию по корневому элементу и поднимает соответствующую стратегию извлечения — наружу один и тот же единая структура данных.

Извлечение всех значимых полей

Разбор достаёт не только «шапку», но и каждый платёж, и балансовые позиции с проверкой контрольных сумм:

  • BasicRequisites — реквизиты документа, период, номер выписки
  • ORFK — орган Федерального Казначейства
  • LegalEntity — юридическое лицо, ИНН/КПП, лицевой счёт
  • SDTotalSum / EDTotalSum — контрольные суммы дебета/кредита
  • balance_items — каждая балансовая позиция с разбивкой по КБК

Кодировка Windows-1251 без сюрпризов

1CClientBankExchange исторически требует Windows-1251 — это жёсткое требование стандарта банк-клиента. Конвертер открывает выходной файл с encoding="cp1251" и заранее обрабатывает символы, которых в этой кодировке нет, — никаких «кракозябр» при импорте.

03 · Стек

Стек намеренно скучный — потому что надёжный

Python 3.11+

Один исполняемый скрипт, нулевые зависимости от облака

xml.etree.ElementTree

Стандартная библиотека, без лишних пакетов

Windows-1251 / cp1251

Кодировка по требованию 1CClientBankExchange

1CClientBankExchange

Стандарт обмена банк-клиента — нативный импорт в 1С

Таблица соответствия в Excel

Платёжка_Казначейство_1С_сопоставление.xlsx — справочник полей

Командная строка

Запуск из командной строки или через .bat-обёртку на рабочем месте

Pythonxml.etreeWindows-12511CClientBankExchangeCLIExcel-mapping
04 · Результат

Сравнение до и после

Время обработки
2–3 ч 5 сек

на одну выписку любого размера

Точность
100%

контрольные суммы сходятся побайтно, никаких опечаток

Покрытие протокола
V3 + V4

обе версии XML-формата ГИС Казначейство

Главный результат — даже не время. Главное в том, что убирается весь класс ошибок ручного ввода. Каждое поле берётся прямо из исходного XML, без «перенабрать сумму с экрана».

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

05 · Применимость

Где ещё ложится та же методология

За кейсом стоит типовая задача «структурированный документ X → структурированный документ Y через жёсткий маппинг». Та же архитектура применима везде, где данные ходят между госсистемой и учётной системой:

  • Выписки банков в формате 1С банк-клиент / СУФД — те же поля, другой namespace
  • УПД / ЭДО-документы от Диадок / Контур.Диадок / СБИС → импорт в 1С УТ/Бухгалтерия
  • Маркировка «Честный знак» — XML-отчёты в учётную систему
  • Налоговые декларации / отчёты в нестандартных форматах ФНС → внутренние таблицы
  • Тендерная документация (XML-выгрузки с госплощадок) → CRM / внутренние Excel-реестры
Что переиспользуется на следующих проектах
  • Шаблон скрипта, который сам определяет версию формата по корневому элементу
  • Соответствие полей ведётся в справочнике Excel — бухгалтер правит его сам, без изменений в коде
  • Сверка контрольных сумм до записи файла: при расхождении скрипт сразу останавливается, ошибки в учёт не попадают
  • Запуск через .bat-обёртку на рабочем месте — никакого Python для конечного пользователя
Похожая задача?

Если у вас есть документ-донор и документ-приёмник с жёстким форматом — это решается

Конвертеры документов — самый предсказуемый класс автоматизаций. Срок от первого XML до запуска в работу — 3–7 рабочих дней. Окупаемость считается на пальцах.

Готовы начать?

Аудит за 9 900 ₽ — с конкретным отчётом и сметой

Расскажу что внедрить в вашем бизнесе в первую очередь, какая будет окупаемость, и нужен ли вообще AI для вашей задачи (иногда — нет).

Или просто напишите свой вопрос — отвечу в течение 2 часов