Работа с заказами

[san]

Интерфейс Заказы.

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

Необходимые фильтры:

• все заказы(фильтры отключены)
• все заказы, кроме отгруженных неделю назад и ранее

Интерфейс Редактирование заказа

• позволяет создать заказ (указывается год/номер заказа)
• позволяет добавить в заказ изделия без серийных номеров указав их имя и задав количество штук
• позволяет заполнить серийные номера для выбранных изделий (с проверкой соответствия имени изделия)

[san]

Комментарий от Дениса:
Выполнение.

Создание таблицы orders:
create table orders (id integer not null UNIQUE,
datetime datetime not null,
deadline date not null,
status enum ('created', 'accept', 'completed', 'verify', 'otk', 'shipped') not null,
recipient varchar (200) not null)
Создание таблицы orders-items:
CREATE TABLE order-items ( order-items - в кавычках, наклонённых влево, иначе при создании будет ошибка
order_id INT(32) NOT NULL,
serial VARCHAR(100),
type VARCHAR(100) NOT NULL,
name VARCHAR(100) NOT NULL,
parent VARCHAR(100),
UNIQUE KEY (order_id,serial),
FOREIGN KEY (order_id) REFERENCES orders (id) ON DELETE CASCADE,
FOREIGN KEY (serial) REFERENCES products (serial) ON DELETE RESTRICT)
mysql> show columns from orders;
+-----------+---------------------------------------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+---------------------------------------------------------------+------+-----+---------+-------+
| id | int | NO | PRI | NULL | |
| datetime | datetime | NO | | NULL | |
| deadline | date | NO | | NULL | |
| status | enum('created','accept','completed','verify','otk','shipped') | NO | | NULL | |
| recipient | varchar(200) | NO | | NULL | |
+-----------+---------------------------------------------------------------+------+-----+---------+-------+

mysql> show columns from order-items;
+----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| order_id | int | NO | MUL | NULL | |
| serial | varchar(100) | YES | MUL | NULL | |
| type | varchar(100) | NO | | NULL | |
| name | varchar(100) | NO | | NULL | |
| parent | varchar(100) | YES | | NULL | |
+----------+--------------+------+-----+---------+-------+

Версия 1.0 интерфейса "Заказы": 40195fb
Права у того, кто создает заказ:"createorder". У того, кто заносит серийные номера: "addserial".
Таблицы order-items и orders необходимо привести к виду, указанному выше.
Не сделано: статус заказа не меняется из других интерфейсов.

[alx]

Replying to san:

CREATE TABLE order-items ( order-items - в кавычках, наклонённых влево, иначе при создании будет ошибка
order_id INT(32) NOT NULL,
serial VARCHAR(100),
type VARCHAR(100) NOT NULL,
name VARCHAR(100) NOT NULL,
parent VARCHAR(100),
UNIQUE KEY (order_id,serial),
FOREIGN KEY (order_id) REFERENCES orders (id) ON DELETE CASCADE,
FOREIGN KEY (serial) REFERENCES products (serial) ON DELETE RESTRICT)

Я обнаружил здесь дублирование информации: поля type и name присутствуют и в таблице order-items, и в таблице products. Так как серийный номер уже однозначно идентифицирует изделие, не лучше ли нормализовать таблицу order-items, удалив из нее столбцы type и name?

Также есть вопрос по поводу столбца parent. Его назначение мне неизвестно, в реальной ДБ он всегда содержит NULL. Если я верно догадался из его названия, что в нем предполагается хранить указание на изделие, в которое входит описываемая строкой позиция (например указание на кассету, в которую установлена заказанная плата), то следовало бы добавить для этого поля FOREIGN KEY для исключения возможности указания несуществующего серийного номера.

[alx]

Replying to alx:

Я обнаружил здесь дублирование информации: поля type и name присутствуют и в таблице order-items, и в таблице products. Так как серийный номер уже однозначно идентифицирует изделие, не лучше ли нормализовать таблицу order-items, удалив из нее столбцы type и name?

Я, кажется, сам понял, в чем тут суть. Когда сотрудник отдела продаж создает заказ, он не может указать никакие серийные номера. Он может указать только наименования и количество изделий. А серийные номера указываются позже, уже на производстве... В таком случае, первое предложение comment:5 снимается.

Непонятен теперь другой момент: каким образом в реальной БД я вижу, что только что созданные заказы (заказы в статусе 'created') уже имеют серийный номера плат (например заказ 2022003)? Каким образом эти номера туда попали, если заказ еще даже не был принят производственным отделом?

[san]

Также есть вопрос по поводу столбца parent. Его назначение мне неизвестно, в реальной ДБ он всегда содержит NULL. Если я верно догадался из его названия, что в нем предполагается хранить указание на изделие, в которое входит описываемая строкой позиция (например указание на кассету, в которую установлена заказанная плата), то следовало бы добавить для этого поля FOREIGN KEY для исключения возможности указания несуществующего серийного номера.

Да, правильно понял. Но пока не понятно кто и когда в реальной жизни будет этот столбец заполнять. С предложением добавить FOREIGN KEY согласен.

Я, кажется, сам понял, в чем тут суть. Когда сотрудник отдела продаж создает заказ, он не может указать никакие серийные номера. Он может указать только наименования и количество изделий. А серийные номера указываются позже, уже на производстве... В таком случае, первое предложение comment:5 снимается.

Суть такая, да. Имя изделия в заказе нужно до тех пор пока не известен его серийный номер(поле тип теперь планируется не использовать в таблицах products и order_items т.к. договорились об уникальности имени изделия и тип всегда можно узнать из list_of_products)

Непонятен теперь другой момент: каким образом в реальной БД я вижу, что только что созданные заказы (заказы в статусе 'created') уже имеют серийный номера плат (например заказ 2022003)? Каким образом эти номера туда попали, если заказ еще даже не был принят производственным отделом?

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

[alx]

Replying to san:

После нажатия =>Если не существует платы в базе:
Записать в products => serial, type = тип , name = имя, location = 'work', owner = 'АДС', date = now(), testing = 'notest'???, otk = 'nocheck', mismatch = 'no', repair = 'no', comment = 'no'.
Записать в history => uid (из products), type_write = 'record', worker, date = now(), order_from = 'stock(склад)', whom_order = work(производство), comment = 'product from stock, add in list of 'ship(продукт со склада, добавлен в лист отправки).

Мне кажется, что так делать неправильно...
Откуда у комплектующего заказ сотрудника может взяться плата, которой нет в БД? Если серийного номера нет в БД, то это значит одно из двух:

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

[san]

Мне кажется, что так делать неправильно...

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

[alx]

Replying to san:

Исходя из реалий план немного изменился, заказ теперь должен создаваться и наполняться серийными номерами в едином интерфейсе(создают и заполняют сотрудники производства),

Как сотрудник отдела производства может создать заказ? Откуда он знает, что хочет купить покупатель? Это может знать только зам директора по маркетингу, так как он принимает запросы покупателей...

Статуса "принят" теперь нет.

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

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

[san]

Отдел маркетинга передаёт заказы на производство другим способом, не через базу.
А на производстве создают заказ в базе.

Статуса "принят" теперь нет.

Вообще-то пока еще есть

Я имел в виду что этот статус больше не используется. Из базы ещё не удалил.

[alx]

Replying to san:

Отдел маркетинга передаёт заказы на производство другим способом, не через базу.

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

[san]

Оставим этот вопрос риторическим)

[san]

Актуализировал задание.