counterparty_kontur.rst

Синхронизация данных контрагентов и их ящиков с Контур.Диадок

Данная синхронизация предназначена для автоматизации заполнения данных контрагентов, включая ящики ЭДО.

Логика работы:

1. При создании синхронизации, стандартными средствами ECOS создается FutureTask, привязанный к определенному триггеру, который завязан на крон, или на переодический таймер

2. При вызове созданной ранее FutureTask, выполняется метод execute, вызывающий запуск синхронизации.

3. В методе execute, вызывается метод executeImpl, в котором:

   1. Производится поиск зарегистрированного CounterpartiesSyncService, интерфейс которого определен в ecos-edi-commons, а реализация описывается в отдельном бандле для каждого ЭДО провайдера. К примеру :ref:`ecos-edi-kontur-lib<ecos-edi-kontur-lib>`

      Если CounterpartiesSyncService не найден, выбрасывается исключение.

   2. Запускается синхронизация контрагентов, на основе описанной в синхронизации конфигурации.

Логика работы синхронизационного сервиса KonturDiadocCounterpartiesSyncService:

1. Валидируются и извлекаются параметры, из конфигурации синхронизации
2. Происходит отправка запроса в Контур.Диадок, для получения всех контрагентов, для заданного ящика. В данном случае видна разница между этой синхронизацией и синхронизацией документов. В данном случае, мы получаем всех контрагентов, так как у Контура нет никакой событийной системы для них.
3. Производится маппинг данных, полученных из Контура в dto Counterparty, описанное в ecos-edi-commons
4. Полученные и обработанные данные передаются в camel route, описанный в настройках синхронизации

Устройство бандла для обработки контрагентов

Бандл устроен достаточно просто:

1. Активатор, в котором, в момент загрузки бандла инициализируется фабрика ApplicationCamelContextFactory. В момент его удаления происходит её уничтожение
2. Класс фабрики для инициализации camel routes и всех необходимых сервисов
3. Классы самих роутов, в которых производится фильтрация, передача данных в другие роуты и делегирование обработки классам процессорам
4. Классы процессоры, которые обрабатывают данные по необходимому алгоритму

Классы роутов устроены достаточно однотипно и их логика не будет меняться, если нет необходимости исключить какие-то статусы из обработки.

Классы процессоры обрабатывают данные, согласно заложенному в них алгоритму.

Пример обработчика контрагентов в статусах IsMyCounteragent, RejectsMe, IsRejectedByMe:

1. Производится поиск контрагента, на основе полученных данных. Например, по ИНН

   1. Если контрагент не найден, в лог пишется информация, об этом, процессор завершает обработку полученных данных

2. Производится заполнение запроса на мутацию с полученными данными. Отдельно производится заполнение данных ящиков, так как это ассоциация

3. Отправляется запрос на мутацию

4. Процессор завершает обработку полученных данных

Пример обработчика контрагентов в статусе InvitesMe:

На примере заполнения “Заявок на ЭДО”:

1. Производится поиск контрагента, на основе полученных данных. Например, по ИНН.

   1. Если контрагент найден, производится обновление его данных, для последующего прикрепления к карточке.

2. Производится поиск карточки “Заявки на ЭДО”, по полученным данным.

   1. Если такая заявка найдена, её данные обновляются, процессор завершает обработку полученных данных.

3. Заполняется запрос на мутацию карточки “Заявка на ЭДО”. Отдельно создаются сопутствующие документы-приглашения, если они есть(к карточке привязывается процесс и если пользователь принимает заявку, при наличии, их необходимо подписать), после чего они привязываются к карточке.

4. Отправляется запрос на мутацию.

5. Процессор завершает обработку полученных данных.

Настройка синхронизации контрагентов с Контур.Диадок

Шаги по настройке:

1. Открываем журнал “Синхронизации”

2. Нажимаем кнопку +

3. В выпадающем списке находим “Синхронизация контрагентов(ЭДО)”, нажимаем на этот пункт выпадающего списка

   

4. Заполняем открывшуюся форму

   

Параметры:

Идентификатор – идентификатор синхронизации. На саму синхронизацию не влияет, нужен только для понимания, за что эта интеграция отвечает. Если обработка происходит для конкретного статуса контрагента, лучше указывать идентификатор статуса + sync. Если все контрагенты обрабатываются в одном роуте, можно указать diadoc-counterparties-sync.

Наименование – наименование синхронизации. Так же не влияет на саму интеграцию, нужно для понимания. Обычно, совпадает с идентификатором.

Включена – включена ли синхронизация.

Необходимо перезагрузить – перезапуск интеграции сразу после сохранения.

Ящик ЭДО – отвечает за то, для какого ящика будет проводиться синхронизация, как и в случае с документооборотом Контур.Диадок.

Время наложения блокировки – необходимо задавать для того, чтобы одновременно не запускалось более 2х интеграций для одного и того же ящика. Если значение не задано - блокировка будет накладываться на 2 часа.

Camel endpoint – описанный ранее роут для обработки контрагентов.

Cron expression – Подробнее здесь: org.springframework.scheduling.support.CronTrigger

Trigger period – Используется, если не задан Cron expression. Должен быть задан, если не задан Cron expression, иначе могут проблемы при работе синхронизации

Use fixed rate – отсчет времени до следующего триггирования будет начинаться только после того как завершилась работа по предыдущему триггированию. Подробнее здесь: org.springframework.scheduling.support.PeriodicTrigger

Initial delay – джоба не будет триггериться первые N миллисекунд

DTO для механизма синхронизации контрагентов

Для синхронизации данных по контрагентам с Контур.Диадок, при получении данных используется Protobuf диадока.

Описание данных по контрагентам: Counteragent — документация Диадок 1.87.0

Для преобразования полученных данных, в ECOS используются следующие DTO:

Counterparty:

Тип поля	Название поля	Примечание
OrgId	myOrgId	Идентификатор организации, от лица которой совершался запрос на получение контрагента.
OurId	ourId	Идентификатор ящика, с которого совершался запрос на получение контрагента.
OrgId	orgId	Идентификатор организации контрагента.
String	fullName	Полное наименование организации контрагента.
String	shortName	Сокращенное/альтернативное наименование организации контрагента.
String	inn	ИНН организации контрагента.
String	kpp	КПП организации контрагента.
String	ogrn	ОГРН организации контрагента.
String	address	Почтовый адрес организации контрагента.
String	status	Статус организации контрагента.
String	fnsParticipantId	Налоговый идентификатор организации контрагента.
Long	lastEventTimestamp	Время последнего события, произошедшего между нашей организацией и организацией контрагента (изменение статуса).
InvitationDocument	InvitationDocument	Структура документа-приглашения. Опциональный.
List<EdiBoxDto>	boxDtos	Структура ящиков контрагента в Контур.Диадок. Может быть множественным.
ObjectData	data	Дополнительные параметры, которые не определены в основной структуре. Опциональный.

InvitationDocument:

Тип поля	Название поля	Примечание
DocumentEdiIdentifier	docId	Идентификатор документа приглашения в Контур.Диадок
SignedContent	signedContent	Подписанный контрагентом контент документа-приглашения
FileContent	docContent	Контент документа-приглашения
boolean	НsignatureRequested	Флаг, указывающий на то, запросил контрагент от нас подписание документа-приглашения, или нет. Дефолтное значение – false
ObjectData	data	Дополнительные параметры, которые не определены в основной структуре. Опциональный

SignedContent:

Тип поля	Название поля	Примечание
Signature	signature	Подписанный контент документа.
ObjectData	data	Дополнительные параметры, которые не определены в основной структуре. Опциональный.

EdiBoxDto:

Тип поля	Название поля	Примечание
String	id	Идентификатор ящика Контур.Диадок.
String	title	Заголовок ящика Контур.Диадок.
OurId	ourId	Идентификатор нашей организации. Опциональный.
EdiProviderType	ediProviderType	Тип ЭДО провайдера. В нашем случае, – KONTUR. Другое значение принимать не может.
RecordRef	datasourceRef	Ссылка на запись источника, для синхронизации. Опциональный.
RecordRef	credentialsRef	Ссылка на данные учетной записи для синхронизации. Опциональный.
ObjectData	specialInfo	Дополнительные параметры, которые не определены в основной структуре. Опциональный. Обычно там хранится идентификатор ящика организации контрагента.