From 1878649317db0c3b509f700a2ec9635d54553d71 Mon Sep 17 00:00:00 2001 From: Repinoid Date: Fri, 30 Oct 2026 13:40:56 +0300 Subject: [PATCH] docs: clarify contract reconciliation concept Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- concept-for.md | 41 ++++++++++++++++++----------------------- 1 file changed, 18 insertions(+), 23 deletions(-) diff --git a/concept-for.md b/concept-for.md index 45a3cce..5f0f189 100644 --- a/concept-for.md +++ b/concept-for.md @@ -1,17 +1,17 @@ # Сервис «Сверка договоров»: концепция для утверждения ## 1. Какую задачу решает сервис -Сервис принимает массив подписанных клиентских документов (сотни и тысячи файлов Word, PDF, архивы ZIP с произвольными именами), автоматически разбирает их по контрагентам и договорам, **восстанавливает историю всех услуг и цен во времени** и **сверяет её с данными CRM и фискальной системы (1С)**. - -Главная цель — автоматически находить расхождения между подписанными бумагами и учётными системами (прежде всего ошибки в **датах начала оказания услуг**, ценах, объёмах, а также забытые или вовремя не отключённые допсоглашения). +1. **Базовая задача (ядро):** сервис принимает массив подписанных клиентских документов (сотни и тысячи файлов Word, PDF, архивы ZIP с произвольными именами), автоматически разбирает спецификации в структурированный вид, связывает цепочки допсоглашений с договорами и **восстанавливает состояние договора во времени**. +2. **Целевая задача сверки:** использовать полученное из договоров состояние как эталон для **построчного сравнения данных из CRM с данными из фискальной системы (1С)** — прежде всего для выявления ошибок в **датах начала оказания услуг**, ценах, количествах и услугах PAYG (суффикс `-m`). +3. **Опционально:** сопоставление текстовых описаний услуг с каталогом услуг (артикулами), где это возможно. --- ## 2. Как устроена логика обработки (5 принципов) 1. **Автоматический разбор пачки и фильтрация:** - - Система сама отделяет договорные документы от бухгалтерского потока (счета, УПД, платёжки, акты сверки отсеиваются). - - **Акты начала оказания услуг (акты готовности)** не выбрасываются, а учитываются отдельно, если фактическая дата запуска биллинга привязана к акту. + - Система обрабатывает только **договоры, дополнительные соглашения и спецификации**. + - Бухгалтерский и сопутствующий поток (счета, счета-фактуры, УПД, платёжные поручения, акты сверки, акты оказанных услуг) автоматически отсеивается. - Полные дубликаты файлов в разных папках склеиваются автоматически. 2. **Устойчивость к реальным опечаткам в документах:** @@ -22,36 +22,31 @@ - ИИ (только собственная модель внутри закрытого контура) сначала разбирает каждый документ сам по себе и не «додумывает» данные. - Программный код автоматически проверяет арифметику каждой таблицы: сходится ли `цена × объём = сумма`, бьются ли строки с итогом таблицы и с общей суммой прописью в тексте соглашения. -4. **Полноценное состояние договора во времени (Таймлайн вместо одной плоской таблицы):** +4. **Состояние договора во времени (учёт периодов и изменений):** - Система разделяет **разовые (инсталляционные)** платежи, **ежемесячные абонентские** услуги и услуги **по потреблению (PAYG)**. - Учитываются ступенчатые периоды внутри одного документа (например, когда в одной спецификации задана одна цена с 01.04 по 24.04 и другая цена с 25.04). - Поддерживаются оба типа допсоглашений: и полное переиздание спецификации в новой редакции, и точечные текстовые изменения отдельных позиций. - Когда в допнике меняется параметр внутри составного описания услуги (например, мощность стойки `10 → 15 кВт` или облако `62 → 80 vCPU`), система фиксирует это как изменение параметров и цены той же услуги с новой даты, сохраняя всю историю. 5. **Принцип «не фантазировать» (Очередь исключений):** - - Если в документе есть неразрешимое противоречие (не сходится сумма в самом PDF, конфликт номеров, невозможно однозначно определить затронутую строку или код услуги из каталога), система **не гадает и не тормозит всю пачку**. - - 90% однозначных позиций собираются и сверяются автоматически, а конкретная спорная строка или связь выносится в отдельный список исключений с цитатой из документа для быстрой проверки глазами. + - Если на любом этапе возникает исключение или противоречие (не сходится сумма в самом PDF, конфликт номеров договора, невозможно однозначно определить изменённую строку или сопоставить артикул), система **не гадает и не тормозит всю пачку**. + - Однозначные позиции разбираются автоматически, а конкретная элементарная подзадача помечается как **нерешаемая автоматически** и выносится в отдельный список исключений с цитатой из документа для проверки глазами. --- ## 3. Что на выходе сервиса -1. **Таймлайн обязательств по каждому договору:** - - Полная картина по контрагенту: какие услуги, в каком объёме, по какой цене и в какие интервалы дат (`[дата начала — дата окончания]`) действовали, со ссылкой на конкретный документ и таблицу. - - Возможность посмотреть действующие условия договора на любую выбранную дату или за период (месяц, квартал, год). -2. **Привязка к каталогу услуг (где возможно):** - - Сопоставление текстовых описаний из договоров с артикулами каталога (а для комплексных облачных пакетов с одной общей ценой в договоре — связка пакета с группой позиций в учёте). -3. **Отчёт о расхождениях «Договоры ↔ CRM ↔ Фискальная система»:** - - Несовпадение **даты начала / окончания** оказания услуги. - - Несовпадение **цены, количества или суммы**. - - Услуга есть в подписанном договоре/ДС, но отсутствует в начислениях (или наоборот). - - Отдельный список документов/строк с внутренними ошибками и опечатками, требующих внимания человека. +1. **Эталонное состояние договора во времени (по документам):** + - Структурированная картина по контрагенту и договору: какие услуги, в каком объёме, по какой цене и в какие интервалы дат (`[дата начала — дата окончания]`) действовали, со ссылкой на конкретный документ и таблицу. + - Возможность получить срез действующих услуг и цен на любую дату или за период (месяц, квартал, год). +2. **Построчная сверка «CRM ↔ Фискальная система» (по эталону договора):** + - Выявление расхождений в **датах начала / окончания** оказания услуг, **ценах и количестве**. + - Сопоставление с каталогом услуг (где это реализуемо по описанию) и учёт позиций PAYG (`-m`). + - Отдельный список неразрешённых позиций и противоречий в исходных документах для ручного контроля. --- -## 4. Три коротких вопроса для старта сверки с CRM/1С +## 4. Два коротких уточнения для этапа сверки CRM ↔ фискальная система -Чтобы сразу заложить точный формат финальной сверки, нужны 3 уточнения: -1. **Образец данных для сверки:** можно ли получить обезличенный пример (несколько строк) выгрузки из CRM, фискальной системы и справочника услуг (с артикулами и `-m`), которые нужно сравнивать между собой? -2. **Правило даты старта:** в спецификациях колонка называется *«Планируемая дата начала оказания услуг»*, а в договорах упоминается *«Акт начала оказания услуг»*. Какая дата является главной при сверке с CRM — дата прямо из таблицы спецификации/ДС или дата из акта запуска? -3. **НДС в учётных системах:** в бумажных спецификациях суммы указаны с НДС. В выгрузках из CRM цены хранятся с НДС или без НДС? +1. **Образец выгрузки:** можно ли получить небольшой обезличенный пример (несколько строк) из CRM и фискальной системы (плюс пример справочника услуг с `-m`), чтобы проверить точность построчной сверки на реальном кейсе? +2. **НДС в выгрузках:** в бумажных спецификациях цены указаны с НДС. В выгрузках из CRM суммы идут с НДС или без НДС?