zuevav
e7344d8121
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q4YVo4UMopqT5DzicqpPjL
58 lines
5.5 KiB
Markdown
58 lines
5.5 KiB
Markdown
# Вопросы программисту 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);
|
||
- в карточке перевода — статус по каждой бумаге, оповещение оператору о частичном исполнении.
|