NODEDC_1C/docs/ADDRESS/tz/_tmp_docx_extract/document.txt

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