Разработка #3627
Обновлено Андрей Золотухин 6 месяца назад
В системе должна появиться функциональность для двух типов перевода олигов:
1. Из науки в производство.
2. Из производства в науку.
В рамках этой задачи пока что реализуем только перевод из науки в производство.
В общем случае перевод выполняется посредством создания заказа нового типа. В системе появятся два типа заказов:
1. *Перевод в производство.* Под переводом в производство подразумевается перевод олигов из научных в производственные.
2. *Перевод в архив.* Под переводом в архив подразумевается перевод олигов из производственных в научные.
На текущий момент Справочнике наименований олигов (сущностей Olig), списки разделяются по двум вкладкам: производственные и научные, на основе значения поля orderType (INDUSTRIAL или SCIENTIFIC). И при выполнении перевода, - у наименований олигов меняется значение поля orderType в зависимости от типа перевода.
Кроме этого, с сущностью Olig связаны сущности OligsOrderTypeChangesSnapshot. Это снэпшоты изменений параметров олига при редактировании, на текущий момент любое редактирование олига через справочник приводит к созданию такого снэпшота.
И при переводе, когда мы меняем orderType - также должна создаваться запись данного снэпшота. Для данной сущности есть свой сервис, туда будет необходимо добавить соответствующую логику.
Также к теме снэпшотов добавлю то, что при переводе из науки в производство, помимо изменения orderType, иногда выполняется и переименование сущности Olig, изменяется значение поля name. Это изменение также должно быть зафиксировано в том же снэпшоте, который будет создан при выполнении перевода. Более подробно про переименование будет указано ниже.
В разделе "Заказы" должен появиться пункт меню "Переводы".
!clipboard-202510091303-ikpvm.png!
Внутри которого должен располагаться подпункт:
1. Перевод в производство.
На соответствующих страницах: Перевод в производство и Перевод в архив, - будут располагаться список созданных заказов соответствующих типов, и кнопка для их создания.
*Создание заказа Перевода из науки в производство*
* Необходимо добавить страницу создания заказа с типом "Перевод в производство".
* На данной странице должна быть следующая функциональность:
* Пользователь загружает .csv-файл с полями: старое название олига, новое название олига, последовательность, конечная концентрация олига, серия олига. Под серией подразумевается дата синтеза олига в формате 140720, где 14 это день, 07 месяц, 20 это год.
* При импорте данного .csv-файла необходимо выполнить ряд валидаций. И после выполнения валидаций отобразить предупреждающий блок с деталями найденных несоответствий (то есть пишем, какое несоответствие было найдено для какого олига):
* Все последовательности в файле должны быть пропущены через валидатор последовательности в ДТ-Синтезе. При валидации на текущий момент выполняется поиск ошибок в последовательности и их исправление. Визуализацию этого процесса можно посмотреть на странице /settings/validation.
На текущий момент в стандартных заказах уже выполняется валидация и очистка последовательностей, можно посмотреть, как там это происходит. Прикрепляю скриншот с примером того, как это можно было бы сделать. *Важно!* Коллеги попросили использовать другой вариант отображения в этом случае. Более подробная информация содержится в задаче https://redmine.dna-tech.dev/issues/3657.
!clipboard-202510091303-vhgnp.png!
* Если последовательность не найдена в ДТ-Синтезе. Критическое несоответствие. Не даём завершить создание заказа.
* Если для соответствующей последовательности, название в ДТ-Синтезе не соответствует старому названию олига в файле. Критическое несоответствие. Не даём завершить создание заказа.
* Если значение Нового названия уже используется в системе. Критическое несоответствие. Не даём завершить создание заказа.
После выполнения всех валидаций для соответствующих последовательностей олигов на страницу должна подгрузиться информация об имеющихся в системе активных и терминированных по причине передачи заказчику олигах.
Информацию об олигах можно пока что показать с такими полями:
!clipboard-202510091304-fppjc.png!
И для каждого отдельного импортированного из файла наименования, также выполнить следующую валидацию:
* Найдено ли в системе необходимое количество физизических олигов, которое соответствует количеству серий (дат синтеза), указанных в файле.
Например для данного наименования в файле указаны серии 250525,250625, в системе нашлись два физических олига, у одного дата синтеза равна 250525, у второго 250625. Дату синтеза необходимо подгружать из каналов. В этом случае всё нормально, предупреждение показывать не нужно.
Но если например нашёлся бы только один физический олиг - показали бы предупреждение, что количество найденных физических олигов не соответствует количеству серий, указанному в файле.
* Необходимо проверить, соответствуют ли значения дат синтеза у найденных олигов тем значениям серий (дат синтеза), что указаны в файле. Например, если в ситуации описанной в предыдущем пункте было найдено также два олига, но у одного из них или обоих другая дата синтеза, не как в файле, или если у них обоих дата синтеза 250525, а судя по файлу должно быть 250525,250625, - то отобразить предупреждение говорящее об этом несоответствии.
Две данных валидации должны работать пока что только в формате предупреждения, и не должны препятствовать завершению создания заказа.
То есть при завершении можно показать модальное окно, что были найдены несоответствия в сериях, завершить создание?
При поиске соответствующих физических олигов необходимо добавить ещё одну валидацию:
* Для импортированного наименования не было найденного ни одного олига в системе, - показываем блок с предупреждением для данной ошибки, и пока что считаем данное предупреждение критическим. Не даём завершить создание заказа.
По поводу визуализации того, как можно было бы отобразить информацию об импортированных наименованиях олигов, и связанных с ними физических сущностях, на странице создания заказа, - я бы предложил использовать формат со скриншота ниже:
!clipboard-202510091304-e1ukb.png!
Только на форме создания заказа в верхнем блоке была бы указана вся информация об импортированном наименовании олига из файла.
А в таблице - отобразился бы список подгруженных физических сущностей для соответствующего наименования.
Блок с предупреждениями, связанными с найденными несоответствиями серий или отсутствием активных олигов для соответствующего наименования можно было бы разместить между верхним блоком и таблицей.
Предупреждение можно отображать в таком формате. Данный блок уже используется на УПР. На странице со Списком олигов на разведение.
!clipboard-202510091304-kgocj.png!
* Хотел бы ещё раз отметить, что подгружаем не только активные, - но и терминированные по причине передачи заказчику.
* Формат работы с данной страницей должен быть таким, что пользователь может ещё раз переимпортировать .csv-файл, и вся информация будет перезагружена заново.
* В верхней части страницы создания заказа должны располагаться поля ввода "Дата перевода", "Тема перевода", "Клиент", аналогичные поля уже есть на стандартной форме создания заказа.
* В случае если критических предупреждений не было обнаружено, - разрешаем завершить создание заказа.
* При завершении создания заказа в те физические олиги, которые были подгружены на страницу будут *переназначены* в новый созданный заказ. Данный механизм переназначения олигов в новый заказ уже реализован в системе, и используется на стандартной странице создания заказа, для этого используется метод createNewSynthesisObjectsFromOligInOrder(). Данный метод переносит существующий synthesisObject в новый заказ. В данном методе необходимо внести изменения, чтобы synthesisObject в старом заказе терминировался не по причине SYSTEM_TERMINATION, а по причине TERMINATED_BY_USER, и создавалось событие с типом REASSIGNED_TO_NEW_ORDER, и для synthesisObject'а из старого заказа тоже.
* После создания заказа ему необходимо установить новый статус "В проверке". Пока установлен данный статус информация об олигах из заказа не отображается на УВП и УВПН. Об этом будет далее. Пока что просто можно установить статус.
* Детали данного заказа можно выполнить с помощью аналогичного компонента, который используется в Архиве УВПН и на Деталях научного заказа. Но конечно в блоке информации о заказе будет меньше полей, пока что только номер заказа, дата перевода (дата созадния), тема перевода (название заказа), клиент и статус.
* В компоненте связанных олигов заказа перевода в производство будет использоваться почти та же таблица, что и для научных олигов, но без статуса по объёму и контролю, а вместо этого будет возможность указать следующие статусы: "Одобрен для передачи", "Одобрен с доп. проверкой", "Списан". Эти статусы относятся непосредственно к физическому олигу (synthesisObject'у). Также для олига должно отображаться старое и новое название. Новое название - это текущее название олига, старое название - это source-название из таблицы OligsOrderTypeChangesSnapshot, из последней записи, где было произведено переименование олига. Если такой записи нет, - то отображаем просто текущее название.
* *Дополнительное пожелание по отображению столбцов.* Должны быть столбцы, как в архиве, добавить архивный номер, убрать статус по объёму и контролю (было указано в предыдущем пункте).
* Кроме статусов, которые может выставить пользователь, в строках таблицы должны отображаться автоматические статусы, которые относятся к отдельным физическим сущностям и формируются на основе фактической концентрации олига и целевой концентрации из oligForSynthesis. При создании заказа целевая концентрация переносится в oligInOrder и oligForSynthesis из значения целевой концентрации, указанной в .csv-файле. Если фактическая концентрация олига больше, чем целевая в oligForSynthesis (с учётом 5%, как это работает сейчас), - должен отображаться статус - "Довести до требуемой", если фактическая концентрация меньше, чем целевая в oligForSynthesis, - должен отображаться статус "Сконцентрировать", иначе - отображается статус "Отдать".
* Важный момент, связанный с данным заказом, - так как при создании ему установлен статус "В проверке", - у пользователя должна быть кнопка, отметить, что данный заказ перемещается в работу (после чего информация о нём будет отображаться и на УВПН, и УВП, но это тема другой задачи). При нажатии на эту кнопку у заказа меняется статус на "В работе". И для всех наименований олигов из данного заказа - выполняется их переименование и перенос в производственные в справочнике (с сопутствующим созданием информации в таблице OligsOrderTypeChangesSnaphot. В случае, если по какой-то причине перевод в производство уже был выполнен, - повторно не создаём запись снэпшота изменений олига, если при этом было выполнено переименование олига, - создаём снэпшот только с изменением этого параметра.
* В связи с тем, что процесс переименования происходит после подтверждения, - название из колонки "Новое название олига", - необходимо фиксировать дополнительным параметром в OligInScientificOrder, и если статус заказа "В проверке" - отображать данное значение, иначе - отображать актуальное значение названия олига.
Далее будут описаны требования Альбины по ее файлу:
1. Проставлять статусы при создании заказа
- если серия имеется в архиве и в csv напротив строки будет “V” — передавать.
- если есть синтезы (серии), которых не было в csv, эта срока будет отмечена “!” - передавать с доп. проверкой.
- если серия из csv не нашлась, на этапе создания заказа появится уведомление об этом, тогда Соня будет разбираться с разработчиками
2. Совпала последовательность, не совпало название — при создании заказа будет выдана ошибка, вероятно будет переименован, Соня подтверждает переименование вручную.
3. Не совпала последовательность, совпало название — при создании заказа будет выдана ошибка, Соня будет уточнять у разработчиков. Вероятно, олиг в архиве будет переименован, и тогда строчка исчезнет.
4. Если в csv-файле серий нет, то считаем, что все серии одобрены.
5. После создания заказа на перевод Соне необходимо переместить олиги из базы научных в производственные. В момент перемещения должен появится еще один csv-файл (который сейчас используется для перевода), в котором будут указаны дополнительные сведения к конкретному наименованию: ООУП, детритилирование, проверка. Этот файл можем внести в рамках заказа, либо отдельным функционалом в настройках, олигонуклеотиды.
6. Отображение в Заказах:
!clipboard-202511111557-nb1yj.png!
7. Возможные статусы и переходы:
1. Готов к выдаче - Выдан
2. Списать – Списан. Списываются олиги объемом меньше 100 мкл при целевой.
3. Передать в проверку - Передан в проверку – Готов к выдаче - Выдан
4. Сконцентрировать – Готов к выдаче - Выдан
5. Довести до целевой – Готов к выдаче - Выдан
6. Перевыпуск – Готов к выдаче - Выдан
В самом заказе можно изменять статус вручную, при этом рядом со статусом появляется значок и возможность отмены ручной установки статуса.
В самом заказе сделаем две вкладки — все синтезы, активные синтезы. В активных будут отображаться только физически существующие в архиве синтезы.
Если олиг списан, выдан, то в самом заказе он не будет отображаться во вкладке Активные.
Если пришли результаты проверки, в заказе можно будет это отметить, тогда статус поменяется на готов к выдаче.
Статус меняются в зависимости от подстатусов, те если олиг высушили и довели до целевой, то он становится готовым к выдаче.
В самом заказе можно изменять статус вручную, при этом рядом со статусом появляется значок и возможность отмены ручной установки статуса.
В самом заказе сделаем две вкладки — все синтезы, активные синтезы. В активных будут отображаться только физически существующие в архиве синтезы.
Если олиг списан, выдан, то в самом заказе он не будет отображаться во вкладке Активные.
Если пришли результаты проверки, в заказе можно будет это отметить, тогда статус поменяется на готов к выдаче.
Статус меняются в зависимости от подстатусов, те если олиг высушили и довели до целевой, то он становится готовым к выдаче.
Приоритеты подстатусов:
1. Сначала проверяем количество, те списываем или нет.
2. Потом проверяем срок годности. Если истек – статус перевыпуск. Критерии по сроку годности стандартные для УВП (разные для разных типов олигов). Срок годности считается от даты синтеза.
3. Потом оцениваем сушить или развести
4. Передача в проверку
Перевыпуск – существует несколько вариантов:
1. Передается олиг на 2RP на УХ, УПР, УВК. После УПР олиги передаются сразу на УВП
2. Передается олиг на УПР для проверки концентрации. После УПР олиги передаются сразу на УВП.
3. Передается аликвота на УВК для проверки качества
Олиги с перевода при передаче с других участков отображаются на УВП всегда во вкладке Перевод.
УВП может списать олиги, которые система будет рекомендовать перевыпустить, так как объемы могут быть незначительными, а также будут существовать другие серии. В этом случае УВП меняет вручную статус на списать.
Какие варианты изменения статусов:
1. Установить “Готов к выдаче”
2. Установить “Списать”
3. Установить “Перевыпуск”
4. Установить “Передать в проверку”
5. Установить “Сконцентрировать”
6. Установить “Довести до целевой”
На странице заказа должны быть кнопки:
Списать ---- Передать в проверку ---- Передать на производство