Добрый день всем. Возникла задача спроектировать склад. Склад очень даже простенький. Это внутренний склад предприятия. То есть сюда идут материалы от поставщиков, а раздаются уже по предприятию и никуда больше. Посмотрел как у человека хранится всё на данный момент) ну понимаете амбарная книга. Посмотрел, что там есть, вроде всё что там записано всё учёл в базе. Думал может ещё немного расширить функционал, ни разу склад не делал. Думаю, люди с опытом, что посоветуют дополнительно. Остатки решил хранить так: Таблица DetailNakl(табличная часть)NAKL(это шапка) в ней поле type_2 там будет соответственно храниться (+ или – или r) то есть приход, расход и остатки соответственно. Остатки высчитывать раз в месяц или по требованию пользователя. То есть последний остаток по конкретному товару +\- все записи приходные расходные и соответственно новый остаток высчитать. Расходные документы формировать уже последний остаток и +\- все приходы расходы по товару и решить уже хватит или нет. По инету полазил ничего интересного по складу не нашёл. Думаю есть альтернативные методы хранения остатков. Прошу всех кто сталкивался с такой задачей. Киньте наводку пожалуйста.

http://pixs.ru/showimage/1gif_6444482_178086.gif
30 kb
вот картинка БД, к сообщению не прикрепляется почему то(

Senya_L,
К примеру:пришёл товар.
В шапку(NAKL) записывается id накладной(ID_NAKL), FK(поставщик) ,дата накладной, и сам иднтификатор операции приход(+).
В табличную часть(DetailNakl) идёт id табл.части,FK(ID_NAKL)накладная по которой описывается что именно пришло, FK(материал из справочника), ну и количество по каждому материалу.
тоесть получается одной записи в nakl где описывается когда и от кого пришло соответствует несколько записей в DetailNakl где уже записывается что именно пришло и в каком количестве.

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

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

1) Как Вы собираетесь в 2 таблицы (nakl и detailnakl) собираетесь уложить всю схему движения товара?
2) Как отличить кем является запись из таблицы client: поставщиком или получателем? Справочник вполне может быть один, но как в накладной отличить что было проделано (получение или отпуск) - непонятно.

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

Схема такова
Приходит товар от поставщика “A” шайбы, болты, саморезы.
Делаем приходную накладную
В шапку(nakl) пойдёт запись
Номер наладной
Fk (из таблицы client выбирается наш поставщик)
Дата накладной
И тип операции. приход (+) к примеру.

В табличную часть(detailnakl) пойдёт запись

FK (номер накладной)
FK (Наименование материала.)
Соответственно будет несколько записей С одним номером накладной и разными материалами.
Ну и количество для каждого материала.

То есть получается
Хранится, пришло шайбы столько-то, болты-саморезы столько-то, от такого то поставщика.

Потом решили отдать в цех саморезы и болты.
Делаем расходную накладную

В шапку(nakl) пойдёт запись
Номер наладной
Fk(из таблицы client выбирается подразделение или человек который забирает материал, то есть там хранятся и поставщики и подразделения предприятия так скажем. (Надо тут подумать может разделить.)
Дата накладной
И тип операции. расход (-) к примеру.

В табличную часть(detailnakl) пойдёт запись
FK (номер накладной)
Наименование материала. (для одной накладной несколько строк с разными материалами и количеством)

Всё кончился месяц, пришла пора подсчитать остатки.

Берём последние остатки по заданному товару, плюсуем всё что пришло и вычитаем всё что пришло. Получаем новый остаток. На такую то дату, по такому то товару в таком то количестве. Ну в таблице NAKL будет иметь вид не (+) или (-) а (o) остаток к примеру.

А дальше программа уже работает от последний остаток вычесть(проверим, хватает ли с учётом остатков и с учётом того что пришло по конкретному товару.)

Вот мне это как то так видится.
упрошённо конечно всё.
кстати цена у меняя хранится в справочнике товаров
её наверно надо в detailnakl поместить, она же постоянно меняется.

Хитроглазыйна складе есть товары с ограниченным сроком годности?

не, изначально подразумевается как для авто-транспортного цеха.
По сути нету. склад там небольшой.
колёса, масла, запчасти и всякая фигня хранится.

немного подправил
решил остатки хранить в отдельной таблице.
http://pixs.ru/showimage/2gif_5099732_178887.gif
32кб

http://dl.getdropbox.com/u/833984/BD.gif
30 kb
вот на данный момент такая схема
программу доделал почти.. осталось мелочёвка с отётами разобратся.


подумал тут
что действительно необходимно бы добавить
стелажи или как нить ещё.
склад то один, но там может лежать в разных углах на разных полках. вот думаю как обычно это реализовывают. точнее к моей схеме уже прикрутить.

на данный момент
учитывается приход\расход\списание\ остатки формируются и расчёт идёт уже от остатков + движения от остатков последних.

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

rilioНа вкус и цвет товарища нет, но сугубо личное мнение...
(за последние 15 лет раз 5 приходилось писать похожие склады)

1. Остатки (ost)
Я так понимаю, товар у Вас (судя по схеме) хранится по партиям.
То есть, может быть несколько записей "Саморезы 30x8, 15 р.30 коп." с разными датами поступления?
Это нормальный вариант, но тогда AVG_Coast - не средняя цена, а цена этой конкретной партии. Это так?
А сумма должна вычисляться, а никак не храниться.
PS: а точно Вам нужен партионный учет?


Нет не по партиям
Да может быть несколько поступлений хоть с одной датой хоть с разными.

AVG_Coast, хмм тут начать стоит с того как расчитывается остаток:
Берётся последний остатко по данному товару из таблицы OST смотрим дату время иищём всё из связки таблиц Nakl and DetailNakl тоесть движения.
получается мы хоти что то отдать со склада
проверям
последний остаток по товару + все движения по этому товару за период после пересчёта остатков. если хватает то списываем если нет то списываем сколька можэм.

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

Про то что сумма должна вычилсяться, а не хранится. мне один умный человек подсказал, а почему бы и нет. вот изменилась налоговая ставка. и в случае формирования какого либа отчёта для бухгалтера собсно изменится, сумма по товару уже в закрытом периоде. это не гуд получается. поэтому решил сразу пр ивводе высчитывать сумму и хранить её. от этого хуже не будет. легче выбирать из базы инфу и на запрос меньше нагрузки в случае большой базы. я так думаю.

rilio
2. Material
Материалы всегда и только в одной единице измерения учитываются?
Если так, м.б. я не делал бы даже табличку Edizm, а указывал в Material единицу измерения текстом.
Все равно никаких пересчетов не предвидится.
А вот если в дальнейшем понадобятся пересчеты, я бы добавил Edizm_id в Ost


Нет ед измерения разные
там штука,килограмм,литр,тонна,грамм,центнер, может ещё чё придумают)

rilio
3. Client_out.
Телефон не стоит делать integer. Факс тоже.
Р/счет в integer просто не влезет. Никакой.
Адрес может не влезть в varchar(255) ... [не, наверно влезет...]
Если кор/счет, тогда и БИК.
Если банковские реквизиты, то и ИНН/КПП

поправил спасибо)

rilio
4. Nakl.
Номер документа не понадобится?

nakl это собсно и есть шапка
поле ID_nakl там есть
тоесть уник номер записи.
он собственно и является номером документа
иил вы имеет ввиду
для каждого типа документа нумерация с нуля, тоесть в отдельном поле. и при закрытии периода, можно снова начинать нумираию с нулся к примеру. так я понял?

если да
то это идея в принципе
можно пораскинуть мозгаме
rilio
5. DetailNakl
Опять же, сумма должна вычисляться как цена * кол-во.
Nalog - это у Вас именно налог? В складском учете имеет значение только один - НДС, остальные побоку.
по крайней мере, в приходных/отгрузочных документах налоги не детализируются, только ставка

Ну поле summcc
и есть цена * количество.

Налог ну это налог вдруг ставка НДС изменится или вабще товар налогом не облагается
чтоб могли указать. есть справочник налоги там собсно и могут изменть ставку или ввести какойнить новый налог.
Нужен для расчёта цена с ндс
от туда ставку беру в %
rilio
6."coast" переименуйте в "cost" или "price" или "cena" (так уже, придираюсь по мелочи...)

А стеллажи и полки (места хранения) - ну, добавьте табличку PLACES(ID, NAME) и PLACE_ID в Ost.

coast
плиин с английским тагавато видать))
открыл словарь написал)) ммда
будем думать что очепятка)

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