Files
contracts-flask/concept-for.md
T
RepinoidandCopilot 1878649317
Deploy contracts-flask / validate (push) Canceled after 0s
docs: clarify contract reconciliation concept
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-10-30 13:40:56 +03:00

7.9 KiB

Сервис «Сверка договоров»: концепция для утверждения

1. Какую задачу решает сервис

  1. Базовая задача (ядро): сервис принимает массив подписанных клиентских документов (сотни и тысячи файлов Word, PDF, архивы ZIP с произвольными именами), автоматически разбирает спецификации в структурированный вид, связывает цепочки допсоглашений с договорами и восстанавливает состояние договора во времени.
  2. Целевая задача сверки: использовать полученное из договоров состояние как эталон для построчного сравнения данных из CRM с данными из фискальной системы (1С) — прежде всего для выявления ошибок в датах начала оказания услуг, ценах, количествах и услугах PAYG (суффикс -m).
  3. Опционально: сопоставление текстовых описаний услуг с каталогом услуг (артикулами), где это возможно.

2. Как устроена логика обработки (5 принципов)

  1. Автоматический разбор пачки и фильтрация:

    • Система обрабатывает только договоры, дополнительные соглашения и спецификации.
    • Бухгалтерский и сопутствующий поток (счета, счета-фактуры, УПД, платёжные поручения, акты сверки, акты оказанных услуг) автоматически отсеивается.
    • Полные дубликаты файлов в разных папках склеиваются автоматически.
  2. Устойчивость к реальным опечаткам в документах:

    • В подписанных файлах встречаются разночтения (например, в шапке ДС указан один номер или дата договора, а в преамбуле — другой, либо смешаны русские и латинские буквы ХХХ/XXX).
    • Система извлекает все реквизиты из документа и связывает файлы в единое досье договора по совокупности признаков (Заказчик/ИНН, все упомянутые номера, перечень услуг), даже если сам базовый рамочный договор в папке отсутствует.
  3. Изолированный разбор каждого документа + математический самоконтроль:

    • ИИ (только собственная модель внутри закрытого контура) сначала разбирает каждый документ сам по себе и не «додумывает» данные.
    • Программный код автоматически проверяет арифметику каждой таблицы: сходится ли цена × объём = сумма, бьются ли строки с итогом таблицы и с общей суммой прописью в тексте соглашения.
  4. Состояние договора во времени (учёт периодов и изменений):

    • Система разделяет разовые (инсталляционные) платежи, ежемесячные абонентские услуги и услуги по потреблению (PAYG).
    • Учитываются ступенчатые периоды внутри одного документа (например, когда в одной спецификации задана одна цена с 01.04 по 24.04 и другая цена с 25.04).
    • Поддерживаются оба типа допсоглашений: и полное переиздание спецификации в новой редакции, и точечные текстовые изменения отдельных позиций.
    • Когда в допнике меняется параметр внутри составного описания услуги (например, мощность стойки 10 → 15 кВт или облако 62 → 80 vCPU), система фиксирует это как изменение параметров и цены той же услуги с новой даты, сохраняя всю историю.
  5. Принцип «не фантазировать» (Очередь исключений):

    • Если на любом этапе возникает исключение или противоречие (не сходится сумма в самом PDF, конфликт номеров договора, невозможно однозначно определить изменённую строку или сопоставить артикул), система не гадает и не тормозит всю пачку.
    • Однозначные позиции разбираются автоматически, а конкретная элементарная подзадача помечается как нерешаемая автоматически и выносится в отдельный список исключений с цитатой из документа для проверки глазами.

3. Что на выходе сервиса

  1. Эталонное состояние договора во времени (по документам):
    • Структурированная картина по контрагенту и договору: какие услуги, в каком объёме, по какой цене и в какие интервалы дат ([дата начала — дата окончания]) действовали, со ссылкой на конкретный документ и таблицу.
    • Возможность получить срез действующих услуг и цен на любую дату или за период (месяц, квартал, год).
  2. Построчная сверка «CRM ↔ Фискальная система» (по эталону договора):
    • Выявление расхождений в датах начала / окончания оказания услуг, ценах и количестве.
    • Сопоставление с каталогом услуг (где это реализуемо по описанию) и учёт позиций PAYG (-m).
    • Отдельный список неразрешённых позиций и противоречий в исходных документах для ручного контроля.

4. Два коротких уточнения для этапа сверки CRM ↔ фискальная система

  1. Образец выгрузки: можно ли получить небольшой обезличенный пример (несколько строк) из CRM и фискальной системы (плюс пример справочника услуг с -m), чтобы проверить точность построчной сверки на реальном кейсе?
  2. НДС в выгрузках: в бумажных спецификациях цены указаны с НДС. В выгрузках из CRM суммы идут с НДС или без НДС?