Отчет по анализу архива address_query
Инвентаризация разметки 1С, покрытие доменов и статус runtime-сценариев
Источник: архив address_query.zip | Дата документов внутри архива: 2026-03-29
Главный вывод
Архив посвящен не общему налоговому/НДС-контуру, а отдельному runtime-режиму address_query для factual lookup по взаиморасчетам, договорам, документам, банковским операциям и остаткам по счетам.
Масштаб inventory
Обработано 7 039 648 строк из 12 monthly snapshot-файлов за 2020 год, parse errors = 0, найдено 286 уникальных сущностей в 10 family-группах.
Что реально покрыто сейчас
На уровне V1/M2.3c подтверждены прежде всего сценарии по контрагентам и документам; account-сценарии видны, но еще ограничены materialization/account-scope проблемами; contract-сценарии требуют специализированных recipe.
Что с НДС
НДС-сущности и related entities в inventory присутствуют, но в текущий whitelist intents/runtime V1 они не входят как отдельный поддержанный домен.
1. Что находится в архиве
• Главный README описывает пакет как набор документов для перехода к отдельному runtime-режиму `question_mode=address_query`.
• Есть слой системной инвентаризации сущностей 1С по snapshot-корпусу 2020: entity inventory JSON-артефакты, relation/intention support sets, readable summary, run summary.
• Есть продуктовый слой: scenario matrix, query recipes, runtime contracts, integration plan, readiness matrix, question bank, acceptance suites и UI dry-run наборы.
• То есть архив сочетает два уровня: исследование структуры 1С-базы и проектирование прикладного factual-query runtime поверх этой структуры.
2. Структура пакета по смысловым блокам
Блок
Ключевые файлы
Зачем нужен
Инвентаризация 1С
entity_map_1c_2020.md, entity_inventory_*.json, run_summary.json
Показывает, какие сущности есть в snapshot-корпусе, насколько они query-suitable и какие relation patterns обнаружены.
Сценарии и intents
address_scenario_matrix.md, question_bank_v1.md
Фиксирует пользовательские вопросы, intent mapping, приоритеты и expected response types.
Recipe-слой
query_recipes_v1.md, address_runtime_contracts.md
Задает безопасный runtime-контур: intent -> filters -> recipe -> MCP -> factual result.
Интеграция и готовность
runtime_integration_plan.md, runtime_readiness_matrix_v1.md, execution_lineup_v1_2026-03-29.md
Показывает, как это встраивается и какие сценарии уже живы, а какие еще нет.
Acceptance и dry-run
curated_positive_live_suite_v1.md, data_aware_positive_acceptance_suite_v1.md, ui_dry_run_*
Нужны для live-проверки, контроля false factual и ручного прогона поддержанных вопросов.
3. Масштаб и состав inventory по базе 1С
• Источник данных: 12 monthly NDJSON snapshots за 2020 год.
• Обработано 7 039 648 строк без parse errors.
• Найдено 286 сущностей в 10 family-группах.
• Наиболее крупный пласт по строкам - INFORMATION_REGISTER (6,3 млн строк), но адресный runtime строится прежде всего на регистрах, документах, журналах и справочниках.
Family
Сущностей / строк
Приоритет
Комментарий
DOCUMENT
77 / 202 636
все P0
Главный источник document-level factual lookup.
ACCOUNTING_REGISTER
2 / 190 244
оба P0
Ключ к остаткам, хвостам и drilldown по проводкам.
NSI_CATALOG
50 / 140 050
3 P0 / 47 P1
Нужен для договоров, контрагентов и фильтровых резолверов.
DOCUMENT_JOURNAL
12 / 126 868
все P1
Быстрый индекс документов и банковских выписок.
ACCUMULATION_REGISTER
36 / 73 022
все P0
В inventory высоко видимы, но в runtime V1 почти не заведены как отдельные intents.
4. Какие домены реально прорабатываются
• Ключевой продуктовый домен - адресные factual-вопросы по взаиморасчетам и документам, а не произвольная аналитика по всей базе.
• Судя по scenario matrix, question bank и runtime contracts, текущий V1 разбит не по классическим бухгалтерским разделам, а по operational query-доменам.
Домен
Что входит
Статус
Комментарий
Контрагенты и задолженность
payables, receivables, open items by counterparty
ядро V1
Самый зрелый блок; есть curated positive cases и live-with-limits.
Счета и остатки
account balance, balance docs, turnover
частично
Структурно готово, но account-scope/materialization ограничивает стабильные non-empty ответы.
Договоры
open contracts, docs/open items by contract
не дожато
Есть в дизайне, но нужны specialized recipe и resolver path.
Документы и банковские операции
docs by counterparty, bank ops, list by type
ближе к рабочему
Именно здесь подтверждены live non-empty кейсы по counterparty family.
НДС и налоговые сущности
НДС-регистры, счета-фактуры, НДС-документы в inventory
не runtime V1
Есть в инвентаризации, но не заведены как whitelist intents.
5. Какие intents поддержаны по документам
• P0-ядро, зафиксированное в bootstrap report: `list_open_contracts`, `list_payables_counterparties`, `list_receivables_counterparties`, `account_balance_snapshot`, `open_items_by_counterparty_or_contract`.
• Как ближайшее расширение v1.1 перечислены: `list_documents_by_counterparty`, `list_documents_by_contract`, `documents_forming_balance`.
• Фактически в live runtime на момент пакета явно реализованы: `list_documents_by_counterparty`, `bank_operations_by_counterparty`, `documents_forming_balance`.
ID
Сценарий
Статус
Что мешает
AQ-P0-02
payables by counterparty
live, но с ограничениями
Широкие промпты пока дают sparse matches.
AQ-P0-03
receivables by counterparty
live, но с ограничениями
Нужны более точные period hints и anchor refinement.
AQ-P0-04
account balance snapshot
live, но с ограничениями
Строки приходят, но выпадают до materialization.
AQ-P0-05
open items by counterparty
live, но с ограничениями
Нужен явный counterparty anchor для стабильного non-empty.
AQ-P0-07
documents by counterparty
live, но с ограничениями
Есть positive cases, но якоря еще хрупкие.
AQ-P0-07B
bank ops by counterparty
live, но с ограничениями
Позитив подтвержден, но узкие/широкие варианты нестабильны.
AQ-P0-01/06/08
contract-related scenarios
требует спец. recipe
Не хватает contract-aware recipe и contract resolver.
AQ-P0-09
documents forming balance
live, но с ограничениями
Account family still blocked before materialization.
6. Какие сущности являются опорными
• Главная структурная опора - `AccountingRegister_Хозрасчетный_RecordType`: через него идут account, document, organization и часть business drilldown связей.
• Из документов центральны `СписаниеСРасчетногоСчета`, `ПоступлениеНаРасчетныйСчет`, их строки расшифровки платежа, а также `АктСверкиВзаиморасчетов`.
• Из справочников критичен `Catalog_ДоговорыКонтрагентов`; при этом `Catalog_Контрагенты`, `Catalog_Организации`, `Catalog_БанковскиеСчета` формально в triage отмечены как P1, но фактически обязательны для фильтров и resolver-логики.
• Document journals (`ДокументыПоставщиков`, `ДокументыПокупателей`, `БанковскиеВыписки`) играют роль быстрого индексного слоя для list/drilldown сценариев.
7. Что можно сказать про НДС
• В inventory присутствуют НДС-регистры и связанные сущности: `AccumulationRegister_НДСПредъявленный`, `AccumulationRegister_НДСЗаписиКнигиПокупок`, `AccumulationRegister_НДСЗаписиКнигиПродаж`, документы `СчетФактураПолученный`, `СчетФактураВыданный`, `СписаниеНДС`, журнал `РегламентныеДокументыНДС`.
• Однако в scenario matrix, recipe catalog и readiness matrix они не оформлены как отдельный runtime-домен текущего `address_query`.
• Поэтому корректный вывод такой: НДС уже есть в структурной инвентаризации базы, но в текущем пакете это не целевое продуктовое покрытие V1.
8. Ограничения и риски
• Часть labels и entity names в исходном экспорте испорчена cp1251/utf8 mojibake; потребуется финальный decoding/cleanup перед production binding.
• Без business resolvers нельзя надежно переходить от имени контрагента, договора или счета к ID.
• Free-form query builder специально запрещен; доступ предполагается только через whitelist recipe.
• Compound factual вопросы пока только детектируются, но не исполняются как multi-intent decomposition.
• Account-семейство пока не дает стабильный поток до materialization, хотя сырье на входе уже есть.
9. Выводы по текущему состоянию
• Архив уже дает хорошую картину по 1С-сущностям и будущему runtime.
• Сейчас реально прорабатывается не вся база и не весь бухгалтерский домен, а конкретный address-query слой: контрагенты, задолженность, договоры, документы, банковские операции, остатки/расшифровка по счетам.
• Самый зрелый operational блок - counterparty/document lookup.
• Contract-specific и account-specific сценарии структурно готовы, но требуют еще одного цикла реализации и настройки.
• НДС виден в inventory и может стать следующим отдельным доменом, но в данном архиве это пока не активное runtime-покрытие.
10. Практический next step
• Собрать отдельную матрицу: “что есть в inventory” vs “что заведено в intents/recipes” vs “что уже реально работает live”.
• Развести домены на 3 слоя: текущий рабочий V1, design-only backlog и visible-inventory but not productized.
• Отдельно сделать shortlist по НДС/налоговым сущностям, если следующая цель - расширить покрытие за пределы address_query.