В программе сейчас есть таблица заявок. Структура следующая: Дата, Товар, Количество.
Теперь хотят добавить в нее важность заявки. Можно было бы просто добавить новую колонку "Важность".

Но проблема в том, что эта важность во-первых может меняться. То есть сегодня мы решили что важнее купить принтер, а завтра что важнее купить жесткий диск. И нужно хранить установленную важность для заявки на определенную дату. Получается нужно делать отдельную таблицу, которая ссылается на таблицу заявок: ДатаУстановкиВажности, ДатаЗаявки, Товар, Важность.

Во-вторых проблема если заявка на 5 единиц, а нам 3 из них нужно очень срочно, (то есть важность высокая), а 2 - не срочно (важность низкая). Получается нужно как то еще и разбивать по количеству. Ну как по количеству связать две таблицы уж совсем не могу придумать!

Хоть что-нибудь посоветуйте!

модВообще-то заявка - это многострочный документ (типа СФ). Соотв. приоритет можно ставить на каждую строку. В вашем примере 5 штук надо разбить на 3+2 и поставить разные приоритеты. Историю изменений можно хранить отдельно (а можно и не хранить).

Спасибо!
Я так думал сделать, но есть одно но
Заявку мы сделали например неделю назад на 5 дисков, поставили важность среднюю и ждем когда нам привезут, то что мы заказали.
Сегодня у нас вылетел диск, нам срочно его нужно заменить. Не полезем же мы в старую заявку разбивать ее на две строки, изменять приоритет и т.д.
Удобнее было бы как-то сразу указать, что с сегодняшней даты 1 диск нам нужен очень срочно, а остальные - важность не меняется.
Как это можно сделать?

Да в общем-то пока не по каким.

По отделу, например.
Например отделу кадров нужен новый принтер. Мы делаем документ "Заявка", и в нем строка: Отдел кадров, принтер, 1 шт. В принципе можно добавить еще одну строку, например: Бухгалтерия, мышка, 2 шт.

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

ModelR[Посмотрите и с другой стороны: снабженец, закупающий диски уже получил счет от поставщика на 5 дисков и возможно его уже оплатили, а диски в пути и что ему делать?
Возможно вам придется офрмить отдельный заказ на шестой диск.

А как раз и ничего не надо делать. Он видит что по заявке такой то изменилась важность. То есть надо быстрее получить диск. Но диски то уже оплачены и в пути, значит снова заказывать, оплачивать не надо, надо просто поторопить доставку.

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

Как будет выглядеть струткура таблиц в таком варианте?

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

Статус у докумнета вообще менять не надо. Важность заявки - это же не статус. Это просто наше желание получить что-то быстрее, а что-то можно позже. Типа желаемая очередность покупки. Но она не отражает реальную очередность покупок. Реальная очередность может быть отслежена докмунетом например "Выполнение заявки".
Вот.
А важность, которая мне сейчас нужна, - это просто характеристика товара в заявке, по которой снабженец может отсортировтаь все заявки, и увидеть на покупку чего надо направить свои усилия. Это как бы планируемая очередность покупок.
Повторюсь, что реальная очередность покупок меня пока не интересует.

То есть задачу можно переформулировать так: для заявки нужно хранить планируемую важность. Причем эта важность может изменяться. Нужно хранить историю изменения важности. Какую структуру таблиц использовать для хранения этой важности?

модВ строке заявки два поля: id другой заявки и тип замены (оба м.б. null). Если у вас можно сделать заявки однострочными, то структура будет проще.
А какие данные надо записать в таблицы, чтобы отобразить ситуацию с изменением важности:
1. вчера создаем заявку на 5 дисков
2. устанавливаем важность на сегодняшнюю дату к примеру "не очень срочно"
3. завтра решили для 2 дисков установить важность "срочно", а для 3 дисков оставить прежнюю срочность.

В таблице заявок понятное дело будет только одна запись: 6.09.2007 Диск 5 шт.
А что будет в другой таблице?

Владимир П.Надо отделить заявку от заказа -- это два разных документа.

Заявка пусть будет однострочным элементом. Не по структуре "шапка документа--пункты документа", а только пункты. Одна заявка -- одна вещь. В заявке колонка "Важность", возможно, с хранением истории важностей.
Насчет разделения заявки и заказа - согласен.
А про одна заявка - одна вещь - не понял. Если есть заявка на 5 дисков то что? Делать 5 отдельных строк? То есть 5 отдельных заявок? А если нужно сделать заявку на 1000 единиц?

stiЧестно говоря, так и не понял смысла введения вашей "Важности".

Смысл в удобстве работников отдела снабжения и планирования. Есть 1000 заявок в общей сложности на 10000 единиц товаров и на сумму 1.000.000 руб. Купить все сразу невозможно. Возникает вопрос что купить в первую очередь? Распределить покупки по времени например в течение 3 месяцев. Для этого и нужна важность. Работник формирует список всех заявленных товаров , отсортировав его по важности. Потом обсуждает с заявителями (обычно это начальники других отделов) установленную ими важность, возможно ее корректирует, формирует окончательный список. Отбирает верхние например 10 позиций и начинает закупать. Через неделю процесс повторяется.

Вот. Механизм работы такой, а вот структура БД неясна :(

Просматривающий
А может тогда завести в строке заявки планируемый дату поставки? Можно в сочетании с Важностью.

Дополнительное поле дата можно ввести, но ее смысл такой же как и для важности. Чем раньше дата тем важнее. Суть та же, но проблема остается: какую структуру БД сделать для этой даты?

Владимир П.Для удобства в прикладной программе предусмотреть автоматизированное расщепление заявки.

Не-е-е. Заявку расщеплять нельзя. Это документ, он уже сформирован, подписан, и находится в закрытом периоде. Может быть просто сделать доптаблицу, в которой хранить расщепленные заявки? Тогда получается нужно иметь следующие таблицы:

1. Заявки (первоначальный ввод): дата, товар, кол-во
2. Расщепленные заявки: дата, товар, частичное кол-во, важность

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