Разработка #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! Только на форме создания заказа в верхнем блоке была бы указана вся информация об импортированном наименовании олига из файла. А в таблице - отобразился бы список подгруженных физических сущностей для соответствующего наименования. Блок с предупреждениями, связанными с найденными несоответствиями серий или отсутствием активных олигов для соответствующего наименования можно было бы разместить между верхним блоком и таблицей. Предупреждение можно отображать в таком формате. Данный блок уже используется на УПР. На странице со Списком олигов на разведение. !clipboard-202510091232-ekynl.png! Хотел бы ещё раз отметить, что подгружаем не только активные, - но и терминированные по причине передачи заказчику. Формат работы с данной страницей должен быть таким, что пользователь может ещё раз переимпортировать .csv-файл, и вся информация будет перезагружена заново.