Синтез

В системе должна появиться функциональность для двух типов перевода олигов:
1. Из науки в производство.
2. Из производства в науку.
В рамках этой задачи пока что реализуем только перевод из науки в производство.

В общем случае перевод выполняется посредством создания заказа нового типа. В системе появятся два типа заказов:
1. Перевод в производство. Под переводом в производство подразумевается перевод олигов из научных в производственные.
2. Перевод в архив. Под переводом в архив подразумевается перевод олигов из производственных в научные.

На текущий момент Справочнике наименований олигов (сущностей Olig), списки разделяются по двум вкладкам: производственные и научные, на основе значения поля orderType (INDUSTRIAL или SCIENTIFIC). И при выполнении перевода, - у наименований олигов меняется значение поля orderType в зависимости от типа перевода.

Кроме этого, с сущностью Olig связаны сущности OligsOrderTypeChangesSnapshot. Это снэпшоты изменений параметров олига при редактировании, на текущий момент любое редактирование олига через справочник приводит к созданию такого снэпшота.
И при переводе, когда мы меняем orderType - также должна создаваться запись данного снэпшота. Для данной сущности есть свой сервис, туда будет необходимо добавить соответствующую логику.

Также к теме снэпшотов добавлю то, что при переводе из науки в производство, помимо изменения orderType, иногда выполняется и переименование сущности Olig, изменяется значение поля name. Это изменение также должно быть зафиксировано в том же снэпшоте, который будет создан при выполнении перевода. Более подробно про переименование будет указано ниже.

В разделе "Заказы" должен появиться пункт меню "Переводы".

Внутри которого должен располагаться подпункт:
1. Перевод в производство.

На соответствующих страницах: Перевод в производство и Перевод в архив, - будут располагаться список созданных заказов соответствующих типов, и кнопка для их создания.

1 Этап: Создание заказа Перевода из науки в производство

• Необходимо добавить страницу создания заказа с типом "Перевод в производство".
• На данной странице должна быть следующая функциональность:
• Пользователь загружает .csv-файл с полями: старое название олига, новое название олига, последовательность, конечная концентрация олига, серия олига. Под серией подразумевается дата синтеза олига в формате 140720, где 14 это день, 07 месяц, 20 это год.
• При импорте данного .csv-файла необходимо выполнить ряд валидаций. И после выполнения валидаций отобразить предупреждающий блок с деталями найденных несоответствий (то есть пишем, какое несоответствие было найдено для какого олига):
• Все последовательности в файле должны быть пропущены через валидатор последовательности в ДТ-Синтезе. При валидации на текущий момент выполняется поиск ошибок в последовательности и их исправление. Визуализацию этого процесса можно посмотреть на странице /settings/validation.
  На текущий момент в стандартных заказах уже выполняется валидация и очистка последовательностей, можно посмотреть, как там это происходит. Прикрепляю скриншот с примером того, как это можно было бы сделать. Важно! Коллеги попросили использовать другой вариант отображения в этом случае. Более подробная информация содержится в задаче https://redmine.dna-tech.dev/issues/3657.
  

• Если последовательность не найдена в ДТ-Синтезе. Критическое несоответствие. Не даём завершить создание заказа.
• Если для соответствующей последовательности, название в ДТ-Синтезе не соответствует старому названию олига в файле. Критическое несоответствие. Не даём завершить создание заказа.
• Если значение Нового названия уже используется в системе. Критическое несоответствие. Не даём завершить создание заказа.

После выполнения всех валидаций для соответствующих последовательностей олигов на страницу должна подгрузиться информация об имеющихся в системе активных и терминированных по причине передачи заказчику олигах.
Информацию об олигах можно пока что показать с такими полями:

И для каждого отдельного импортированного из файла наименования, также выполнить следующую валидацию:

• Найдено ли в системе необходимое количество физизических олигов, которое соответствует количеству серий (дат синтеза), указанных в файле.
  Например для данного наименования в файле указаны серии 250525,250625, в системе нашлись два физических олига, у одного дата синтеза равна 250525, у второго 250625. Дату синтеза необходимо подгружать из каналов. В этом случае всё нормально, предупреждение показывать не нужно.
  Но если например нашёлся бы только один физический олиг - показали бы предупреждение, что количество найденных физических олигов не соответствует количеству серий, указанному в файле.
• Необходимо проверить, соответствуют ли значения дат синтеза у найденных олигов тем значениям серий (дат синтеза), что указаны в файле. Например, если в ситуации описанной в предыдущем пункте было найдено также два олига, но у одного из них или обоих другая дата синтеза, не как в файле, или если у них обоих дата синтеза 250525, а судя по файлу должно быть 250525,250625, - то отобразить предупреждение говорящее об этом несоответствии.

Две данных валидации должны работать пока что только в формате предупреждения, и не должны препятствовать завершению создания заказа.
То есть при завершении можно показать модальное окно, что были найдены несоответствия в сериях, завершить создание?

При поиске соответствующих физических олигов необходимо добавить ещё одну валидацию:

• Для импортированного наименования не было найденного ни одного олига в системе, - показываем блок с предупреждением для данной ошибки, и пока что считаем данное предупреждение критическим. Не даём завершить создание заказа.

По поводу визуализации того, как можно было бы отобразить информацию об импортированных наименованиях олигов, и связанных с ними физических сущностях, на странице создания заказа, - я бы предложил использовать формат со скриншота ниже:

Только на форме создания заказа в верхнем блоке была бы указана вся информация об импортированном наименовании олига из файла.
А в таблице - отобразился бы список подгруженных физических сущностей для соответствующего наименования.
Блок с предупреждениями, связанными с найденными несоответствиями серий или отсутствием активных олигов для соответствующего наименования можно было бы разместить между верхним блоком и таблицей.
Предупреждение можно отображать в таком формате. Данный блок уже используется на УПР. На странице со Списком олигов на разведение.

• Хотел бы ещё раз отметить, что подгружаем не только активные, - но и терминированные по причине передачи заказчику.
• Формат работы с данной страницей должен быть таким, что пользователь может ещё раз переимпортировать .csv-файл, и вся информация будет перезагружена заново.
• В верхней части страницы создания заказа должны располагаться поля ввода "Дата перевода", "Тема перевода", "Клиент", аналогичные поля уже есть на стандартной форме создания заказа.
• В случае если критических предупреждений не было обнаружено, - разрешаем завершить создание заказа.
• При завершении создания заказа в те физические олиги, которые были подгружены на страницу будут переназначены в новый созданный заказ. Данный механизм переназначения олигов в новый заказ уже реализован в системе, и используется на стандартной странице создания заказа, для этого используется метод createNewSynthesisObjectsFromOligInOrder(). Данный метод переносит существующий synthesisObject в новый заказ. В данном методе необходимо внести изменения, чтобы synthesisObject в старом заказе терминировался не по причине SYSTEM_TERMINATION, а по причине TERMINATED_BY_USER, и создавалось событие с типом REASSIGNED_TO_NEW_ORDER, и для synthesisObject'а из старого заказа тоже.
• После создания заказа ему необходимо установить новый статус "В проверке". Пока установлен данный статус информация об олигах из заказа не отображается на УВП и УВПН. Об этом будет далее. Пока что просто можно установить статус.
• Детали данного заказа можно выполнить с помощью аналогичного компонента, который используется в Архиве УВПН и на Деталях научного заказа. Но конечно в блоке информации о заказе будет меньше полей, пока что только номер заказа, дата перевода (дата созадния), тема перевода (название заказа), клиент и статус.
• В компоненте связанных олигов заказа перевода в производство будет использоваться почти та же таблица, что и для научных олигов, но без статуса по объёму и контролю, а вместо этого будет возможность указать следующие статусы: "Одобрен для передачи", "Одобрен с доп. проверкой", "Списан". Эти статусы относятся непосредственно к физическому олигу (synthesisObject'у). Также для олига должно отображаться старое и новое название. Новое название - это текущее название олига, старое название - это source-название из таблицы OligsOrderTypeChangesSnapshot, из последней записи, где было произведено переименование олига. Если такой записи нет, - то отображаем просто текущее название.
• Дополнительное пожелание по отображению столбцов. Должны быть столбцы, как в архиве, добавить архивный номер, убрать статус по объёму и контролю (было указано в предыдущем пункте).
• Кроме статусов, которые может выставить пользователь, в строках таблицы должны отображаться автоматические статусы, которые относятся к отдельным физическим сущностям и формируются на основе фактической концентрации олига и целевой концентрации из oligForSynthesis. При создании заказа целевая концентрация переносится в oligInOrder и oligForSynthesis из значения целевой концентрации, указанной в .csv-файле. Если фактическая концентрация олига больше, чем целевая в oligForSynthesis (с учётом 5%, как это работает сейчас), - должен отображаться статус - "Довести до требуемой", если фактическая концентрация меньше, чем целевая в oligForSynthesis, - должен отображаться статус "Сконцентрировать", иначе - отображается статус "Отдать".
• В связи с тем, что процесс переименования происходит после подтверждения, - название из колонки "Новое название олига", - необходимо фиксировать дополнительным параметром в OligInScientificOrder, и если статус заказа "В проверке" - отображать данное значение, иначе - отображать актуальное значение названия олига.

Далее будут описаны требования Альбины по ее файлу:

Проставлять статусы при создании заказа:

• если серия имеется в архиве и в csv напротив строки будет “V” — передавать.
• если есть синтезы (серии), которых не было в csv, эта срока будет отмечена “!” - передавать с доп. проверкой.
• если серия из csv не нашлась, на этапе создания заказа появится уведомление об этом, тогда Соня будет разбираться с разработчиками

Валидация:

• Совпала последовательность, не совпало название — при создании заказа будет выдана ошибка, вероятно будет переименован, Соня подтверждает переименование вручную.
• Не совпала последовательность, совпало название — при создании заказа будет выдана ошибка, Соня будет уточнять у разработчиков. Вероятно, олиг в архиве будет переименован, и тогда строчка исчезнет.
• Если в csv-файле серий нет, то считаем, что все серии одобрены.

После подтверждения создается заказ, на УВП и УВПН появляется список олигов во вкладках Перевод на производство.
1. На УВПН должна появиться новая страница "Перевод (Наука → Производство)", сокращённо можно назвать "Перевод Н → П". На данной странице будут отображаться олиги из заказов "Перевод в производство", сгруппированные по заказам, записи физических сущностей будут отображаться всегда (с указанием участка, на котором находится олиг). Вариант отображения должен быть похожим на тот, который сейчас отображается в Архиве УВПН.
1.1. В данном списке олигов актуально отображение статусов "Довести до требуемой", "Сконцентрировать", "Отдать", которые упомянуты в задаче https://redmine.dna-tech.dev/issues/3627.
1.2. В целом, состав столбцов можно взять из заказа "Перевод в производство".
2. На УВП должна появиться новая страница "Перевод в производство". На данной странице олиги должны отображаться просто в виде таблицы, с данными похожими как в списке олигов на УВПН. В случае если олиг находится на долговременном хранении - в колонке с участком должно отображаться значение "Архив". Если олиг достали с долговременного хранения, - то УВПН. Для отображения на данной странице олиги должны находиться на УВПН.

2 Этап: Перевод олигов из научных в производственные.

От Альбины П.:
"После создания заказа на перевод Соне необходимо переместить олиги из базы научных в производственные. В момент перемещения должен появится еще один csv-файл (который сейчас используется для перевода), в котором будут указаны дополнительные сведения к конкретному наименованию: ООУП, детритилирование, проверка. Этот файл можем внести в рамках заказа, либо отдельным функционалом в настройках, олигонуклеотиды."

"Создание сsv -файла с ооуп, детритилированием и официальным переводом из науки в производстве. После завершения статус в заказе - в работе. И в этот момент олиги появляются на участках, можно даже предусмотреть уведомление на увп и увпн. Олиги переназначаются из научных заказов в перевод."

От Андрея Е.

- Важный момент, связанный с данным заказом, - так как при создании ему установлен статус "В проверке", - у пользователя должна быть кнопка, отметить, что данный заказ перемещается в работу (после чего информация о нём будет отображаться и на УВПН, и УВП, но это тема другой задачи). При нажатии на эту кнопку у заказа меняется статус на "В работе". И для всех наименований олигов из данного заказа - выполняется их переименование и перенос в производственные в справочнике (с сопутствующим созданием информации в таблице OligsOrderTypeChangesSnaphot. В случае, если по какой-то причине перевод в производство уже был выполнен, - повторно не создаём запись снэпшота изменений олига, если при этом было выполнено переименование олига, - создаём снэпшот только с изменением этого параметра.
- В связи с тем, что процесс переименования происходит после подтверждения, - название из колонки "Новое название олига", - необходимо фиксировать дополнительным параметром в OligInScientificOrder, и если статус заказа "В проверке" - отображать данное значение, иначе - отображать актуальное значение названия олига.

3 Этап: поиск и передача на производство.

Требует уточнения