mr_maxДелаю журнал накладных..
В самой накладной есть дата, и к ней идет спецификация накладной.
А в журнале делать дату. или ее брать из накладной?

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

(Этот топик, пожалуй, больше подходит для форума Проектирование БД)
mr_maxЕсть две таблицы. поступление продукции на склад, и отгрузка. И будут выводиться в разных журналах.Требуется ли создание таблицы, где будет номер накладной и тип документа. Или не создавать?
Если речь идет именно о двух разных видах накладных, я бы предложил вообще другое решение: не разделять приходные и расходные накладные, а вести их в общих таблицах. Нет времени описывать доводы за такой вариант. Поверь, многие через это проходили, плюсов в таком объединении обычно гораздо больше, чем минусов.
Если же рассматривать обобщенно разные типы документов, то тогда да, неплохо бы иметь общую таблицу списка всех документов. При этом рекомендуется всем документам независимо от типа сделать сквозной ID - это значительно упростит в дальнейшем многие задачи.

mr_max
Т.е. внутренню накладную(передача готовой продукции на склад) и накладную на отгрузку все держать в одной таблице?
Это не догма, а лишь вариант. Разумеется, надо вдумчиво рассматривать каждый случай. Очевидно, странно было бы держать в одной таблице, скажем, накладные и платежные поручения (однако это не мешает и им обеспечить сквозную идентификацию через общую таблицу документов). И так же нелогично заводить по таблице под каждуюм минимальную модификацию документа: например расходные и приходные накладные, как упоминалось выше. А вот по внутренним накладным надо смотреть. Они хоть и тоже накладные, но по набору атрибутов заметно отличаются от приходных и расходных. Может быть есть смысл держать их в отдельных таблицах.

mr_maxА может быть потом и проверять наличие на складе товаров
запросом И не нужно таблиц для склада. Так можно?

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

mr_maxт.е.
мне надо щас сделать
таблицу проводки
...
Какие поля нужны в проводке..?

Тут я присоединюсь к совету iscrafm или посоветую поискать в инете - есть неплохие статьи про проектирование складского учета. Или посмотреть, как сделаны другие аналогичные продукты, коих по этой теме великое множество, в том числе и open source.
Для того, чтобы понять, какие поля и вообще какие таблицы нужны - надо анализировать задачу, требования, рисовать концептуальную модель, потом уже проектировать структуру БД.
Если цель - получить систему складского учета для предприятия, то скорее всего еще на этапе анализа задачи с большой вероятностью самым оптимальным решением будет взять готовую систему. Даже, не побоюсь этого слова, 1с достойна рассмотрения
Если цель - поучиться делать системы (и к тому же за счет несчастного работодателя), то путь выспрашивания каждого шага на форуме немножко странный и непродуктивный. Тут очень много надо объяснять. Этим занимаются аналитики и проектировщики, которые стоят достаточно дорого.

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

mr_maxДа это не для коммерции, а для зачота..

mr_max
А где хоть один исходник найти, везде коммерция..

У-у-у! Тогда "НИЗАЧОТ", как пишут некоторые индивиды. За неумение пользоваться методическими материалами и инструментами типа google, yandex.