Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Есть небольшая задачка, спроектировать БД для программы учета на складе готовой продукции В общем опыта мало, потому прошу здесь совета. Пока выделил три функции 1) Учитывать приход товаров 2) Учитывать расход товаров с выпиской накладных. 3) Выдавать отчет по остаткам на складе Схему БД пока представляю след образом 1) Таблица PRIHOD с полями ID Дата Номенклатурный_номер Поставщик Кол-во Цена единицы ----------------------------------------------------------------------------------------------------------- 2) Таблица RASHOD c полями ID Дата Номенклатурный_номер Номер накладной Покупатель Кол-во ------------------------------------------------------------------------------------------------------- 3) Справочник товаров SPR_NOMENKLATURA c полями ID Номеклатурный_номер Наименование_товара Примечание ------------------------------------------------------------------------------------------ Нужно выдавать отчет вида Наименование_товара Остаток_на_предыдущий_день Приход Расход Остаток_текущий Возник вопрос с расчетом <Остаток_на_предыдущий_день> по каждому номенклатурному номеру. Я так понимаю что это будет СУММА(Приход)-СУММА(Расход) за весь период учета Т.е. при увеличении числа записей в таблицах прихода и расхода будет увеличиваться время просчета этого остатка. Есть мысль организовать отдельную таблицу остатков, в которую ежедневно заносить остатки по каждому наменклатурному номеру. И затем в отчет уже брать из этой таблицы. Вот интересует насколько это будет правильно. В общем, больно не бить, плиз. Буду признателен за любые советы по реализации и ссылки на проектирование БД для складского учета Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2004, 11:49 |
|
||
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
Будем бить больно ) Первое что надо сделать это поехать на этот склад и посмотреть в реале сколько и какие там операции учитываются ... (или получить наормальное ТЗ от заказчика) я думаю это вас несколько удивит ... и отрезвит ... то что вы написали, максимум где можно применить это в учете домашнего хозяйства ... Так навскидку: 1. Приход (приходование товара) 2. Расход (отгрузка) 3. Списание 4. Возврат поставщику 5. Инвентаризация 6. Внутренние перемещения 7. Комлектация/разукомлектация 8. Фьючерский приход (заявка поставшику) 9. Фючерский расход (заявка покупателя) 10. Возврат от покупателя и т.д и т.п. Вообще посмотрите по форуму (помоему было про организацию складского учета) ну и вообще в инете поищите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2004, 12:25 |
|
||
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
olk прав - дейст явно маловато :) + Справочников тоже мало. На вскидку: Справочник поставщиков Справочник покупателей Дабы не плодить инфу и не напрягать оператора на вбив реквизитов покупателя при повторной отгрузке :) А, вообще, проси ТЗ и пляши уже от него ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2004, 12:45 |
|
||
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
Хорошо бы отвязать документы-основания от материальных транзакций. Хорошо бы материальные транзакции держать в одной таблице. Структура же таблиц для хранения документов-оснований может быть сколь угодно разной. Хорошо бы (во многих отношениях) иметь таблицу с текущими остатками. Теперь по сути вопроса. Предлагаемая схема с сохранением ежедневных остатков - вполне рабочая при определенных условиях (что доказано на практике). С другой стороны, она не является критично необходимой, а иногда может быть и вредной (и это тоже доказано на практике). В самом деле: бывает так, что товар пришел - товар полежал - товар ушел. И больше не придет. Две транзакции, между которыми 30 дней. Сколько записей будет в таблице транзакций? Две. Сколько в таблице ежедневных остатков? Минимум 30. При условии, что нулевые остатки не хранятся. А если сохранять и нулевые остатки каждый день? А если плюс к тому ведется партионный учет? Кстати, добавь в функции 4.Товарный отчет за период. 5. Реестр прихода/расхода за период по типам операций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2004, 13:02 |
|
||
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
Вырисовываются следующая структура: заголовок накладной INVOICE в котором среди прочих будут поля SRC_ID (источник ) DST_ID (получатель). INVOICEPOS (позиции накладной) , который будут связыватья с INVOICE по ключевому полю INVOICE_ID и в которых будет храниться товар, кол-во, стоимость, возможно партия товара Т е приходы и расходы будут храниться вместе. Еще одна таблица -STOREPOS (содержимое хранилищ), в котором будут храниться STORE_ID,товар,кол-во, возможно стоимость и партия Содержимое хранилищ на определенный день будет просчитан как текущее состояние хранилищ минус разность между расходами и приходами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2004, 13:04 |
|
||
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
1.Всех контрагентов в одну таблицу. 2.Все движение в одну таблицу, с указанием вида движения (еще одна таблица-справочник) и партии (если надо). 3.Таблица номенклатурный справочник товаров с текущим остатком . Все. Навороты по вкусу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 10:44 |
|
||
|
Ликбез требуется
|
|||
|---|---|---|---|
|
#18+
А я бы поставил им 1С-Торговлю и не мучился бы. Хотя каждому свое. Если всетаки "руки чешутся" посмотри как там сделано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 10:51 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32531842&tid=1546464]: |
0ms |
get settings: |
6ms |
get forum list: |
17ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
51ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 362ms |

| 0 / 0 |
