sti es3000Ну у нас считают что это реально нужно.
Тут уже неоднократно встречался такой совет: пусть тот, кто считает, что это нужно напишет ТЗ. Если напишет, что сомнительно, тогда вы узнаете в каком виде это нужно и сможете начинать проектировать. А пока, перечитайте топик, вам многие говорят, что задача не формализована и проектировать просто рано.

Если ждать ТЗ от простых работников службы снабжения, уж точно в этом ТЗ ничего полезного не будет.
Суть их пожеланий ясна, а детали самим нужно продумывать.
Уже очень много выяснили, осталось совсем чуть-чуть и структура нарисуется сама собой :)

Cane Cat Fisher
Нет, я просто поражаюсь. Как Вы это себе представляете - сначала написать базу данных и программу, а потом пытаться вность туда документы в произвольном виде? Да Вам на второй день принесут такой произвольный вид, что там будут и замены позиций, и отмены заказов, и перемены заявок по отделам... Короче говоря, Вы пытаетесь избежать предпроектного обследования и проектирования задачи, и будете за это строго наказаны.

Необходимо:
1. Пообщаться со ВСЕМИ людьми, участвующими в процессе снабжения - от пользователя-заказчика до поставщика. Собрать образцы ВСЕХ документов, участвующих в процессе. Разумеется, Вы не будете автоматизировать весь процесс сразу. Возможно, Вы никогда не будете автоматизировать процесс полностью. Но даже чтобы автоматизировать малую его часть, исследовать нужно гораздо шире - по крайней мере все смежные аспекты.

2. Из собранных документов выделить недостаточно формализованные. Формализовать, предложить типовые бланки - например, заявка, коррекция заявки. Их графы должны перекликаться с представляемой базой данных. Попробовать заполнить десяток-другой бланков. Понять, где "жмет".

3. Думать о структуре базы данных.

Я конечно согласен. Возразить даже нечего.
Но изначально проблема была просто в изменении важности заявки. Никакой коррекции самой заявки не надо было. А эта мелочь почему-то выросла в коррекцию, отмену.
Может вернемся к важности? И подумаем только над этим?