# Обмен M2M с Fancy DEPO на Firebird 2.5

Перенос трансферных таблиц и процедур обработки MSSQL-версии (`deploy/depo/fancy-m2m`, Фонтвьель, тексты от
22.10.2026, `FTV_M2M_PROCESS_OPERATION` — от 24.10.2026) на Firebird 2.5. Логика процедур та же; отличия перечислены в шапке `10_FTV_M2M_PROCS.sql`.

| Файл | Что делает |
|---|---|
| `00_FTV_M2M_TABLES.sql` | таблицы `FTV_M2M*`, генераторы и триггеры ID, исключение `FTV_M2M_ERROR`, таблица привязок `FTV_M2M_SETTINGS` |
| `10_FTV_M2M_PROCS.sql` | процедуры: `FTV_M2M_FAIL/GET/DT/DAY` (вспомогательные), `PROCESS_WIRING`, `PROCESS_OPERATION`, `UPDATE_HANDBOOK`, `PROCESS_EVENTS`, `PROCESS_CREATE`, `JOB` |
| `20_FTV_M2M_GRANTS.sql` | права процедурам на таблицы Fancy и логину bj (`:BJ_USER`) на `FTV_M2M_JOB` и таблицы обмена |
| `test/` | заглушки таблиц Fancy (по схеме MSSQL), прогон всех веток на встроенном Firebird 2.5.9 |

Порядок установки: 00 → заполнить `FTV_M2M_SETTINGS` → 10 → 20 (под SYSDBA или владельцем базы).

Файлы — в UTF-8, а база Fancy обычно в кодировке NONE с данными в WIN1251. Ставить в WIN1251, иначе русские
тексты процедур попадут в базу в UTF-8:

```
iconv -f utf-8 -t cp1251 10_FTV_M2M_PROCS.sql > 10.sql
isql -ch WIN1251 -user SYSDBA -i 10.sql <сервер>:<путь к базе>
```

(в IBExpert — кодировка подключения WIN1251, файл открыть в UTF-8).

## Проверено на базе Fancy

27.10.2026, обезличенная база Fancy: Firebird 2.5.9, ODS 11.2, диалект 1, кодировка NONE, UDF `ib_Fansy` и
штатные триггеры Fancy. Прошли установка 00–20, справочник участников (HANDBOOK), поручения IN и OUT, события до
`BJ_EXECUTED`: операции зачисления и списания, входящие записи по отчёту НРД, проводки через `OD_PR_INS_WIRS`.
Ошибки (неизвестный контрагент, повтор GUID, неизвестное событие, нет строки поручения) — текст в `COMMENT`.

Подтвердилось: имена и колонки таблиц; `FU_NEXT_DOC_NUM (CAT_SYS_NAME, D_DATE, DIRECTION, FOR_DOC)` — выполняемая,
принимает `SYS_NAME` или ID категории; `OD_PR_INS_WIRS` — 31 входной и 4 выходных параметра; `D_CLISER_M2M.DOC_GUID`
— `VARCHAR(36)`; флаги `LAST_FLAG = 1`, `E_DATE = '9999-01-01'`; категории `I_CLISER_M2M_ZACH/SPIS`, `OP_INV_ZACH/SPIS`,
`D_FILER`; состояние `WAIT_RESP_DECIS`; кодировщик НДЦ; таблицы `D_CLISER_M2M*`, `U_OP_INV_ZACH/SPIS`.

Исправлено по итогам: генераторы `OD_DOCS_ID_GEN`/`OD_DOLS_ID_GEN`; `COMMENT` без кавычек (в диалекте 1 `"…"` —
строка); дата без времени — через `FTV_M2M_DAY` (в диалекте 1 `CAST(… AS DATE)` время не отрезает).

Справочник участников — на настоящем справочнике НРД (169 участников, 2 места расчётов), записанном так же, как
bj пишет его в MSSQL (полная перезапись `FTV_M2M_HANDBOOK` + событие `HANDBOOK`): первый прогон — 168 юрлиц с
кодами M2M, повторный — «никаких изменений не обнаружено». Исправлено относительно MSSQL-версии (там осталось):
- место расчётов без кода участника (`KIND = 'PLACE'`, например «СПБ Банк») — юрлицо создаётся без кода M2M
  (`OD_FACE_CODERS.CODE` — `NOT NULL`; в MSSQL-версии справочник падает целиком, если места ещё нет в Fancy);
- один ИНН дважды в справочнике (СПБ Банк — место расчётов и депозитарий) — одно юрлицо, код добавляет шаг 3
  (в MSSQL-версии — два одинаковых юрлица).

## Проверить у клиента

1. **UDF Fancy `ib_Fansy`**: без неё не читаются `OD_DOCS`, `OD_BALANCES` и не ставятся процедуры (вычисляемые
   поля и триггеры Fancy). На сервере Fancy она есть всегда. Тестовый стенд без Windows — Firebird 2.5 для
   Windows под wine с `ib_Fansy.dll` той же разрядности.
2. **Кодировщик M2M** — юрлицо `OD_FACES` с `MNEM = 'M2M'`. В проверенной базе его не было; без него HANDBOOK и
   создание поручений падают с понятной ошибкой. Завести в Fancy или так (остальные поля заполнят триггеры Fancy):
   `INSERT INTO OD_FACES (ID, S_TYPE, NAME, MNEM) VALUES (GEN_ID(OD_FACES_ID_GEN, 1), 1, 'Кодировщик M2M (справочник участников НРД)', 'M2M');`
3. **Оператор**: логин, под которым bj вызывает `FTV_M2M_JOB`, должен быть в `OD_OPERATORS` (`USER_ID` = логин,
   `U_FACE` = `OD_SETS.WHOS`). `FU_NEXT_DOC_NUM` берёт депозитарий и префикс номера по текущему пользователю;
   триггеры Fancy проверяют права оператора (кроме `UPDATE … ID = 0`). Проверено под SYSDBA.
4. **Привязки `FTV_M2M_SETTINGS`** — ID из справочников клиента: `WHOS` (депозитарий), `OPER_USER`, `FILER_CAT`
   (категория `D_FILER`), `D_NUM`/`K_NUM` (балансовые счета 98010 и 98070), `MARKET` (Мосбиржа), `B_TYPE`
   («Отчёт депозитария» в `DEPO96_DCLA`), `CORR_FACE` (НКО АО НРД), `FILER_RUBRICA`. В проверенной базе счета,
   категория, биржа и тип основания совпали с Фонтвьель (313, 836, 255, 8106, 31) — справочники поставки Fancy;
   `WHOS` и `CORR_FACE` — свои (`OD_SETS.WHOS`; НРД — юрлицо с `MNEM = 'НДЦ'`).
5. **Кодировка и диалект**: `RDB$DATABASE.RDB$CHARACTER_SET_NAME`, `MON$DATABASE.MON$SQL_DIALECT`. При NONE или
   WIN1251 — ставить в WIN1251 (см. выше); текст ошибки в `FTV_M2M_JOB` приводится к WIN1251.
6. **Числа состояний** в `PROCESS_EVENTS` (`STATE = 1, 2, 3, 8`) — как у Фонтвьель; в проверенной базе поручения
   дошли до `STATE = 2`, сверить с `OD_DOC_STATES` клиента.

## Открытые вопросы логики (те же, что в MSSQL-версии)

- `BJ_ORDER_REJECTED` не обрабатывается — уходит в «неизвестное событие» (вопрос программисту от 16.10.2026).
- `BJ_CP_CONFIRM` с направлением OUT перехватывается веткой `BJ_DECISION_CONFIRM` выше.
- Депонент не найден — поручение создаётся без депонента, ошибки нет. Ищется по имени и серии+номеру документа:
  при пустой серии (`NULL`) не находится.