Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
 Схема базы данных заявок и позиций со статусом  [new]
Помидор
Member

Откуда:
Сообщений: 12
Есть заявки на закуп, каждая заявка может содержать одну или больше позиций. Каждая позиция содержит поля (номенклатура, количество, цена, статус). Жизненный цикл позиции заявки проходит через 3 отдела (Продажа, Склад, Закуп) в зависимости от некоторых условий. Для каждого статуса позиции есть его следующие статусы, то есть невозможно из некоторого статуса А перейти на статус В минуя статус Б, если это только не предусмотренно каким то условием. Все это разработано, и все это работает на отлично. Все это было в ТЗ.

Сейчас встал вопрос как быть если не все количество что есть в позиции меняет статус. То есть, надо закупить 10 штук стульев. Отдел закупок связались с производителем, они отправляют 4 штуки, остальные 6 штук только после 2 месяцев. Получается надо разбить позицию заявки на две части, первая часть это 4 штук стульев меняют статус на 'в дороге'. Вторая часть 6 штук остается со старым статусом или меняется на подходящий.

Какие есть предложение структуры базы данных чтобы реализовать эту бизнес логику?
14 июн 17, 08:59    [20562382]     Ответить | Цитировать Сообщить модератору
 Re: Схема базы данных заявок и позиций со статусом  [new]
LSV
Member

Откуда: Киев
Сообщений: 30150
Разбивать на две строки с разным статусом.
Других вариантов и не будет.
14 июн 17, 09:17    [20562425]     Ответить | Цитировать Сообщить модератору
 Re: Схема базы данных заявок и позиций со статусом  [new]
Помидор
Member

Откуда:
Сообщений: 12
LSV
Разбивать на две строки с разным статусом.
Других вариантов и не будет.

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

    А вот структура таблиц какой должна быть? У меня мозг отказывается что-то придумать.
  • 14 июн 17, 11:09    [20562858]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    mad_nazgul
    Member

    Откуда:
    Сообщений: 4233
    Помидор
    LSV
    Разбивать на две строки с разным статусом.
    Других вариантов и не будет.

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

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

  • С точки зрения "заявки" она не выполнена и будет выполнена только когда прибудут все 10 стульев.
    Соответственно данная заявка будет находится в состоянии не выполнено.
    Далее.
    При отправке создается ТТН. (состояние открыта/закрыта)
    На складе акт прием передачи (от поставщика на склад, со склада к клиенту)

    Т.е. каждое изменение статуса стула должно быть подтверждено документами.

    Т.о. ваша задача к изменению каждого статуса привязать соответствующие документы.
    Ну а документы имеют определенную структуру.
    Которая в первом приближении будет таблица (в процессе нормализации их конечно будет больше)
    Но как минимум это послужит основой сущностей.
    14 июн 17, 13:58    [20563659]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Cane Cat Fisher
    Member

    Откуда:
    Сообщений: 1478
    Помидор
    LSV
    Разбивать на две строки с разным статусом.
    Других вариантов и не будет.

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

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


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

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

    Какая часть структуры непонятна?
    14 июн 17, 15:57    [20564209]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Помидор
    Member

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

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

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

    Структура таблиц в базе данных. Можете привести пример структур таблиц чтобы сохранялась история перемещения позиций с разбивкой их на более мелкие части в какой то момент и объединением этих мелких частей обратно на большие?
    14 июн 17, 21:21    [20565121]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    vmag
    Member

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


    Помидор
    будет выглядеть примерно так:
  • 2 штуки на складе;
  • 1 штука в дороге;
  • 3 штуки доставлен клиенту;


  • так экспромт... дробить это Ж..., хотя и напрашивается первым, а если вдруг потом опять 6 стульев дробить... ?
    можно попробовать на позицию держать несколько полей вместо одного количества:
    - Заказано
    - На складе
    - В дороге
    - Доставлено
    ... может еще чего (но лбом об пол до упаду не надо)...
    Естественно, меняются все цифры в динамике и контролируются периодически по простейшим формулам...
    Преимущества - что и где за один заход...
    Дополнительно на позицию придумать и повесить таблицу типа "История", чтоб если че - как говорится "Все ходы записаны"...
    14 июн 17, 22:15    [20565220]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Помидор
    Member

    Откуда:
    Сообщений: 12
    vmag
    так экспромт... дробить это Ж..., хотя и напрашивается первым, а если вдруг потом опять 6 стульев дробить... ?

    Так и есть, позиция может дробиться при каждом своем новом статусе, каждая раздробленная новая подпозиция живет своей жизнью.
    1. Отдел продаж - клиент прости 10 стульев.
    2. Отдел склада - есть 4 стулья на складе, появляется новая подпозиция со статусом на складе, для остальных создается подпозиция 6 стульев закупить.
    3. Отдел закупок - 2 стулья может доставить этот дистрибьютор, 4 стулья доставит сам производитель, таким образом появляется еще две подпозиции на подпозицию 6 стульев.
    Ну и так далее.
    При этом надо всегда знать например складу какие именно стулья для какого клиента предназначены, чтобы стулья для какого то срочного клиента не выдали шустрому агенты продаж.
    15 июн 17, 04:57    [20565480]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    LSV
    Member

    Откуда: Киев
    Сообщений: 30150
    попробовать на позицию держать несколько полей вместо одного количества:
    - Заказано
    - На складе
    - В дороге
    - Доставлено
    Плохое решение. Вдруг понадобится иметь подробную инфу по каждому пункту, н-р в дороге - понятие растяжимое: могут доставить 3 стула завтра, а остальные через 3 дня.
    15 июн 17, 09:37    [20565729]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    kernA
    Member

    Откуда: Санкт-Петербург
    Сообщений: 246
    Помидор,

    по логике, добавить состояние для каждого элемента(стул) заказа и отслеживать по отдельности.
    В зависимости от наименьшего состояния элемента будет определяться статус заявки.
    15 июн 17, 09:43    [20565748]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Кот Матроскин
    Member

    Откуда: Москва
    Сообщений: 7688
    Cane Cat Fisher же все правильно описал - нужно делать дополнительные сущности.

    Заявка - Складской резерв (1..N)
    Заявка - Накладные на закупку (1..N)
    ...
    (Можно при этом из заявок, накладных и т.п. выделить супертип "документ", и связи делать между абстрактными документами - но это сложнее)
    Количество в самой заявке не меняется (разве что клиент сам передумает "мне не нужно 10, мне нужно 12!"), изменяется количество и состав привязанных к заявке документов. У каждого документа свой жизненный цикл (скажем, "накладная на закупку" тоже породит "складской резерв", когда товар реально будет закуплен и принят на склад).
    15 июн 17, 09:49    [20565761]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Cane Cat Fisher
    Member

    Откуда:
    Сообщений: 1478
    Помидор
    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 стульев сразу.

    Дальше идут приходные накладные, там все аналогично, суть в том, что позиции накладной связаны с позициями договора.
    15 июн 17, 10:28    [20565859]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    kernA
    Member

    Откуда: Санкт-Петербург
    Сообщений: 246
    Cane Cat Fisher,

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


    Как я понял, автору нужно отслеживать фактическое движение товара, а не запланированные поставки по договору
    15 июн 17, 10:39    [20565895]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Cane Cat Fisher
    Member

    Откуда:
    Сообщений: 1478
    kernA
    Cane Cat Fisher,

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


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


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

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

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

    Единственное, что я не уверен - каким документом лучше зафиксировать, что товар "в дороге". Как это у них построено сейчас? В крайнем случае, можно псевдодокумент сделать - "Сведения об отгрузке в путь".
    15 июн 17, 10:57    [20565978]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    LSV
    Member

    Откуда: Киев
    Сообщений: 30150
    kernA
    Как я понял, автору нужно отслеживать фактическое движение товара, а не запланированные поставки по договору
    Движение обычно происходит в разрезе договора и возможно - заявки. Договоров может быть несколько на один и тот же товар.
    В случае любого спора с поставщиком всегда нужно знать структуру спора: по какому договору/заявке/счету условия не выполнены.
    15 июн 17, 11:00    [20565995]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    kernA
    Member

    Откуда: Санкт-Петербург
    Сообщений: 246
    [quot Cane Cat Fisher]
    kernA
    Cane Cat Fisher,

    пропущено...


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


    Перемещение я вижу себе так:

    таблицу с описанием товара
    (ТоварTypeID,
    Марка,
    ТТХ
    );

    Таблица товаров
    (ТоварID,
    СерийныйНомер
    )

    Таблица Cостояний - (склад, перемещается, доставлен)
    (СостояниеID,
    ОписаниеСостояние)

    Таблица Cостояний Товара
    (ТоварID,
    СостояниеID
    )
    15 июн 17, 11:32    [20566132]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Помидор
    Member

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

    Вот список статусов:
  • Новая - отдел продаж создал заявку на поставку.
  • На складе - отдел склада помечает то что есть в наличие на складе, указывает нужное количество.
  • Выход - отдел склада отгружает товар клиенту.
  • Закупить - отдел склада помечает что надо купить отделу закупок.
  • В пути - отдел закупок договаривается с поставщиками, и отмечает какие товары уже в пути к ним.
  • Доставлено - отдел склада получает товары от поставщика.
  • Завершено - Когда клиент получил товар.
  • Отмена - отмена всей заявки, или одного или больше позиции, или частично (количественно) позиции.

    Вы все правильно поняли. Чтобы было возможность просмотреть состояние как всей заявки, так и по отдельным позициям и подпозициям.
  • 15 июн 17, 12:41    [20566489]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Помидор
    Member

    Откуда:
    Сообщений: 12
    kernA
    Помидор,

    по логике, добавить состояние для каждого элемента(стул) заказа и отслеживать по отдельности.
    В зависимости от наименьшего состояния элемента будет определяться статус заявки.

    Да, так произойдет наихудшем случае, но изначально вот так следить за каждым элементов в позиции это лишняя работа. Не проблема когда 3 штуки, но это большая проблема уже при большем количестве.
    15 июн 17, 12:45    [20566507]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    kernA
    Member

    Откуда: Санкт-Петербург
    Сообщений: 246
    Помидор
    kernA
    Помидор,

    по логике, добавить состояние для каждого элемента(стул) заказа и отслеживать по отдельности.
    В зависимости от наименьшего состояния элемента будет определяться статус заявки.

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


    Вы же понимаете, если делать учёт по операциям, то набор товаров в процессе движения будет меняться- что то повредится при перевозке, что то останется на складе, что то неотгруженным. При составлении рекламации придётся указывать позиции повреждённых товаров и тп.
    15 июн 17, 14:56    [20567189]     Ответить | Цитировать Сообщить модератору
     Re: Схема базы данных заявок и позиций со статусом  [new]
    Cane Cat Fisher
    Member

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

    Вот список статусов:
  • Новая - отдел продаж создал заявку на поставку.
  • На складе - отдел склада помечает то что есть в наличие на складе, указывает нужное количество.
  • Выход - отдел склада отгружает товар клиенту.
  • Закупить - отдел склада помечает что надо купить отделу закупок.
  • В пути - отдел закупок договаривается с поставщиками, и отмечает какие товары уже в пути к ним.
  • Доставлено - отдел склада получает товары от поставщика.
  • Завершено - Когда клиент получил товар.
  • Отмена - отмена всей заявки, или одного или больше позиции, или частично (количественно) позиции.

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


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

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

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

    Если решите, что запросы сложные - можно посадить поле статуса в деталь заявки явном виде, и заполнять триггерами, по мере проведения соответствующих документов. Но это если статусы уже устоялись, а если часто их пересматривать и новые придумывать - замучаетесь сопровождать.
    15 июн 17, 15:57    [20567494]     Ответить | Цитировать Сообщить модератору
    Все форумы / Проектирование БД Ответить