1) Сомнительно разделение накладных по разным таблицам. По моей практике - спектр документов намного шире, чем накладная-приход/накладная-расход и заводить под каждый отдельную таблицу, имхо, неправильно. В т.ч. бывают и накладные перемещения товара между складами.
2) Непонятна иерархическая связь товара самого с собой, зачем она?
3) у автозапчастей часто бывает по несколько номеров производителя и несколько оригинальных номеров, для каждого оригинального номера должна быть своя ссылка на производителя.
4) Цены и наценка могут зависеть от склада.
5) применяемость запчасти на автомобили может определяться параметрами в количестве до пары десятков, а не строчкой "модель".
6) Нет связки товар-ответственный менеджер.

DevianArt1. У Товаров поле оригинал - логическое да или нет. Группа товара означает, что это товары одинаковые (оригиналы или аналоги).Если мне память не изменяет, бывают запчасти, которые являются оригиналом для одной машины и аналогом для другой. Особенно с последними веяними по глобализации производства и копирования машин производителями друг у друга. DevianArt2. Ответственный менеджер в фирме один.Наймете второго - будете переписывать базу? DevianArt3. В Позиции накладной сложный ключ из 2х не уникальных полей.
Не так уж редки случаи, когда в накладных от поставщиков позиции дублируются. А в случае партионного учета могут быть даже с разной ценой.

DevianArt miksoftЕсли мне память не изменяет, бывают запчасти, которые являются оригиналом для одной машины и аналогом для другой. Особенно с последними веяними по глобализации производства и копирования машин производителями друг у друга.Выбранное решение: оригинал или нет (вернее номер оригинала) так или иначе пробивается по электронному каталогу (EPC), а во внутренней базе все одинаковые товары лишь группируются с целью подбора любого другого аналога. И если запчасть аналог, то в программе есть номер ее оригинала для построения связей.Не понял, что вы хотите сказать...
Кстати, насчет аналогов учитывайте, что бывают односторонние аналоги, т.е. в машине X запчасть A можно заменить на B, а в машине Y запчасть B нельзя заменить на запчасть A. DevianArt miksoftНаймете второго - будете переписывать базу?Привязку на будущее решил сделать в виде таблицы связывающей менеджера с группой товара и производителем, более детальная формализация этой связи не понадобится и получится переизбыток информации (если связывать ID товара с менеджером, т.к. их будет 1, макс. 2)
Если рост не предполагается, то как хотите... А в крупных фирмах менеджеры чаще специализируются по фирмам-поставщикам, чтобы был один человек, отвечающий за работу с конкретной фирмой. DevianArt miksoftНе так уж редки случаи, когда в накладных от поставщиков позиции дублируются. А в случае партионного учета могут быть даже с разной ценой.В таблице добавил поле время, куда будет записываться время с точностью до миллисекунд, в Mysql это достаточно мелкая величина, что позволит избежать повторений.Я говорил о дублировании позиций внутри одной накладной. Тогда время может быть одинаковым для всех позиций.
Кстати, если мне память не изменяет, то в Mysql нет типа данных для хранения даты/времени с точностью до миллисекунд.
Да оно и не надо в данном случае, тут лучше, имхо, использовать суррогатный PK, тот же автоинкремент.

DevianArtПреподаватель БДЭто курсовик? так бы стразу и сказали... для курсовика масса тонкостей не нужна...

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

DevianArtс программой в дальнейшем будут работать на фирме.Ну а у самой фирмы есть какие-то требования? предметную область-то они должны знать, по идее...

DevianArtА оригиналы которых нет, будут просто добавляться в БД как позиция, чтобы привязать к нему аналоги. Т.к. когда приходит товар-аналог, в накладной или отдельно поставщик указывает номер оригинала и если его нет в базе, то он просто добавляется в БД.Если фирма когда-нибудь хочет вырасти из масштабов ларька, то, имхо, это очень неверный подход.
Потом очень тяжело будет модифицировать структуры данных, если, например, придется загружать данные о применимости из внешних источников, например, из TECDOC-а.
Лучше разделяйте информацию, аналоги и применимость - это одно, а учетная единица товара - это другое.

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