Сброс флага несоответствия при контроле ОТК

[alx]

В БД изделий АДС в коде otk.php я обнаружил такой фрагмент:

if ($_POST['status'] == 'fail')
    $query = "UPDATE products set `otk` = ?, `mismatch` = 'yes' where `uid` = ?";
else if ($_POST['status'] == 'ok')
    $query = "UPDATE products set `otk` = ?, `mismatch` = 'no' where `uid` = ?";
else
    $query = "UPDATE products set `otk` = ? where `uid` = ?";

Из этого кода следует, что контроль ОТК может устранять несоответствия изделий (см. вторую ветку условия)!!! Как такое возможно?

Моя логика подсказывает, что если изделие имеет какое-то несоответствие, то для устранения этого несоответствия требуется провести ремонт. Разве в обязанности контролера ОТК входит проведение ремонта? Я точно не знаю, но предполагаю, что нет - он только контролирует факт соответствия изделия КД, но ничего не ремонтирует (а если даже ремонтирует - есть интерфейс "Ремонт"). Следовательно, в процессе контроля имеющееся у изделия несоответствие исчезнуть никак не может (может быть только выявлено новое несоответствие). И, следовательно, признак наличия несоответствия не должен сбрасываться при контроле ОТК.

Предлагаю убрать из второй ветки процитированного выше условия , `mismatch` = 'no'`

Более того, было бы логично вообще не допускать до контроля ОТК (выдавать ошибку при вводе S/N такого изделия) изделия, о которых известно, что они имеют несоответствия - зачем тратить время контролера, если изделие заведомо не пройдет контроль ОТК? Предлагаю реализовать такую проверку.

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

Добавил зам. директора по качеству в копию, так как ему тоже, наверное, будет интересно.

[san]

Это не баг а фича, функция называется "мелкий ремонт через ОТК". Т.е. Денис, как исполнитель, сделал всё правильно, по заданию, поэтому заберу тикет себе.

[alx]

Replying to san:

Это не баг а фича, функция называется "мелкий ремонт через ОТК". Т.е. Денис, как исполнитель, сделал всё правильно, по заданию,

Для протокола: я и не утверждал, что Denis_N что-то сделал неправильно, так как не видел задания, по которому он работал. Да и вообще мне не интересно, кто сделал неправильно. Мне интересно, чтобы стало более правильно, чем есть сейчас. :)

Хорошо, мое предположение о том, что контролер ОТК не производит ремонт, оказалось неверным. Но, тогда, если он выполнил ремонт изделия, он ведь должен внести соответствующую запись о ремонте в БД, не так ли? А при добавлении записи об успешном ремонте флаг несоответствия будет сброшен! Таким образом, нет необходимости повторно его сбрасывать при добавлении записи о контроле ОТК.

[san]

Для протокола

Я просто пояснил, почему забрал тикет себе.

[alx]

И, пользуясь случаем, что ты забрал тикет себе, выскажу более общую мысль. Мне вообще не очень нравится существующий механизм с флагом mismatch (даже сами названия столбцов в этой БД вводят в ступор иногда :) ). Этот флаг более-менее выполняет свою функцию, когда в изделии только одно несоответствие. Но когда их сразу несколько, могут возникнуть проблемы...

По логике, этот флаг - агрегированный признак наличия в изделии хотя бы одного несоответствия. Теперь представь, что у изделия выявлено сразу два разных, не связанных друг с другом несоответствия. Тогда работник, устранивший одно из несоответствий, занося запись в БД, должен установить статут ремонта как "неуспешный", что контр-интуиитвно и, главное, не соответствует действительности! А если он по ошибке установит статус ремонта "успешно" (он ведь устранил несоответствие!), то общий флаг несоответствия будет сброшен, несмотря на то, что у изделия осталось еще одно несоответствие. Как результат, изделие с несоответствием могут отгрузить заказчику (если контролер ОТК его не заметит). А если изделие большое и сложное, несоответствий может быть больше двух...

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

В свете предложения comment:5 было бы правильно в "совмещенном" интерфейсе ремонта и контроля ОТК показывать по чекбоксу с полем комментария на каждое из имеющихся в изделии несоответствий. Чтобы контролер мог одним нажатием занести сразу несколько записей о ремонте (плюс запись о контроле ОТК)...

[san]

Чтобы оставить функцию ремонта контролёром Отк(ну удобнее так производству), но устранить озвученные недостатки предлагаю следующее:
Добавить в интерфейс ОТК чекбокс - Ремонт (при открытии интерфейса он должен быть всегда снят).
При наличии несоответствия изделия и попытке записать успешный статус ОТК:

• если чекбокс Ремонт не установлен - отказать в записи и выдать сообщении об ошибке вроде "Статус ОТК не записан. Изделие содержит несоответствие"
• если чекбокс Ремонт установлен, то в историю должны быть сделаны две записи Ремонт=ok, а затем ОТК=pass, а отметка о несоответствии в продуктах должна быть снята. Пользователь обязательно должен заполнить комментарий, который будет размещён в записи Ремонт.

Если записывается Неуспешный статус ОТК, чекбокс Ремонт никак не влияет на запись, наверное логично сделать его неактивным
Уточнение от alx: требуется проверять одновременное наличие у пользователя прав "otk" и "repair". Иначе (если есть только "otk") - показывать "чистый" интерфейс ОКТ (без предложенного дополнения).

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

[alx]

Replying to san:

• если чекбокс Ремонт установлен, при записи отметка о несоответствие должна быть снята, но пользователь обязательно должен заполнить комментарий.

То есть ты предлагаешь совместить интерфейсы "Ремонт" и "Контроль ОТК" на одной странице. Я правильно понял? Чтобы одним запросом делалась и запись о ремонте, и запись о контроле ОТК?

[san]

Ага.
Ах да, нужно же ещё в историю записать, что изделие отремонтировано.. дополню свой комментарий

[san]

Этой гибридной функцией "ремонтируются" изделия которые уже прошли проверку но не прошли ОТК (ОТК обнаружил несоответствие)
И ещё, сюда-же нужно добавить условие, что для изделий которые не прошли проверку, ОТК не может пройти успешно не зависимо от галочки ремонт

[alx]

Replying to san:

Ага.

В таком случае, напомню, что для предложенного объединения требуется проверять одновременное наличие у пользователя прав "otk" и "repair". Иначе (если есть только "otk") - показывать "чистый" интерфейс ОКТ (без предложенного дополнения).

Также дополнил свой comment:4 в свете предложения comment:5.

[san]

В свете предложения comment:5 было бы правильно в "совмещенном" интерфейсе ремонта и контроля ОТК показывать по чекбоксу с полем комментария на каждое из имеющихся в изделии несоответствий. Чтобы контролер мог одним нажатием занести сразу несколько записей о ремонте (плюс запись о контроле ОТК)...

Эта функция сделана по просьбе производства для устранения мелких несоответствий. Когда контролёр ОТК сам обнаружил проблемму - записал, сам устранил - записал сразу с успешным статусом ОТК. Если несоответствий несколько и нельзя их устранить сразу(в одной записи ремонта), то логичнее использовать интерфейс Ремонт.

[alx]

Replying to san:

И ещё, сюда-же нужно добавить условие, что для изделий которые не прошли проверку,

Что ты имеешь в виду? Не тестировалось, или тестировалось с отрицательным результатом? :) Предполагаю, что первое...

ОТК не может пройти успешно не зависимо от галочки ремонт

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

• если изделие, серийный номер которого введен, не тестировалось, выдавать ошибку;
• если изделие тестировалось и имеет несоответствия, и у пользователя нет права "repair", выдавать ошибку.

[alx]

Replying to san:

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

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

[san]

не допускать на контроль ОТК изделия с несоответствиями (которые не сам контролер в процессе контроля обнаружил)

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

Ещё помнится запись несоответствия через интерфейсы Несоответствие и Ремонт, должны приводить к сбросу статуса тестирования в "не тестировалось" а запись несоответствия через ОТК нет, нужно проверить это...

[alx]

Replying to san:

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

Не вижу для этого никаких препятствий.

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

Как странно... Должен устанавливаться статус, не соответствующий действительности... Зачем?

[san]

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

[alx]

Replying to san:

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

А, понятно. Логика, конечно, не бесспорная, но она определенно есть. :)

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

[alx]

Replying to san:

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

А (по аналогии) статус контроля ОТК "успешно" тоже в этом случае должен сбрасываться на "не контролировалось"?

[san]

Replying to san:

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

Это предложение не было реализовано и я думаю и не надо.

По основному вопросу тикета передаю Денису #1173, этот тикет закрываю.

[alx]

Replying to san:

этот тикет закрываю.

Когда закрываешь тикет с резолюцией "дубликат" указывай, пожалуйста, тикет, который был продублирован закрываемым.