|
|
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
авторБерётся последний остатко по данному товару из таблицы OST смотрим дату время иищём всё из связки таблиц Nakl and DetailNakl тоесть движения. У Вас сейчас расход строго привязан к приходу через Nakl. (Client_in, Client_out) А может ли случиться, что поступило 30 шурупов от поставщика XYZ и 10 шурупов - от ABCD, а выдать надо 35 штук все равно от кого? Если да, то Вам нужно отдельную табличку Приходные_Накладные (или совместить с табличкой Nakl, разделение по флагу - Вам решать) и отдельно Остатки. В Остатках - материал, количество на сегодня (с разбивкой по складам и стеллажам), возможно - средняя (учетная) цена. Никаких дат нет. А в Приходных_Накладных - дата, поставщик, материал, количество, цена и т.д. Если нет, то хранить остатки вообще не нужно. авторсоответственно встала задача ну я хрнаю остаток а вот мне надо списать товар, тоесть ну нето его потерялся, акт списания так сказать. и по какой цене списать) В бухучете РФ, вроде, предусмотрены 4 способа: фифо, лифо, по среднему и ...[блин, не помню... еще какой-то был...] авторПро то что сумма должна вычилсяться, а не хранится. мне один умный человек подсказал, а почему бы и нет. вот изменилась налоговая ставка. и в случае формирования какого либа отчёта для бухгалтера собсно изменится, сумма по товару уже в закрытом периоде Цену хранить, ставку налога хранить, наценки/скидки хранить, а сумму высчитывать... Но это "очень IMHO"... Просто, если Ваша программа напечатает "4 гвоздя по 20 руб., итого 85 р. 50 коп.", могут возникнуть вопросы... авторНет ед измерения разные там штука,килограмм,литр,тонна,грамм,центнер, может ещё чё придумают) Но для гвоздей как определили единицу - центнер, так только в центнерах и учитываем? авторполе ID_nakl там есть тоесть уник номер записи. он собственно и является номером документа А в "бумажных" накладных тот же номер? Если другой, его надо учитывать. автордля каждого типа документа нумерация с нуля, тоесть в отдельном поле. и при закрытии периода, можно снова начинать нумираию с нулся к примеру. так я понял? Ну, строгие требования у нас только к нумерации счетов-фактур и платежек... Но обычно накладные тоже проходят через бухгалтерию, и хотят нумеровать по-своему. авторНалог ну это налог вдруг ставка НДС изменится или вабще товар налогом не облагается чтоб могли указать. есть справочник налоги там собсно и могут изменть ставку или ввести какойнить новый налог. Вы так не шутите... новый налог ввести :) А вообще, в накладных предусмотрено только одно поле для ставки налога. (кстати, посмотрите стандартные формы документов) авторв табличку остатки всё же. я думал при вводе указывать тоесть при заполнений накладной ибо в табличку остатки вабще юзер ничего не пишет, в неё пишут тока запросы котоырй остатки выщитывают. Если разделите Остатки и Приходные_Накладные, то и в Приходных_Накладных, и в Остатках. Обновлять остатки можно хранимой процедурой или триггером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2009, 23:54 |
|
||
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
Senya_LAlexandr2006AVG_Coast, хмм тут начать стоит с того как расчитывается остаток...Тут надо начать с того, что Вы неправильно истолковали, то, что было сказано в ветке FB. :) Кстати, кросс-постинг не приветствуется. Про хранение суммы по товарам в таблице остатков совет был мой. Про хранение среднего - это уже сами нафантазировали. Величина вычисляемая, так что имхо не стОит. Вопрос: каков смысл в столбце DetailNakl.SummCC? Такое ощущение, что Вы решили крепко забить на 1НФ. авторплиин с английским тагавато видать))С русским тоже неважнецки. :( Эта тема появилась до той когда ещё начал проектировать. нее DetailNakl.SummCC хранит сумму товар*количество аа ну да.. блин глаз замылился)) там нет этого поля в Ost. С рууским получше уж час ночи, сижу в темноте, гдето и очепятался)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2009, 23:56 |
|
||
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
> Автор: Alexandr2006 > Эта тема появилась до той > когда ещё начал проектировать. Я отлично помню предысторию. Начали Вы здесь, потом переместились в FB. Расчет остатков обсуждали. У меня до сих пор тестовая БД зарегистрирована в IBExpert'е. > > нее > DetailNakl.SummCC хранит сумму товар*количество > Это к чему, если уже есть количество и цена? Если в таблице это будет вычисляемое поле - это Ваше дело. А если отдельным столбцом данных - за такое надо бить. :) Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2009, 00:08 |
|
||
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
Senya_L > Автор: Alexandr2006 > Эта тема появилась до той > когда ещё начал проектировать. Я отлично помню предысторию. Начали Вы здесь, потом переместились в FB. Расчет остатков обсуждали. У меня до сих пор тестовая БД зарегистрирована в IBExpert'е. ну вот тут собственно советовался по структуре, а там уже когда возникла пролемма с посчётом остатков) Senya_L Это к чему, если уже есть количество и цена? Если в таблице это будет вычисляемое поле - это Ваше дело. А если отдельным столбцом данных - за такое надо бить. :) есть количество и цена. да это отдельный столбец данных. он вычитывается при вводе. ну я же объяснял почему так сделал. --- вот изменилась налоговая ставка. и в случае формирования какого либа отчёта для бухгалтера собсно изменится, сумма по товару уже в закрытом периоде. --- да и думаю может запрос пошустрее прокручиваться будет если он не будет вычислять это поле, а уже брать из таблицы значения. и всё же я совета не понял про стелажи или так скажем место хранения. ну в таблицу Ost добавлю дак таблица Ost формируется динамически так скажем при закрытии месяца. смысла туда добавлять нет. там более сегодня допустим пришло колесо от машины 20 штук положили в одно место, а завтра ещё 10 уже в другое во и думаю как организовать такое. в случае с таблице Ost так не выйдет. Походу придётся писать в detail_nakl тоесть уже грубо при заведени прих.ордера в базу будет указывать где что лежит.. опять же списывается у меня то не по партиям. а просто делается расходка. в след раз расходка делается она уже считает остатки + всё то что пришло от послед остатков - всё что ушло от посл.остатков и выщитывает есть ли ещё на складе материал так что если у меня пришло 10 колёс я их положил на полку А1, а завтра пришло ещё 5 полёс я их положил на полку А2. и после этого спишу 7 колёс, а потом ещё 7, то как кладовщику то узнать с какой полки их брать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2009, 16:10 |
|
||
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
> Автор: Alexandr2006 > > Senya_L > > Это к чему, если уже есть количество и цена? Если в таблице это > будет > вычисляемое поле - это Ваше дело. А если отдельным столбцом > данных - за > такое надо бить. :) > > > есть количество и цена. да это отдельный столбец данных. он > вычитывается при вводе. > ну я же объяснял почему так сделал. > > --- > вот изменилась налоговая ставка. и в случае формирования какого либа > отчёта для бухгалтера собсно изменится, сумма по товару уже в закрытом > периоде. > --- Извините, но повторю: за такую двойную бухгалтерию надо бить. Не дело заплатки такие "лепить". > да и думаю может запрос пошустрее прокручиваться будет > если он не будет вычислять это поле, а уже брать из таблицы значения. Напрасно Вы так думаете. Вычисление произведения - это копейки, по сравнению с дисковым I/O. > > и всё же я совета не понял про стелажи или так скажем место хранения. > ну в таблицу Ost добавлю > дак таблица Ost формируется динамически так скажем при закрытии > месяца. > смысла туда добавлять нет. Таблицу OST не надо трогать. > там более сегодня допустим пришло колесо от машины 20 штук положили в > одно место, а завтра ещё 10 уже в другое > во и думаю как организовать такое. в случае с таблице Ost так не > выйдет. > Походу придётся писать в detail_nakl тоесть уже грубо при заведени > прих.ордера в базу будет указывать где что лежит.. опять же списывается у > меня то не по партиям. а просто делается расходка. в след раз расходка > делается она уже считает > остатки + всё то что пришло от послед остатков - всё что ушло от > посл.остатков и выщитывает есть ли ещё на складе материал > так что если у меня пришло 10 колёс я их положил на полку А1, а > завтра пришло ещё 5 полёс я их положил на полку А2. и после этого спишу 7 > колёс, а потом ещё 7, то как кладовщику то узнать с какой полки их брать. > Сделайте таблицу размещения по полкам. Она же таблица перемещения внутри склада. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2009, 22:59 |
|
||
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
автори всё же я совета не понял про стелажи или так скажем место хранения. Учет по местам хранения всегда нетривиален и очень зависит от того, как это делается в реальной жизни. Когда кладовщик переносит товар на другой стеллаж, он бумажку какую-нибудь подписывает на это? Если да, то все просто - документ называется "накладная перемещения" Если нет... ну, мы доходили до того, что рисовали в масштабе план склада и юзер мышкой двигает партии товара туда-сюда... И все равно, в итоге запутывается :) Если учет не партионный - повторюсь - Вам не надо хранить в Ost даты и цены (только количество, материал, и код места хранения). Все даты и цены вычисляются из документов движения. Приходная накладная говорит только о том, что пришло 800 гвоздей. Далее, на ее основе делается [внутренняя накладная, карточка учета, расписка... названия м.б. разные] документ, где оно разносится по стеллажам. При этом контролируется и номенклатура и количество. 300 гвоздей на первую полку, 300 на вторую, ОК, - ошибка - нам надо разнести ровно 800. Именно этот документ говорит о том, что товар на склад таки принят. При отгрузке тоже может быть так, что сначала отгружаем, потом списываем с конкретных полок. И точно так же - два документа - "бухгалтерский" о ценах и общем количестве, "складской" - с каких полок взято. Между приходом и отгрузкой - "инвентаризация". Документ описывает, сколько чего на какой полке лежит. автордак таблица Ost формируется динамически так скажем при закрытии месяца. Не понял... А актуальные остатки Вам не нужны? При закрытии месяца можно и посчитать все, что требуется... зачем хранить? PS: и все же, не храните сумму. Храните все, из чего она складывается, но 2*2 должно быть 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2009, 00:54 |
|
||
|
Прошу ваши комментарии к БД склад
|
|||
|---|---|---|---|
|
#18+
Всем добрый день. То же занимаюсь проектированием БД склада. Все вроде сделал, но обнаружил ошибку. При выдачи оборудования со склада, переписывается поле "Кол. Выданного". В результате обнаружил, что при приеме товара заполняю, в качестве подчиненной таблицы использую, таблицу "Описание модели". Добавил новую таблицу "Перемещения" в качестве подчиненной таблицы для акта приема. Посмотрите, пожалуйста. Может, что не учел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2012, 14:10 |
|
||
|
|

start [/forum/topic.php?fid=32&startmsg=35923931&tid=1541431]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
36ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 317ms |

| 0 / 0 |
