Общие проверки при обработке методов
1. Стандартные проверки при обработке методов:
1.1. Необходимо проверить заполнение обязательных полей по тэгу required. Для параметров с required=false может быть описана условная обязательность в таблице, где перечислены все параметры метода. Если хотя бы один обязательный параметр не заполнен, вернуть ошибку (*002) «Не заданы обязательные поля».
1.2. Необходимо проверить значения параметров, которые имеют ссылку на справочники, по тэгу link. Если указанного значения нет в справочнике, вернуть ошибку (*003) «Запись с указанным идентификатором в справочнике %s не найдена».
2. Стандартные проверки прав:
2.1. Проверяем, что в таблице userCls есть пользователь, от которого пришел запрос. Иначе вернуть ошибку (*007) «Пользователь не найден».
2.2. Проверяем, что запрос пришел от пользователя с ролью "Администратор Клиринга" userRoleSessions.userRole=ADMN (см. справочник userRole). Иначе вернуть ошибку (*001) «Нет прав на проведение данной операции».
3. Проверка статуса клиринговой сессии:
Проверить, что клиринговая сессия активна: session.sessionStatus=ACTV (см. справочник sessionStatus). Иначе вернуть ошибку (5210) "Клиринговая сессия неактивна" (пока актуально только для модуля balance-service).
* - подставляется цифра соответствующего модуля согласно кодам ошибок из dictionaries.xml
Заполнение стандартных полей
1. id:
при добавлении - из генератора,
при изменении - не меняется,
при удалении - не меняется.
2. createdAt:
при добавлении - дата-время создания записи,
при изменении - не меняется,
при удалении - не меняется.
3. updatedAt:
при добавлении - дата-время создания записи,
при изменении - дата-время изменения записи,
при удалении - дата-время удаления записи (в том случае, когда для записи проставляется неактивный статус, то есть формально запись не удаляется из таблицы).
4. clearingDate:
при добавлении - текущая дата,
при изменении - не меняется,
при удалении - не меняется.
Клиринг
Клиринг запускается автоматически по расписанию или launcher "?" (когда Администратор Клиринга нажал кнопку необходимой ему команды в WEB-интерфейсе)?
Обработка клиринга выполняется модулем clearing-service после проверок сделок, полученных из Торговой системы (проверки сделок представлены в описании заполнения объекта executionDeposit).
В процессе клиринга необходимо:
0. Выполнить сортировку сделок executionDeposit перед их обработкой следующим образом:
0.1. Для сделок участников "Категории «Б» - Кредитная организация ДР" (т.е. clearingMemberCategory.clearingMemberCategory=B, где clearingMemberCategory.companyId=executionDeposit.companyId) в первую очередь должен выполняться расчет возратов по депозитам, во вторую - расчет обязательств по новым депозитам. Данное требование должно обеспечить сортировку сделок executionDeposit перед обработкой, выполняемую в следующей последовательности:
0.1.1. executionDeposit.companyId - Возрастающий
0.1.2. executionDeposit.side - сначала BUY «Разместить», потом SELL «Привлечь»
0.1.3. executionDeposit.exchangeExecutionId - Возрастающий
В случае если контроль не выполняется условия возврата депозитных договоров, то адмнистратор Клиринговой Системы перед расчетом обязательств по вновь залкюченным договорам должен подтвердить функцию запуска расчета. Текст уведомления: «Проводить расчет обязательств с учетом невозврата?» При положительном ответе выполняется расчет, а при отрицательном не выполняется. Ответ Администратора системы должен быть записан в системном журнале приложения о действиях пользователя.
0.2. Для сделок участников "Категории «В» - Инициатор по ТКС" (т.е. clearingMemberCategory.clearingMemberCategory=V, где clearingMemberCategory.companyId=executionDeposit.companyId) в первую очередь должен выполняться расчет обязательств по новым депозитам с наименьшими объемами. Данное требование должно обеспечить сортировку сделок executionDeposit перед обработкой, выполняемую в следующей последовательности:
0.2.1. в рамках executionDeposit.side=SELL «Привлечь» сортировка по возрастанию executionDeposit.firstLegAmount .
1. Выполнить расчет требований и обязательств по каждой сделке (т.е. строке таблицы executionDeposit). В ходе расчета для каждой сделки выполнять ряд проверок:
1.1. Проверка, что договор на клиринг по УК позволяет клиринг: relation.serviceStatus=ACTV (см. справочник serviceStatus), где relation.consumerId=executionDeposit.companyId .
1.2. Проверка отсутствия блокировки счета: account.accountStatus=ACTV (см. справочник accountStatus), где account.id=executionDeposit.accountId и account.relationId=relation.id (который найден в предыдущей проверке на доступность клиринга).
1.3. Проверка отсутствия блокировки по компании: company.workflowStatus=ACTV (см. справочник workflowStatus), где company.id=executionDeposit.companyId .
1.4. По итогу проверки сформировать по две новые записи (по первой ноге - на сегодня, по второй ноге - на дату возврата) в объектах liabilitiesClaimsMoney и liabilitiesClaimsAssets согласно описанию заполнения объекта liabilitiesClaimsMoney и описанию заполнения объекта liabilitiesClaimsAssets соответственно (см. отметку "Клиринг"). При этом:
1.4.1. При непрохождении хотя бы одной из проверок, поле liabilitiesClaimsMoney/liabilitiesClaimsAssets.clearingStatus заполняется значением MNG (см. справочник clearingStatus)
И для обрабатываемой сделки установить executionDeposit.coverageStatus=DEND (см. справочник allowed).
1.4.2. Если все предыдущие проверки пройдены, то поле liabilitiesClaimsMoney/liabilitiesClaimsAssets.clearingStatus=PROC (см. справочник clearingStatus)
2. После расчета требований и обязательств (создали записи в liabilitiesClaimsMoney/liabilitiesClaimsAssets по предыдущему пункту),
для требований, у которых
[liabilitiesClaimsMoney.clearingStatus=PROC (см. справочник clearingStatus)
И liabilitiesClaimsMoney.liabilitiesAmount≠null
И участник "Категории «В» - Инициатор по ТКС" (т.е. clearingMemberCategory.clearingMemberCategory=V, где clearingMemberCategory.companyId=liabilitiesClaimsMoney.companyId)]
необходимо выполнить контроль обеспеченности обязательств, включаемых в клиринговый пул, по условию |liabilitiesClaimsMoney.liabilitiesAmount| ≤ accountBalance.freeBalanceAccount .
2.1. При непрохождении проверки:
2.1.1. liabilitiesClaimsMoney.clearingStatus=FAIL (см. справочник clearingStatus).
2.1.2. liabilitiesClaimsAssets.clearingStatus=FAIL (см. справочник clearingStatus), у которого liabilitiesClaimsAssets.liabilitiesClaimsMoneyId=liabilitiesClaimsMoney.id (статус которого обновили в предыдущей подпункте).
2.1.3. executionDeposit.coverageStatus=DEND (см. справочник allowed), для соответствующей сделки.
2.2. Если проверка пройдена, переход к следующему пункту.
3. Обновить баланс счета согласно описанию движений в accountBalance, отмеченных тэгом "Клиринг".
Объект может быть изменен модулем utility-service:
1. По команде от пользователя (из backend-api): авторизация пользователя userCls/put.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из параметра userName полученного метода.
Из параметра name полученного метода (из кейклока приходит в параметре name).
Из параметра firstName полученного метода (из кейклока приходит в параметре givenName).
Из параметра lastName полученного метода (из кейклока приходит в параметре familyName).
Из параметра middleName полученного метода (из кейклока приходит в параметре middleName).
Из параметра email полученного метода (из кейклока приходит в параметре email).
При обработке метода:
1. Проверить, что есть запись userCls.identifier=userName из метода.
1.1. Если такая запись найдена, новая запись в таблице userCls не создается, переход к следующему п.2.
1.2. Если такой записи нет, создать запись о новом пользователе согласно описанию.
2. Внести изменения в таблицах:
2.1. userRoleSession согласно описанию (необходимо передавать роль пользователя из сообщения от backend-api);
2.2. userConnect согласно описанию.
Заполняется модулем utility-service в результате получения сообщения от backend-api об авторизации пользователя (детали см. обработка userCls). Проверки при заполнении userRoleSession:
1. Проверить, что в таблице userRoleSession для данного userId указаны все роли userRole, которые пришли в параметре roles сообщения об авторизации пользователя (маппинг ролей), и они имеют status=ACTV (см. справочник workflowStatus):
1.1. Если для всех полученных ролей есть записи в userRoleSession, то изменения не вносим.
1.2. Если для какой-то из ролей нет записи в userRoleSession, то проверить есть ли у этого пользователя данная роль со status=BLKD:
1.2.1. если есть, то у этой записи обновить status на "ACTV";
1.2.2. если нет, создать запись для этого пользователя с новой ролью согласно описанию.
1.3. Если в userRoleSession есть запись о роли, которая не получена в параметре roles, то обновить в этой записи status на "BLKD".
По логике заполнения стандартных полей.
Идентификатор пользователя из userCls.id
В зависимости от значения параметра roles сообщения от backend-api на добавление пользователя:
=ADMN (см. справочник userRole) - при получении в roles 1 "МКР CS_MKR_ADMIN";
=SPVS (см. справочник userRole) - при получении в roles 2 "МКР CS_MKR_SUPERVISER";
=SCRT (см. справочник userRole) - при получении в roles 3 "МКР CS_MKR_SECURITY".
Всегда =1 "СПВБ".
При добавлении:
=ACTV (см. справочник workflowStatus)
При изменении:
см. проверки при заполнении userRoleSession.
Объект может быть изменен модулем utility-service:
1. По команде от пользователя (из backend-api): авторизация пользователя userSettings/put.
По логике заполнения стандартных полей.
При добавлении:
из соответствующего параметра полученного метода.
При изменении:
не меняется.
При добавлении:
из соответствующего параметра полученного метода.
При изменении:
из соответствующего параметра полученного метода, если значение отличается от сохраненного ранее.
При добавлении:
из соответствующего параметра полученного метода.
При изменении:
из соответствующего параметра полученного метода, если значение отличается от сохраненного ранее.
При обработке метода:
1. Проверить, что есть запись userSettings.userId=userId из метода.
1.1. Если такая запись найдена, то обновить эту запись согласно описанию изменения userSettings.
1.2. Если такой записи нет, создать запись о новом пользователе согласно описанию добавления userSettings.
Заполняется модулем utility-service в результате:
1-авторизация пользователя в Системе;
2-выхода пользователя из Системы.
Логика заполнения полей userConnect согласно описанию.
При входе:
из генератора.
При выходе:
не меняется.
При входе:
дата-время создания записи.
При выходе:
не меняется.
При входе:
не меняется.
При выходе:
дата-время изменения записи.
При входе:
идентификатор пользователя из userCls.id
При выходе:
не меняется.
При входе:
текущее время.
При выходе:
не меняется.
При входе:
не меняется.
При выходе:
текущее время.
При входе:
IP адрес сервера.
При выходе:
не меняется.
При входе:
IP адрес клиента.
При выходе:
не меняется.
При входе:
=CNCT (см. справочник connectionState).
При выходе:
=DSBL (см. справочник connectionState).
При входе:
текущая дата.
При выходе:
не меняется.
При входе/выходе:
Заполняется кодом ошибки при ее выявлении.
При входе/выходе:
Заполняется кодом полного текста ошибки при ее выявлении.
От пользователя (из backend-api) могут прийти методы:
1. Добавления - plannerTemplate/post
2. Изменения - plannerTemplate/put
3. Удаления - plannerTemplate/delete
По итогу заполнения plannerTemplate необходимо добавить запись в plannerAllToday, если она должна туда попасть по логике заполнения plannerAllToday.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода plannerTemplate/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить, что taskTime больше или равно текущему времени. Иначе вернуть ошибку (7011) «Невозможно добавить задачу на прошедшее время».
3.3. Если заполнена companyId, проверить:
3.3.1. Проверить, что в таблице company есть такая компания по planner.companyId. Если такой записи нет, вернуть ошибку (7014) «Указанная в задаче компания не найдена».
3.3.2. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7015) «Указанная компания неактивна».
3.4. Если заполнен securityId, проверить:
3.4.1. Проверить, что в таблице security есть такой инструмент по planner.securityId. Если такой записи нет, вернуть ошибку (7012) «Указанный в задаче нструмент не найден».
3.4.2. Проверить, что в таблице security запись об инструменте имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7013) «Указанный инструмент неактивен».
4. Если предыдущие проверки выполнены успешно:
4.1. Добавить новую запись в plannerTemplate согласно описанию.
4.2. Добавить новую запись в plannerAllToday, если она должна туда попасть по логике заполнения plannerAllToday.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода plannerTemplate/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице plannerTemplate есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (7006) "Запись не найдена".
3.3. Необходимо проверить, что taskTime больше или равно текущему времени. Иначе вернуть ошибку (7011) «Невозможно добавить задачу на прошедшее время».
3.4. Если заполнена companyId, проверить:
3.4.1. Проверить, что в таблице company есть такая компания по planner.companyId. Если такой записи нет, вернуть ошибку (7014) «Указанная в задаче компания не найдена».
3.4.2. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7015) «Указанная компания неактивна».
3.5. Если заполнен securityId, проверить:
3.5.1. Проверить, что в таблице security есть такой инструмент по planner.securityId. Если такой записи нет, вернуть ошибку (7012) «Указанный в задаче нструмент не найден».
3.5.2. Проверить, что в таблице security запись об инструменте имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7013) «Указанный инструмент неактивен».
4. Если предыдущие проверки выполнены успешно:
4.1. Обновить запись в plannerTemplate согласно описанию.
4.2. Обновить запись в plannerAllToday, если она записана там по логике заполнения plannerAllToday.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода plannerTemplate/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице plannerTemplate есть запись, которую нужно удалить, по ключу id. Если такой записи нет, вернуть ошибку (7006) "Запись не найдена".
4. Если предыдущие проверки выполнены успешно:
4.1. Удалить запись из plannerTemplate.
4.2. Удалить запись из plannerAllToday.
От пользователя (из backend-api) могут прийти методы:
1. Добавления - clearingCalendar/post
2. Изменения - clearingCalendar/put
3. Удаления - clearingCalendar/delete
По итогу заполнения planner необходимо добавить запись в plannerAllToday, если она должна туда попасть по логике заполнения plannerAllToday.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода clearingCalendar/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить, что clearingDate больше или равна текущей дате. Иначе вернуть ошибку (7010) «Невозможно добавить задачу на прошедшую дату».
3.3. Если заполнена companyId, проверить:
3.3.1. Проверить, что в таблице company есть такая компания по clearingCalendar.companyId. Если такой записи нет, вернуть ошибку (7014) «Указанная в задаче компания не найдена».
3.3.2. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7015) «Указанная компания неактивна».
4. Если предыдущие проверки выполнены успешно:
4.1. Добавить новую запись в clearingCalendar согласно описанию.
4.2. Добавить новую запись в plannerAllToday, если она должна туда попасть по логике заполнения plannerAllToday.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода clearingCalendar/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице clearingCalendar есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (7006) "Запись не найдена".
3.3. Необходимо проверить, что clearingDate больше или равна текущей дате. Иначе вернуть ошибку (7010) «Невозможно добавить задачу на прошедшую дату».
3.4. Если заполнена companyId, проверить:
3.4.1. Проверить, что в таблице company есть такая компания по clearingCalendar.companyId. Если такой записи нет, вернуть ошибку (7014) «Указанная в задаче компания не найдена».
3.4.2. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7015) «Указанная компания неактивна».
4. Если предыдущие проверки выполнены успешно:
4.1. Обновить запись в clearingCalendar согласно описанию.
4.2. Обновить запись в plannerAllToday, если она записана там по логике заполнения plannerAllToday.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода clearingCalendar/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице clearingCalendar есть запись, которую нужно удалить, по ключу id. Если такой записи нет, вернуть ошибку (7006) "Запись не найдена".
4. Если предыдущие проверки выполнены успешно:
4.1. Удалить запись из clearingCalendar.
4.2. Удалить запись из plannerAllToday.
От пользователя (из backend-api) могут прийти методы:
1. Добавления - planner/post
2. Изменения - planner/put
3. Удаления - planner/delete
По итогу заполнения planner необходимо добавить запись в plannerAllToday, если она должна туда попасть по логике заполнения plannerAllToday.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода planner/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить, что clearingDate больше или равна текущей дате. Иначе вернуть ошибку (7010) «Невозможно добавить задачу на прошедшую дату».
3.3. Если clearingDate=текущей дате, необходимо проверить, что taskTime больше или равно текущему времени. Иначе вернуть ошибку (7011) «Невозможно добавить задачу на прошедшее время».
3.4. Если заполнена companyId, проверить:
3.4.1. Проверить, что в таблице company есть такая компания по planner.companyId. Если такой записи нет, вернуть ошибку (7014) «Указанная в задаче компания не найдена».
3.4.2. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7015) «Указанная компания неактивна».
3.5. Если заполнен securityId, проверить:
3.5.1. Проверить, что в таблице security есть такой инструмент по planner.securityId. Если такой записи нет, вернуть ошибку (7012) «Указанный в задаче нструмент не найден».
3.5.2. Проверить, что в таблице security запись об инструменте имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7013) «Указанный инструмент неактивен».
4. Если предыдущие проверки выполнены успешно:
4.1. Добавить новую запись в planner согласно описанию.
4.2. Добавить новую запись в plannerAllToday, если она должна туда попасть по логике заполнения plannerAllToday.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода planner/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице planner есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (7006) "Запись не найдена".
3.3. Необходимо проверить, что clearingDate больше или равна текущей дате. Иначе вернуть ошибку (7010) «Невозможно добавить задачу на прошедшую дату».
3.4. Если clearingDate=текущей дате, необходимо проверить, что taskTime больше или равно текущему времени. Иначе вернуть ошибку (7011) «Невозможно добавить задачу на прошедшее время».
3.5. Если заполнена companyId, проверить:
3.5.1. Проверить, что в таблице company есть такая компания по planner.companyId. Если такой записи нет, вернуть ошибку (7014) «Указанная в задаче компания не найдена».
3.5.2. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7015) «Указанная компания неактивна».
3.6. Если заполнен securityId, проверить:
3.6.1. Проверить, что в таблице security есть такой инструмент по planner.securityId. Если такой записи нет, вернуть ошибку (7012) «Указанный в задаче нструмент не найден».
3.6.2. Проверить, что в таблице security запись об инструменте имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (7013) «Указанный инструмент неактивен».
4. Если предыдущие проверки выполнены успешно:
4.1. Обновить запись в planner согласно описанию.
4.2. Обновить запись в plannerAllToday, если она записана там по логике заполнения plannerAllToday.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода planner/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице planner есть запись, которую нужно удалить, по ключу id. Если такой записи нет, вернуть ошибку (7006) "Запись не найдена".
4. Если предыдущие проверки выполнены успешно:
4.1. Удалить запись из planner.
4.2. Удалить запись из plannerAllToday.
Заполнение мапы plannerAllToday:
1. Заполнение должно выполняться после запуска idГенератора. Только на одной ноде (аналогично id Генератору) и до сторадж должен начать принимать соединения после ее заполнения.
2. Данные берутся из трех мап plannerTemplate, clearingCalendar, planner
3. Логика заполнения:
3.1. Берем данные из plannerTemplate по следующим правилам [в clearingCalendar смотрим на тек.день (по полю clearingDate)]:
3.1.1. Если тек.день=ПН-ПТ и не задан clearingCalendar (т.е. нет записи),
то из plannerTemplate копируем все записи со статусом taskStatus=ACTV (см. справочник taskStatus).
3.1.2. Если тек.день=СБ-ВС и не задан clearingCalendar (т.е. нет записи),
то plannerTemplate не копируем.
3.1.3. Если тек.день=СБ-ВС и clearingCalendar.dayStatus=BDAY день рабочий (см. справочник dayStatus) и companyId задан,
то из plannerTemplate копируем все записи со статусом taskStatus=ACTV (см. справочник taskStatus).
3.1.4. Если тек.день=ПН-ПТ и clearingCalendar.dayStatus=DOFF день нерабочий (см. справочник dayStatus) и companyId не задан,
то plannerTemplate не копируем.
3.1.5. Если тек.день=ПН-ПТ и clearingCalendar.dayStatus=DOFF день нерабочий (см. справочник dayStatus) и companyId задан,
то plannerTemplate не копируем.
3.1.6. Если тек.день=ПН-ПТ и clearingCalendar.dayStatus=BDAY день рабочий (см. справочник dayStatus), то есть clearingCalendar.dayStatus повторяет признак рабочего дня,
то в этом случае обрабатываем как обычную ПН-ПТ (независимо от того, указана companyId или нет) - см. пп.3.1.1
3.1.7. Если тек.день=СБ-ВС и clearingCalendar.dayStatus=DOFF день нерабочий (см. справочник dayStatus), то есть clearingCalendar.dayStatus повторяет признак нерабочего дня,
то в этом случае обрабатываем как обычную СБ-ВС (независимо от того, указана companyId или нет) - см. пп.3.1.2
3.2. Берем данные из planner на тек.день (по полю clearingDate):
3.2.1. Если planner.taskStatus=ACTV (см. справочник taskStatus), то копируем эту запись в plannerAllToday.
3.2.2. Если planner.taskStatus=CNCL или BLKD (см. справочник taskStatus), необходимо дополнительно проверять, добавлена ли запись с такой задачей в plannerAllToday по ключу planner.task,taskTime,securityId,companyId:
- если такая задача найдена, то удалить эту запись из plannerAllToday;
- если такой задачи нет - ничего не делаем.
По логике заполнения стандартных полей.
Из соответствующего поля таблицы-источника, если оно заполнено.
Из соответствующего поля таблицы-источника, если оно заполнено.
Из соответствующего поля таблицы-источника, если оно заполнено.
Из соответствующего поля таблицы-источника, если оно заполнено.
Из соответствующего поля таблицы-источника, если оно заполнено.
Из соответствующего поля таблицы-источника, если оно заполнено.
Из соответствующего поля таблицы-источника, если оно заполнено.
В зависимости от таблицы-источника:
=TMPL, если plannerTemplate;
=CLND, если clearingCalendar;
=PLNR, если planner.
Идентификатор записи таблицы-источника.
Объект может быть изменен модулем scheduler-service:
1. По командам от пользователя (из backend-api): возможные команды.
2. По расписанию.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении (по команде от backend-api):
=userId, переданному рядом с сообщением от backend-api
При добавлении (по команде от backend-api):
=коду задачи из (см. справочника task), который соответствует полученной команде.
При обработке любого из нижеуказанных методов:
необходимо выполнить общую проверку прав для userId, переданного рядом с сообщением от backend-api:
-если ошибки не выявлены, создать запись в launcher согласно описанию;
-иначе вернуть ошибку без создания записи.
Объект может быть изменен модулем company-service:
1. По сообщению на добавление компании company из очереди от модуля api-lk-company:
1.1. необходимо создать записи в company согласно описанию с тэгом "При добавлении (от api-lk-company)";
1.2. необходимо создать записи в relation согласно описанию в разделе relation.
2. По команде от пользователя (из backend-api): удаление объекта company/delete.
3. По команде от пользователя (из backend-api): изменение объекта companyInfo/put.
4. При обработке документа расторжения договора (обработка расторжения описана в разделе profileDocument): необходимо обновить запись в company согласно описанию с тэгом "При обработке расторжения".
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
не меняется.
При удалении (company/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
не меняется.
При удалении (company/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
не меняется.
При удалении (company/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (от api-lk-company):
=ACTV (см. справочник workflowStatus)
При изменении (companyInfo/put):
не меняется.
При удалении (company/delete):
=BLKD (см. справочник workflowStatus)
При обработке расторжения:
=BLKD (см. справочник workflowStatus)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (company/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (company/delete):
не меняется.
При обработке расторжения:
не меняется.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода company/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице company есть запись, которую нужно удалить, по ключу id. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.3. Проверить, что в таблице company запись имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице company согласно описанию.
Объект может быть изменен модулем company-service:
1. По сообщению на добавление информации о компании companyInfo из очереди kafka от модуля api-lk-company: необходимо создать записи в companyInfo согласно описанию с тэгом "При добавлении (от api-lk-company)".
2. По команде от пользователя (из backend-api): изменение объекта companyInfo/put.
По логике заполнения стандартных полей.
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
заполняется идентификатором компании из company.id
При изменении (companyInfo/put):
не меняется.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companyInfo/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление информации о компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
Поле таблицы company, логика создания/изменения/удаления записей в company представлена в описании этой таблицы.
Поле таблицы company, логика создания/изменения/удаления записей в company представлена в описании этой таблицы.
Поле таблицы company, логика создания/изменения/удаления записей в company представлена в описании этой таблицы.
Поле таблицы company, логика создания/изменения/удаления записей в company представлена в описании этой таблицы.
Поле таблицы company, логика создания/изменения/удаления записей в company представлена в описании этой таблицы.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода companyInfo/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице companyInfo есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (3013) "Профиль Компании не найден".
3.3. Проверить, что в таблице company есть запись, которую нужно изменить по companyInfo.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.4. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить записи в таблицах:
4.1. company согласно описанию;
4.2. companyInfo согласно описанию.
Объект может быть изменен модулем company-service:
1. По сообщению на добавление категорий компании clearingMemberCategory из очереди kafka от модуля api-lk-company: необходимо создать записи в clearingMemberCategory согласно описанию с тэгом "При добавлении (от api-lk-company)".
2. По команде от пользователя (из backend-api): добавление объекта clearingMemberCategory/post.
3. По команде от пользователя (из backend-api): изменение объекта clearingMemberCategory/put.
4. По команде от пользователя (из backend-api): удаление объекта clearingMemberCategory/delete.
При добавлении (от api-lk-company ИЛИ clearingMemberCategory/post):
по логике заполнения стандартных полей.
При изменении (clearingMemberCategory/put):
по логике заполнения стандартных полей.
При удалении (clearingMemberCategory/delete):
из таблицы БД удаляется запись с данным идентификатором clearingMemberCategory.id
При добавлении (от api-lk-company):
заполняется идентификатором компании из company.id
При добавлении (clearingMemberCategory/post):
из соответствующего параметра метода добавления.
При изменении (clearingMemberCategory/put):
не меняется.
При удалении (clearingMemberCategory/delete):
из таблицы БД удаляется запись с данным идентификатором clearingMemberCategory.id
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При добавлении (clearingMemberCategory/post):
из соответствующего параметра метода добавления.
При изменении (clearingMemberCategory/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (clearingMemberCategory/delete):
из таблицы БД удаляется запись с данным идентификатором clearingMemberCategory.id
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода clearingMemberCategory/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице company есть компания, для которой нужно добавить категорию по clearingMemberCategory.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.3. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
3.4. Проверить, что в таблице clearingMemberCategory еще нет записи с такой же категорией для этой компании по ключу companyId и clearingMemberCategory. Если такая запись найдена, вернуть ошибку (3017) "Компании уже присвоена Категория %s".
4. Если предыдущие проверки выполнены успешно, добавить запись в таблицу clearingMemberCategory согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода clearingMemberCategory/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице clearingMemberCategory есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (3016) "Категория Компании не найдена".
3.3. Проверить, что в таблице company есть запись, которую нужно изменить по clearingMemberCategory.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.4. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить записи в таблице clearingMemberCategory согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода clearingMemberCategory/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице clearingMemberCategory есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (3016) "Категория Компании не найдена".
3.3. Проверить, что в таблице company есть запись, которую нужно изменить по clearingMemberCategory.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.4. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице clearingMemberCategory согласно описанию.
Объект может быть изменен модулем company-service:
1. По сообщению на добавление контактов компании contact из очереди kafka от модуля api-lk-company: необходимо создать записи в contact согласно описанию с тэгом "При добавлении (от api-lk-company)".
2. По команде от пользователя (из backend-api): изменение объекта contact/put.
При добавлении (от api-lk-company):
по логике заполнения стандартных полей.
При изменении (contact/put):
по логике заполнения стандартных полей.
При удалении:
отдельное удаление контакта компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
заполняется идентификатором компании из company.id
При изменении (contact/put):
не меняется.
При удалении:
отдельное удаление контакта компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (contact/put):
не меняется.
При удалении:
отдельное удаление контакта компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (contact/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление контакта компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода contact/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице contact есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (3015) "Контакт Компании не найден".
3.3. Проверить, что в таблице company есть запись, которую нужно изменить по contact.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.4. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице contact согласно описанию.
Объект может быть изменен модулем company-service:
1. По команде от пользователя (из backend-api): добавление объекта profileDocument/post.
При добавлении (из очереди api-lk-company):
по логике заполнения стандартных полей.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
заполняется идентификатором компании из company.id
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении/удалении:
отдельное изменение/удаление документа компании пока не предусмотрено, может быть изменена/удалена сама компания (детали company/delete)
При обработке метода:
1.Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода profileDocument/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице company есть запись, которую нужно изменить по profileDocument.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.3. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, создать запись в таблице profileDocument согласно описанию.
5. При успешном создании записи в profileDocument с типом documentType=XCNT, необходимо:
5.1. Передать в очередь kafka для модуля account-service сообщение на обновление статуса в бизнес-объекте account согласно описанию (см. пункт "Изменение account при обработке расторжения").
(!) Дальнейшая обработка документа о расторжении, то есть обновление статусов в company и relation, возможна только после ответа об успешном обновлении статуса в account.
5.2. Обновить статус в бизнес-объекте company [profileDocument.companyId=company.id] согласно описанию (см. пункт "При обработке документа расторжения договора").
5.3. Обновить статус в бизнес-объекте relation [profileDocument.companyId=relation.consumerId] согласно описанию (см. пункт "При обработке документа расторжения договора").
Объект может быть изменен модулем company-service:
1. По сообщению на добавление реквизитов компании companySymbols из очереди kafka от модуля api-lk-company: необходимо создать записи в companySymbols согласно описанию с тэгом "При добавлении (от api-lk-company)".
2. По команде от пользователя (из backend-api): изменение объекта companySymbols/put.
При добавлении (от api-lk-company):
по логике заполнения стандартных полей.
При изменении:
по логике заполнения стандартных полей.
При удалении:
отдельное удаление реквизита компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
заполняется идентификатором компании из company.id
При изменении (companySymbols/put):
не меняется.
При удалении:
отдельное удаление реквизита компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companySymbols/put):
не меняется.
При удалении:
отдельное удаление реквизита компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При изменении (companySymbols/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
отдельное удаление реквизита компании пока не предусмотрено, может быть удалена сама компания (детали company/delete)
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода companySymbols/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице companySymbols есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (3014) "Реквизит Компании не найден".
3.3. Проверить, что в таблице company есть запись, которую нужно изменить по companySymbols.companyId. Если такой записи нет, вернуть ошибку (3011) «Компания не найдена».
3.4. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице companySymbols согласно описанию.
Объект может быть изменен модулем clearing-service в следующих случаях:
I - По расписанию (task "Формирование реестра участников клиринга")
I - Создание clearmemberRegistry по расписанию
Формирование реестра запускается автоматически по расписанию (task=GLMR по справочнику task).
В реестр попадают только компании с relatoin.serviceProduct= «MKR».
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из company.tradingCode
Из company.clearingCode
Из company.fullName
Из company.shortName
Из clearingMemberCategory.clearingMemberCategory[company.id = clearingMemberCategory.companyId]
Текущая дата
serviceProduct= "MKR"
Должен вестись журнал изменений информации Участников Клиринга
CompanyInfo.UpdatedAt при изменении комментария
Код клиринга
Company.clearingCode
Комментарий
CompanyInfo.comment
От пользователя (из backend-api) могут прийти методы:
1. Добавления - keyRate/post
2. Изменения - keyRate/put
3. Удаления - keyRate/delete
По логике заполнения стандартных полей.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
=ACTV (см. справочник workflowStatus)
При изменении:
не меняется.
При удалении:
=BLKD (см. справочник workflowStatus)
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода keyRate/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить корректность значений полей: startDate и endDate. Если endDate меньше startDate, вернуть ошибку (2004) «Неверное значение поля %s».
3.3. Проверить, что еще нет такой же записи в таблице keyRate по ключу rate, startDate, endDate И со статусом security.workflowStatus=ACTV (см. справочник workflowStatus). Если запись существует, вернуть ошибку (2005) «Такая запись уже существует».
4. Если предыдущие проверки выполнены успешно, добавить новую запись в таблицу keyRate согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода keyRate/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить корректность значений полей (если эти поля заполнены): startDate и endDate. Если endDate меньше startDate, вернуть ошибку (2004) «Неверное значение поля %s».
3.3. Проверить, что в таблице keyRate есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (2006) «Запись не найдена».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице keyRate согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода keyRate/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице keyRate есть запись, которую нужно удалить, по ключу id. Если такой записи нет, вернуть ошибку (2006) «Запись не найдена».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице keyRate согласно описанию.
Объект может быть изменен модулем account-service:
I - По сообщению на добавление банковского счета из очереди kafka от модуля api-lk-company: в результате обработки заполнения объекта bankAccount.
II - По командам от пользователя (из очереди kafka от backend-api): добавление/изменение/удаление банковского счета (в интерфейсе банковский счет=банковским реквизитам) - объекта bankAccount.
III - По сообщению на добавление клирингового счета из очереди kafka от модуля balance-service: в процессе обработки заполнения объекта statement.
IV - При автоматическом создании информационного счета клиринговой системой: в результате обработки заполнения объекта informationAccount.
V - По сообщению на блокировку/разблокировку клирингового счета из очереди kafka от модуля dbf-importer (как результат заполнения таблицы sDf12) - см. Изменение account по sDf12.
VI - По сообщению на обновление статуса в account из очереди kafka от модуля company-service: в процессе обработки документа расторжения договора (обработка расторжения описана в разделе profileDocument) - см. Изменение account при обработке расторжения.
V - Изменение account по sDf12
Примечание: выполняется обработка записей таблицы sDf12 с generationId, который получен из сообщения очереди.
1. Проверить в sDf12.status получено одно из значений 0 (Blocked), 1 (Unblocked), 2 (Closed). Иначе записать в лог ошибку (5004) "Неверное значение поля %s".
2. Проверить, что в account есть запись с account.account=sDf12.account И accountType=CLRN (см. справочник accountType) И для соответствующей компании:
a) выбрать company.id по company.tradingCode=sDf12.deal;
б) выбрать relation.id по relation.consumerId=company.id, который выбран в предыдущем пункте, и relation.service=MKR (см. справочник service);
в) account.relationId = relation.id, который выбран в предыдущем пункте.
Если такой компании нет, то записать в лог ошибку (5013) name="Компания не найдена".
Если нет счета для найденной компании, то записать в лог ошибку (5011) name="Счет %s не найден".
3. Если ошибки не обнаружены, приступить к обновлению найденной записи таблицы account согласно описанию при изменении (из очереди от модуля dbf-importer).
4. По итогу обработки предыдущих пунктов (и в результате успешной обработки, и при выявлении ошибки) необходимо инициировать добавление ответных записей в таблице-квитанции sDf18 согласно логике заполнения sDf18. В метод заполнения sDf18 необходимо передавать значения ряда полей обработанной записи таблицы sDf12: id, generationId и ошибку, если она была обнаружена.
VI - Изменение account при обработке расторжения
1. Проверить отсутствие обязательств - liabilitiesClaimsAssets.liabilitiesQuantity[account.id=liabilitiesClaimsMoney.accountId] = 0
Если liabilitiesQuantity != 0, то записать в лог ошибку (3018) "У компании присутствуют обязательства" и положить в очередь kafka для модуля company-service ответное сообщение о выявленной ошибке. Дальнейшую обработку изменения статуса в account прекратить.
2. Если ранее ошибок не выявлено, необходимо обновить запись в account согласно описанию с тэгом "При обработке расторжения".
В результате положить в очередь kafka для модуля company-service ответное сообщение об успешном обновлении статуса в account.
При добавлении (любым из способов):
по логике заполнения стандартных полей.
При изменении (любым из способов):
по логике заполнения стандартных полей.
При удалении (bankAccount/delete):
по логике заполнения стандартных полей.
При добавлении (любым из способов):
по логике заполнения стандартных полей.
При изменении (любым из способов):
по логике заполнения стандартных полей.
При удалении (bankAccount/delete):
по логике заполнения стандартных полей.
При добавлении (любым из способов):
по логике заполнения стандартных полей.
При изменении (любым из способов):
по логике заполнения стандартных полей.
При удалении (bankAccount/delete):
по логике заполнения стандартных полей.
При добавлении (из очереди api-lk-company):
из соответствующего параметра сообщения очереди.
При добавлении (bankAccount/post):
из соответствующего параметра метода добавления.
При добавлении (из очереди balance-service):
из соответствующего параметра сообщения очереди.
При добавлении (создание инфо-счета):
/ToDo/
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При изменении (из очереди от модуля dbf-importer):
не меняется.
При удалении (bankAccount/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (из очереди api-lk-company):
=BANK (см. справочник accountType)
При добавлении (bankAccount/post):
=BANK (см. справочник accountType)
При добавлении (из очереди balance-service):
=CLRN (см. справочник accountType)
При добавлении (создание инфо-счета):
=INFO (см. справочник accountType)
При изменении (любым из способов):
не меняется.
При удалении (bankAccount/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (любым из способов):
=relation.id для relation.consumerId = данная company.id и relation.service=MKR (см. справочник service)
При изменении (любым из способов):
не меняется.
При удалении (bankAccount/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (любым из способов):
=ACTV (см. справочник accountStatus)
При изменении (bankAccount/put):
не меняется.
При изменении (из очереди от модуля dbf-importer):
=ACTV (см. справочник accountStatus) - при получении из соответствующего параметра очереди значения 1 (Unblocked);
=BLKD (см. справочник accountStatus) - при получении 0 (Blocked);
=CLOS (см. справочник accountStatus) - при получении 2 (Closed).
При удалении (bankAccount/delete):
=BLKD (см. справочник accountStatus)
При обработке расторжения:
=CLOS (см. справочник accountStatus)
При добавлении (любым из способов):
=ALWD (см. справочник allowed) для каждого счета, который впервые добавляется данной company.id
При изменении (любым из способов):
не меняется.
При удалении (bankAccount/delete):
не меняется.
При обработке расторжения:
не меняется.
При добавлении (любым из способов):
=relation.consumerId = данная company.id и relation.service=MKR (см. справочник service)
При изменении (любым из способов):
не меняется.
При удалении (bankAccount/delete):
не меняется.
При обработке расторжения:
не меняется.
Объект может быть изменен модулем company-service:
1. При создании компании (добавление компании описано в разделе company): необходимо создать записи в relation согласно описанию с тэгом "При создании компании".
2. По команде от пользователя (из backend-api): изменение объекта relation/put.
3. При обработке документа расторжения договора (обработка расторжения описана в разделе profileDocument): необходимо обновить запись в relation согласно описанию с тэгом "При обработке расторжения".
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При создании компании:
из company.id
При изменении (relation/put):
не меняется.
При обработке расторжения:
не меняется.
При создании компании:
всегда =1 "СПВБ".
При изменении (relation/put):
не меняется.
При обработке расторжения:
не меняется.
При создании компании:
=ACTV (см. справочник serviceStatus).
При изменении (relation/put):
из соответствующего параметра полученного метода, если значение отличается от сохраненного ранее.
При обработке расторжения:
=CLOS (см. справочник serviceStatus)
При создании компании:
=MKR (см. справочник service).
При изменении (relation/put):
не меняется.
При обработке расторжения:
не меняется.
При создании компании:
=ZERO (см. справочник serviceProduct).
При изменении (relation/put):
не меняется.
При обработке расторжения:
не меняется.
При создании компании:
пока не заполняется.
При изменении (relation/put):
из соответствующего параметра полученного метода, если значение отличается от сохраненного ранее.
При обработке расторжения:
не меняется.
При обработке метода:
1.Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода relation/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице relation есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (3015) "Запись о договорных отношениях не найдена".
3.3. Проверить, что в таблице company запись о компании имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (3012) «Компания неактивна».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице relation согласно описанию.
Объект может быть изменен модулем account-service:
1. По сообщению на добавление банковского счета bankAccount из очереди kafka от модуля api-lk-company: необходимо создать записи в bankAccount согласно описанию с тэгом "При добавлении".
2. По команде от пользователя (из backend-api): добавление - bankAccount/post
3. По команде от пользователя (из backend-api): изменение bankAccount/put
4. По команде от пользователя (из backend-api): удаление - bankAccount/delete
При добавлении (любым из способов):
по логике заполнения стандартных полей.
При изменении (bankAccount/put):
по логике заполнения стандартных полей.
При удалении (bankAccount/delete):
по логике заполнения стандартных полей.
При добавлении (любым из способов):
заполняется идентификатором созданной записи account.id (логика создания account).
При изменении (bankAccount/put):
не меняется.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При добавлении (bankAccount/post):
пока не заполняется.
При изменении (bankAccount/put):
пока не заполняется.
При удалении (bankAccount/delete):
не меняется.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При добавлении (bankAccount/post):
пока не заполняется.
При изменении (bankAccount/put):
пока не заполняется.
При удалении (bankAccount/delete):
не меняется.
При добавлении (от api-lk-company):
из соответствующего параметра сообщения очереди.
При добавлении (bankAccount/post):
пока не заполняется.
При изменении (bankAccount/put):
пока не заполняется.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
При добавлении (любым из способов):
из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (bankAccount/delete):
не меняется.
Поле таблицы account (логика создания/изменения/удаления записей в account).
При добавлении (любым из способов):
(?)из соответствующего параметра сообщения очереди/метода добавления.
При изменении (bankAccount/put):
(?)не меняется.
При удалении (bankAccount/delete):
не меняется.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода bankAccount/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что еще нет такой же записи в таблице account по ключу account И со статусом account.status=ACTV (см. справочник workflowStatus). Если запись существует, вернуть ошибку (5010) «Счет %s уже существует».
4. Если предыдущие проверки выполнены успешно, добавить новые записи в таблицы:
4.1. account согласно описанию;
4.2. bankAccount согласно описанию.
Обязательно, если currency=RUB
Обязательно, если currency=RUB
Обязательно, если currency=RUB
Обязательно, если currency=RUB
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода bankAccount/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице bankAccount есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (5011) «Счет %s не найден».
3.3. Проверить, что в таблице account есть запись, которую нужно изменить по bankAccount.accountId. Если такой записи нет, вернуть ошибку (5011) «Счет %s не найден».
3.4. Проверить, что в таблице accounty запись о счете имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (5012) «Счет %s неактивен».
4. Если предыдущие проверки выполнены успешно, изменить записи в таблицах:
4.1. account согласно описанию;
4.2. bankAccount согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода moneyMarketSecurity/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице bankAccount есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (5011) «Счет %s не найден».
3.3. Проверить, что в таблице account есть запись, которую нужно изменить по bankAccount.accountId. Если такой записи нет, вернуть ошибку (5011) «Счет %s не найден».
3.4. Проверить, что в таблице accounty запись о счете имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (5012) «Счет %s неактивен».
4. Если предыдущие проверки выполнены успешно, изменить записи в таблицах:
4.1. account согласно описанию;
4.2. bankAccount согласно описанию.
/ToDo/
Объект может быть изменен модулем securities-service:
1. По командам от пользователя (из backend-api): добавление/изменение/удаление объекта moneyMarketSecurity.
2. По сообщению из очереди kafka от модуля clearing-service (при загрузке сделки с новым инструментом) - логика создания записи в security
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении (moneyMarketSecurity/post):
из соответствующего параметра метода добавления.
При изменении (moneyMarketSecurity/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
пока не заполняется.
При изменении (moneyMarketSecurity/put):
пока не заполняется.
При удалении (moneyMarketSecurity/delete):
пока не заполняется.
При добавлении (moneyMarketSecurity/post):
пока не заполняется.
При изменении (moneyMarketSecurity/put):
пока не заполняется.
При удалении (moneyMarketSecurity/delete):
пока не заполняется.
При добавлении (moneyMarketSecurity/post):
из соответствующего параметра метода добавления.
При изменении (moneyMarketSecurity/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
пока не заполняется.
При изменении (moneyMarketSecurity/put):
пока не заполняется.
При удалении (moneyMarketSecurity/delete):
пока не заполняется.
При добавлении (moneyMarketSecurity/post):
пока не заполняется.
При изменении (moneyMarketSecurity/put):
пока не заполняется.
При удалении (moneyMarketSecurity/delete):
пока не заполняется.
При добавлении (moneyMarketSecurity/post):
из соответствующего параметра метода добавления.
При изменении (moneyMarketSecurity/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
=ACTV (см. справочник workflowStatus)
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении (moneyMarketSecurity/delete):
=BLKD (см. справочник workflowStatus)
Объект может быть изменен модулем securities-service:
1. По команде Добавления от пользователя (из backend-api) - moneyMarketSecurity/post
2. По команде Изменения от пользователя (из backend-api) - moneyMarketSecurity/put
3. По команде Удаления от пользователя (из backend-api) - moneyMarketSecurity/delete
4. По сообщению из очереди kafka от модуля clearing-service (при загрузке сделки с новым инструментом) - логика создания записи в moneyMarketSecurity
По логике заполнения стандартных полей.
При добавлении:
заполняется идентификатором созданной записи security.id (логика создания записи в security).
При изменении:
не меняется.
При удалении:
не меняется.
При добавлении:
пока не заполняется.
При изменении:
пока не заполняется.
При удалении:
пока не заполняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления.
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
При добавлении:
из соответствующего параметра метода добавления (пока всегда RUB).
При изменении:
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении:
не меняется.
Поле таблицы security (логика создания/изменения/удаления записей в security).
Поле таблицы security (логика создания/изменения/удаления записей в security).
Поле таблицы security (логика создания/изменения/удаления записей в security).
Поле lotSize таблицы listing (логика создания/изменения/удаления записей в listing)
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода moneyMarketSecurity/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить корректность значений полей: startDate и endDate. Если endDate меньше startDate, вернуть ошибку (1004) «Неверное значение поля %s».
3.3. Проверить, что еще нет такой же записи в таблице security по ключу securitySymbol И со статусом security.workflowStatus=ACTV (см. справочник workflowStatus). Если запись существует, вернуть ошибку (1010) «Такой Инструмент уже существует».
4. Если предыдущие проверки выполнены успешно, добавить новые записи в таблицы:
4.1. security согласно описанию;
4.2. moneyMarketSecurity согласно описанию;
4.3. listing согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода moneyMarketSecurity/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить корректность значений полей (если эти поля заполнены): startDate и endDate. Если endDate меньше startDate, вернуть ошибку (1004) «Неверное значение поля %s».
3.3. Проверить, что в таблице moneyMarketSecurity есть запись, которую нужно изменить, по ключу id. Если такой записи нет, вернуть ошибку (1011) «Инструмент не найден».
3.4. Проверить, что в таблице security есть запись, которую нужно изменить по moneyMarketSecurity.securityId. Если такой записи нет, вернуть ошибку (1011) «Инструмент не найден».
3.5. Проверить, что в таблице security запись об инструменте имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (1012) «Инструмент неактивен».
4. Если предыдущие проверки выполнены успешно, изменить записи в таблицах:
4.1. security согласно описанию;
4.2. moneyMarketSecurity согласно описанию;
4.3. listing согласно описанию.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода moneyMarketSecurity/delete в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице moneyMarketSecurity есть запись, которую нужно удалить, по ключу id. Если такой записи нет, вернуть ошибку (1011) «Инструмент не найден».
3.3. Проверить, что в таблице security есть запись, которую нужно изменить по moneyMarketSecurity.securityId. Если такой записи нет, вернуть ошибку (1011) «Инструмент не найден».
3.4. Проверить, что в таблице security запись об инструменте имеет статус ACTV (см. справочник workflowStatus). Иначе вернуть ошибку (1012) «Инструмент неактивен».
4. Если предыдущие проверки выполнены успешно, изменить записи в таблицах:
4.1. security согласно описанию;
4.2. moneyMarketSecurity согласно описанию;
4.3. listing согласно описанию.
Объект может быть изменен модулем securities-service:
1. По командам от пользователя (из backend-api): добавление/изменение/удаление объекта moneyMarketSecurity.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении (moneyMarketSecurity/post):
заполняется идентификатором созданной записи security.id (логика создания записи в security).
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
из соответствующего параметра метода добавления.
При изменении (moneyMarketSecurity/put):
из соответствующего параметра метода изменения, если значение отличается от сохраненного ранее.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
=1 (ссылка на таблицу market - необходимо уточнение значения!)
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
=security.securitySymbol
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
=security.fullName
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении:
не меняется.
При добавлении (moneyMarketSecurity/post):
=moneyMarketSecurity.nominalCurrency
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении (moneyMarketSecurity/delete):
не меняется.
При добавлении (moneyMarketSecurity/post):
=ACTV (см. справочник workflowStatus)
При изменении (moneyMarketSecurity/put):
не меняется.
При удалении (moneyMarketSecurity/delete):
=BLKD (см. справочник workflowStatus)
Объект может быть изменен модулем balance-service в следующих случаях:
I - Изменение accountBalance в ходе преклиринга/постклиринга
II - Изменение accountBalance по statement
III - Изменение accountBalance в ходе клиринга
I - Изменение accountBalance в ходе преклиринга/постклиринга
При получении сообщения на изменение accountBalance в ходе преклиринга/постклиринга из очереди kafka от модуля scheduler-service [запускается автоматически по расписанию или launcher "startPreClearing" / "startPostClearing" (когда Администратор Клиринга нажал кнопку необходимой ему команды в WEB-интерфейсе)], необходимо обновить все записи таблицы accountBalance согласно описанию с тэгом "Преклиринг" или "Постклиринг" соответственно.
II - Изменение accountBalance по statement
1. Перед изменением accountBalance необходимо выполнить ряд проверок:
1.1. Найти в company запись, у которой company.id=statement.addresseeId. Если такой записи нет, передать ошибку (5211) "Компания не найдена" для ее сохранения в statement.
1.2. Проверить, есть ли в таблице account счет, у которого account.id=statement.accountId и account.accountType=CLRN (см. справочник accountType).
Если такой записи нет, передать ошибку (5217) "Счет %s не найден" для ее сохранения в statement.
1.3. Проверить в account статус записи, у которого account.id=statement.accountId и account.accountType=CLRN (см. справочник accountType).
Если account.status≠ACTV (см. справочник workflowStatus), передать ошибку (5218) "Счет %s неактивен" для ее сохранения в statement.
2. Если все предыдущие проверки пройдены, проверить, есть ли в таблице accountBalance запись, у которой accountBalance.accountId=statement.accountId и accountBalance.companyId=statement.companyId:
2.1. Если такая запись найдена, то новая запись не добавляется, необходимо обновить поля найденной записи согласно описанию.
2.2. Если такая запись не найдена, то необходимо сформировать новую запись согласно описанию.
III - Изменение accountBalance в ходе клиринга
При получении сообщения на изменение accountBalance из очереди kafka от модуля clearing-service, необходимо:
1. Найти запись accountBalance для счета, по которому необходимо обновить баланс в результате клиринга (обработка клиринга описана в разделе Клиринг).
2. Обновить найденную запись согласно описанию с тэгом "Клиринг".
Преклиринг/Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf-таблицам):
по логике заполнения стандартных полей.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
=statement.addresseeId
При обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf-таблицам):
по логике заполнения стандартных полей.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
дата-время изменения записи.
При добавлении/обновлении (на базе изменения statement по sDf-таблицам):
по логике заполнения стандартных полей.
Клиринг:
дата-время изменения записи.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
=statement.accountId
При обновлении (на базе изменения statement по sDf-таблицам):
аналогично добавлению, если значение отличается от сохраненного ранее.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
из account.accountType, у которой account.id=statement.accountId
При обновлении (на базе изменения statement по sDf-таблицам):
аналогично добавлению, если значение отличается от сохраненного ранее.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
из account.account, у которой account.id=statement.accountId
При обновлении (на базе изменения statement по sDf-таблицам):
аналогично добавлению, если значение отличается от сохраненного ранее.
Клиринг:
не меняется.
Преклиринг:
=0
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf01):
=statement.amount
При добавлении/обновлении (на базе изменения statement по sDf16/sDf09):
не меняется.
Клиринг:
не меняется.
Преклиринг:
=accountBalance.closeBalanceAmount
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг:
не меняется.
Постклиринг:
=accountBalance.balanceAmount
При добавлении/обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг:
=0
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
Преклиринг:
=accountBalance.closeBalanceAmount
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf01):
=statement.amount из сообщения очереди.
При добавлении/обновлении (на базе изменения statement по sDf16/sDf09):
=accountBalance.freeBalanceAmount+statement.amount из сообщения очереди.
Клиринг:
=accountBalance.freeBalanceAmount+liabilitiesClaimsMoney.liabilitiesAmount из сообщения очереди.
Преклиринг:
=0
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf01):
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf16/sDf09):
=accountBalance.freeBalanceAmount+statement.amount из сообщения очереди.
Клиринг:
=accountBalance.changeBalanceAmount+liabilitiesClaimsMoney.liabilitiesAmount из сообщения очереди.
Преклиринг:
=0
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf01):
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf16/sDf09):
=accountBalance.creditAmount+statement.amount из сообщения очереди.
Клиринг:
=accountBalance.creditAmount+|liabilitiesClaimsMoney.liabilitiesAmount| из сообщения очереди.
Преклиринг:
=0
Постклиринг:
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf01):
не меняется.
При добавлении/обновлении (на базе изменения statement по sDf16/sDf09):
=accountBalance.debitAmount+statement.amount из сообщения очереди.
Клиринг:
=accountBalance.debitAmount+|liabilitiesClaimsMoney.liabilitiesAmount| из сообщения очереди.
Преклиринг:
=accountBalance.closeBalanceAmount
Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf01):
=statement.amount
При обновлении (на базе изменения statement по sDf01):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении/обновлении (на базе изменения statement по sDf16/sDf09):
=accountBalance.balanceAmount+statement.amount из сообщения очереди.
Клиринг:
=accountBalance.balanceAmount+liabilitiesClaimsMoney.liabilitiesAmount из сообщения очереди.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
=ACNT (см. справочник balanceAccountType).
При обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
=текущая дата.
При обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
=statement.cashMovementCurrencyCode
При обновлении (на базе изменения statement по sDf-таблицам):
аналогично добавлению, если значение отличается от сохраненного ранее.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
из company.tradingCode, у которой company.id=accountBalance.companyId
При обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
из company.shortName, у которой company.id=accountBalance.companyId
При обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Преклиринг/Постклиринг:
не меняется.
При добавлении (на базе изменения statement по sDf-таблицам):
из company.fullName, у которой company.id=accountBalance.companyId
При обновлении (на базе изменения statement по sDf-таблицам):
не меняется.
Клиринг:
не меняется.
Объект может быть изменен модулем clearing-service в следующих случаях:
I - По расписанию (task "Формирование реестров")
I - Создание balanceRegistry по расписанию
Формирование реестра запускается автоматически по расписанию (task=GREG по справочнику task).
В ходе формирования реестра на основе бизнес-объекте sDf01. В реестр попадают только те записи, у которых operationStatus.operationStatus = EXEC [sDf01.id=statement.inSDfId]
В таблицу balanceRegistry должны быть добавлены записи согласно описанию.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из sDf01.generationTime
Из sDf01.curr_code
Из sDf01.account
Из sDf01.remainder
Не используется в системе
Не используется в системе
Из sDf01.market
Из sDf01.acc_name
typeRemaiins ="Входящий"
Из sDf01.id
Из account.companyId для account.account=balanceRegistry.account
От пользователя (из backend-api) могут прийти методы:
1. Добавления - managementJournal/post
По логике заполнения стандартных полей.
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
При добавлении (managementJournal/post):
указывается пользователь, который создал запись.
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
При добавлении (managementJournal/post):
=CRT (см. справочник managementJournalStatus)
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
При добавлении (managementJournal/post):
из соответствующего параметра метода добавления.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода managementJournal/post в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Необходимо проверить корректность значений поля: eventDate. Если eventDate меньше текущей даты, вернуть ошибку (1004) «Неверное значение поля %s».
4. Если предыдущие проверки выполнены успешно, добавить новые записи в таблицу:
4.1. menegementJournal согласно описанию;
Заполняется модулем journal-service согласно описанию в результате получения сообщения из очереди kafka от dbf-importer с результатами загрузки ДФ-файлов. В сообщении будет передан ряд параметров, которые перечислены в разделе "Заполнение журнала входящих документов" ТЗ dbf-importer (P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-loader.Дополнение для разработчиков.docx). Под заполнением inDocumentJournal понимается добавление записей в таблицу (изменение/удаление не предполагается).
По логике заполнения стандартных полей.
Из соответствующего параметра сообщения очереди.
Из соответствующего параметра сообщения очереди.
Из соответствующего параметра сообщения очереди.
Из соответствующего параметра сообщения очереди.
Из company.fullName для company.id=2 "НКО АО ПРЦ".
Всегда =1.
Пока не заполняется.
=STHS (см. справочник courierType).
Пока не заполняется.
Пока не заполняется.
Из соответствующего параметра сообщения очереди.
Пока не заполняется.
Пока не заполняется.
Из соответствующего параметра сообщения очереди.
Заполняется модулем journal-service согласно описанию в результате получения сообщения из очереди kafka от dbf-exporter с результатами загрузки ДФ-файлов. В сообщении будет передан ряд параметров, которые перечислены в разделе "Заполнение журнала исходящих документов" ТЗ dbf-exporter (P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-export.Дополнение для разработчиков.docx). Под заполнением outDocumentJournal понимается добавление записей в таблицу (изменение/удаление не предполагается).
По логике заполнения стандартных полей.
Из соответствующего параметра сообщения очереди.
Из соответствующего параметра сообщения очереди.
Из соответствующего параметра сообщения очереди.
Из соответствующего параметра сообщения очереди.
Из company.fullName для company.id=2 "НКО АО ПРЦ".
Всегда =1.
Пока не заполняется.
=STHS (см. справочник courierType).
Пока не заполняется.
Пока не заполняется.
Из соответствующего параметра сообщения очереди.
Пока не заполняется.
Из соответствующего параметра сообщения очереди.
Объект может быть изменен модулем clearing-service в следующих случаях:
I - Изменение executionDeposit при получении новых сделок из ТС (новые записи в s_trade)
II - Изменение executionDeposit по итогу расчета требований и обязательств
III - Изменение executionDeposit по итогу клиринга
I - Изменение executionDeposit при получении новых сделок из ТС
Должна быть автоматическая обработка таблицы s_trade на получение новых сделок, старших чем запрошенные по параметру trade_num, равному 0 на начало дня.
1.При выявлении новых сделок необходимо выполнить следующие контрольные проверки:
1.1. Найти в security запись, у которой security.securitySymbol=s_trade.sec_code. Если такой записи нет, то положить в очередь kafka для модуля securities-service сообщение о добавлении инструмента с параметром securitySymbol=s_trade.sec_code .
(!) Дальнейшая обработка возможна только после ответа об успешном добавлении инструмента.
1.2. Найти в company запись, у которой company.tradingCode=s_trade.firm_id. Если такой записи нет, запомнить ошибку (10010) "Компания не найдена" для ее записи в журнал аудита работы системы.
1.3. Рассчитанные в КС контрольные суммы (общее количество сделок и суммарный объем заключенных сделок в денежном выражении) должны совпадать со значениями, рассчитанными Торговой системой:
count(execution[tradingDay]) = count (trade_arqua)
2. По итогу проверок:
2.1. При непрохождении хотя бы одной из проверок, информация об этом должна быть записана в журнал аудита работы системы с текстом ошибки errorText «Проверка на выгрузку сделок из Торговой Системы завершилась с расхожожениями».
Также в журнал аудит работы системы должен быть записан стандартный набор параметров:
createdAt (Дата и время создания события)
userId (Идентификатор пользователя)
module (Код модуля, являющегося источником события)
object (Объект системы, в виде бизнес-объекта, кода действия, кода события системы или расписания, наименования справочника)
action (Метод бизнес-объекта, CRUD операция, уточнение отчета или функция расписания)
errorText (Сообщение об ошибке при наличии)
parameters (Данные бизнес объекта, параметры метода или действия пользователя, события системы или расписания)
2.2. Если все предыдущие проверки пройдены, то необходимо сформировать новую запись согласно описанию.
2.3. В результате успешного создания записи в executionDeposit, необходимо создать копию этой записи в dealRegister согласно описанию.
II - Изменение executionDeposit по итогу расчета требований и обязательств
ToDo - обновляется executionDeposit.coverageStatus
III - Изменение executionDeposit по итогу клиринга
ToDo - обновляется executionDeposit.sessionId
По логике заполнения стандартных полей.
Из s_trade.trade_num
Из s_trade.trade_date_time
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
=текущая дата
По логике заполнения стандартных полей.
Из account.id, выбранного по account.account=s_trade.money_account
=MKRS (см. объект market)
Из s_trade.price
Из s_trade.qty
=executionDeposit.lots * listing.lotSize, выбранный по listing.securityId=executionDeposit.securityId
Из s_trade.value
Из s_trade.value
пока не заполняется
Символьный код по справочнику moneyFlowSide), соответствующий значению из s_trade.operation
=RUB (см. справочник currencyCode)
Из company.id, выбранного по company.tradingCode=s_trade.firm_id
Из s_trade.days_to_mat_date
=текущий день
Из s_trade.settle_date
пока не заполняется
пока не заполняется
Из s_trade.settle_code
Из security.fullName, выбранного по security.id=executionDeposit.securityId
Из security.securitySymbol, выбранного по security.id=executionDeposit.securityId
Из security.id, выбранного по security.securitySymbol=s_trade.sec_code
пока не заполняется
Заполняется по справочнику allowed в результате расчета требований и обязательств.
Заполняется идентификатором сессии в результате клиринговой сессии.
Объект может быть изменен модулем clearing-service в следующих случаях:
I - Изменение dealRegister при успешном сохранении сделки
I - Изменение dealRegister при успешном сохранении сделки
При получении команды на добавление в данный реестр записи о сделке, которая успешно сохранена в executionDeposit (заполнение executionDeposit описано в разделе executionDeposit), необходимо:
1. Проверить, есть ли уже в dealRegister запись об этой сделке по dealRegister.exchangeExecutionId=executionDeposit.exchangeExecutionId и dealRegister.tradingDate=текущая дата:
1.1. Если такая запись найдена, обновить ее согласно описанию с тэгом "При обновлении записи".
1.2. Если такой записи нет, добавить согласно описанию с тэгом "При добавлении записи".
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из executionDeposit.id
При добавлении:
из executionDeposit.exchangeExecutionId
При обновлении:
не меняется.
При добавлении/обновлении:
из executionDeposit.exchangeExecutionTime
При добавлении:
из executionDeposit.tradingDate
При обновлении:
не меняется.
При добавлении/обновлении:
из account.account, у которой account.id=executionDeposit.accountId
При добавлении/обновлении:
из executionDeposit.market
При добавлении/обновлении:
из executionDeposit.price
При добавлении/обновлении:
из executionDeposit.firstLegAmount
При добавлении/обновлении:
из executionDeposit.side
При добавлении/обновлении:
из executionDeposit.settlementCurrency
При добавлении/обновлении:
из executionDeposit.companyId
При добавлении/обновлении:
из executionDeposit.firstLegSettlementDate
При добавлении/обновлении:
из executionDeposit.secondLegSettlementDate
При добавлении/обновлении:
из executionDeposit.securityFullName
При добавлении/обновлении:
из executionDeposit.securitySymbol
При добавлении/обновлении:
из executionDeposit.securityId
При добавлении/обновлении:
из executionDeposit.counterPartyId
При добавлении/обновлении:
из executionDeposit.coverageStatus
При добавлении/обновлении:
из executionDeposit.sessionId
Объект может быть изменен модулем clearing-service в следующих случаях:
I - В результате клиринга
I - Создание admittedDealRegister в результате клиринга
Формирование реестра запускается в результате клиринга (обработка клиринга описана в разделе Клиринг).
В ходе формирования реестра на базе сделок из executionDeposit, у которых executionDeposit.coverageStatus=ALWD or executionDeposit.coverageStatus=DEND (см. справочник allowed), в таблицу coveredDealRegister должны быть добавлены записи согласно описанию.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из executionDeposit.id
Из company.fullName, у которой id=1
Из executionDeposit.tradingDate
Из executionDeposit.exchangeExecutionId
Из executionDeposit.exchangeExecutionTime
Из executionDeposit.securityFullName
Из executionDeposit.securityFullName
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из company.fullName, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из company.clearingCode, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из account.account, у которой account.id=executionDeposit.accountId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из company.fullName, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из company.clearingCode, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из account.account, у которой account.id=executionDeposit.accountId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
из executionDeposit.firstLegAmount
Объект может быть изменен модулем clearing-service в следующих случаях:
I - В результате клиринга
I - Создание coveredDealRegister в результате клиринга
Формирование реестра запускается в результате клиринга (обработка клиринга описана в разделе Клиринг).
В ходе формирования реестра на базе сделок из executionDeposit, у которых executionDeposit.coverageStatus=ALWD (см. справочник allowed), в таблицу coveredDealRegister должны быть добавлены записи согласно описанию.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из executionDeposit.id
Из company.fullName, у которой id=1
Из executionDeposit.tradingDate
Из executionDeposit.exchangeExecutionId
Из executionDeposit.exchangeExecutionTime
Из executionDeposit.securityFullName
Из executionDeposit.securityFullName
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из company.fullName, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из company.clearingCode, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из account.account, у которой account.id=executionDeposit.accountId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из company.fullName, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из company.clearingCode, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из account.account, у которой account.id=executionDeposit.accountId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
из executionDeposit.firstLegAmount
Объект может быть изменен модулем clearing-service в следующих случаях:
I - В результате клиринга
I - Создание uncoveredDealRegister в результате клиринга
Формирование реестра запускается в результате клиринга (обработка клиринга описана в разделе Клиринг).
В ходе формирования реестра на базе сделок из executionDeposit, у которых executionDeposit.coverageStatus=DEND (см. справочник allowed), в таблицу uncoveredDealRegister должны быть добавлены записи согласно описанию.
по логике заполнения стандартных полей.
по логике заполнения стандартных полей.
по логике заполнения стандартных полей.
по логике заполнения стандартных полей.
из executionDeposit.id
из company.fullName, у которой id=1
из executionDeposit.tradingDate
из executionDeposit.exchangeExecutionId
из executionDeposit.exchangeExecutionTime
из executionDeposit.securitySymbol
из executionDeposit.securityFullName
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из company.fullName, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из company.clearingCode, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
заполняется из account.account, у которой account.id=executionDeposit.accountId
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из company.fullName, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из company.clearingCode, у которой company.id=executionDeposit.companyId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
-если executionDeposit.side=BUY (см. справочник moneyFlowSide),
заполняется из account.account, у которой account.id=executionDeposit.accountId
-если executionDeposit.side=SELL (см. справочник moneyFlowSide),
не заполняется
из executionDeposit.firstLegAmount
=NACK (см. справочник resultStatus)
При формировании отчетов Клиринговая Система должна добавлять запись о сформированном отчете в реестр отправленных отчетов:
infoAccountBalance - отчета о денежных средствах на счетах внутреннего учета (клиринговом регистре) УК
netPositionBank и netPositionInitiator - Оотчета об обязательствах/требованиях УК
liabilitiesClaimsBank - Отчета об обязательствах/требованиях (отчета о нетто-позициях) в разрезе каждого Уполномоченного банка с целью отображения в ЛК
liabilitiesClaimsSingleBank - Отчета об обязательствах/требованиях (отчета о нетто-позициях) по соответствующему Уполномоченному банку с целью отображения в ЛК
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
infoAccountBalance.company_fullName
OR
netPositionInitiator.liabilitiesClaimsAssets_fullName
OR
netPositionBank.liabilitiesClaimsAssets_fullName
OR
company_fullName [clearingCode = liabilitiesClaimsBank.company_clearingCode]
OR
company_fullName [clearingCode = liabilitiesClaimsSingleBank.company_clearingCode]
infoAccountBalance.clearingCode
OR
netPositionBank.company_clearingCode
OR
netPositionInitiator.company_clearingCode
OR
liabilitiesClaimsBank.company_clearingCode
OR
liabilitiesClaimsSingleBank.company_clearingCode
Из infoAccountBalance.sessionId
Из netPositionBank.liabilitiesClaimsAssets_comment
netPositionInitiator.liabilitiesClaimsAssets_comment
Наименование отчета
quantity = 1
При формировании отчетов Клиринговая Система должна создать записи в журнале регистрации договоров на оказание клиринговых услуг
Информация заполняется соответствующими полями из объекта profileDocument с типом документ CNTR – Договор клиринга.
Также должга появиться запись в данном регистре, при добавлении документа с типом XCNT - Документ о расторжении Договора клиринга
Из генератора
Дата создания записи
Дата изменения записи
Наименование документа
profileDocument.name
Номер документа
profileDocument.number
Дата составления
profileDocument.issueDate
Наименование лица
company.fullName [id=profileDocument.companyId]
Идентификатор Компании
profileDocument.companyId
Идентификатор типа документа
profileDocument.documentType
Место выдачи
profileDocument.issuePlace
Кем выдан
profileDocument.issuer
Код выдавшего органа
profileDocument.issuerCode
Место
profileDocument.place
Дата начала срока действия
profileDocumente.validFromDate
Дата окончания срока действия
profileDocumente.validToDate
Дата расторжения
profileDocumente.validTiDate[documentType = XCNT]
Указывается вручную категория, дата прекращения и основание
documentType = CNTR
Объект может быть изменен модулем clearing-service в следующих случаях:
I - По расписанию (task "Формирование реестров")
Реестр формируется на основе бизнес-объекта paymentInstruction.
В таблицу orderRegistry должны быть добавлены записи согласно описанию.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из paymentInstruction.clearingDate
Из paymentInstruction.creditLeg_accountId
Из paymentInstruction.creditLeg_currencyCode
Из paymentInstruction.creditLeg_amount
Из paymentInstruction.creditLeg_direction
Из paymentInstruction.debitLeg_account
Из paymentInstruction.senderId
Из paymentInstruction.addresseeId
Из paymentInstruction.documentNumber
Объект может быть изменен модулем clearing-service в следующих случаях:
I - Изменение liabilitiesClaimsMoney в ходе клиринга
I - Изменение liabilitiesClaimsMoney в ходе клиринга
При получении команды на изменение liabilitiesClaimsMoney в ходе клиринга (обработка клиринга описана в разделе Клиринг), необходимо:
1. Найти две записи (по первой ноге - на сегодня, по второй ноге - на дату возврата) в liabilitiesClaimsMoney для счета, по которому необходимо обновить обязательства и требования:
1.1. Условие поиска записи по первой ноге: liabilitiesClaimsMoney.
1.2. Условие поиска записи по второй ноге:
2. По итогу поиска записей:
2.1. Если искомые записи отсутствуют, создать новые записи согласно описанию с тэгом "При создании".
2.2. Если записи найдены, то обновить их согласно описанию с тэгом "При обновлении".
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
При обновлении:
не меняется.
Объект может быть изменен модулем clearing-service в следующих случаях:
I - Изменение liabilitiesClaimsAssets в ходе клиринга
I - Изменение liabilitiesClaimsAssets в ходе клиринга
При получении команды на изменение liabilitiesClaimsAssets, необходимо:
1. Найти запись liabilitiesClaimsAssets для счета, по которому необходимо обновить обязательства и требования в результате клиринга (обработка клиринга описана в разделе Клиринг).
2. Обновить найденную запись согласно описанию с тэгом "Клиринг".
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
При обновлении:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Клиринг:
не меняется.
Объект может быть изменен модулем balance-service в результате:
I - получения из очереди kafka от модуля dbf-importer сообщения на обработку новых записей таблицы sDf01 - см. Изменение statement по sDf01;
II - получения из очереди kafka от модуля dbf-importer сообщения на обработку новых записей таблицы sDf16 - см. Изменение statement по sDf16.
III - получения из очереди kafka от модуля dbf-importer сообщения на обработку новых записей таблицы sDf09 - см. Изменение statement по sDf09.
Примечание: если при выборе счета, по которому необходимо выполнить какие-либо действия, нашлось несколько подходящих счетов, то необходимо выбирать тот, у которого account.processingSign=ALWD (см. справочник allowed).
I - Изменение statement по sDf01
1. Перед изменением statement необходимо выполнить ряд проверок:
1.0. Выполнить проверку активности клиринговой сессии. (пока не делаем, добавим если будет такое требование от Заказчика)
1.1. Найти в company запись, у которой company.tradingCode=sDf01.deal. Если такой записи нет, записать в лог ошибку (5211) "Компания не найдена".
1.2. Проверить, есть ли в таблице account счет, у которого account.account=sDf01.account и account.accountType=CLRN (см. справочник accountType).
Если такой записи нет, то положить в очередь kafka для модуля account-service сообщение о добавлении счета с параметрами account=sDf01.account и companyId, найденную в предыдущих пунктах при проверке.
(!) Дальнейшая обработка sDf01 возможна только после ответа об успешном создании счета.
1.3. Проверить, что sDf01.curr_code=RUR. Иначе записать в лог ошибку (5213) "Валюта не найдена".
1.4. Проверить, что sDf01.dat=текущая дата. Иначе записать в лог ошибку (5214) "Загрузка остатков возможна только на текущую дату".
1.5. Проверить, что sDf01.market=U. Иначе записать в лог ошибку (5215) "Загрузка остатков возможна только по рынку МКР".
1.6. Проверить, что sDf01.acc_type=A. Иначе записать в лог ошибку (5216) "Загрузка остатков возможна только по собственным счетам".
2. Если все предыдущие проверки пройдены, проверить, есть ли в таблице statement запись, у которой statement.account=sDf01.account:
2.1. Если такая запись найдена, то новая запись не добавляется, необходимо обновить поля найденной записи согласно описанию.
2.2. Если такая запись не найдена, то необходимо сформировать новую запись согласно описанию.
3. По итогу добавления/изменения statement:
3.1. Необходимо инициировать добавление ответных записей в таблице-квитанции sDf02 согласно описанию. В метод заполнения sDf02 необходимо передавать:
- sDf01.id (ссылка на ту запись таблицы sDf01, которая инициирует создание ответной записи в таблице sDf02);
- ошибку из п.1 раздела Изменение statement по sDf01, если она была обнаружена.
3.2. Если в п.1 раздела Изменение statement по sDf01 ошибок не обнаружено, то инициировать изменение таблицы accountBalance согласно описанию.
По итогу изменения accountBalance в statement должны быть обновлены значения полей:
- operationStatus;
- errorCode в случае выявления ошибки;
- errorText в случае выявления ошибки.
II - Изменение statement по sDf16
1. Перед изменением statement необходимо выполнить ряд проверок:
1.0. Выполнить проверку активности клиринговой сессии. (пока не делаем, добавим если будет такое требование от Заказчика)
1.1. Найти компанию, для которой необходимо выполнить операцию дозачисления/списания, по следующей логике:
выбрать companyId из companySymbols, у которой
для companySymbols.companySymbol=INN указано companySymbols.companySymbolValue=sDf16.INN
ИЛИ для companySymbols.companySymbol=BIC указано companySymbols.companySymbolValue=sDf16.BIC [в sDf16 будет заполнено или INN, или BIC].
Если такой записи нет, записать в лог ошибку (5211) "Компания не найдена".
1.2. Проверить, есть ли в таблице account счет, у которого account.account=sDf16.account и account.accountType=CLRN (см. справочник accountType). Иначе записать в лог ошибку (5217) "Счет %s не найден".
1.3. Проверить, что sDf16.market=U. Иначе записать в лог ошибку (5219) "Дозачисления/списания возможны только по рынку МКР".
1.4. Если sDf16.sum меньше нуля, то проверить достаточность средств на счете:
accountBalance.freeBalanceAmount [выбранное по accountBalance.account=sDf16.account и accountBalance.accountType=CLRN (см. справочник accountType)] должно быть больше или равно sDf16.sum . Иначе записать в лог ошибку (5222) "Сумма списания превышает сумму средств на счете".
2. Если все предыдущие проверки пройдены, проверить, есть ли в таблице statement запись, у которой statement.account=sDf16.account:
2.1. Если такая запись найдена, то новая запись не добавляется, необходимо обновить поля найденной записи согласно описанию.
2.2. Если такая запись не найдена, то необходимо сформировать новую запись согласно описанию.
3. По итогу добавления/изменения statement:
3.1. Необходимо инициировать добавление ответных записей в таблице-квитанции sDf17 согласно описанию. В метод заполнения sDf17 необходимо передавать:
- sDf16.id (ссылка на ту запись таблицы sDf16, которая инициирует создание ответной записи в таблице sDf17);
- ошибку из п.1 раздела Изменение statement по sDf16, если она была обнаружена.
3.2. Отправить пользователю запрос на подтвержение операции дозачисления/списания. Для этого необходимо в очередь kafka для модуля utility-service направить сообщение на добавление записи в таблицу notification, при этом передается ряд парметров:
- senderId=statement.senderId;
- addresseeId=statement.addresseeId;
- objectType=STMT (см. справочник objectType);
- objectId=statement.id .
По итогу обновления статуса notification (придет из очереди kafka от модуля utility-service, когда от пользователя получено подтверждение/отклонение операции дозачисления/списания) в statement должно быть обновлено значение поля:
- operationStatus.
3.3. Если в п.1 раздела Изменение statement по sDf16 ошибок не обнаружено
И в notification для обрабатываемой операции дозачисления/списания статус notificationStatus обновлен на ACPT (см. справочник notificationStatus),
то инициировать изменение таблицы accountBalance согласно описанию.
По итогу изменения accountBalance в statement должны быть обновлены значения полей:
- operationStatus;
- errorCode в случае выявления ошибки;
- errorText в случае выявления ошибки.
III - Изменение statement по sDf09
1. Перед изменением statement необходимо выполнить ряд проверок:
1.0. Выполнить проверку активности клиринговой сессии. (пока не делаем, добавим если будет такое требование от Заказчика)
1.1. Найти компанию, для которой необходимо отразить информацию из уведомления о поступлении средств на клиринговый счет, по следующей логике:
выбрать companyId из companySymbols, у которой для companySymbols.companySymbol=INN указано companySymbols.companySymbolValue=sDf09.INN .
Если такой записи нет, записать в лог ошибку (5211) "Компания не найдена".
1.2. Проверить, есть ли в таблице account счет, у которого account.account=sDf09.account и account.accountType=CLRN (см. справочник accountType). Иначе записать в лог ошибку (5217) "Счет %s не найден".
1.3. Проверить, что sDf09.market=U. Иначе записать в лог ошибку (5215) "Поступление средств возможно только по рынку МКР".
1.4. Если sDf09.sum меньше нуля, то проверить достаточность средств на счете:
accountBalance.freeBalanceAmount [выбранное по accountBalance.account=sDf09.account и accountBalance.accountType=CLRN (см. справочник accountType)] должно быть больше или равно sDf16.sum . Иначе записать в лог ошибку (5222) "Сумма списания превышает сумму средств на счете".
2. Если все предыдущие проверки пройдены, проверить, есть ли в таблице statement запись, у которой statement.account=sDf09.account:
2.1. Если такая запись найдена, то новая запись не добавляется, необходимо обновить поля найденной записи согласно описанию.
2.2. Если такая запись не найдена, то необходимо сформировать новую запись согласно описанию.
3. По итогу добавления/изменения statement:
3.1. Необходимо инициировать добавление ответных записей в таблице-квитанции sDf10 согласно описанию. В метод заполнения sDf10 необходимо передавать:
- sDf09.id (ссылка на ту запись таблицы sDf09, которая инициирует создание ответной записи в таблице sDf10);
- ошибку из п.1 раздела Изменение statement по sDf09, если она была обнаружена.
3.2. Если в п.1 раздела Изменение statement по sDf09 ошибок не обнаружено, то инициировать изменение таблицы accountBalance согласно описанию.
По итогу изменения accountBalance в statement должны быть обновлены значения полей:
- operationStatus;
- errorCode в случае выявления ошибки;
- errorText в случае выявления ошибки.
По логике заполнения стандартных полей.
При добавлении записи (независимо от причины добавления):
=companyId, найденной при проверке перед изменением statement.
При обновлении записи (независимо от причины обновления):
не меняется.
При добавлении записи (на базе sDf-таблиц):
=2 "ПРЦ"
При обновлении (на базе sDf-таблиц):
не меняется.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении записи (на базе sDf01):
=FULL (см. справочник statementType).
При добавлении записи (на базе sDf16):
=INCR (см. справочник statementType).
При добавлении записи (на базе sDf09):
=INCR (см. справочник statementType).
При обновлении записи (на базе sDf-таблиц):
не меняется.
При добавлении записи (на базе sDf01/sDf09):
не заполняется.
При добавлении записи (на базе sDf16):
из sDf16.SPEC
При обновлении (на базе sDf01/sDf09):
не меняется.
При обновлении (на базе sDf16):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf-таблиц):
из account.id, у которой account.account=sDf01/sDf16/sDf09.account
При обновлении записи (на базе sDf-таблиц):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf-таблиц):
=sDf01/sDf16/sDf09.account
При обновлении записи (на базе sDf-таблиц):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf01/sDf16/sDf09):
=IN (см. справочник inOutDirection).
При обновлении записи (на базе sDf-таблиц):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf01):
=sDf01.dat
При добавлении записи (на базе sDf16/sDf09):
не заполняется.
При обновлении записи (на базе sDf-таблиц):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf01):
=sDf01.remainder
При добавлении записи (на базе sDf16/sDf09):
=sDf16/sDf09.sum
При обновлении записи (на базе sDf-таблиц):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf01):
=RUB (см. справочник currencyCode), т.к. на текущий момент в sDf01.curr_code всегда RUR.
При добавлении записи (на базе sDf16/sDf09):
=RUB (см. справочник currencyCode), т.к. на текущий момент будут использоваться только рубли.
При обновлении записи (на базе sDf-таблиц):
аналогично добавлению, если значение отличается от сохраненного ранее.
При добавлении записи (на базе sDf-таблиц) в таблице statement:
=PEND (см. справочник operationStatus).
При обновлении записи (на базе sDf-таблиц) в таблице statement:
аналогично добавлению, если значение отличается от сохраненного ранее.
Обновление статуса по итогу получения подтверждения/отклонения операции из sDf-16 (на базе notification.notificationStatus):
=CNCL (см. справочник operationStatus) - при notification.notificationStatus=CNCL;
=обновляется позже (по итогу заполнения accountBalance) - при notification.notificationStatus=ACPT.
Обновление статуса по итогу заполнения accountBalance
:
=RJCT (см. справочник operationStatus) - при выявлении ошибки на этапе заполнения accountBalance;
=EXEC (см. справочник operationStatus) - при успешном заполнении accountBalance.
Заполняется кодом ошибки при ее выявлении на этапе заполнения accountBalance.
Заполняется кодом полного текста ошибки при ее выявлении на этапе заполнения accountBalance.
Заполняется идентификатором записи в таблице sDf, на основании которой изменяется statement:
=sDf01.id при добавлении/обновлении записи об остатках;
=sDf16.id при дозачислении/списании ден.средств;
=sDf09.id при внесении информации из уведомления о поступлении средств на клир.счет.
Заполняется идентификатором записи в таблице sDf, формируемой по итогу изменения statement:
=sDf02.id при добавлении/обновлении записи об остатках (создание sDf02);
=sDf17.id при дозачислении/списании ден.средств (создание sDf17);
=sDf10.id при внесении информации из уведомления о поступлении средств на клир.счет (создание sDf10).
При добавлении/обновлении (на базе sDf-таблиц):
=0102 (см. справочник inOutSDfType) - при обработке sDf01;
=1617 (см. справочник inOutSDfType) - при обработке sDf16;
=0910 (см. справочник inOutSDfType) - при обработке sDf16.
Заполняется модулем dbf-importer (детали в ТЗ по пути "P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-loader.Дополнение для разработчиков.docx" в разделе "Заполнение таблицы S_DF01").
Заполняется модулем balance-service по итогу обработки изменения statement по sDf01. Для заполнения sDf02 будут переданы sDf01.id (ссылка на ту запись таблицы sDf01, которая инициирует создание ответной записи в таблице sDf02) и ошибка, если она была обнаружена при проверках перед обновлением таблицы statement.
Логика заполнения полей sDf02 согласно описанию.
По итогу заполнения sDf02 необходимо положить в очередь kafka для модуля dbf-exporter сообщение на создание файла ДФ-02.
Из генератора.
По итогу сгенерированный идентификатор записи sDf02.id должен быть записан для соответствующей записи в statement.outSDfId
(актуально когда входящая запись из таблицы sDf01 была обработкана без ошибок, т.к. в противном случае запись в statement не создается).
Из sDf01.curr_code по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.account по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.remainder по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.deal по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.acc_code по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.dat по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.market по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.acc_name по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.acc_type по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.sumengage по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.sumunblock по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Из sDf01.file_type по sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
В зависимости от результата изменения statement по sDf01:
=последние 3 цифры кода полученной ошибки (statement НЕ обновлена по sDf01);
=ОК! - если ошибки нет (т.е. statement обновлена по sDf01).
Заполняется датой-временем создания записи.
Из генератора, у всех записей, формируемых на основании одного файла DF-01 (в таблице sDf01 у таких записей одинаковый generationId), должен быть одинаковый идентификатор взаимодействия.
Из sDf01.id (должен быть передан по итогу обработки изменения statement по sDf01).
Заполняется модулем clearing-service на базе объекта paymentInstruction. Данный запрос может выполняться автоматически по расписанию или launcher "createOrder" (когда Администратор Клиринга нажал кнопку необходимой ему команды в WEB-интерфейсе).
1. На базе всех записей таблицы paymentInstruction со статусом transactionStatus=STLD (см. справочник transactionStatus) формируется одна группа записей (такие записи имеют одинаковый generationId) в sDf03 или sDf11 (в зависимости от категории компании - см. в пунктах ниже):
1.1. Всю группу обрабатыеваемых записей из paymentInstruction необходимо отсортировать по компаниям paymentInstractions.senderId, дальнейшая обработка должна выполняться в рамках каждой из компаний (то есть: отсортировали все записи по компаниям -> обрабатываем все записи первой компании -> когда по первой компании записи закончились, начинаем обработавать все записи второй компании и так далее).
1.2. В зависимости от категории компании clearingMemberCategory.clearingMemberCategory для clearingMemberCategory.companyId=paymentInstraction.senderId:
1.2.1. Если clearingMemberCategory=I (см. справочник clearingMemberCategory),
отсортировать записи этой компании следующим образом:
a-сначала записи, у которых
account.accountType=CLRN для account.id=paymentInstraction.creditLeg_accountId
И account.accountType=BANK для account.id=paymentInstraction.debitLeg_accountId (accountType по справочнику accountType)
b-далее записи, у которых
account.accountType=BANK для account.id=paymentInstraction.creditLeg_accountId
И account.accountType=CLRN для account.id=paymentInstraction.debitLeg_accountId (accountType по справочнику accountType)
c-проверить:
-что сумма paymentInstraction.creditLeg_amount всех записей пункта "a" равна сумме paymentInstractions.creditLeg_amount всех записей пункта "b",
иначе записать в лог ошибку (10012) «У компании %s не сошлась сумма кредит-проводок»;
-что сумма paymentInstraction.debitLeg_amount всех записей пункта "a" равна сумме paymentInstractions.debitLeg_amount всех записей пункта "b"
иначе записать в лог ошибку (10013) «У компании %s не сошлась сумма дебет-проводок»;
если хотя бы одна из проверок по суммам не прошла:
-установить paymentInstruction.transactionStatus=CHER (см. справочник transactionStatus),
при этом обработка оставшихся записей должна продолжиться,
но ДФ-файлы DF-03 и DF-11, который будут сформированы на базе этих записей в sDf03 и sDf11 из этого прогона, должны будут выгрузиться в отдельную директорию SettlementHouse_Fail (чтобы не отдавать такие файлы в ПРЦ).
d-сформировать записи в sDf03, сохраняя сортировку из пунктов a-b; логика заполнения полей sDf03 согласно описанию.
1.2.2. Если clearingMemberCategory=B (см. справочник clearingMemberCategory):
сформировать записи в sDf11 (сортировка записей как при формировании sDf03 не требуется); логика заполнения полей sDf11 аналогична sDf03 согласно описанию.
2. По итогу заполнения sDf03/sDf11 необходимо положить в очередь kafka для модуля dbf-exporter сообщение на создание файла ДФ-03/ДФ-11.
3. Установить статус paymentInstruction.transactionStatus:
3.1. Если в рамках всего прогона (одинаковый generationId) НЕ выявлено ошибок, необходимо для всех записей paymentInstruction этого прогона установить transactionStatus=SENT (см. справочник transactionStatus).
3.2. Если в рамках всего прогона (одинаковый generationId) хотя бы для одной записи paymentInstruction была выявлена ошибка, необходимо для всех остальных записей paymentInstruction этого прогона установить transactionStatus=NSNT (см. справочник transactionStatus).
Примечание: в дальнейшем описанный алгоритм можно дополнить проверками:
-ClearingMemberCategory не удалось определить;
-не удается найти Account по CreditLegAccountId, DebitLegAccountId, или там кривой тип;
-соотношение типов (CreditLegAccountId/DebitLegAccountId) другое (не "bank/clrn", не "clrn/bank");
(пока считаем, что в paymentInstruction будут уже корректные записи, исключающие эти ошибки, т.к. paymentInstruction мы формируем сами, а не переписываем из внешних систем).
По логике заполнения стандартных полей.
Всегда =U
Всегда =S
Всегда =002
paymentInstruction.id, при преобразовании в varchar если получилось более 16-ти символов, взять последние 16 символов
Всегда пусто.
Всегда =9
В зависимости от paymentInstruction.senderId:
=@0, если если senderId≠1 "СПВБ" 2 "ПРЦ";
=@09999, если senderId=1 "СПВБ" 2 "ПРЦ".
paymentInstruction.debitLeg_account
В зависимости от paymentInstruction.senderId:
- если 1 "СПВБ", то заполнить из paymentInstruction.payeeBankName;
- иначе (≠ 1 "СПВБ"), то заполнить из company.shortName по company.id=paymentInstruction.senderId
(если всё значение не помещается в sbanknam1, то остаток записать в sbanknam2 и т.д. до sbanknam5).
paymentInstruction.payeeBankName
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
В зависимости от paymentInstruction.addresseeId:
=@0, если senderId≠1 "СПВБ" 2 "ПРЦ";
=@09999, если senderId=1 "СПВБ" 2 "ПРЦ".
paymentInstruction.creditLeg_account
В зависимости от paymentInstruction.addresseeId:
- если 1 "СПВБ", то заполнить из paymentInstruction.addresseeBankName;
- иначе (≠ 1 "СПВБ"), то заполнить из company.shortName по company.id=paymentInstruction.addresseeId
(если всё значение не помещается в rbanknam1, то остаток записать в rbanknam2 и т.д. до rbanknam5).
paymentInstruction.addresseeBankName
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
paymentInstruction.clearingDate Текущая дата в формате dd.mm.yy
Всегда пусто.
Всегда "RUR".
paymentInstruction.debitLeg_amount
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
paymentInstruction.PaymentPurpose (если всё значение не помещается в specif_1, то остаток записать в specif_2 и т.д. до specif_6).
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Всегда пусто.
Заполняется датой-временем создания записи.
Из генератора (у одной группы записей, которые должны попасть в один ДФ-файл, должен быть одинаковый generationId).
paymentInstruction.id
Заполняется модулем dbf-importer (детали в ТЗ по пути "P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-loader.Дополнение для разработчиков.docx" в разделе "Заполнение таблицы S_DF04") на базе файла в формате ДФ-04, который является ответной квитанцией от ПРЦ на ДФ-03/ДФ-11, отправляемые КС в адрес ПРЦ.
При получении из очереди kafka от модуля dbf-importer сообщения на обработку новых записей мапы sDf04 необходимо:
1. По sDf04.docnm_ref=paymentInstruction.id найти запись в таблице (см. paymentInstruction).
2. Для найденной записи в paymentInstruction обновить поле transactionStatus в зависимости от sDf04.imp_result:
=OK (см. справочник transactionStatus) - если sDf04.imp_result="ОК!";
=FAIL (см. справочник transactionStatus) - если sDf04.imp_result≠"ОК!".
Заполняется модулем balance-service на базе объекта account по результатам успешной сверки в конце клиринговой сессиисправочник accountStatus).
По логике заполнения стандартных полей.
Текущая дата создания записи
Текущее время создания записи
tp="0753"
pr="3"
Заполняется датой-временем создания записи.
Из генератора (у "пачки" записей, которые должны попасть в один ДФ-файл, должен быть одинаковый generationId).
Заполняется модулем balance-service при необходимости запроса остатков по всем счетам. Данный запрос может выполняться автоматически по расписанию или launcher "getAllBalance" (когда Администратор Клиринга нажал кнопку необходимой ему команды в WEB-интерфейсе).
Логика заполнения полей sDf08 согласно описанию.
По итогу заполнения sDf08 необходимо положить в очередь kafka для модуля dbf-exporter сообщение на создание файла ДФ-08.
Из генератора.
Заполняется 10-тизначным целым числом из генератора.
UNIX-время создания записи в миллисекундах, 13-тизначное целое число.
Заполняется датой-временем создания записи.
Из генератора (у "пачки" записей, которые должны попасть в один ДФ-файл, должен быть одинаковый generationId).
Заполняется модулем dbf-importer (детали в ТЗ по пути "P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-loader.Дополнение для разработчиков.docx" в разделе "Заполнение таблицы S_DF09").
Заполняется модулем balance-service по итогу обработки изменения statement по sDf09. Для заполнения sDf10 будут переданы sDf09.id (ссылка на ту запись таблицы sDf09, которая инициирует создание ответной записи в таблице sDf10) и ошибка, если она была обнаружена при проверках перед обновлением таблицы statement.
Логика заполнения полей sDf10 согласно описанию.
Из генератора.
По итогу сгенерированный идентификатор записи sDf10.id должен быть записан для соответствующей записи в statement.outSDfId
(актуально когда входящая запись из таблицы sDf09 была обработкана без ошибок, т.к. в противном случае запись в statement не создается).
Из sDf09.account по sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
Из sDf09.sum по sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
Из sDf09.market по sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
Из sDf09.type по sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
Из sDf09.number по sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
Из sDf09.INN по sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
В зависимости от результата изменения statement по sDf09:
=последние 3 цифры кода полученной ошибки (statement НЕ обновлена по sDf09);
=ОК - если ошибки нет (т.е. statement обновлена по sDf09).
Заполняется датой-временем создания записи.
Из генератора, у всех записей, формируемых на основании одного файла DF-09 (в таблице sDf09 у таких записей одинаковый generationId), должен быть одинаковый идентификатор взаимодействия.
Из sDf09.id (должен быть передан по итогу обработки изменения statement по sDf09).
Заполняется модулем clearing-service на базе объекта paymentInstruction. Данный запрос может выполняться автоматически по расписанию или launcher "createOrder" (когда Администратор Клиринга нажал кнопку необходимой ему команды в WEB-интерфейсе).
Логика заполнения sDf11 аналогична заполнению sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Всегда пусто
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Логика заполнения аналогична заполнению соответствующего поля таблицы sDf03 (см. описание).
Заполняется модулем dbf-importer (детали в ТЗ по пути "P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-loader.Дополнение для разработчиков.docx" в разделе "Заполнение таблицы S_DF12").
На стороне КС формируется Реестр остатков денежных средств автоматически по расписанию или в ручном режиме командой Администратора Клиринга (по соответствующей кнопке)
Данные реестра хранятся в таблице ORDER_REGISTRY
Из генератора.
«V» – Категория В
всегда: 002-Банк-банк
2022ММДД0000N, где N - порядковый номер участника в файле
всегда: пусто
всегда: 9
paymentInstruction.payeeBIC
paymentInstruction.creditLeg_account
bankAccount.bankName [paymentInstruction.payeeBankName=id]
Всегда пусто
Всегда пусто
Всегда пусто
Всегда пусто
paymentInstruction.adresseeBIC
paymentInstruction.debit_csAccount
bankAccount.bankName [paymentInstruction.addresseeBankName=id]
Всегда пусто
Всегда пусто
Всегда пусто
Всегда пусто
(dd.mm.yy - дата из заголовка файла) Текущий день
Всегда пусто
всегда RUR
paymentInstruction.creditLeg_amount
Всегда АО СПВБ
company.fullName[senderId = id]
Всегда пусто
Всегда пусто
paymentInstruction.creditLeg_account
company.fullName[paymentInstruction.addresseeId=id]
Всегда пусто
paymentInstruction.debitLeg_account
Всегда пусто
paymentInstruction.PaymentPurpose
Всегда пусто
Всегда пусто
Всегда пусто
Всегда пусто
Всегда пусто
Срочно
Всегда пусто
Всегда пусто
Заполняется датой-временем создания записи.
Из генератора (у одной группы записей, которые должны попасть в один ДФ-файл, должен быть одинаковый generationId).
Заполняется модулем dbf-importer (детали в ТЗ по пути "P:\ТЗ\analysis\projects\spcex\Clearing\ТЗ\dev\dbf-loader.Дополнение для разработчиков.docx" в разделе "Заполнение таблицы S_DF16").
Заполняется модулем balance-service по итогу обработки изменения statement по sDf16. Для заполнения sDf17 будут переданы sDf16.id (ссылка на ту запись таблицы sDf16, которая инициирует создание ответной записи в таблице sDf17) и ошибка, если она была обнаружена при проверках перед обновлением таблицы statement.
Логика заполнения полей sDf17 согласно описанию.
Из генератора.
По итогу сгенерированный идентификатор записи sDf17.id должен быть записан для соответствующей записи в statement.outSDfId
(актуально когда входящая запись из таблицы sDf16 была обработкана без ошибок, т.к. в противном случае запись в statement не создается).
Из sDf16.account по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.sum по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.market по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.type по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.INN по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.BIC по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.SPEC по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Из sDf16.number по sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
В зависимости от результата изменения statement по sDf16:
=0 (Операция выполнена успешно) - если statement обновлена по sDf16;
=1 (Ошибка. Попытка повторно исполнить операцию) - для данного ДФ-формата пока не используется;
=2 (Ошибка. Участник не найден) - если получена ошибка (5211) "Компания не найдена" (т.е. statement НЕ обновлена по sDf16);
=3 (Ошибка. Сумма списания превышает сумму средств на торговом счете участника в ТС) - если получена ошибка (5222) "Сумма списания превышает сумму средств на счете" (т.е. statement НЕ обновлена по sDf16);
=4 (Ошибка. Торги не идут) - если получена ошибка (5210) "Клиринговая сессия неактивна" (т.е. statement НЕ обновлена по sDf16);
=9 (Другие ошибки, выявленные в КС) - если получены другие ошибки (т.е. statement НЕ обновлена по sDf16).
Заполняется датой-временем создания записи.
Из генератора, у всех записей, формируемых на основании одного файла DF-16 (в таблице sDf16 у таких записей одинаковый generationId), должен быть одинаковый идентификатор взаимодействия.
Из sDf16.id (должен быть передан по итогу обработки изменения statement по sDf16).
Заполняется модулем account-service по итогу обработки изменения таблицы account по sDf12. Для заполнения sDf18 будут переданы sDf12.id, sDf12.generationId (из той записи таблицы sDf12, которая инициирует создание ответной записи в таблице sDf18) и ошибка, если она была обнаружена при проверках перед обновлением таблицы account.
Логика заполнения полей sDf18 согласно описанию.
Из генератора.
Из sDf12.account по sDf12.id (должен быть передан по итогу обработки изменения account по sDf12).
Из sDf12.deal по sDf12.id (должен быть передан по итогу обработки изменения account по sDf12).
Из sDf12.status по sDf12.id (должен быть передан по итогу обработки изменения account по sDf12).
В зависимости от результата изменения account по sDf12:
=0 (Операция выполнена успешно) - если account обновлена по sDf12;
=1 (Ошибка. Попытка повторно исполнить операцию) - для данного ДФ-формата пока не используется;
=2 (Ошибка. Участник не найден) - если получена ошибка (5013) "Компания не найдена" (т.е. account НЕ обновлена по sDf12);
=3 (Ошибка. Сумма списания превышает сумму средств на торговом счете участника в ТС) - для данного ДФ-формата пока не используется;
=4 (Ошибка. Торги не идут) - ? ;
=9 (Другие ошибки, выявленные в КС) - если получены другие ошибки (т.е. account НЕ обновлена по sDf12).
Заполняется датой-временем создания записи.
Из генератора, у всех записей, формируемых на основании одного файла DF-12 должен быть одинаковый идентификатор взаимодействия. В таблице sDf12 у таких записей из одного DF-12 одинаковый generationId, он должен быть передан по итогу обработки изменения account по sDf12.
Из sDf12.id (должен быть передан по итогу обработки изменения account по sDf12).
Данные выгружаются из Торговой Системы для выполнения расчетов по сделкам. Выгрузка выполняется автоматически по расписанию или launcher "getTrades" (когда Администратор Клиринга нажал кнопку необходимой ему команды в WEB-интерфейсе). Данные должны запрашиваться в разрезе Инициатора: сделки должны группироваться по компаниям (поле firm_id) и сохраняться в s_trade поочередно для каждой из компаний.
Сохранение сделок, полученных из Торговой Системы, в нашей таблице s_trade выполняется модулем TS-importer. В результате заполнения s_trade должно выполняться заполнение объекта executionDeposit.
Объект может быть изменен модулем utility-service:
1. При получении команды на добавление сообщения пользователю в notification из очереди kafka от других модулей (например, balance-service): логика заполнения полей notification согласно описанию.
В результате заполнения notification, в очередь kafka для модуля backend-api должна быть помещена команда на отображение/подтвержение у пользователя записанного в notification сообщения.
2. По команде от пользователя (из очереди kafka от backend-api): изменение объекта notification/put.
В результате обновления статуса notificationStatus, в очередь kafka для того модуля, который инициировал создание записи в notification (например, balance-service), должно быть передано сообщение с обновленным notificationStatus.
Примечание: модуль, инициировавший создание записи в notification, можно определять по notification.objectType:
- если STMT (см. справочник objectType), то модуль balance-service;
- других значений пока нет.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
При добавлении:
из соответствующего параметра сообщения очереди.
При изменении:
не меняется.
При добавлении:
из соответствующего параметра сообщения очереди.
При изменении:
не меняется.
При добавлении:
из соответствующего параметра сообщения очереди.
При изменении:
не меняется.
При добавлении:
из соответствующего параметра сообщения очереди.
При изменении:
не меняется.
При добавлении:
=PEND (см. справочник notificationStatus)
При изменении:
из соответствующего параметра сообщения очереди.
При обработке метода:
1. Необходимо выполнить общую проверку прав.
2. В запросе придут параметры в соответствии с описанием метода notification/put в мете.
3. Проверяем значения полученных параметров:
3.1. Необходимо выполнить ряд проверок, стандартных для всех методов.
3.2. Проверить, что в таблице notification есть запись, статус которой нужно обновить, по ключу id. Если такой записи нет, вернуть ошибку (8006) «Запись не найдена».
4. Если предыдущие проверки выполнены успешно, изменить запись в таблице notification согласно описанию.
1. Сверка может быть запущена модулем control-service в результате:
1.1 Получение из очереди kafka от модуля dbf-importer на проведение сверки по новым записям таблицы sDf01
1.2 Запускается автоматически по расписанию или launcher "startVerivication" (когда Администратор Клиринга нажал кнопку, необходимой ему команды в WEB-интерфейсе)
2. Необходимые сверки:
2.1 Необходимо сравнить сумму по остаткам в бизнес-объекте accountBalance:
sDf01.remainder = accountBalance.closeBalanceAmount [sDf01.account = accountBalance.account]
2.2 Расчет контрольных сумм:
3. Добавить запись в таблицу verificationResult согласно описанию.
4. Отправить пользователю уведомление о результатах сверки. Для этого необходимо в очередь kafka для модуля utility-service направить сообщение на добавление записи в таблицу notification, при этом передается ряд парметров:
4.1 objectType=VFRS
4.2 objectId=generationId
5 (обсудить). Передать в очередь kafka для модуля clearing-service сообщение для формирования ДФ-11, пункт 1.2.1
6. Передать в очередь kafka для модуля clearing-service сообщение для формирования ДФ-05
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
По логике заполнения стандартных полей.
Из company.clearingCode[accountBalance.companyId=company.Id]
Из accountBalance.account
Из accountBalance.openBalanceAmount
Из accountBalance.closeBalanceAmount
Из sDf01.remainder[accountBalance.account=sDf01.account]
outIntSum – outExtSum
id из генератора (при выполнении сверки для всех новых записей указать один id)
В случае полностью успешной сверки (то есть по всем записям этого прогона сверки нет расхождений), установить для всех записей этого прогона
generationStatus=ACK (см. справочник resultStatus).
В случае выявления расхождения хотя бы в одной записи этого прогона сверки, установить для всех записей этого прогона
generationStatus=NACK (см. справочник resultStatus).
В случае успешной сверки конкретной записи этого прогона, установить индивидуально для этой записи
generationStatus=ACK (см. справочник resultStatus).
В случае выявления расхождений в результате сверки конкретной записи этого прогона, установить индивидуально для этой записи
generationStatus=NACK (см. справочник resultStatus).
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
На основе данных из бизнес-объекта liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut.
Маска файла: REPBR.0420315.P1.{start}-{end}.{datetime}
Идентификатор организатора торговли.
company.id
В данное поле должно записываться значение элемента id из бизнес-объекта company
Наименование организатора торговли.
company.fullName[id=1];
fullName;
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта company
Количество исполненных договоров за отчетный период, шт.
ƩliabilitiesClaimsAssets[distinct contract]
В данное поле необходимо записать общее количество исполненных договоров, шт. элемент contract из бизнес-объекта liabilitiesClaimsAssets
Объем исполненных обязательств по договорам за отчетный период. тыс. руб.
ƩliabilitiesClaimsAssets.liabilities[distinct contract]
Сумма элемента по исполненным договорам, элемент liabilities из бизнес-объекта liabilitiesClaimsAssets.
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
start ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ end
companyId= clearingMemberCategory.companyId and clearingMemberCategory=I,V
clearingStatus = OK
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
На основе данных из бизнес-объекта liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut.
Маска файла: REPBR.0420315.P2.{start}-{end}.{datetime}
Количество исполненных договоров за отчетный период, шт.
Сумма по столбцу «количество договоров за отчетный период, шт»
Ʃcontract_qty
Сумма по столбцу «объем исполненных обязательств по договорам за отчетный период. тыс. руб.»
Ʃliabilities_amount
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
start ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ end
companyId= clearingMemberCategory.companyId and clearingMemberCategory=I,V
clearingStatus = OK
Формируется отчет о предоставлении, прекращении, приостановки и возобновлении допуска к клиринговому обслуживанию на ежемесячной основе.
На основании данных бизнес-объекта relation – «Договорные отношения»
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420317.{start}-{end}.{datetime}
Идентификатор участника клиринга.
company.clearingCode[id =repation.consumerId]
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Идентификатор операции
relation.id[service = MKR]
В данное поле необходимо записать значение элемента serviceId из бизнес-объекта relation
Тип операции
relation.serviceStatus
В данное поле проставляется тип операции из элемента serviceStatus из бизнес-объекта relation
Дата операции
relation.updatedAt
В данное поле проставляется значение элемента updatedAt из бизнес-объекта relation
Полное наименование участника клиринга
company.fullName[consumerId=companyId]
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта company
ИНН или TIN участника клиринга
В данное поле записывается ИНН участника из бизнес-объекта companySymbol
Код страны по ОКСМ участника клиринга
countryCode_id[consumerId= companyInfo.companyId]
В данное поле записывает значение элемента id из справочника countryCode
Основание изменения допуска
relation.comment
В данное поле записывается значение элемента comment бизнес-объекта relation
Система должна определить записи для отчета из relation в соответствии со следующими критериями:
start ≤ relation.updatedAt
Система должна определить записи для отчета из relation в соответствии со следующими критериями:
relation.updatedAt ≤ end
Формируется отчет о неисполненных обязательствах на ежемесячной основе.
На основании данных бизнес-объекта liabilitiesClaimsAssets – «Требования и обязательства финансовых активов» и liabilitiesClaimsMoney – «Требования и обязательства денежных средств»
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420318.{start}-{end}.{datetime}
Полное наименование участника клиринга
liabilitiesClaimsAssets.fullName
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта liabilitiesClaimsAssets
ИНН или TIN участника клиринга
В данное поле записывается ИНН участника, элемент code accountId бизнес-объекта bankAccount
Код страны по ОКСМ участника клиринга
companyInfo.countryCode[companyId= liabilitiesClaimsAssets.companyId]
В данное поле записывает значение элемента id из бизнес-объекта companyInfo
Номер/идентификатор сделки
liabilitiesClaimsAssets.Contract
В данное поле необходимо внести значение элемента Contract из бизнес-объекта «liabilitiesClaimsAssets»
Код валюты
liabilitiesClaimsMoney.currencyCode
В данное поле необходимо внести значение элемента currency из бизнес-объекта «liabilitiesClaimsAssets»
Сумма неисполненных обязательств
ƩliabilitiesClaimsAssets.liabilitiesQuantity
В данное поле необходимо внести сумму значений элемента liabilitiesQuantity из бизнес-объекта «liabilitiesClaimsAssets»
Единица измерения базисного актива/неисполненных обязательств
liabilitiesClaimsMoney.name[currencyCode=currencyCode.name]
В данное поле необходимо записать значение элемента name из бизнес-объекта currencyCode
Объем неисполненных обязательств
ƩliabilitiesClaimsAssets.liabilities[distinct contract]
В данное поле необходима записать общее количество из элемента liabilities бизнес-объекта liabilitiesClaimsAssets
Причина неисполнения
liabilitiesClaimsAssets.comment
В данное поле необходимо записать значение элемента comment из бизнес-объекта liabilitiesClaimsAssets
ИНН организатора торговли
В данное поле необходимо записать значение из элемента code бизнес-объекта companySymbol
Сторона, не исполнившая обязательство
liabilitiesClaimsAssets.fullName
В данное поле необходимо записать значение элемента fullname из бизнес-объекта liabilitiesClaimsAssets
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
clearingStatus = FAIL
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблицы liabilitiesClaimsAssets – «Требования и обязательства финансовых активов».
Система должна определить записи для отчета из paymentInstraction.
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut.
Маска файла: REPBR.0420314.P1.{start}-{end}.{datetime}
Идентификатор участника клиринга
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Идентификатор договора, заключенного с участником клиринга
В данное поле записывается значение элемента id из бизнес-объекта profileDocument
Полное наименование участника
company.fullName[senderId= companyId]
В данное поле необходимо записать значение элемента fullName бизнес-объекта company
ИНН или TIN участника клиринга
В данное поле записывается ИНН участника, элемент code accountId бизнес-объекта bankAccount
ОГРН участника клиринга
В данное поле необходимо записать ОГРН участника из бизнес-элемента companySymbols
Группа (категория) участника клиринга
clearingMemberCategory.clearingMemberCategory [senderId= companyId]
В данное поле необходимо записать значение элемента clearingMemberCategory бизнес-объекта clearingMemberCategory. Если значений несколько - их необходимо записать через запятую
Номер договора без участия центрального контрагента
В данное поле необходимо записать номер договора из бизнес-объекта liabilitiesClaimsAssets
Дата договора без участия центрального контрагента
В данное поле необходимо записать дату договора из бизнес-объекта liabilitiesClaimsAssets
Сумма обязательств участника клиринга, допущенных к клирингу
liabilitiesClaimsAssets.liabilitiesQuantity
В данное поле необходимо записать значение элемента liabilitiesQuantity бизнес-объекта liabilitiesClaimsAssets
Система должна определить записи для отчета из paymentInstraction в соответствии со следующими критериями
startDate≤ paymentInstruction.createdAt
Система должна определить записи для отчета из paymentInstraction в соответствии со следующими критериями
paymentInstruction.createdAt ≤ endDate
clearingStatus = OK
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) paymentInstruction – «Денежные средства от расчетной организации»;
2) accountBalance – «Информация об остатках ден. средств»;
3) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов».
Система должна определить записи для отчета из paymentInstraction.
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut.
Маска файла: REPBR.0420314.P2.{start}-{end}.{datetime}
Идентификатор участника клиринга
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Идентификатор договора, заключенного с участником клиринга
paymentInstruction.id[companyId = senderId]
В данное поле необходимо записать номер договора и его дату из бизнес-объекта profileDocument
Входящие остатки на торговых счетах участника клиринга
В данное поле необходимо записать значение элемента openBalanceAmount бизнес-объекта accountBalance
Сумма остатка на торговом счете участника клиринга - обороты по покупке
∑paymentInstruction.creditLeg_amount
В данное поле необходимо записать сумму значений элемента creditLeg_amount из бизнес-объекта paymentInstractiont
Сумма остатка на торговом счете участника клиринга - обороты по продаже
∑paymentInstructiont.debitLeg_amount
В данное поле необходимо записать сумму значений элемента debitLeg_amount из бизнес-объекта paymentInstractiont
Исходящие остатки на торговых счетах участника клиринга
В данное поле необходимо записать значение элемента closeBalanceAmount бизнес-объекта accountBalance
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate≤paymentInstraction.createdAt
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
paymentInstraction.createdAt≤ endDate
transactionStatus = EXEC
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблицы:
relation - "Договорные отношения"
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р1-1.{start}-{end}.{datetime}
Идентификатор участника клиринга
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Полное наименование участника клиринга
company.fullName[companyId=relation.consumerId]
В данное поле необходимо записать значение элемента fullName бизнес-объекта company
ИНН или TIN участника клиринга
В данное поле необходимо записать значение из элемента code бизнес-объекта companySymbol
ОГРН участника клиринга
В данное поле необходимо записать значение из элемента code бизнес-объекта companySymbol
Код страны по ОКСМ участника клиринга
countryCode_id[consumerId= companyInfo.companyId]
В данное поле записывает значение элемента id из справочника countryCode
Группа (категория) участника клиринга
В данное поле необходимо записать значение элемента clearingMemberCategory бизнес-объекта clearingMemberCategory. Если значений несколько - их необходимо записать через запятую
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
transactionStatus = ACTV
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р1-2.{start}-{end}.{datetime}.
Идентификатор участника клиринга
liabilitiesClaimsAssets.companyId
В данное поле должно записываться значение элемента companyId из бизнес-объекта liabilitiesClaimsAssets
Денежные средства
ƩliabilitiesClaimsAssets.liabilitiesQuantity
В данное поле должна записываться сумма значений элемента liabilitiesQuantity из бизнес-объекта liabilitiesClaimsAssets
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.8
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р1-3.{start}-{end}.{datetime}
Идентификатор участника клиринга
liabilitiesClaimsAssets.companyId
В данное поле должно записываться значение элемента companyId из бизнес-объекта liabilitiesClaimsAssets
Межбанковская
ƩliabilitiesClaimsAssets.liabilitiesQuantity
В данное поле должно записываться значение элемента liabilities из бизнес-объекта liabilitiesClaimsAssets
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Общая сумма по столбцам в отчете 1.8
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р1-4.{start}-{end}.{datetime}
Межбанковская
∑liabilitiesClaimsAssets.liabilities
В данное поле должно записываться сумма значений по столбцу liabilitiesClaimsAssets_liabilities
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.10
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р1-5.{start}-{end}.{datetime}
Идентификатор участника клиринга
liabilitiesClaimsAssets.companyId
В данное поле должно записываться значение элемента companyId из бизнес-объекта liabilitiesClaimsAssets
Межбанковская
∑liabilitiesClaimsAssets.liabilities
В данное поле должно записываться сумма значений по столбцу liabilitiesClaimsAssets_liabilities
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.10
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR. 0420312_р1-6.{start}-{end}.{datetime}
Межбанковская
∑liabilitiesClaimsAssets.liabilities
В данное поле должно записываться сумма значений по столбцу liabilitiesClaimsAssets_liabilities
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.10
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р1-7.{start}-{end}.{datetime}
Межбанковская
∑liabilitiesClaimsAssets.liabilities
В данное поле должно записываться сумма значений по столбцу liabilitiesClaimsAssets_liabilities
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.7, но с учетом кода валют.
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р3-1.{start}-{end}.{datetime}
Идентификатор кода валюты
currencyCode.id [code=liabilitiesClaimsAssets.currencyCode]
В данное поле необходимо записать идентификатор кода валюты из справочника currencyCode
Идентификатор участника клиринга
liabilitiesClaimsAssets.companyId
В данное поле должно записываться значение элемента companyId из бизнес-объекта liabilitiesClaimsAssets
Полное наименование участника клиринга
liabilitiesClaimsAssets.fullName
В данное поле необходимо записать значение элемента fullName бизнес-объекта libiatiliesClaimsAssets
ИНН или TIN участника клиринга
В данное поле необходимо записать значение из элемента code бизнес-объекта companySymbol
ОГРН участника клиринга
В данное поле необходимо записать значение из элемента code бизнес-объекта companySymbol
Код страны по ОКСМ участника клиринга/контрагента по сделке
В данное поле необходимо записать значение элемента countryCode бизнес-объекта liabilitiesClaimsAssets
Группа (категория) участника клиринга
В данное поле необходимо записать значение элемента clearingMemberCategory бизнес-объекта clearingMemberCategory. Если значений несколько - их необходимо записать через запятую
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.8, но с учетом кода валют.
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р3-2.{start}-{end}.{datetime}
Идентификатор кода валюты
currencyCode.id [code=liabilitiesClaimsAssets.currencyCode]
В данное поле необходимо записать идентификатор кода валюты из справочника currencyCode
Идентификатор участника клиринга
liabilitiesClaimsAssets.companyId
В данное поле должно записываться значение элемента companyId из бизнес-объекта liabilitiesClaimsAssets
Код валюты
liabilitiesClaimsMoney.currencyCode
В данное поле должно записываться значение элемента currenceCode бизнес-объекта liabilitiesClaimsMoney
Объем денежных средств
liabilitiesClaimsAssets.liabilities
В данное поле должно записываться значение элемента liabilities из бизнес-объекта liabilitiesClaimsAssets
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Те же данные, что и в отчете 1.9.
Формируется отчет об исполненных обязательствах, допущенных к клирингу, за отчетный период, который составляется по состоянию на последний календарный день отчетного месяца включительно.
Отчет формируется на основании данных таблиц:
1) liabilitiesClaimsAssets – «Требования и обязательства финансовых активов»;
Отчет по нетто-позиции участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut
Маска файла: REPBR.0420312_р3-3.{start}-{end}.{datetime}
Объем денежных средств в единицах валюты
∑liabilitiesClaimsAssets.liabilities
В данное поле должно записываться значение элемента liabilities из бизнес-объекта liabilitiesClaimsAssets
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
startDate ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
end
3. В расчет входят бизнес-объекты liabilitiesClaimsAssets
4. Существует у участника категория Б: liabilitiesClaimsAssets.companyId = clearingMemberCategory.companyId и clearingMemberCategory.clearingMemberCategory = «B» - Б
Отчет участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории 1СModuleOut из списка директорий для модуля отчета
Маска файла: 1С.Head.{start}-{end}.{datetime}]]>
Поля в заголовке
TS_PAYMENTS
Клиринговая комиссия – {текущий месяц} {текущий год}
Начало периода – первый день месяца
Конец периода – последний день месяца
Дата генерации. Текущая дата
Время генерации. Текущее время
КС
Договор.
liabilitiesClaimsAssets.contract
liabilitiesClaimsAssets.tradingDate
liabilitiesClaimsAssets.settlementDate
liabilitiesClaimsAssets.refundDate
refundDate – settlementDate
«M» - константа
«C» - константа
liabilitiesQuantity
liabilitiesQuantity * (refundDate – settlementDate) * companyTariff[companyId, category=B]
liabilitiesQuantity * (refundDate – settlementDate) * companyTariff[companyId, category=B]
Код участника клиринга company.clearingCode
Участник клиринга company.fullName
ИНН для companyId в companySymbols=INN
КПП для companyId в companySymbols=CPP
Договор для companyId в profileDocuments=CNTR как склейка строк:
«Договор №{number} от { issueDate }»
Договор для companyId в profileDocuments.number[CNTR]
Договор для companyId в profileDocuments.issueDate[CNTR]
Start
End
Сумма подчиненных ячеек
«Z» - всегда значение
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ startDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Система должна сгенерировать следующий отчет о денежных средствах Участника Клиринга, находящихся на счетах внутреннего учета средств
Отчет должен быть размещен в директории ReportModuleOut
Критерии:
Account.account [accountType=INFO]
AND
clearingCategory = V
Маска файла: REPPA.V.{start}-{end}.{datetime}
Наименование организатора торговли.
company.fullName;
fullName;
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта company
Наименование организатора торговли.
company.fullName[id=1];
fullName;
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта company
Идентификатор участника клиринга
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Номер клиринговой сессии
clearing.sessionId
Номер клирингового счета СПВБ
Account.account [accountType=CLRN]
Код счета внутреннего учета
Account.account [accountType=INFO]
Сумма средств на счете
SUM statement[inOutDirection = IN]
Изменение сумм средств на счете
LIST tradeSettlement.amount
Исходящий остаток
SUM statement[inOutDirection = OUT]
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ startDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Формируется отчет на основании данных о рассчитанных в КС нетто-обязательствах и нетто-требованиях участников клиринга.
На основании данных в таблице liabilitiesClaimsAssets - "информация об обязательствах и требованиях для инструментов и денежных средств"
Отчет должен быть размещен в директории ReportModuleOut
Маска файла: REPPA.IV.{start}-{end}.{datetime}
Полное наименование участника клиринга
liabilitiesClaimsAssets.fullName
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта liabilitiesClaimsAssets
Идентификатор участника клиринга
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Дата расчета
liabilitiesClaimsAssets.settlementDate
Дата возврата
liabilitiesClaimsAssets.refundDate
Дата сделки
liabilitiesClaimsAssets.tradingDate
Договор
liabilitiesClaimsAssets.contract
Сумма обязательств
liabilitiesClaimsAssets.liabilitiesQuantity
Сумма клиринговой комиссии
chargeCommission
Сумма требований
liabilitiesClaimsAssets.ClaimsQuantity
№ п/п
liabilitiesClaimsAssets.refundPaymentId
Статус
liabilitiesClaimsAssets.clearingStatus
Комментарий
liabilitiesClaimsAssets.comment
Сумма по столбцу "Сумма требований"
ƩliabilitiesClaimsAssets_ClaimsQuantity
Сумма по столбцу "Сумма обязательств"
ƩliabilitiesClaimsAssets_liabilitiesQuantity
Сумма по столбцу «Позиция»
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ startDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
companyId= clearingMemberCategory.companyId and clearingMemberCategory=I,V
Формируется отчет на основании данных о рассчитанных в КС нетто-обязательствах и нетто-требованиях участников клиринга.
На основании данных в таблице liabilitiesClaimsAssets - "информация об обязательствах и требованиях для инструментов и денежных средств"
Отчет должен быть размещен в директории ReportModuleOut
Маска файла: REPPA.B.{start}-{end}.{datetime}
Полное наименование участника клиринга
liabilitiesClaimsAssets.fullName
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта liabilitiesClaimsAssets
Идентификатор участника клиринга
В данное поле необходимо записать значение элемента clearingCode из бизнес-объекта company
Дата расчета
liabilitiesClaimsAssets.settlementDate
Дата возврата
liabilitiesClaimsAssets.refundDate
Дата сделки
liabilitiesClaimsAssets.tradingDate
Договор
liabilitiesClaimsAssets.contract
Сумма обязательств
liabilitiesClaimsAssets.liabilitiesQuantity
Сумма клиринговой комиссии
chargeCommission
Сумма требований
liabilitiesClaimsAssets.ClaimsQuantity
№ п/п
liabilitiesClaimsAssets.refundPaymentId
Статус
liabilitiesClaimsAssets.clearingStatus
Комментарий
liabilitiesClaimsAssets.comment
Сумма по столбцу "Сумма требований"
ƩliabilitiesClaimsAssets_ClaimsQuantity
Сумма по столбцу "Сумма обязательств"
ƩliabilitiesClaimsAssets_liabilitiesQuantity
Сумма по столбцу «Позиция»
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ startDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
companyId= clearingMemberCategory.companyId and
clearingMemberCategory= B
Клиринговая Система должна сформировать данные отчета по итогам торгов для передачи отдельному модулю для генерации отчета.
По итогам торгов должно быть сформирован отчет на базе следующего бизнес-объекта: marketData - Итоги торгов
Данный документ должен быть сохранен в директорию «Директории для обмена файлами» для модуля отчетов.
Маска файла: MarketData.Body.{datetime}.pdf
Биржевой код инструмента
marketData.securitiesDepositId
В данное поле необходимо записать значение элемента securitiesDepositId из бизнес-объекта marketData
Режим торгов
marketData.marketId;
В данное поле необходимо записывать значение элемента marketId из бизнес-объекта marketData
Кол-во участников, заключивших сделки
marketData.counterPartyNum
В данное поле необходимо записывать значение элемента counterPartyNum из бизнес-объекта marketData
Кол-во сделок
marketData.tradesNum
В данное поле необходимо записывать значение элемента tradesNum из бизнес-объекта marketData
Объем сделок руб
marketData.amount
В данное поле необходимо записывать значение элемента amount бизнес-объекта marketData
Цены сделок, в % годовых. Столбец "Откр."
marketData.openPrice
В данное поле необходимо записывать значение элемента openPrice бизнес-объекта marketData
Цены сделок, в % годовых, Столбец "Макс."
marketData.maxPrice
В данное поле необходимо записывать значение элемента maxPrice бизнес-объекта marketDat
Цены сделок, в % годовых, Столбец "Мин."
marketData.minPrice
В данное поле необходимо записывать значение элемента minPrice бизнес-объекта marketDat
Цены сделок, в % годовых, Столбец "Закр."
marketData.closePrice
В данное поле необходимо записывать значение элемента closePrice бизнес-объекта marketDat
Цены сделок, в % годовых, Столбец "Ср.взв."
marketData_avgPrice
В данное поле необходимо записывать значение элемента avgPrice бизнес-объекта marketDat
Срок. дней
marketData.duration
В данное поле необходимо записывать значение элемента diration бизнес-объекта marketDat
Итого, в режиме Аукциона (А)
∑ marketData.amount [marketId=A]
В данное поле необходимо записать сумму значений столбца "Объем седлок руб." по режиму торгов "А"
Итого, в режиме Торгов (Т)
∑ marketData.amount [marketId=T]
В данное поле необходимо записать сумму значений столбца "Объем седлок руб." по режиму торгов "Т"
Всего:
∑ marketData
В данное поле необходимо записать сумму значений столбца "Объем седлок руб." по режиму торгов "А" и "Т"
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ startDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ endDate
Клиринговая Система должна сформировать данные отчета о денежных средства на счете внутреннго учета Участника Клиринга в следующем формате как на макете.
Данный отчет генерируется на ежедневной основе
Данная информация получается из объекта: accountBalance –«Информация об остатках денежных средств».
Необъодимо учитывать объекты с призанком accountBalance.accountType= CLRN | INFO.
Отчет участника клиринга секции МКР должен быть сформирован на ежедневной основе и размещен в директории ReportModuleOut из списка директорий для модуля отчета с учетом следующей маски файла
Маска файла: INACCNT.{company.clearingCode}.{datetime}
Клиринговая организация
Company.fullName [id=1]
Код участника клиринга:
Company.clearingCode
Наименование участника клиринга:
Company.fullName
№ счета внутреннего учета
accountBalance.account
Входящий остаток accountBalance.openAmount
Зачисления
accountBalance.debitAmount
Зачисления
accountBalance.creditAmount
Исходящий остаток средств
accountBalance.closeAmount
Дата, на которую сформирован отчет
Время, на которое сформирован отчет
Клиринговая Система должна сформировать данные отчета о нетто-позициях для передачи отдельному модулю для генерации отчета.
В рамках взаимодействия с Личным Кабинетом должно быть направлено программное сообщение для генерации сведений по нетто-обязательствам по участникам клиринга, где clearingMemberCategory отличается от «I» и «V» в одном файле (формат CSV)
Общие требования к формату CSV-файлов:
1. Первая строка – заголовок, содержит наименования параметров.
2. Разделитель параметров/значений – запятая.
3. Значения должны быть заключены в кавычки (например, "123", "абв").
4. Формат даты – dd.MM.yyyy, где dd – день месяца, MM – порядковый номер месяца в году, yyyy – год (например, "15.04.2022").
5. Формат времени – hh:mm:ss, где hh – час (в формате 24 часа), mm – минуты, ss – секунды (например, "12:34:56").
6. Числа не должны разделяться пробелами поразрядно (правильно – "1000", неправильно – "1 000").
7. Дробная часть в числах должна отделяться символом «.» (например, "123.45").
Маска файла:
KS_REP_CASH_NETTO.{id}
Должна быть функция в расписании для вызова данного события sendLiabilitiesClaims
Код участника клиринга:
Company.clearingCode[id=liabilitiesClaimsMoney.companyId]
В данное поле необходимо запимать значение элемента clearingCode бизнес-объекта company
Номер денежного счета
liabilitiesClaimsMoney.account[accountType=CLRN]
В данное поле необходимо записать значение элемента account бизнес-объекта liabilitiesClaimsMoney
Нетто-обязательство (руб.).
Точность – 2 знака
liabilitiesClaimsMoney.liabilitiesAmount
В данное поле необходимо записать значение элемента liabilitiesAmount бизнес-объекта liabilitiesClaimsMoney
Дата, на которую рассчитано нетто-обязательство
Дата, на которую сформирован отчет
Время, на которое сформирован отчет
Клиринговая Система должна сформировать данные отчета о нетто-позициях по соответствующему Уполномченному банку для передачи отдельному модулю для генерации отчета.
В рамках взаимодействия с Личным Кабинетом должно быть направлено программное сообщение для генерации сведений по нетто-обязательствам по участникам клиринга, где clearingMemberCategory отличается от «I» и «V» в формате CSV
Общие требования к формату CSV-файлов:
1. Первая строка – заголовок, содержит наименования параметров.
2. Разделитель параметров/значений – запятая.
3. Значения должны быть заключены в кавычки (например, "123", "абв").
4. Формат даты – dd.MM.yyyy, где dd – день месяца, MM – порядковый номер месяца в году, yyyy – год (например, "15.04.2022").
5. Формат времени – hh:mm:ss, где hh – час (в формате 24 часа), mm – минуты, ss – секунды (например, "12:34:56").
6. Числа не должны разделяться пробелами поразрядно (правильно – "1000", неправильно – "1 000").
7. Дробная часть в числах должна отделяться символом «.» (например, "123.45").
Маска файла:
KS_REP_CASH_NETTO.{id}
Должна быть функция в расписании для вызова данного события sendLiabilitiesClaimsSingle
Номер денежного счета
liabilitiesClaimsMoney.account[accountType=CLRN]
В данное поле необходимо записать значение элементе account бизнес-объекта liabilitiesClaimsMoney
Нетто-обязательство (руб.).
Точность – 2 знака
liabilitiesClaimsMoney.liabilitiesAmount
В данное поле необходимо записать значение элементе liabilitiesAmount бизнес-объекта liabilitiesClaimsMoney
Дата, на которую рассчитано нетто-обязательство
Код участника клиринга:
Company.clearingCode[id=liabilitiesClaimsMoney.companyId]
В данное поле необходимо запимать значение элемента clearingCode бизнес-объекта company
Дата, на которую сформирован отчет
Время, на которое сформирован отчет
end
3. В расчет входят бизнес-объекты liabilitiesClaimsAssets
4. Существует у участника категория Б: liabilitiesClaimsAssets.companyId = clearingMemberCategory.companyId и clearingMemberCategory.clearingMemberCategory = «B» - Б
5. Группировка данных происходит идет по каждому инициатору, блок данных в таблице повторяется.
]]>
- Отчет формируется за указанный пользователем период (месяцы)
- Отчет формируется как по конкретному УК, так и сводный по всем УК
- Сделки в отчет отбираются по дате исполнения сделки
- Отчет формируется по блокам – в разрезе вкладчиков
- Сортировка в блоках производится по дате заключения сделки (по возрастанию)
- В строке ИТОГО выводится сумма клиринговых комиссий по столбцам «Без НДС, руб.», «С НДС, руб.», «Общая сумма, руб.» по каждому блоку.
- В строке «Сумма комиссионного вознаграждения ВСЕГО» выводится сумма клиринговых комиссий по столбцам «Без НДС, руб.», «С НДС, руб.», «Общая сумма, руб.» по ВСЕМ блокам.
Администратор клиринга должен вызвать генерацию отчета с указанием начала и конца расчетного периода.
Отчет участника клиринга секции МКР должен быть сформирован на ежемесячной основе и размещен в директории ReportModuleOut, с учетом следующей маски файла
Маска файла: NCOMREP.{start}-{end}.{datetime}
из генератора
Наименование участника.
company.fullName[liabilitiesClaimsAssets.fullName]
В данное поле необходимо записывать элемент fullname –«полное наименование участника» из бизнес-объекта company
Номер договора
liabilitiesClaimsAssets.contract
В данное поле необходимо записать значение элемента contract из бизнес-объекта liabilitiesClaimsAssets
Дата заключения сделки
liabilitiesClaimsAssets.settlementDate
В данное поле необходимо записать значение элемента settlementDate из бизнес-объекта liabilitiesClaimsAssets
Дата исполнения сделки
liabilitiesClaimsAssets.tradingDate
В данное поле необходимо записать значение элемента tradingDate из бизнес-объекта liabilitiesClaimsAssets
Сумма заключения сделки, руб.
liabilitiesClaimsAssets.liabilitiesQuantity
В данное поле необходимо записать значение элемента liabilitiesQuantity из бизнес-объекта liabilitiesClaimsAssets
Без НДС, руб.
liabilitiesQuantity * (refundDate – settlementDate) * companyTariff[companyId, category=B]
Количество дней использования инструмента
refundDate – settlementDate
Сумма по столбцу «Без НДС, руб.» по всем блокам
ƩNetCommissionAmount
Сумма по столбцу «Без НДС, руб.» по каждому блоку
ƩNetCommissionAmount
Наименование "Итого"
Сумма по столбцу «Без НДС, руб.» по всем блокам
ƩNetCommissionAmount
Наименование "Сумма комиссионного вознагораждения ВСЕГО"
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
start ≤ liabilitiesClaimsAssets.refundDate
Система должна определить записи для отчета из liabilitiesClaimsAssets в соответствии со следующими критериями
liabilitiesClaimsAssets.refundDate ≤ end
companyId= clearingMemberCategory.companyId and clearingMemberCategory=B
Журнал исходящих документов КО секции МКР должен быть сформирован на ежедневной основе за текущий день и размещен в директории ReportModuleOut из списка директорий для модуля отчета, с учетом следующей маски файла
Маска файла: DOCOUT.{datetime}
Из генератора
Время регистрации
outDocumentJournal.registrationTime
Регистационный номер
outDocumentJournal.registrationNumber
Наименование документа
outDocumentJournal.documentName
Полное наименование получателя
outDocumentJournal.addresee
Кол-во экз.
outDocumentJournal.quantity
Код УК
outDocumentJournal.clearingCode
Способ отправки
outDocumentJournal.courierType
Дата отправки эл. почтой
outDocumentJournal.emailDate
Сумма
outDocumentJournal.Amount
Номер дела
outDocumentJournal.dossierNumber
Дата почтового отправления
outDocumentJournal.postDate
Дата регистрации
outDocumentJournal_registrationDate
Журнал входящих документов КО секции МКР должен быть сформирован на ежедневной основе за текущий день и размещен в директории ReportModuleOut из списка директорий для модуля отчета, с учетом следующей маски файла
Маска файла: DOCIN.{datetime}
Из генератора
Дата регистрации
inDocumentJournal.registrationDate
Время регистрации
inDocumentJournal.registrationTime
Регистационный номер
inDocumentJournal.registrationNumber
Наименование документа
inDocumentJournal.documentName
Полное наименование получателя
inDocumentJournal.addresee
Кол-во экз.
inDocumentJournal.quantity
Код УК
inDocumentJournal.clearingCode
Способ отправки
inDocumentJournal.courierType
Дата отправки эл. почтой
inDocumentJournal.emailDate
Сумма
inDocumentJournal.Amount
Номер дела
inDocumentJournal.dossierNumber
Комментарий
inDocumentJournal.Comment
Дата получения оригинала
inDocumentJournal.receiptDate
При получении сообщения account-accounttype-clearing из очереди kafka должно быть сформировано уведомление в формате .docx, для расчетной организации в соответствии с шаблоном.
При получении сообщения relation-servicestatus-reopen из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: OBT.ACTV.{company.clearingCode}.{datetime}.
Уведомление о прекращении допуска
При получении сообщения relation-servicestatus-blocked из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: OBT.ACTV.{company.clearingCode}.{datetime}.
Уведомление о приостановлении допуска
ППри получении сообщения relation-servicestatus-suspended из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: OBT.SSPD.{company.clearingCode}.{datetime}.
Уведомление о расторжении договора
При получении сообщения relation-servicestatus-closed из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: OBT.CLOS.company.clearingCode}.{datetime}.
Уведомление о заключении договора
При получении сообщения relation-servicestatus-actived из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: OBT.NEW.company.clearingCode}.{datetime}.
При получении сообщения account-accounttype-clearing из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Поля для заполнения:
При получении сообщения account-accounttype-information из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Уведомление о возобновлении допуска
При получении сообщения relation-servicestatus-reopen из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: REC.ACTV.{company.clearingCode}.{datetime}
Уведомление о прекращении допуска
При получении сообщения relation-servicestatus-suspended из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: REC.SSPD.{company.clearingCode}.{datetime}
Уведомление о приостановлении допуска
При получении сообщения relation-servicestatus-blocked из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: REC.BLKD.{company.clearingCode}.{datetime}
При получении сообщения relation-servicestatus-closed из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: REX.{company.clearingCode}.{datetime}
При получении сообщения relation-servicestatus-closed из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: RRPC.{company.clearingCode}.{datetime}
Уведомление о возобновлении допуска
При получении сообщения relation-servicestatus-reopen из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: ROOT.ACTV.{company.clearingCode}.{datetime}.
Уведомление о прекращении допуска
При получении сообщения relation-servicestatus-blocked из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: ROOT.BLKD.{company.clearingCode}.{datetime}.
Уведомление о приостановлении допуска
При получении сообщения relation-servicestatus-suspended из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: ROOT.SSPD.{company.clearingCode}.{datetime}.
Уведомление о расторжении договора
При получении сообщения relation-servicestatus-closed из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: ROOT.CLOS.company.clearingCode}.{datetime}.
Уведомление о заключении договора
При получении сообщения relation-servicestatus-actived из очереди kafka должно быть сформировано уведомление в формате .docx, в соответствии с шаблоном.
Маска файла: ROOT.NEW.company.clearingCode}.{datetime}.