diff --git a/clearing-parent/backend-api/pom.xml b/clearing-parent/backend-api/pom.xml index 974f8f46f..71e76bde9 100644 --- a/clearing-parent/backend-api/pom.xml +++ b/clearing-parent/backend-api/pom.xml @@ -129,34 +129,187 @@ ${project.artifactId} - org.codehaus.mojo xml-maven-plugin + + + ddl transform + + + + src/main/resources/meta + + meta.xml + + src/main/resources/meta/xsl/ddl.xsl + + + ddl.sql + + + + + + + + + data + + transform + + + + + src/main/resources/meta + + data.xml + + src/main/resources/meta/xsl/data.xsl + + + data.sql + + + + + + + + + db + + transform + + + + + src/main/resources/meta + + meta.xml + + src/main/resources/meta/xsl/db.xsl + + + db.html + + + + + + + + + json + + transform + + + + + src/main/resources/meta + + meta.xml + + src/main/resources/meta/xsl/json.xsl + + + meta.json + + + + + + + + + core + + transform + + + + + src/main/resources/meta + + meta.xml + + src/main/resources/meta/xsl/core.xsl + + + core.html + + + + + + + + + report + + transform + + + + + src/main/resources/meta + + meta.xml + + src/main/resources/meta/xsl/report.xsl + + + report.html + + + + + + + + + web + + transform + + + + + src/main/resources/meta + + meta.xml + + src/main/resources/meta/xsl/web.xsl + + + web.html + + + + + - - - - src/main/resources/meta - - meta.server.xslt - - src/main/resources/meta/meta.server.xslt - - - .json - - - - - maven-resources-plugin diff --git a/clearing-parent/backend-api/src/main/resources/meta/meta.xml b/clearing-parent/backend-api/src/main/resources/meta/meta.xml index 29462b328..b10cf5af4 100644 --- a/clearing-parent/backend-api/src/main/resources/meta/meta.xml +++ b/clearing-parent/backend-api/src/main/resources/meta/meta.xml @@ -261,9 +261,9 @@ - + - + diff --git a/clearing-parent/backend-api/src/main/resources/meta/meta.xsd b/clearing-parent/backend-api/src/main/resources/meta/meta.xsd new file mode 100644 index 000000000..b8d175f40 --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/meta.xsd @@ -0,0 +1,26952 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Общие проверки при обработке методов

+

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). + +* - подставляется цифра соответствующего модуля согласно кодам ошибок из data.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}. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/core.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/core.xsl new file mode 100644 index 000000000..b33dedd4e --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/core.xsl @@ -0,0 +1,193 @@ + + + + + + + + + + + + + + + + Web + + + + + Version: + + + + + + + + + +

Общее описание бизнес-объектов

+
+ + + + + + + + + + + + + + + + +

1.. -

+ +
+
+ + +

1..1. Обработка методов

+ +
+ + + +

1..1.. -

+
+
+ + + + + + + + + + + +
#ПолеТипОбяз.Наименование
+ + + + () + + + + + O + +
+ + + + 		+
+
Ссылается на объект: +
+ + +

1..2. Поля объекта

+ + + + + + + + + + + +
#ПолеТипНаименованиеОбработка
+ + + + + + + + () + + +
+
Ссылается на объект: +  Содержит значение объекта связанного по полям =.
 + + + 		+
+
+ + + + + + + +

2.. -

+ + + +
#ПолеНаименованиеТип
+
Значения:
+ + . -
+ + + + + + + + + + + + + + () + + + + + + + + + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/data.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/data.xsl new file mode 100644 index 000000000..c3568c6af --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/data.xsl @@ -0,0 +1,163 @@ + + + + + +abcdefghijklmnopqrstuvwxyz +ABCDEFGHIJKLMNOPQRSTUVWXYZ +_0123456789 + + + + +-- DB version: +-- DATA version: + + + + +/* Dictionaries */ + + + + +/* Business objects */ + + + + + -- . : - + , + + + + + +INSERT INTO ( + +) values ( + +); + + + + + +INSERT INTO ( + +) values ( + +); + + + + + + + + + + + +, + + + + + + + +'' +'' +'' +'' +'' + + +, + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + upper + + + + + + + + + + + + + + + + + + + + + + + _ + + + + + + + + + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/db.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/db.xsl new file mode 100644 index 000000000..80a747f3a --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/db.xsl @@ -0,0 +1,209 @@ + + + + +abcdefghijklmnopqrstuvwxyz +ABCDEFGHIJKLMNOPQRSTUVWXYZ +_0123456789 + + + + + + + Web + + + + Version: + + + + +-- DB version: + + +/* Dictionaries */ + + + + +/* Business objects */ + + + + + /* views */ + + + + -- Data types + + + + + -- . : - + , + + + + +

. - ( )

+ + + +
№ПолеТипНаименование
+ + + + +

. - ( )

+ + + + +
№ПолеТипНаименование
+ + + + +, + + + + +  +() PRIMARY KEY + + + + + + + + + () + + (linked to ) + + + + + + + + + + + () + + (linked to ) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + upper + + + + + + + + + + + + + + + + + + + + + + + _ + + + + + + + + + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/ddl.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/ddl.xsl new file mode 100644 index 000000000..49acfd171 --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/ddl.xsl @@ -0,0 +1,191 @@ + + + + +abcdefghijklmnopqrstuvwxyz +ABCDEFGHIJKLMNOPQRSTUVWXYZ +_0123456789 + + + +-- DB version: + + +/* Dictionaries */ + + + + +/* Business objects */ + + + + + /* views */ + + + + -- Data types + + + + + -- . : - + , + + + +-- - + +CREATE TABLE IF NOT EXISTS (); +COMMENT ON TABLE IS ''; + + + + +-- - + +CREATE TABLE IF NOT EXISTS (); +COMMENT ON TABLE IS ''; + + + +-- History log of - + +CREATE TABLE IF NOT EXISTS _HISTORY(_ID BIGINT NOT NULL, EVENT_TIME timestamp, EVENT_USER_ID BIGINT, ); +COMMENT ON TABLE _HISTORY IS 'История изменений таблицы '; +COMMENT ON COLUMN _HISTORY._ID IS 'Идентификатор записи в таблице '; +COMMENT ON COLUMN _HISTORY.EVENT_TIME IS 'Дата и время изменения'; +COMMENT ON COLUMN _HISTORY.EVENT_USER_ID IS 'Инициатор изменения'; + + + + + + + + + + + +, + + + + + + +() PRIMARY KEY + + + + + + +COMMENT ON COLUMN . IS ' (linked to )'; + + + + + + + + + +COMMENT ON COLUMN . + IS ' (linked to )'; + + + + + + + + +COMMENT ON COLUMN _HISTORY. IS ' (linked to )'; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + upper + + + + + + + + + + + + + + + + + + + + + + + _ + + + + + + + + + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/json.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/json.xsl new file mode 100644 index 000000000..78e8d929d --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/json.xsl @@ -0,0 +1,197 @@ + + + + + + + + + + { + "version": "", + + } + + + + "enums": { + + } + + + + + ,"objects": { + + } + + + + + ,"views": { + + } + + + + + + + + ,"types": [ + + ] + + + + + , + { + "code": "", + + "": "" + , + + } + + + + + , + "": { + + "": "", + + "fields": [] + } + + + + + , + "": { + + "": "", + + "fields": [] + + ,"actions":[] + } + + + + + + + + + + + + , + {"method":"", + + "": "", + + "fields": [] + } + + + + + + + + , + "": { + + "": "", + + "sources": [] + ,"fields":[] + } + + + + + , + "" + + + + + , + + + + + + { + + , + "": + + { + + + , + + } + + + } + + + + + + + , + {"code": "", + + + "": + "": + "": + "": + "": + "": + "": + "": + "": "" + + , + + } + + + + , + {"": + { + + + "": + "": "" + "": "" + "": "" + + , + + }} + + + + + + "": + "": + "": + "": + "": + "": + "": + "": "" + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/report.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/report.xsl new file mode 100644 index 000000000..6916dbe7e --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/report.xsl @@ -0,0 +1,151 @@ + + + + + + + + + + + + + + + + Web + + + + + Version: + + + + + + + + + + + + + +

Общее описание отчетов

+
+ + + + + + + + + + + + + + + + + +

1.. -

+ +
+
+ + +
. = + - + +
+ + +

1..2. Поля объекта

+ + + + + + + + + +
#ПолеОбработка
+ + +
+
+
Пример:
+
+ + + + + + +

2.. -

+ + + +
#ПолеОписаниеНаименованиеТип
+ + + + + + + + + + + + + () + + + + + + + + + + + + + + + + + + + + + diff --git a/clearing-parent/backend-api/src/main/resources/meta/xsl/web.xsl b/clearing-parent/backend-api/src/main/resources/meta/xsl/web.xsl new file mode 100644 index 000000000..177bb2dc9 --- /dev/null +++ b/clearing-parent/backend-api/src/main/resources/meta/xsl/web.xsl @@ -0,0 +1,172 @@ + + + + + + + + + + + + Web + + + + + Version: + + + + + + + + + + + + + + + + + + + +

Data types

+ + +
+ + + + + + + + + +

-

+ + + +
#ПолеОписаниеНаименованиеТип
+ + + + +

-

+ + + +
#ПолеТипНаименование
+ + + + + + + + + + + + + + () + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + () + + + + + . + +
Ссылается на объект : + + + + + + + + + + + + + "": + "": + "": + "": + "": + "": + "": + "": "" + + +