NODEDC_1C/IN/Этап 4 — пакет по амортизации.md

Этап 4 — пакет по амортизации.md
: замыкание доказательной цепочки по объектам ОС
1. Контекст

После аудита и последующих пакетов:

НДС уже не главный blocker;
РБП выведен из критического состояния;
амортизация остаётся следующим главным узлом.

По аудиту по амортизации картина такая:

источник не пустой;
admissible evidence уже есть;
live path уже что-то поднимает;
но claim-proof не замыкается из-за:
недостаточного mapping связей 1С,
слабого покрытия claim anchors,
отсутствия внятного expected set объектов ОС за июль.

То есть проблема по амортизации сейчас не в нуле данных, а в том, что система не умеет собрать из уже поднятых данных доказанный вывод:

все ли нужные объекты ОС попали в начисление;
если не все — какой именно объект/контур выпал;
или текущий набор начислений выглядит полным.
2. Цель пакета

Нужно не “улучшить ответ”, а замкнуть proof-контур по амортизации:

вопрос про амортизацию → объекты ОС → expected set за июль → фактическое начисление → проводки/движения → покрытие / непокрытие → доказательный вывод

Итогом должно стать:

явное понимание, какие объекты ОС должны участвовать в начислении за июль;
явное понимание, какие из них реально попали в начисление;
восстановление связей между объектами ОС, документом начисления, движениями и проводками;
non-zero claim-proof coverage;
ответ, который может либо:
доказать полноту начисления,
либо показать, что есть риск пропуска конкретных объектов,
либо честно ограничиться, если не хватает ключевой связи.
3. Source of truth
Базовый вопрос

31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?

Текущий диагноз

По аудиту и прогонам:

admissible evidence уже есть;
live path не нулевой;
но итоговый proof не закрывается, потому что не хватает:
корректной карты связей,
object-level coverage,
claim anchor closure.
4. Главная рабочая гипотеза

Для амортизации основной разрыв сейчас в связке:

entity/relation mapping
система не понимает до конца, как объект ОС связывается с начислением, движением, проводкой и expected coverage;
expected set reconstruction
система не умеет уверенно определить, какие объекты ОС вообще должны были попасть в начисление за июль;
claim anchor closure
сумма начисления и сам факт начисления видны, но они не собираются в доказательство полноты/неполноты охвата.
5. Что нужно сделать

Работу выполнить по 5 узлам.

Узел A — Построить минимальную предметную модель амортизации
Задача

Понять, какие сущности 1С обязательны для доказательного ответа на вопрос про полноту начисления амортизации.

Что сделать

Для кейса амортизации определить:

A1. Seed entities
документ/операция начисления амортизации на 31 июля;
три суммы: 2 471,52 / 2 465,28 / 849,83;
July 2020;
объекты ОС, если их можно выделить напрямую или через связанные документы/регистры.
A2. Required entities

Минимально установить:

документ начисления амортизации;
объект(ы) ОС;
движения начисления;
проводки;
регистры состояния/начисления/учёта ОС;
expected set объектов ОС на июль;
фактический set объектов, попавших в начисление;
признаки “должен был попасть / не попал”.
A3. Expected transitions

Обязательные переходы:

объект ОС → начисление амортизации;
начисление → движения/проводки;
объект ОС → expected July coverage;
expected set → actual set;
actual set vs missing set → риск неполного начисления.
Acceptance
Должен появиться явный fa_required_entity_map.
Должно быть понятно, без каких сущностей доказательство полноты невозможно.
Узел B — Восстановить expected set объектов ОС за июль
Задача

Ответить на главный скрытый вопрос:
какие объекты ОС вообще должны были попасть в амортизацию за июль?

Что сделать
Определить, откуда в 1С можно получить expected population объектов ОС на июль:
активные объекты ОС;
объекты, находящиеся в состоянии, допускающем амортизацию;
объекты, не выбывшие и не исключённые из расчёта;
объекты, для которых июльское начисление ожидаемо.
Проверить:
есть ли этот expected set в snapshot;
есть ли он через live;
нужно ли собирать его из нескольких регистров/документов.
Зафиксировать:
expected_fa_set
actual_fa_set_from_amortization
missing_fa_candidates
uncertain_fa_candidates
Acceptance
Должен появиться reconstructible expected_fa_set, а не просто суммы начисления.
Должно быть понятно, может ли система вообще доказать “полноту” начисления, а не только наличие документа.
Узел C — Восстановить relation mapping по объектам ОС
Задача

Понять, как именно объект ОС связывается с начислением, движениями и проводками.

Что сделать

Для каждого candidate объекта ОС построить relation map:

fa_object
document_amortization
movement
posting
period
coverage_status

Нужно зафиксировать:

прямые связи;
косвенные связи;
missing links;
ambiguous links;
какие связи текущий runtime уже использует;
какие связи есть в 1С, но не реконструируются рантаймом.
Acceptance
Должна появиться object-level relation map по амортизации.
Должно стать ясно, где именно рвётся связь между ОС и начислением.
Узел D — Замкнуть claim anchors для амортизации
Задача

Сделать так, чтобы claim по амортизации опирался не только на суммы, а на полноценный набор anchors.

Что сделать

Для claim типа prove_fixed_asset_amortization_coverage выделять и проверять:

период;
суммы начисления;
документ начисления;
объекты ОС;
expected object set;
actual object set;
missing object candidates;
проводки/движения, подтверждающие начисление.

В debug/export ввести:

claim_type
required_anchors
resolved_anchors
missing_anchor_classes
claim_anchor_coverage_ratio
Acceptance
Кейc по амортизации не должен падать просто как claim_anchor_coverage_insufficient без расшифровки.
Должно быть видно, каких именно anchors не хватает.
Узел E — Собрать proof-style answer по амортизации
Задача

Сделать так, чтобы финальный ответ зависел от object-level proof, а не от общей гипотезы по lifecycle.

Что сделать
Если proof-path собран

Ответ должен уметь сказать:

какие объекты ОС подтверждены в начислении;
какие должны были попасть и не подтверждены;
выглядит ли начисление полным;
где именно есть риск пропуска.
Если proof-path неполный

Ответ должен честно сказать:

каких данных не хватает;
какого object-level звена не хватает;
можно ли судить только о частичном покрытии.
Запрещено
выдавать общий lifecycle-туман без object-level explanation;
ограничиваться только тем, что “сигнал слабый”.
Acceptance
Answer mode должен быть привязан к object-level proof.
Амортизация должна перестать быть абстрактным month-close кейсом без объектной структуры.
6. Проверки

Обязательно выполнить:

replay базового вопроса по амортизации;
debug/export после фикса;
live call inventory;
relation reconstruction trace;
expected vs actual FA coverage matrix;
before/after по answer mode.

Желательно:

один соседний follow-up по тому же кейсу;
один sanity-check по другому ОС-related кейсу, если есть.
7. Метрики пакета

Добавить/обновить:

fa_expected_set_reconstruction_rate
fa_relation_mapping_coverage_rate
fa_claim_anchor_coverage_rate
fa_actual_vs_expected_comparison_rate
fa_proof_closure_rate
fa_false_grounded_answer_rate
Минимальные пороги
fa_expected_set_reconstruction_rate >= 0.85
fa_relation_mapping_coverage_rate >= 0.85
fa_claim_anchor_coverage_rate >= 0.9
fa_proof_closure_rate > 0
fa_false_grounded_answer_rate = 0
8. Обязательные артефакты

В новой run-папке положить:

README.md
run_summary.json
fa_expected_set_report.md
fa_relation_mapping_report.md
fa_claim_anchor_report.md
fa_proof_closure_report.md
fa_before_after_matrix.md
chat_export_fa.md
debug_payloads/
raw_live_calls/
fa_required_entity_map.json
fa_expected_vs_actual_set.json
fa_relation_map.json
fa_admissibility_reject_breakdown.json
9. Что не делать
не тащить в эту волну РБП как главный фокус;
не расползаться на весь month-close контур;
не строить новый общий proof engine;
не закрывать пакет по summary без replay амортизационного кейса;
не маскировать отсутствие object-level proof красивым текстом ответа.
10. Финальный verdict

В конце пакета выдать:

FA_EXPECTED_SET_FIXED / NOT_FIXED
FA_RELATION_MAPPING_FIXED / NOT_FIXED
FA_CLAIM_ANCHOR_CLOSURE_FIXED / NOT_FIXED
FA_PROOF_CLOSURE_FIXED / NOT_FIXED

И общий статус:

FA_PACK_ACCEPTED
или FA_PACK_ACCEPTED_WITH_LIMITATIONS
или FA_PACK_NOT_ACCEPTED
11. Ожидаемый результат

После этого пакета должно стать ясно:

какие объекты ОС должны были участвовать в начислении за июль;
какие реально участвовали;
по каким объектам доказательство есть;
где именно остаётся разрыв;
может ли система по амортизации выдавать не просто “limited”, а нормальный object-level proof-style вывод.