Разработка #3604
Обновлено Андрей Ерзунов 7 месяца назад
В системе должна появиться функциональность для двух типов перевода олигов:
1. Из науки в производство.
2. Из производства в науку.
В общем случае перевод выполняется посредством создания заказа нового типа. В системе появятся два типа заказов:
1. *Перевод в производство.* Под переводом в производство подразумевается перевод олигов из научных в производственные.
2. *Перевод в архив.* Под переводом в архив подразумевается перевод олигов из производственных в научные.
На текущий момент Справочнике наименований олигов (сущностей Olig), списки разделяются по двум вкладкам: производственные и научные, на основе значения поля orderType (INDUSTRIAL или SCIENTIFIC). И при выполнении перевода, - у наименований олигов меняется значение поля orderType в зависимости от типа перевода.
Кроме этого, с сущностью Olig связаны сущности OligsOrderTypeChangesSnapshot. Это снэпшоты изменений параметров олига при редактировании, на текущий момент любое редактирование олига через справочник приводит к созданию такого снэпшота.
И при переводе, когда мы меняем orderType - также должна создаваться запись данного снэпшота. Для данной сущности есть свой сервис, туда будет необходимо добавить соответствующую логику.
Также к теме снэпшотов добавлю то, что при переводе из науки в производство, помимо изменения orderType, иногда выполняется и переименование сущности Olig, изменяется значение поля name. Это изменение также должно быть зафиксировано в том же снэпшоте, который будет создан при выполнении перевода. Более подробно про переименование будет указано ниже.
В разделе "Заказы" должен появиться пункт меню "Переводы".
!clipboard-202510091100-xxcqh.png!
Внутри которого должны располагаться два подпункта:
1. Перевод в производство.
2. Перевод в архив.
На соответствующих страницах: Перевод в производство и Перевод в архив, - будут располагаться список созданных заказов соответствующих типов, и кнопка для их создания.
*Создание заказа Перевода из науки в производство*
* Необходимо добавить страницу создания заказа с типом "Перевод в производство".
* На данной странице должна быть следующая функциональность:
* Пользователь загружает .csv-файл с полями: старое название олига, новое название олига, последовательность, конечная концентрация олига, серия олига. Под серией подразумевается дата синтеза олига в формате 140720, где 14 это день, 07 месяц, 20 это год.
* При импорте данного .csv-файла необходимо выполнить ряд валидаций. И после выполнения валидаций отобразить предупреждающий блок с деталями найденных несоответствий (то есть пишем, какое несоответствие было найдено для какого олига):
* Все последовательности в файле должны быть пропущены через валидатор последовательности в ДТ-Синтезе. При валидации на текущий момент выполняется поиск ошибок в последовательности и их исправление. Визуализацию этого процесса можно посмотреть на странице /settings/validation.
На текущий момент в стандартных заказах уже выполняется валидация и очистка последовательностей, можно посмотреть, как там это происходит. Прикрепляю скриншот с примером того, как это можно было бы сделать.
!clipboard-202510091210-mzb2q.png!
* Если последовательность не найдена в ДТ-Синтезе. Критическое несоответствие. Не даём завершить создание заказа.
* Если для соответствующей последовательности, название в ДТ-Синтезе не соответствует старому названию олига в файле. Критическое несоответствие. Не даём завершить создание заказа.
* Если значение Нового названия уже используется в системе. Критическое несоответствие. Не даём завершить создание заказа.
После выполнения всех валидаций для соответствующих последовательностей олигов на страницу должна подгрузиться информация об имеющихся в системе активных и терминированных по причине передачи заказчику олигах.
Информацию об олигах можно пока что показать с такими полями:
!clipboard-202510091216-sp5ky.png!
И для каждого отдельного импортированного из файла наименования, также выполнить следующую валидацию:
* Найдено ли в системе необходимое количество физизических олигов, которое соответствует количеству серий (дат синтеза), указанных в файле.
Например для данного наименования в файле указаны серии 250525,250625, в системе нашлись два физических олига, у одного дата синтеза равна 250525, у второго 250625. Дату синтеза необходимо подгружать из каналов. В этом случае всё нормально, предупреждение показывать не нужно.
Но если например нашёлся бы только один физический олиг - показали бы предупреждение, что количество найденных физических олигов не соответствует количеству серий, указанному в файле.
* Необходимо проверить, соответствуют ли значения дат синтеза у найденных олигов тем значениям серий (дат синтеза), что указаны в файле. Например, если в ситуации описанной в предыдущем пункте было найдено также два олига, но у одного из них или обоих другая дата синтеза, не как в файле, или если у них обоих дата синтеза 250525, а судя по файлу должно быть 250525,250625, - то отобразить предупреждение говорящее об этом несоответствии.
Две данных валидации должны работать пока что только в формате предупреждения, и не должны препятствовать завершению создания заказа.
То есть при завершении можно показать модальное окно, что были найдены несоответствия в сериях, завершить создание?
При поиске соответствующих физических олигов необходимо добавить ещё одну валидацию:
* Для импортированного наименования не было найденного ни одного олига в системе, - показываем блок с предупреждением для данной ошибки, и пока что считаем данное предупреждение критическим. Не даём завершить создание заказа.
По поводу визуализации того, как можно было бы отобразить информацию об импортированных наименованиях олигов, и связанных с ними физических сущностях, на странице создания заказа, - я бы предложил использовать формат со скриншота ниже
!clipboard-202510091227-iaqem.png!
Только на форме создания заказа в верхнем блоке была бы указана вся информация об импортированном наименовании олига из файла.
А в таблице - отобразился бы список подгруженных физических сущностей для соответствующего наименования.
Хотел бы ещё раз отметить, что подгружаем не только активные, - но и терминированные по причине передачи заказчику.