# ТЗ v0.2 SHORT: базовая онтология + deep access check

**Дата:** 2026-03-22  
**Контур:** `http://localhost/buh_test/odata/standard.odata/`  
**Режим:** только read-only

## 1. Цель этапа

Нужно получить инженерный вердикт, достаточно ли текущего OData для MVP-слоя ассистента:

1. Построить базовую каноническую онтологию бухгалтерского ядра.
2. Проверить не только чтение сущностей, а восстановление цепочек смысла:
- документ -> проводка -> счет/аналитика
- контрагент/договор -> документы -> движения

## 2. Нефункциональные требования (обязательные)

1. Только read-only доступ.
2. Любые write-операции запрещены политикой роли 1С.
3. В отчёте обязателен негативный тест:
- `POST` -> `403/405/401`
- `PATCH` -> `403/405/401`
- `DELETE` -> `403/405/401`

Без этого этап не считается закрытым.

## 3. Каноническая модель v0.1

### 3.1 Primary fact

`Posting` — основной факт учёта (single source of accounting truth на MVP).

### 3.2 Secondary fact

`RegisterMovement` — вспомогательный слой трассировки, не второй независимый источник истины.

### 3.3 Core dimensions

`Document`, `Account`, `SubcontoType`, `Counterparty`, `Contract`, `Organization`, `BankAccount`, `Currency`, `Item`.

## 4. Mapping правила

1. Один source entity set не должен одновременно создавать независимые `Posting` и `RegisterMovement` без явного правила приоритета.
2. Для каждого маппинга фиксируются:
- `direct` (есть явный link/navigation),
- `derivable` (можно восстановить надежным join),
- `opaque`,
- `missing`.

## 5. Probe-подход

Для каждой приоритетной сущности:

1. `top=5`
2. `select` по ключевым полям
3. `filter` по периоду/организации
4. при наличии — `expand`

Если сущность вернула `0` строк:

1. повторить с расширенным периодом;
2. повторить без фильтра;
3. только потом ставить `missing/opaque`.

## 6. Критичные цепочки (обязательные)

### 6.1 Обязательные без вариантов

1. `Document_РеализацияТоваровУслуг -> Posting -> Account/Subconto`
2. `ChartOfAccounts_Хозрасчетный -> SubcontoType -> Posting`

### 6.2 Дополнительные (минимум 2 из 4)

1. `Document_ПоступлениеТоваровУслуг -> Posting`
2. `Counterparty -> Contract -> Documents -> Movements`
3. `Bank docs (in/out) -> BankAccount -> Posting`
4. `Document_ОперацияБух -> Posting`

## 7. Правило решения по OData

### OData достаточен

Если обе обязательные цепочки имеют статус не ниже `derivable`, и минимум 2 дополнительные цепочки тоже не ниже `derivable`.

### OData частично достаточен (гибрид)

Если чтение сущностей стабильное, но хотя бы одна обязательная цепочка `opaque`.

### OData недостаточен

Если любая обязательная цепочка `missing`.

## 8. Deliverables (обязательные)

1. `docs/ontology_v0_1.md`
2. `docs/mapping_1c_odata_v0_1.md`
3. `docs/probe_matrix.md`
4. `docs/decision_report_odata_vs_deeper_access.md`
5. `docs/relationship_evidence.json`

## 9. Что нельзя делать

1. Нельзя считать “много сущностей” доказательством пригодности.
2. Нельзя объявлять OData достаточным без проверки цепочек.
3. Нельзя допускать запись в 1С в рамках этого этапа.
