Вопросы программисту Fancy о частичном исполнении пакета M2M (события по строке)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q4YVo4UMopqT5DzicqpPjL
2026-09-18 15:52:47 +03:00
parent 284c92dd0b
commit e7344d8121
1 changed files with 57 additions and 0 deletions
@@ -0,0 +1,57 @@
+# Вопросы программисту Fancy: частичное исполнение пакета M2M
+
+Контекст. По входящему переводу M2M на несколько бумаг НРД после нашего согласия формирует
+отдельное депо-поручение 16/1 на каждую бумагу (черновики MF010 приходят по одному на бумагу).
+Дальше каждое поручение исполняется независимо: по одному может прийти MS010 «исполнено», по
+другому — MS010 с отказом (не сквитовалось со встречным 16 контрагента, GS116 «не сквитовано»,
+истёк срок 30 дней). Пример: пакет «10 Сбер + 10 Т-Технологии», Сбер зачислен, Т-Технологии — нет.
+То же возможно по исходящим (поручения 16 по каждой бумаге).
+
+Сейчас bj пишет в FTV_M2M_EVENTS события на весь перевод (REFERENCE пустой):
+BJ_ORDER_ACCEPTED + BJ_EXECUTED либо BJ_ORDER_REJECTED. При частичном исполнении это неверно.
+bj готов писать события **по строке пакета** (REFERENCE = Security/ReferenceId из FTV_M2M_LINES).
+
+## Вопросы
+
+1. **События по строке.** Умеет ли bj2depo обрабатывать событие с заполненным `REFERENCE`
+   (одна бумага пакета): создать проводку зачисления/списания только по ней и не трогать другие
+   строки? Или джоба работает только с событием на весь GUID?
+
+2. **Набор событий для частичного исхода.** Какой вариант удобен джобе:
+   - (а) по каждой строке своё событие: `BJ_EXECUTED` (REFERENCE=Сбер) и `BJ_ORDER_REJECTED`
+     (REFERENCE=Т-Технологии, PARAMETERS — текст отказа НРД); события на весь GUID при этом
+     не пишутся;
+   - (б) одно событие на GUID `BJ_EXECUTED_PARTIAL` с перечнем в PARAMETERS
+     (`executed: ISIN…; rejected: ISIN… — причина`), проводки делает оператор Fancy вручную;
+   - (в) оба: строчные события для проводок и сводное на GUID для статуса документа.
+
+3. **Порядок во времени.** MS010 по разным бумагам приходят в разное время (минуты — дни).
+   Можно ли писать событие по строке сразу при получении её MS010, не дожидаясь остальных
+   (документ в DEPO будет какое-то время «частично исполнен»)? Или ждать, пока ответят по всем,
+   и писать пакетом?
+
+4. **Состояние документа DEPO.** Какое STATE/COMMENT bj2depo поставит документу, у которого
+   часть строк исполнена, часть отказана? Есть ли в DEPO статус «исполнено частично», или
+   документ разделяется на два?
+
+5. **Отказ после исполнения.** Если по бумаге сначала пришло REORD/принятие, а затем отказ
+   (MS010 с отказом) — нужно ли отдельное событие отмены ранее созданной проводки, или
+   `BJ_ORDER_REJECTED` по строке этого достаточно?
+
+6. **Срок 30 дней.** Поручение без MS010 через 30 дней считается отменённым. Сейчас bj пишет
+   `BJ_CANCELLED` на весь GUID. По строке — тем же событием с REFERENCE?
+
+7. **Поручения без строки.** `BJ_ORDER_SENT` сейчас несёт номера всех поданных поручений
+   (contr_d_id) в PARAMETERS. Нужно ли джобе соответствие contr_d_id ↔ REFERENCE (в каком поле)?
+
+8. **Обратная совместимость.** Пока джоба не умеет строки — можем ли мы продолжать писать события
+   на GUID при полном исполнении/полном отказе и переходить на строчные только при частичном
+   исходе? Или переключаться целиком?
+
+## Что сделает bj после ответа
+
+- хранить по каждому поручению 16/16-1 связку `contr_d_id ↔ ISIN ↔ REFERENCE`;
+- вердикт по каждому поручению; статус перевода «исполнен» только когда исполнены все,
+  «отказ» — когда отказ по всем, иначе «исполнен частично» с ожиданием остальных;
+- события в FTV_M2M_EVENTS в согласованном формате (п. 2);
+- в карточке перевода — статус по каждой бумаге, оповещение оператору о частичном исполнении.