ПомидорLSVРазбивать на две строки с разным статусом.
Других вариантов и не будет.
Да, логически это первое что напрашивается. Статусов сейчас штук 8. Если позиция будет вот так разбиваться при каждом своем новом статусе (это в самом худшем случае), то в какой то момент состояние изначальной позиции будет выглядеть примерно так:
2 штуки на складе;

1 штука в дороге;

3 штуки доставлен клиенту;

... .
И все это только одна позиция в заявке. То есть система должна сохранить начальный и дальнейшие позиции при разбиение на под позиции.

А вот структура таблиц какой должна быть? У меня мозг отказывается что-то придумать.


Все верно сказано. Позиция в заявке, что кто-то хочет 10 стульев - это хорошо, но это только начало бизнес-процесса. Это лишь зафиксированнное желание.

Жизнь сложнее: на основании заявки будет несколько договоров на поставку (это к тому, что поставщик обязуется поставить 4 сразу а 6 потом). По каждому исполненному договору - приходные накладные, и вот стулья на складе. Потом в подотчет к пользователям, в учет как основные средства (или как малоценка, ее можно учитывать просто как материалы на складе), потом списание... И все на основании той заявки...

Какая часть структуры непонятна?

ПомидорCane Cat FisherВсе верно сказано. Позиция в заявке, что кто-то хочет 10 стульев - это хорошо, но это только начало бизнес-процесса. Это лишь зафиксированнное желание.

Жизнь сложнее: на основании заявки будет несколько договоров на поставку (это к тому, что поставщик обязуется поставить 4 сразу а 6 потом). По каждому исполненному договору - приходные накладные, и вот стулья на складе. Потом в подотчет к пользователям, в учет как основные средства (или как малоценка, ее можно учитывать просто как материалы на складе), потом списание... И все на основании той заявки...

Какая часть структуры непонятна?
Структура таблиц в базе данных. Можете привести пример структур таблиц чтобы сохранялась история перемещения позиций с разбивкой их на более мелкие части в какой то момент и объединением этих мелких частей обратно на большие?

Таблица Заявки(
ЗаявкаID
Номер
Дата
ОтделID)

Заявка № 10 от 01.04.2017 от Отдела кадров

Таблица ДеталиЗаявки(
ДетальЗаявкиID
ЗаявкаID
Товар
Количество)

Стулья, 10 шт

Таблица ДоговораНаПоставку(
ДоговорID
Номер
Дата
ПоставщикID
ПланируемаяДатаПоставки) --при желании можно отсюда убрать, и впихнуть ее в каждую позицию

Договор № 100 от 20.04.2017 с мебельной фабрикой "Рога и Копыта", до 01.10.2017

Таблица ДеталиДоговора(
ДетальДоговораID
ДоговорID
Товар
Количество
)

В одном или нескольких договорах, но будут две позиции:

Стулья, 4 шт, до 01.10.17
Стулья, 6 шт, до 01.11.17

ТаблицаСвязиДеталейПозицийЗаявокИДоговоров(
ДетальДоговораID
ДетальЗаявкиID
)

детали заявок и договоров связаны как N:N, потому что
могут быть ситуации, как описано: из одной позиции заявки будут несколько позиций договоров
с разными сроками (может даже в разных договорах, у разных поставщиков).
А может наоборот: три отдела составили три заявки по 10 стульев каждый,
а снабженцы составили из них один договор, одну позицию договора на 30 стульев сразу.

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

kernACane Cat Fisher,

Помидор Да, логически это первое что напрашивается. Статусов сейчас штук 8. Если позиция будет вот так разбиваться при каждом своем новом статусе (это в самом худшем случае), то в какой то момент состояние изначальной позиции будет выглядеть примерно так:
2 штуки на складе;
1 штука в дороге;
3 штуки доставлен клиенту;
... .
И все это только одна позиция в заявке. То есть система должна сохранить начальный и дальнейшие позиции при разбиение на под позиции.

Как я понял, автору нужно отслеживать фактическое движение товара, а не запланированные поставки по договору

Запланированные поставки он тоже хочет отслеживать, просто утаивает это от нас. Ведь если пользователь написал в заявке 10 стульев, ему же интересно - заказаны они уже у поставщика, или заявка в столе у снабженца застряла.

А что до дальнейшего движения - после приходной накладной будут документы - перемещение в подотчет, затем - списание. Здесь уже позиции повязаны через партию на складе.

И тогда запросом можно получить, то что желает автор: заявлено 10, из них заказано 6 (есть договор), 5 пришло на склад (есть накладная) 1 уже у клиента (есть перемещение в подотчет, самый шустрый прибежал и забрал).

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

ПомидорCane Cat FisherЗапланированные поставки он тоже хочет отслеживать, просто утаивает это от нас. Ведь если пользователь написал в заявке 10 стульев, ему же интересно - заказаны они уже у поставщика, или заявка в столе у снабженца застряла.

Вот список статусов:
Новая - отдел продаж создал заявку на поставку.

На складе - отдел склада помечает то что есть в наличие на складе, указывает нужное количество.

Выход - отдел склада отгружает товар клиенту.

Закупить - отдел склада помечает что надо купить отделу закупок.

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

Доставлено - отдел склада получает товары от поставщика.

Завершено - Когда клиент получил товар.

Отмена - отмена всей заявки, или одного или больше позиции, или частично (количественно) позиции.

Вы все правильно поняли. Чтобы было возможность просмотреть состояние как всей заявки, так и по отдельным позициям и подпозициям.


Насколько я понял, вы не для себя покупаете, а торгуете с клиентами.

Тогда все то что я говорил остается, только убирается перемещение в подотчет и списание, а вместо него появляется расходная накладная - отгрузка клиенту, опять же связанная с позициями заявки.

И по наличию документов запросом легко отслеживается статус каждой позиции.

Если решите, что запросы сложные - можно посадить поле статуса в деталь заявки явном виде, и заполнять триггерами, по мере проведения соответствующих документов. Но это если статусы уже устоялись, а если часто их пересматривать и новые придумывать - замучаетесь сопровождать.