NODEDC_1C/IN/CHEK_Validation_Run_Accounting_Analytics.md

Да, теперь уже видно не просто то, что “онтология просажена”, а почему именно она просажена и как именно её чинить.

Главный вывод после догрузки: у вас ломается не “граф вообще”, а семаническая нормализация ссылок. Текущий mapping-слой построен слишком грубой эвристикой: все ссылки превращаются в один relation reference, а target_entity определяется почти только по подстроке в имени поля. Из-за этого система формально строит links, но содержательно не понимает, кто есть кто. Отсюда и 1016 Unknown-relations из 2618, при semantic coverage всего 61.19%, хотя link coverage 100%.

Где именно источник поломки

Сейчас правило такое:

• если поле оканчивается на _Key, ref, или выглядит как GUID — оно становится link;
• relation всегда один: reference;
• target_entity угадывается по имени поля;
• если не угадали по нескольким словам вроде контраг, договор, счет, организ, документ, то ставится Unknown.

Это и есть корневая ошибка архитектуры. Для бухгалтерского контура такой подход слишком бедный, потому что:

• Recorder — это не просто “reference”, а источник движения / документ-регистратор;
• Ref в журнале — это не просто “reference”, а journal entry points to concrete document;
• Поставщик_Key и Покупатель_Key — не generic refs, а роли контрагентов;
• Ответственный_Key — не generic ref, а actor / responsible person;
• Валюта_Key — это вообще не Document, а отдельная сущность валюты;
• Склад_Key, ПодразделениеДт_Key, ФизЛицо_Key, СтатьяДвиженияДенежныхСредств_Key требуют собственных классов, а не падения в Unknown.

Что ломается на реальных примерах

1) Recorder в регистрах НДС

В НДС-регистрах Recorder приходит вместе с Recorder_Type, например:

• Recorder_Type = StandardODATA.Document_ПоступлениеТоваровУслуг
• либо Recorder_Type = StandardODATA.Document_СчетФактураПолученный
• либо Recorder_Type = StandardODATA.Document_РеализацияТоваровУслуг. Но в links это всё равно уходит как target_entity = Unknown.

Это критично, потому что для бухгалтерской аналитики регистр без корректного регистратора — почти полуслепая запись. Вы теряете причинную цепочку: движение регистра → документ-регистратор → контрагент/договор/товар/сумма.

2) СчетФактура ошибочно уезжает в Account

В НДС-регистрах поле СчетФактура по смыслу ссылается на документ, а не на бухгалтерский счёт. Но из-за эвристики “если в имени есть счет → Account” оно типизируется как Account. Это уже не просто unknown, а ложноположительное сопоставление.

То есть у вас часть связей не просто потеряна, а неверно искажена.

3) Ref в журналах документов

В DocumentJournal_БанковскиеВыписки есть:

• Ref
• Ref_Type = StandardODATA.Document_СписаниеСРасчетногоСчета или ...ПоступлениеНаРасчетныйСчет. Но link по Ref уходит в Unknown, хотя это должен быть прямой указатель на конкретный документ. Именно поэтому журналы дают много unknown и source_id=unknown.

4) Валюта маппится неверно

В СписаниеСРасчетногоСчета поле ВалютаДокумента_Key в одном из образцов уходит в Document, просто потому что в имени есть слово документа, хотя это ссылка на валюту. Аналогичная проблема в журналах по Валюта_Key, где поле уходит в Unknown.

5) Ролевые контрагенты не разведены

В регистрах есть Поставщик_Key, Покупатель_Key, ДоговорКонтрагента_Key. Сейчас:

• Поставщик_Key и Покупатель_Key часто падают в Unknown,
• ДоговорКонтрагента_Key обычно распознаётся как Contract, но без явной роли в relation.

В результате граф знает, что “что-то связано с контрагентом/договором”, но не знает:

• это supplier или buyer,
• это основной контрагент документа или договор расчётов,
• это связь документа, журнала или регистра.

6) Ответственный_Key, ФизЛицо_Key, Склад_Key, СтатьяДвиженияДенежныхСредств_Key

Эти поля в топе проблемных, потому что для них вообще нет соответствующих сущностей в базовой canonical-модели. В текущем ядре у вас classes: Organization, Counterparty, Contract, Account, Subconto, Document, Posting, RegisterMovement, Period, плюс CanonicalEntity. Но нет нормальных классов для people/employee, warehouse, currency, cashflow article, department, item/product. Поэтому всё это закономерно валится в Unknown.

Значит ли это, что надо “подкручивать только relation rules”?

Нет. Тут нужно чинить сразу три слоя:

A. Расширять canonical classes

Минимально надо добавить:

• EmployeeOrUser / ResponsiblePerson
• Currency
• Warehouse
• CashflowArticle
• Department
• Individual
• Item / Nomenclature
• BankAccount
• TaxRegisterRecord или более общий RegisterRecord
• InvoiceDocument / FacturaDocument как подтип документа, если хотите потом делать объяснения по НДС аккуратнее.

Без этого вы можете переписать relation rules хоть десять раз, но часть полей всё равно некуда будет положить.

B. Уходить от одного relation reference

Нужен не один reference, а словарь осмысленных relations. Минимальный стартовый набор я бы делал такой:

Документы / журналы

• journal_refers_to_document
• document_belongs_to_organization
• document_has_counterparty
• document_has_contract
• document_has_currency
• document_has_warehouse
• document_has_responsible
• document_has_cashflow_article
• document_has_bank_account

Регистры

• register_recorded_by_document
• register_relates_to_supplier
• register_relates_to_buyer
• register_relates_to_invoice
• register_relates_to_vat_account
• register_relates_to_contract
• register_relates_to_organization

Финансовые документы

• payment_relates_to_counterparty
• payment_relates_to_bank_account
• payment_relates_to_cashflow_article
• payment_relates_to_individual
• payment_relates_to_department

Строки табличных частей

• document_line_has_item
• document_line_has_account
• document_line_has_vat_account
• document_line_has_expense_account
• document_line_has_income_account

C. Менять сам принцип типизации

Не по имени поля alone, а по комбинации:

1. source_entity
2. source_field
3. *_Type рядом
4. наличие navigationLinkUrl
5. контекст набора полей вокруг записи.

Именно это даст переносимость между разными 1С-контурами, а не ручную подгонку под июнь 2020, чего у вас как раз требует ТЗ.

Как я бы правил правила маппинга

Правило 1. *_Type имеет приоритет над эвристикой имени

Если есть:

• Recorder_Type
• Ref_Type
• СчетФактура_Type
• ДокументОплаты_Type
• и т.п., то target_entity нужно определять не по имени поля, а по значению type. Например:
• StandardODATA.Document_* → Document
• StandardODATA.Catalog_Контрагенты → Counterparty
• StandardODATA.Catalog_Склады → Warehouse
• StandardODATA.Catalog_Валюты → Currency
• StandardODATA.Catalog_ФизическиеЛица → Individual
• StandardODATA.Catalog_СтатьиДвиженияДенежныхСредств → CashflowArticle. Это автоматически лечит большую часть Recorder, Ref и typed-полей.

Правило 2. Для конкретных полей — словарь приоритетных semantic mappings

Нужен явный field dictionary, например:

• Recorder → relation register_recorded_by_document, target Document
• Ref в DocumentJournal_* → relation journal_refers_to_document, target Document
• Поставщик_Key → relation *_relates_to_supplier, target Counterparty
• Покупатель_Key → relation *_relates_to_buyer, target Counterparty
• Ответственный_Key → relation *_has_responsible, target ResponsiblePerson
• Валюта_Key / ВалютаДокумента_Key → relation *_has_currency, target Currency
• Склад_Key → relation *_has_warehouse, target Warehouse
• СтатьяДвиженияДенежныхСредств_Key → relation *_has_cashflow_article, target CashflowArticle
• ФизЛицо_Key → relation *_relates_to_individual, target Individual
• БанковскийСчет_Key / СчетОрганизации_Key → target BankAccount.

Правило 3. СчетФактура — специальный case

Поле СчетФактура нельзя по общему правилу отправлять в Account. Если рядом есть СчетФактура_Type = StandardODATA.Document_*, то это relation к документу:

• register_relates_to_invoice
• target Document.

Правило 4. Нулевые GUID не создавать как обычные бизнес-связи

00000000-0000-0000-0000-000000000000 сейчас плодит мусорные links. Их лучше:

• либо не писать в canonical links вообще,
• либо писать как null_reference / empty_reference технического типа, отдельно от семанических relations.

Это сразу уменьшит шум в графе и не будет создавать фальшивых “связей с нулевым контрагентом”.

Правило 5. source_id для register records нельзя оставлять unknown

Для регистров, где нет Ref_Key, нужно собирать составной ключ, например:

• source_entity + Recorder + Recorder_Type + LineNumber + Period или аналог. Иначе у вас 358 записей с source_id=unknown, и это разрушает стабильное переиспользование сущности при повторных загрузках.

Приоритеты ремонта по очереди

Приоритет 1 — Recorder, Ref, СчетФактура, Поставщик_Key, Покупатель_Key

Это даст самый большой выигрыш по semantic coverage, потому что именно эти поля сейчас массово ломают регистры, журналы и ключевые документы.

Приоритет 2 — Ответственный_Key, Валюта_Key, ВалютаДокумента_Key

Это быстро снижает долю Unknown в журналах и платежных документах, плюс улучшает explainability по “кто оформлял / в какой валюте”.

Приоритет 3 — СтатьяДвиженияДенежныхСредств_Key, ФизЛицо_Key, Склад_Key, ПодразделениеДт_Key

Это уже следующий слой качества, особенно для операционных и зарплатных/кассовых сценариев.

Что это даст benchmark’у

Если вы сделаете только этот ontology repair, без переписывания всего остального, я ожидаю:

• существенное падение unknown_relations;
• рост semantic coverage заметно выше текущих 61%;
• лучшую связность сценариев document ↔ register ↔ journal;
• меньше ошибочных ответов по cross-entity вопросам;
• меньше ложной уверенности в store-only ответах, потому что router будет видеть более богатую и корректную семантику.

Особенно выиграют вопросы вида:

• связать документ и проводки,
• связать контрагента, договор и документ,
• объяснить происхождение записи НДС,
• пройти от банковской выписки к первичному документу.

Практический план, что делать прямо сейчас

Я бы формализовал следующий этап так:

Шаг 1. Переписать mapper architecture

• ввести entity_type_resolver
• ввести relation_resolver
• ввести null_guid_filter
• ввести composite_source_id_builder для register records.

Шаг 2. Сделать словарь field semantics Отдельная таблица:

• source_entity_pattern
• field_name
• optional_type_field
• target_class
• relation_name
• allow_zero_guid
• priority. Это даст переносимость и управляемость.

Шаг 3. Расширить canonical classes Хотя бы теми классами, которые сейчас массово падают в Unknown.

Шаг 4. Переингестить июнь 2020 После изменения rules — заново посадить slice и пересчитать:

• unknown_relations,
• semantic_coverage_pct,
• relation_types_total,
• top problematic fields.

Шаг 5. Только потом — дочищать router Потому что router сейчас частично страдает вторично: он опирается на недотипизированный граф. Сначала надо дать ему нормальную семаническую подложку.

Мой жёсткий вывод

Сейчас у вас не “плохая онтология”, а слишком примитивный canonical mapper для домена уровня 1С-бухгалтерии. Он годится как стартовый универсальный мост, но не как слой, который должен объяснять бухгалтерскую причинность. Проблема не в snapshot’е июня 2020 — он как раз полезен и достаточно показателен. Проблема в том, что mapping-слой ещё не различает:

• тип ссылки,
• бизнес-роль ссылки,
• typed reference,
• пустую ссылку,
• и специальные 1С-паттерны вроде Recorder/Ref/СчетФактура.

Следующим сообщением я могу собрать тебе уже прямо готовое ТЗ на ремонт ontology/mapping-слоя: с таблицей новых canonical classes, таблицей relation types и таблицей правил для Recorder, Ref, Поставщик, Покупатель, Ответственный, Валюта, Склад, СтатьяДДС.