Opened 4 months ago

Last modified 3 months ago

#1250 new улучшение

Перенести Отгрузку в Заказы

Reported by: Denis_N Owned by: Denis_N
Priority: major Component: БД изделий АДС
Keywords: Cc: alx, san

Description

Перенести кнопку "Отгрузить" из и-са "Отгрузка" в и-с "Заказы". Сообщения о невозможности отгрузить тоже перенести

Change History (9)

comment:1 by alx, 4 months ago

Denis_N, я понимаю, что ты создал тикет сам для себя, и тебе своя же идея понятна без пояснений. :)
Но, так как ты добавил в СС других людей, хотелось бы узнать, в чем же состоит улучшение?

На первый взгляд, идея контринтуитивна: приемом заказов занимается один человек (начальник ПТО), а отгрузкой - другой. Зачем человеку, который не занимается отгрузкой, в веб-интерфейсе кнопка "Отгрузить"? Зачем ему сообщения о невозможности отгрузить? С другой стороны, как будет работать сотрудник, занимающийся отгрузкой, без кнопки "Отгрузить"?

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

comment:2 by Denis_N, 3 months ago

Last edited 3 months ago by Denis_N (previous) (diff)

in reply to:  1 ; comment:3 by Denis_N, 3 months ago

Добрый день, Алексей)

Благодарю за вопрос

Дело в том, что я хочу перенести функционал и-са "Отгрузка в Заказы", потому что в и-се "Заказы" о заказах представлена более развернутая информация. Там отображено количество изделий не прошедших ОТК, не протестированных, без присвоенных серийных номеров

Вижу пользу в этом так так ->
Человек ответственный за отгрузку заказа видит, что он не может отгрузить потому что, например, 5 плат SW-01 не прошли ОТК, две PD-04 не протестированы, а 1 PLC-MV без серийного номера. И этот человек подходит к начальнику ПТО и говорит, что он не может отгрузить из-за вышеперечисленных причин. Считаю, что это дает плюсы в восприятии базы. Плюс есть чувство, что за счет этого другой сотрудник будет более вовлечен (как бы выразиться) в жизнь заказа, и что может лучше взаимодействовать с начальником ПТО

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

Last edited 3 months ago by Denis_N (previous) (diff)

in reply to:  3 comment:4 by alx, 3 months ago

Replying to Denis_N:

Дело в том, что я хочу перенести функционал и-са "Отгрузка в Заказы",

А, так ты хочешь вообще ликвидировать интерфейс "Отгрузка"?

потому что в и-се "Заказы" о заказах представлена более развернутая информация. Там отображено количество изделий не прошедших ОТК, не протестированных, без присвоенных серийных номеров

Не вижу в этом улучшения. Зачем вся перечисленная информация человеку, выполняющему отгрузку? На первый взгляд, ему нужно только знать, что надо отгрузить и куда/кому это надо отгрузить...

Вижу пользу в этом так так ->
Человек ответственный за отгрузку заказа видит, что он не может отгрузить потому что, например, 5 плат SW-01 не прошли ОТК, две PD-04 не протестированы, а 1 PLC-MV без серийного номера.

Не понимаю, какая польза от того, что сотрудник, занимающийся отгрузкой, видит то, что ему не надо (что он не может отгрузить). Зачем ему видеть заказ, не готовый к отгрузке? Если заказ не готов к отгрузке, значит им пока еще занимаются сотрудники ПТО - они и должны его видеть. Но, насколько я понимаю, они его и так видят, так как пользуются интерфейсом "Заказы".

Мне казалось, что сотрудник, занимающийся отгрузкой, должен видеть заказы в следующих состояниях:

  • готов к отгрузке;
  • отгружается;
  • отгружен.

Ты не согласен?

И этот человек подходит к начальнику ПТО и говорит, что он не может отгрузить из-за вышеперечисленных причин.

??? Зачем ему это делать (подходить и говорить)? :) Начальник ПТО как раз пользуется интерфейсом "Заказы", и поэтому сам видит, какие заказы могут, а какие не могут быть отгружены. По моему другой сотрудник, который бы ходил и устно информировал об этом начальника ПТО, не нужен...

Считаю, что это дает плюсы в восприятии базы. Плюс есть чувство, что за счет этого другой сотрудник будет более вовлечен (как бы выразиться) в жизнь заказа, и что может лучше взаимодействовать с начальником ПТО

Зачем ему взаимодействовать с начальником ПТО? Какая от этого польза? Лично я вижу только вред - вместо того чтобы выполнять свои прямые обязанности (отгружать заказы) он будет ходить к начальнику ПТО и говорить с ним... :) И как часто он должно это делать (говорить, что такой-то заказ не готов к отгрузке)? Каждый день? Какой в этом смысл, учитывая, что заказ может находиться в неготовом к отгрузке состоянии долго (месяцы)? Искренне не понимаю...

И еще одна причина в том, что интерфейс "Отгрузка" маленький и легко влился бы в заказы. Словно там его место

Это было бы улучшением на этапе проектирования, до реализации интерфейса. Но если интерфейс "Отгрузка" уже реализован, что улучшит его удаление?

В заказах можно создать, изменить, удалить заказ.

Это, конечно, круто. Но зачем сотруднику, занимающемуся отгрузкой заказов, удалять заказы? А зачем ему их изменять или создавать?

Все эти операции совершаются над заказом.

Совершаются кем? Сотрудником, выполняющим отгрузку? :) Нет ведь! Создает заказы, например, начальник ПТО.

Так почему "отгрузить" находиться отдельно?

Это вопрос к тебе - разработчик-то ты. :)

А почему, например, ты сделал отдельно интерфейс "Тестирование"? А интерфейс "ОТК"? А "Несоответствия"? :)

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

Этот аргумент я вообще не понял. Что такое "косвенное дублирование"? Почему косвенное дублирование - это хорошо? Например, "прямое" дублирование информаици в БД обычно считается недостатком. БД нормализуют, в числе прочего, чтобы устранить дублирование...

comment:5 by san, 3 months ago

  1. При отгрузке отгружающий ещё проверяет правильность заказа в базе (т.е. то что продали по бух. документам с тем что записано в базе и с тем что написано на коробках)
  2. Может возникнуть ситуация, допустим по ошибке, когда отгружаемый заказ готов к отгрузке(упакован), но не готов по базе, не все платы прошли ОТК, например, и отгружающему нужно просигнализировать что не так.

Денис считает что эта информация удобнее и нагляднее представлена в интерфейсе Заказы.

Но если интерфейс "Отгрузка" уже реализован, что улучшит его удаление?

Не нужно будет поддерживать ещё один интерфейс. Например в планах развития интерфейса было добавить "заказы на ремонт".

p.s. Это я просто добавил пояснения по итогу устного разговора с Денисом, мотороллер не мой :-).

in reply to:  5 comment:6 by alx, 3 months ago

Replying to san:

  1. При отгрузке отгружающий ещё проверяет правильность заказа в базе (т.е. то что продали по бух. документам с тем что записано в базе и с тем что написано на коробках)

...

Денис считает что эта информация удобнее и нагляднее представлена в интерфейсе Заказы.

Разве в интерфейсе "Заказы" отображаются бухгалтерские документы? Если нет, то я не понимаю, как совмещение интерфейсов "Отгрузка" и "Заказы" поможет выполнению пункта 1. Если да, по не будет ли лучше проводить сопоставление автоматически, без участия человека? Причем не на этапе отгрузки, а в момент появления необхоидмой для сопоставления информации - ведь чем раньше обнаружится ошибка, тем больше времени будет на ее устранение (мне вообще удивительно, что, например, заказ может быть упакован до того, как он сталнет готов к отгрузке - а вдруг потребуется провести какие-то замены?)...

  1. Может возникнуть ситуация, допустим по ошибке, когда отгружаемый заказ готов к отгрузке(упакован), но не готов по базе, не все платы прошли ОТК, например, и отгружающему нужно просигнализировать что не так.

По пункту 2: кто должен ему об этом просигнализировать? Сотрудник ПТО, не так ли? Но сотрудник ПТО и так пользуется интерфейсом "Заказы"! Он обнаружит ошибку, исправит ее - и заказ перейдет в состояние "готов к отгрузке", и станет отображаться в интерфейсе "Отгрузка", чем и просигнализирует отгружающему сотруднику о том, что его можно отгружать! Зачем сигнализировать отгружающему до того как ошибка устранена? Он ведь все равно не сможет приступить к отгрузке, пока ошибку не исправят...

Но если интерфейс "Отгрузка" уже реализован, что улучшит его удаление?

Не нужно будет поддерживать ещё один интерфейс.

Этот аргумент понятен. Но автор тикета такого аргумента не приводил. :)

comment:7 by san, 3 months ago

Зачем сигнализировать отгружающему до того как ошибка устранена

Ты рассуждаешь так как-будто у нас большая компания с чётким распределением ролей)
В реальности "кто-угодно" может быть заинтересован в поиске причины почему заказ "не отгружается".

Разве в интерфейсе "Заказы" отображаются бухгалтерские документы

На коробке написано "Платы SW-01 - 10 шт." в накладной "Платы SW-01 - 10 шт.", в БД - "Платы SW-01 - 10 шт.", отгружающий проверяет совпадают ли данные из этих трёх источников, возможно в каком-то случае и серийный номер нужно проверить. Это я к тому что информация о составе заказа нужна отгружающему.

in reply to:  7 comment:8 by alx, 3 months ago

Replying to san:

Зачем сигнализировать отгружающему до того как ошибка устранена

Ты рассуждаешь так как-будто у нас большая компания с чётким распределением ролей)

Не совсем так. С четким распределением ролей, это да (мне трудно представить, что сотрудник ПТО будет исправлять ошибку в бухгалтерских документах, а сотрудник бухгалтерии - в технологических), но не большая.

В реальности "кто-угодно" может быть заинтересован в поиске причины почему заказ "не отгружается".

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

Во-вторых, ничто не мешает этому "кое-кому" использовать для этого интерфейс "Заказы", когда и если кто-то попросит его исправить возникшую ошибку. Я надеюсь, что подобные ошибки возникают нечасто, являются исключением, а не правилом...

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

Разве в интерфейсе "Заказы" отображаются бухгалтерские документы

На коробке написано "Платы SW-01 - 10 шт." в накладной "Платы SW-01 - 10 шт.", в БД - "Платы SW-01 - 10 шт.", отгружающий проверяет совпадают ли данные из этих трёх источников,

А разве в интерфейсе "Отгрузка" не отображается информация о том, что в данном заказе 10 плат SW-01? Мне кажется, что должна. См. тикет #1251 - я там как раз в общих чертах описал, как по моему представлению должен выглядеть более-менее удобный интерфейс отгрузчика...

возможно в каком-то случае и серийный номер нужно проверить. Это я к тому что информация о составе заказа нужна отгружающему.

Бесспорно - иначе откуда он узнает, что он должен отгрузить? :)

Last edited 3 months ago by alx (previous) (diff)

comment:9 by san, 3 months ago

Бесспорно - иначе откуда он узнает, что он должен отгрузить

В интерфейсе Отгрузка нельзя сейчас посмотреть состав с детализацией до серийных номеров.

Note: See TracTickets for help on using tickets.