contracts-flask/concept-for.md

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

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

Сервис принимает массив подписанных клиентских документов (сотни и тысячи файлов Word, PDF, архивы ZIP с произвольными именами), автоматически разбирает их по контрагентам и договорам, восстанавливает историю всех услуг и цен во времени и сверяет её с данными CRM и фискальной системы (1С).

Главная цель — автоматически находить расхождения между подписанными бумагами и учётными системами (прежде всего ошибки в датах начала оказания услуг, ценах, объёмах, а также забытые или вовремя не отключённые допсоглашения).

---

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

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

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

2. Устойчивость к реальным опечаткам в документах:

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

3. Изолированный разбор каждого документа + математический самоконтроль:

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

4. Полноценное состояние договора во времени (Таймлайн вместо одной плоской таблицы):

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

5. Принцип «не фантазировать» (Очередь исключений):

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

---

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

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

---

4. Три коротких вопроса для старта сверки с CRM/1С

Чтобы сразу заложить точный формат финальной сверки, нужны 3 уточнения:

1. Образец данных для сверки: можно ли получить обезличенный пример (несколько строк) выгрузки из CRM, фискальной системы и справочника услуг (с артикулами и -m), которые нужно сравнивать между собой?
2. Правило даты старта: в спецификациях колонка называется «Планируемая дата начала оказания услуг», а в договорах упоминается «Акт начала оказания услуг». Какая дата является главной при сверке с CRM — дата прямо из таблицы спецификации/ДС или дата из акта запуска?
3. НДС в учётных системах: в бумажных спецификациях суммы указаны с НДС. В выгрузках из CRM цены хранятся с НДС или без НДС?