Форум: "Базы";
Текущий архив: 2007.09.30;
Скачать: [xml.tar.bz2];
ВнизТриггеры в master-detail Найти похожие ветки
← →
deras © (2007-05-21 15:36) [0]есть 3 таблицы:
1) Главная T_MAIN
Поля: ID, ID_KONTRAG, ID_SKLAD
2)Подчиненная T_CHILD
Поля: ID, ID_PARENT, KOLVO, CENA, SUMA
T_CHILD.ID_PAREN -> T_MAIN.ID
3) Таблица KUB
Поля: ID, ID_KONTRAG, ID_SKLAD, KOLVO, CENA, SUMA
Как повесить триггеры (After INS/UPD/DEL) на какую-то из T_MAIN или T_CHILD (точно не знаю), чтоб данные попадали в таблицу KUB?
← →
Johnmen © (2007-05-21 15:55) [1]
> Как повесить
Так, как описано в документации.
← →
Sergey13 © (2007-05-21 15:56) [2]> [0] deras © (21.05.07 15:36)
> на какую-то из T_MAIN или T_CHILD (точно не знаю), чтоб
> данные попадали в таблицу KUB?
Из какой таблицы данные, на ту и вешай.
← →
deras © (2007-05-21 16:25) [3]> Из какой таблицы данные, на ту и вешай.
В том -то и дело, что данные из двух таблиц помещаются в одну. Пример:
T_Main: T_CHILD:
1 2 1 1 1 20 8.5 170
2 1 10 6.1 61
3 1 15 10 150
Таблица KUB должна быть заполнена так
1 2 1 20 8.5 170
1 2 1 10 6.1 61
1 2 1 15 10 150
Как такое раелизовать?
← →
Sergey13 © (2007-05-21 16:31) [4]> [3] deras © (21.05.07 16:25)
ну так на T_CHILD однозначно.
← →
deras © (2007-05-21 16:39) [5]>ну так на T_CHILD однозначно.
надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?
Приведите пример для инсерта, пожалуйста
← →
Sergey13 © (2007-05-21 16:49) [6]> [5] deras © (21.05.07 16:39)
> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?
А я откуда знаю, что такм нужно?
> Приведите пример для инсерта, пожалуйстаinsert into KUB (ID, ID_KONTRAG, ID_SKLAD, KOLVO, CENA, SUMA)
select ID, ID_KONTRAG, ID_SKLAD, :new.KOLVO, :new.CENA, :new.SUMA from T_MAIN
where :new.id_parent=T_MAIN.id
Если в полях не запутался, то как то так.
← →
deras © (2007-05-21 17:05) [7]>> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?
>А я откуда знаю, что такм нужно?
Я почему спросил... Как тогда обновлять и удалять? На какое поле ориентироваться?
← →
Desdechado © (2007-05-21 17:16) [8]Вообще не понятно, зачем хранить дубли и то, что можно посчитать на лету?
← →
Jan1 © (2007-05-21 17:22) [9]
> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?
надо. А еще удалить поля ID_KONTRAG, ID_SKLAD - лишние.
← →
Jan1 © (2007-05-21 17:23) [10]
> Вообще не понятно, зачем хранить дубли и то, что можно посчитать
> на лету?
я так понимаю ему для OLAP нада. А это как правило хранят.
← →
deras © (2007-05-21 17:27) [11]>Вообще не понятно, зачем хранить дубли и то, что можно посчитать на лету?
для упрощения создания запросов - чтоб не создавать сложных запросов
← →
deras © (2007-05-21 17:30) [12]>А еще удалить поля ID_KONTRAG, ID_SKLAD - лишние.
Вы имеете ввиду, чтоб стр-ра таблицы KUB была такая?
ID, ID_MAIN, ID_CHILD, ID_PARENT, KOLVO, CENA, SUMA
← →
Jan1 © (2007-05-21 17:36) [13]
> для упрощения создания запросов - чтоб не создавать сложных
> запросов
что значит сложных? тебе зачем таблица KUB?
← →
deras © (2007-05-21 17:53) [14]Это упрощенная модель БД учета складского прихода/расхода
T-MAIN и T_CHILD представляют собой таблицы документов прихода на склад
Еще будут две такие же таблицы для расхода.
Записи по приходу (кол-во и сумма) заносятся в KUB с "+", а по расходу - со знаком "-"
А таблица KUB предназна для организации статистики по разным параметрам. Например: Найти колличество товара с id_sklad=2
select sum(KOLVO) from KUB where id_sklad=2
← →
ANB © (2007-05-21 18:13) [15]
> Это упрощенная модель БД учета складского прихода/расхода
Совершенно бредовая модель.
← →
ANB © (2007-05-21 18:14) [16]ЗЫ. Программисту, задающие такие вопросы, рановато браться за складские программы. ИМХО.
← →
Jan1 (2007-05-21 18:43) [17]
> А таблица KUB предназна для организации статистики по разным
> параметрам. Например: Найти колличество товара с id_sklad=2
> select sum(KOLVO) from KUB where id_sklad=2
учить SQL. И надеюсь это у тебя курсовая а не реальный проект...
← →
Sergey13 © (2007-05-22 08:55) [18]> [14] deras © (21.05.07 17:53)
Ну ты и нагородил! Тебе не с тригерами надо разбираться а с проектированием БД. Серьезно разбираться.
ЗЫ: без всяких наездов и желания обидеть.
← →
deras © (2007-05-22 09:03) [19]>Совершенно бредовая модель.
Предложите лучшую модель. Или дайте ссылку, где почитать
>Программисту, задающие такие вопросы, рановато браться за складские программы
Начинать когда-то надо. Вы тоже когда-то былы на низком уровне знаний. И я попросил совета, а не оценки моего уровня знаний в программировании
← →
deras © (2007-05-22 09:06) [20]>Тебе не с тригерами надо разбираться а с проектированием БД. Серьезно разбираться
согласен... есть ссылки на примерное описание с-ры базы склада?
← →
Sergey13 © (2007-05-22 09:15) [21]> [20] deras © (22.05.07 09:06)
На все то мы ссылки ищем. 8-)
А самому подумать? Тут вобщем то ничего особо сложного нет. Просто
> [11] deras © (21.05.07 17:27)
> для упрощения создания запросов - чтоб не создавать сложных запросов
это не критерий проектирования БД. Это показатель отсутствия теоретических знаний.
Тебе по теории надо почитать/подтянуться. Нормальные формы всякие, непротиворечивость данных и т.п.
← →
deras © (2007-05-22 09:32) [22]>А самому подумать? Тут вобщем то ничего особо сложного нет. Просто
Спасибо на добром слове. Серйозно. А то накинулись тут товарищи на неопытного...
Раз Вы говорите, значит, действительно просто... Но если б кто-то подсказал, подтолкнул т.ск.
В чем ошибка такой стр-ры?
← →
Сергей М. © (2007-05-22 09:48) [23]
> В чем ошибка такой стр-ры?
Основная ошибка - в ничем не обоснованной тобой избыточности информации, имеющей место быть в связи с самим существованием таблицы KUB в том виде, в каком ты ее представил.
← →
Sergey13 © (2007-05-22 09:51) [24]> [22] deras © (22.05.07 09:32)
> Раз Вы говорите, значит, действительно просто...
Я не говорил "просто". Я говорил, "просто твоя боязнь сложных вопросов не являяется критерием проектирования".
Просто/сложно - все относительно. Надо разбираться (или иметь грамотного консультанта/постановщика) в предметной области. Тогда проще становится.
Склад - это классика. Все его делали. Но желательно его сделать самому (не отменяя разумеется чтения по теме).
> В чем ошибка такой стр-ры?
Да во всем. Не надо делить расход-приход по разным таблицам. Не надо сводить несколько таблиц в одну для "облегчения" запросов.
← →
deras © (2007-05-22 10:21) [25]Я понимаю, что нельзя это обсудить в рамках форума, но все же....
>Не надо делить расход-приход по разным таблицам
А если стр-ра таблиц отличается. Например, в расходе надо указывать серийник товара, который в приходе сбсно не нужен (я так думаю)
← →
Сергей М. © (2007-05-22 10:30) [26]
> серийник товара, который в приходе сбсно не нужен
У товара нет "серийника".
Серийный номер - необязательный атрибут изделия. Изделие само по себе не обязано быть товаром. А коль оно у тебя стало товаром, то оно стало им именно на этапе прихода.
← →
Sergey13 © (2007-05-22 10:31) [27]> [25] deras © (22.05.07 10:21)
> я так думаю
Думать - мало. Надо знать на 100%.
Никто не запрещает
1. не заполнять некоторые атрибуты в таблицах
2. создавать отдельные таблицы с атрибутами, необходимыми в отдельных случаях.
Вообще первоначально надо точно определиться с системой учета (партионность, FIFO-LIFO, взвешенные цены и т.п.) и с тем, какие даные ты хочешь иметь на выходе. В какие другие внешние системы твой склад возможно будет встраиваться. И т.д.
ЗЫ: Ты пишешь реальный проект или курсовую?
← →
deras © (2007-05-22 10:49) [28]>Ты пишешь реальный проект или курсовую
Проект. Только не надо издевательств по этому поводу... :-)
Это простая программа учета товара на складе. Надо док-ты:
- приход товара
- перемещение
- списание
- продажа
- инвентаризация
- переоценка
Отчеты:
- доход за период
- обороты (колличественные) товара за период
← →
ANB © (2007-05-22 10:55) [29]
> Это простая программа учета товара на складе.
Простая программа в любом случае вылезет потом в сложную.
Для справки. Стоимость нормальной складской программы порядка 500 килобаксов. Если это реальный проект, то :
1. Ты взялся пока за непосильную задачу. Ее можно решить упрощенно, но лучше пока в качестве тренировки, не выводя задачу на реал.
2. Тебя конкретно обувают с этим заказом.
← →
Сергей М. © (2007-05-22 10:58) [30]
> - доход за период
> - обороты (колличественные) товара за период
Это бухгалтерские отчеты, а не складские.
← →
ANB © (2007-05-22 11:01) [31]
> Это бухгалтерские отчеты
Правильно. А это значит, что придется вести еще и бух.учет на основании документов.
← →
Сергей М. © (2007-05-22 11:03) [32]Правильно. И это опять же говорит либо о полной некомпетенции Заказчика и Подрядчика либо об "обувке".
← →
deras © (2007-05-22 11:04) [33]>Ее можно решить упрощенно, но лучше пока в качестве тренировки
Приблизительно это я и хочу сделать. Но даже для тренировки надо знать КАК энто сделать.
Потому и спрашиваю у знающих людей совета....
← →
Сергей М. © (2007-05-22 11:08) [34]
> deras © (22.05.07 11:04) [33]
Определись для начала с наиболее важными моментами - методы и ценовые политики учета, требуемого к реализации в программе.
Без этого даже начинать не стОит.
← →
Sergey13 © (2007-05-22 11:11) [35]> [28] deras © (22.05.07 10:49)
> Только не надо издевательств по этому поводу... :-)
Никто и не издевается. Просто, я уже говорил, многие писали склады и представляют себе объемы работы.
> - приход товара
> - перемещение
> - списание
> - продажа
> - переоценка
Это все движение товара.
> - продажа
> - доход за период
> - обороты (колличественные) товара за период
Значит уже не просто склад, а склад+магазин? Розница? Опт? И то и это?
Это проект под конкретный магазин или ты хочешь создать нечто универсальное?
Вобщем тебе надо рыть в инете по полной программе, читать, вникать, сравнивать. Спрашивать заказчика о его организации работ - очень дотошно и конкретно. Одно "умолчание о несущественных деталях" грозит полной переработкой проекта, а то и полным провалом.
После подобного исследования уже приступать к проектированию БД.
← →
ANB © (2007-05-22 11:11) [36]
> Потому и спрашиваю у знающих людей совета....
Не, это не здесь надо спрашивать. Когда я писал склад + бухгалтерия в весьма упрощенном виде, со мной сидел главбух и в течение двух месяцев старательно разжевывала основы бух учета и складского учета. А потом я уже взялся за таблицы. Да и получилось только с третьего раза.
Совет - поискать инфу по бух учету и складскому учету. Или сесть с заказчиком (точнее его бухом) и нарисовать все на бумажке.
← →
Sergey13 © (2007-05-22 11:19) [37]> [33] deras © (22.05.07 11:04)
http://www.sql.ru/forum/actualtopics.aspx?bid=36
Вот тут много обсуждений проектировани, в том числе и складов. Так же на сайте есть неплохая библиотека.
← →
deras © (2007-05-22 11:40) [38]понял... Надо учить матчасть.....
Огромное все спасибо!
Может, мое мнение тут ни к чему, но. Очень уважительно отношусь к конструктивным ответам, а не просто типа "читай теорию" или "зайди на sql.ru - там все есть"
З.Ы. Хотел спросить, что имеется ввиду, когда говорите от "обувке"? Что это значить?
← →
Sergey13 © (2007-05-22 12:01) [39]> [38] deras © (22.05.07 11:40)
> а не просто типа "читай теорию" или "зайди на sql.ru - там все есть"
Так говорят то так тоже не просто так. А часто потому, что ответ лежит или на первой странице по F1 (справкой надо пользоваться) или когда ответ предполагает целую лекцию по основам, которые уже описаны в книгах.
В твоем случае - второй вариант. Некоторый базиз должен быть прочитан и понят прежде чем идти сюда (куда либо вообще) и спрашивать про проектирование (кстати ты спрашивал даже не про проектирование, а про реализацию неправильно спроектированного решения - почувствуй разницу). А проектирование вообще штука тонкая и неоднозначная. И коротко на такие вопросы отвечать довольно сложно. При том, что начальных условий ты так до сих пор и не объявил.
← →
deras © (2007-05-22 12:23) [40]>При том, что начальных условий ты так до сих пор и не объявил
Чего ж не объявил? Коротко это звучит как [28]
← →
ANB © (2007-05-22 13:01) [41]
> Чего ж не объявил? Коротко это звучит как [28]
В 28 явно не вся задача. И если так тебе ее поставили, то еще придется потратить время на разработку полного ТЗ.
К тому же не объявлена стартовая сумма :)
Про обувку. Судя по ТЗ тебе пытаются заказать под видом простенькой задачки довольно сложную систему, которую писать придеться с доделками несколько лет. При этом сумма гонорара не увеличится. В конце концов тебе скажут, что ты не можешь сделать элементарную вещь и вообще не заплатят.
← →
Sergey13 © (2007-05-22 13:06) [42]> [40] deras © (22.05.07 12:23)
> Чего ж не объявил? Коротко это звучит как [28]
Ты там перечислил некотыре функции, которые хотел бы реализовать. Условий никаких, кроме как "в расходе надо указывать серийник товара, который в приходе сбсно не нужен (я так думаю)".
← →
deras © (2007-05-22 13:28) [43]>Про обувку. Судя по ТЗ тебе пытаются заказать под видом простенькой >задачки довольно сложную систему, которую писать придеться с >доделками несколько лет. При этом сумма гонорара не увеличится. В конце >концов тебе скажут, что ты не можешь сделать элементарную вещь и >вообще не заплатят.
Я как раз об это и думал... Сума? 100 у.е. предварительно. Город небольшой платежездатность маленькая...
>Ты там перечислил некотыре функции, которые хотел бы реализовать. >Условий никаких, кроме как "в расходе надо указывать серийник товара, >который в приходе сбсно не нужен (я так думаю)".
Это я к примеру про серийник... А какие вообще могут быть условия? Склад - продукты бакалеи. Дело в том, что у меня нет понятия "магазин". просто я обзываю склад конкретным именем (например Магазин "У Васи"). Поэтому приход/расход идет на/из склада. Есть единый справочник складов.
Или так тоже неправильно? Надо отдельно справочник магазинов?
← →
ANB © (2007-05-22 13:54) [44]
> Поэтому приход/расход идет на/из склада
Подумай хотя бы над вопросом - кто будет оформлять списание товара из склада "Магазин У Васи" ? Или остатки не нужны ?
Как будет вестись учет остатков ? Если остатки нужны, то в каком разрезе ? Что делать при изменении цен ? Как будет определяться, какой товар (по какой учетной цене) будет списываться ?
100 у.е. - сравни с ценой, которую я озвучил. Самопальную поделку может в конце концов и поставят и 100 баксов отдадут. Только больше ее никто не возьмет. Если устраивает з/п в 100 баксов за несколько лет работы - берись. :)
← →
Sergey13 © (2007-05-22 13:55) [45]> [43] deras © (22.05.07 13:28)
> Это я к примеру про серийник...
Блин! Это твое "к примеру" коренным образом влияет на систему учета, и следовательно, на структуру БД. Чем больше будет конкретики и меньше "к примеру" тем больше шансов получить конкретные ответы, а не отсылки по адресу.
> Дело в том, что у меня нет понятия "магазин". просто я обзываю склад конкретным именем (например Магазин "У Васи").
Ты или пользуйся общей терминологией или не пользуйся ей вообще. Что ты там как обзываешь - это твое личное дело, хоть дурдом "Солнышко". Просто другие этот твой дурдом ведь не видят. А магазин и склад - это несколько разные вещи. Магазин продает, следовательно делает наценки, получает прибыль. Склад же (в общем случае) ничего не продает - просто получает, хранит и передает.
> Надо отдельно справочник магазинов?
А я знаю, что тебе надо? Ты же как партизан на допросе - все клещами надо тянуть. Может у тебя один склад обслуживает несколько магазинов.
> А какие вообще могут быть условия?
см. [27] Sergey13 © (22.05.07 10:31)
← →
ANB © (2007-05-22 14:06) [46]Так же неплохо бы посмотреть на 1С - торговля+склад. Если не хотят ее ставить, то явно жмотяться. Обычно фирмы, которых 1С не устраивает, представляют себе, что цена разработки на заказ будет еще выше.
← →
deras © (2007-05-22 15:54) [47]Очень благодарю за вопросы ANB © (22.05.07 13:54) [44]
>Как будет вестись учет остатков ?
Остатки вычисляются запросом из таблицы KUB
Т.е. нет таблицы, где хранятся остатки. Вы посоветуете - надо? Какова ее стр-ра (минимально)
>Что делать при изменении цен ?
Имеется ввиду продажных цен? Есть справочник товаров, в котором меняется продажная цена
>Как будет определяться, какой товар (по какой учетной цене) будет списываться ?
Первый пришел, первый ушел (как подсказал мне знакомый бухгалтер)
>А магазин и склад - это несколько разные вещи.
Для клиента это не надо. У него товар приходит сразу на точку (торговый лоток)
← →
Sergey13 © (2007-05-22 16:32) [48]> [47] deras © (22.05.07 15:54)
> Для клиента это не надо.
Надо. Только он не знает об этом. Кроме того - тут сидят не клиенты твоей программы, а люди пытающиеся тебе помочь.
> Первый пришел, первый ушел (как подсказал мне знакомый бухгалтер)
Значит должен быть партионный учет, если твой знакомый имеет отношение к заказчику и не врет. Это важный момент, который должен быть учтен в структуре БД - нужно хранить информацию по партиям.
← →
Сергей М. © (2007-05-22 16:33) [49]
> нет таблицы, где хранятся остатки. Вы посоветуете - надо?
Такая таблица нужна лишь для оперативного мониторинга.
> Какова ее стр-ра (минимально)
- Идентификатор поставки
- Идентификатор склада/торг.точки
- Идентификатор номенклатурной единицы
- Тек.остаток в количественном измерении
← →
Sergey13 © (2007-05-22 16:38) [50]> [49] Сергей М. © (22.05.07 16:33)
> Такая таблица нужна лишь для оперативного мониторинга.
Такая таблица нужна, ИМХО, для улучшения производительности системы.
← →
deras © (2007-05-22 16:42) [51]>> Для клиента это не надо.
>Надо. Только он не знает об этом
Т.е. должен быть справочник складов и отдельно справочник магазинов?
>Значит должен быть партионный учет, если твой знакомый имеет отношение >к заказчику и не врет. Это важный момент, который должен быть учтен в >структуре БД - нужно хранить информацию по партиям.
Можно подробней. Как хранить? Должна быть отдельная таблица с названиями партий? Как организовать партийность?
>Сергей М. © (22.05.07 16:33) [49]
Спасибо, понял...
← →
deras © (2007-05-22 16:46) [52]>Такая таблица нужна, ИМХО, для улучшения производительности системы.
т.е. таблица остатков - это что-то этого?
id, id_tovar, rest
Данные (остатки) в ней меняются тригеррами при приходе/расходе?
← →
Сергей М. © (2007-05-22 16:55) [53]
> Sergey13 © (22.05.07 16:38) [50]
Суть одна - скорость выборки данных о текущих остатках, если таковая критична.
Остатки на произвольную дату, разумеется, разумно расчитывать в динамике по инф-ции о движении. Хотя некоторые (довольно сложные, ориентированные в т.ч. на аналитику) системы в подобных таблицах позволяют хранить "снимки" остатков на заданную дату.
← →
Sergey13 © (2007-05-22 16:57) [54]> [51] deras © (22.05.07 16:42)
> Т.е. должен быть справочник складов и отдельно справочник магазинов?
Да не про это я. Я про то, что сижу за тыщи километров от тебя и не вижу твоих лотков. Но для меня например важно что нужно - склад или магазин. Если для тебя не важно - дело твое.
> [52] deras © (22.05.07 16:46)
> т.е. таблица остатков - это что-то этого?
> id, id_tovar, rest
Не обязательно отдельная таблица. Остаток можно прикрутить и к партии и к справочнику товаров - смотря и как что будет устроено.
> Данные (остатки) в ней меняются тригеррами при приходе/расходе?
Да.
ЗЫ: Все, я в командировке.
← →
DrAndrey © (2007-05-22 16:57) [55]Делал подобную фигню в MS Access 7 лет назад, именно за $100. Но сутуация была проще - склад медикаментов в больнице, там нет никаких переоценок. Все переделки затем касались только отчетов и интерфейса, таблицы без единого изменения (нет убирал "лишние" поля). 3 года назад прилепил к mdb-шнику приложение на Delphi, работает до сих пор, все довольны.
Так, что "не боги горшки обжигают" и если у заказчика действительно очень скромные требования (как в моём случае), то почему бы и нет?
← →
deras © (2007-05-22 17:08) [56]>DrAndrey © (22.05.07 16:57) [55]
Спасибо за поддержку!
Проблемка еще в том, что я не могу оценить степень требований.
← →
Сергей М. © (2007-05-22 17:25) [57]
> не могу оценить степень требований
Если ты уже "подписался" на выполнение заказа и пути к отступлению нет, то теперь уж, говоря строго академическим языком, "поздняк метаться".
В противном случае ты вправе в переговорах с Заказчиком настоять на проведении этапа предварительного двусторонненго согласования деталей проекта, с привлечением заинтересованных спецов со стороны Заказчика, как то
складских работников, менеджеров, коомерч. спец-в, бухгалтеров и т.д.
Цель этапа - разработка ТЗ хоть в сколь-либо детальном документированном виде.
Только опираясь на ТЗ можно начинать реализацию проекта. Отсутствие оного грозит в худшем случае "обувкой" кем-то кого-то (обычно Заказчиком Пордрядчика)
← →
deras © (2007-05-22 17:30) [58]>Сергей М. © (22.05.07 17:25) [57]
А если клиент сам не может толком сформулировать задачу. Тогда не браться за нее?
← →
ANB © (2007-05-22 18:22) [59]
> А если клиент сам не может толком сформулировать задачу.
Тогда ему может помочь сформулировать консалтинговая контора. За пару десятков килобаксов. Всего то.
Можешь и сам взяться за эту работу, если хорошо разбираешься в складском учете.
← →
deras © (2007-05-23 08:59) [60]Здравствуйте, все!
Хотелось бы продолжить тему организации БД складского учета
Вот такой вопрос.
Клиент хочет, чтоб на каждом магазине были разные продажные цены (что есть справедливо). Как организовать такое? В справочнике товаров заводить для каждого склада свою продажную цену?
← →
Jan1 © (2007-05-23 09:00) [61]
> В справочнике товаров заводить для каждого склада свою продажную
> цену?
Таблица развязки: ссылка на магазин, ссылка на товар, цена.
← →
DrAndrey © (2007-05-23 09:08) [62]>Клиент хочет, чтоб на каждом магазине были разные продажные цены
Зачем в справочнике товаров цены?
Укажи email, брошу примерную схему БД.
← →
Сергей М. © (2007-05-23 09:26) [63]
> deras © (23.05.07 08:59) [60]
Номенклатурный справочник должен быть единый на все склады/торг.точки. Никаких цен в нем быть не должно. Вместо этого должен быть отдельный справочник цен, каждая запись в котором однозначно связывает элемент справочника номенклатуры, справочника складов/торг.точек и ценовые характеристики данного товара для данного склада/торг.точки.
← →
deras © (2007-05-23 09:49) [64]>DrAndrey © (23.05.07 09:08) [62]
Cпасибо огромное!
kandriy2004@ukr.net
>Сергей М. © (23.05.07 09:26) [63]
Понял. Так и сделаю
Тогда очень просто решается вопрос с переоценкой! Просто меняется цена продажи для конкретного склада и товара в справочнике цен. Так? ... Супер!
← →
Сергей М. © (2007-05-23 10:04) [65]
> deras © (23.05.07 09:49) [64]
А если копнуть чуть глубже, то всплывает возможность ситуации с разными ценами реализации (ЦР) для разных категорий клиентов-покупателей - обычный покупатель (цена без скидки), постоянный покупатель (скидки такие-то), оптовый покупатель (другие скидки) и пр. и пр. Это сразу наводит на идею хранить в справочнике цен не непосредственно ценовые характеристики, а ссылку на элемент Справочника ценовых шкал, где каждой категории покупателей сопоставлен процент скидки. При таком подходе ЦР вычисляется в динамике на основании коэф-та наценки для конкретного товара на конкретном складе/торг.точке, хранимого в Справочнике цен, и коэф-та скидки для конкретной категории покупателя. Разумеется, в движении товара и остатках при этом должна фигурировать себестоимость товара, а не ЦР.
← →
deras © (2007-05-23 10:27) [66]>Сергей М. © (23.05.07 10:04) [65]
Вот это сила! С организацией цен понял.
Вопрос об отображении движения товара. Нужна ли отдельная таблица, куда заносить все приходы и расходы? Если нет, то как вычислить остаток? Или для остатков нужна своя таблица?
← →
Сергей М. © (2007-05-23 10:38) [67]
> Нужна ли отдельная таблица, куда заносить все приходы и
> расходы?
Да, нужна.
> для остатков нужна своя таблица?
Она не обязательна, но в ряде случаев желательна, а порой и просто необходима.
Если таковая имеется, то каждая запись в этой таблице должна ссылаться на соотв. приходную запись в таблице движения.
В противном случае в таблице движения должно фигурировать поле с информацией о тек.остатке, поле заполняется только для приходных актов движения и обновляется при каждом расходном акте, ссылающемся на данный конкретный приходный акт.
← →
deras © (2007-05-23 10:55) [68]>Да, нужна.
Насколько я понял, все документы по приходу и расходу заносятся в одну таблицу? Приход - со знаком "+", а расход с "-"?
Это удобно?
← →
Сергей М. © (2007-05-23 11:10) [69]
> все документы по приходу и расходу заносятся в одну таблицу?
В подавляющем большинстве реализаций - да.
> Приход - со знаком "+", а расход с "-"?
> Это удобно?
Вряд ли.
Я бы даже сказал, что совсем не удобно.
Крайне желателен еще как минимум один справочник - Справочник товарных операций.
Он связывает тип операции (приход, расход) с видом операции (поставка, возврат поставщику, возврат от покупателя, реализация, внутреннее перемещение, списание и т.д.). Каждый акт движения должен ссылаться на элемент справочника тов.операций.
← →
deras © (2007-05-23 11:44) [70]>Крайне желателен еще как минимум один справочник - Справочник >товарных операций.
>Он связывает тип операции (приход, расход) с видом операции (поставка, >возврат поставщику, возврат от покупателя, реализация, внутреннее >перемещение, списание и т.д.). Каждый акт движения должен ссылаться на >элемент справочника тов.операций.
это у меня есть и так и делаю - в каждом документе есть id операции
>Вряд ли.
>Я бы даже сказал, что совсем не удобно.
Тогда вопрос (хотя он может быть и не связан с Вашим ответом): как показать остатки на складе? Если есть отдельная таблица остатков, то как (при каких операциях) заносить в нее данные?
← →
Сергей М. © (2007-05-23 11:47) [71]
> Если есть отдельная таблица остатков, то как (при каких
> операциях) заносить в нее данные?
Это же очевидно - вставка записей при приходе, а обновление/удаление записи при расходе.
← →
ANB © (2007-05-23 11:57) [72]
> Он связывает тип операции (приход, расход) с видом операции
> (поставка, возврат поставщику, возврат от покупателя, реализация,
> внутреннее перемещение, списание и т.д.). Каждый акт движения
> должен ссылаться на элемент справочника тов.операций.
Не удобно. Вполне достаточно делать двойную запись, как в обычной бухгалтерии - т.е. что, сколько, по какой цене откуда взяли и куда дели.
Тип операции - только для справки. Впрочем, его удобнее хранить в заголовке документа. При такой организации можно быстро выгребать приходы и расходы для каждого объекта.
ЗЫ. Вообще то обычно конторки типа пара складов и несколько магазинов используют систему триторга - т.е. на складах учет количественный (по товарам и ценам), в магазинах - суммовой. Если вести в магазинах количественный учет, то надо ставить кассы со сканнерами штрихкодов, а к этому не все готовы.
← →
deras © (2007-05-23 12:09) [73]Хорошо.
Можно ли давать пользователю редактировать/удалять д-ты прихода/расхода? Если можно, то в каких случаях?
← →
Сергей М. © (2007-05-23 12:18) [74]
> ANB © (23.05.07 11:57) [72]
> Не удобно. Вполне достаточно делать двойную запись, как
> в обычной бухгалтерии
Месить бухучет и торгово-складской учет в одну кучу еще неудобней.
> deras © (23.05.07 12:09) [73]
> Можно ли давать пользователю редактировать/удалять д-ты
> прихода/расхода? Если можно, то в каких случаях?
Можно, в случаях когда пользователь вошел в систему с соответствующей ролью.
Каждая роль определяет права пользователя на осуществление тех или иных технологических операций, в т.ч. проведение/откат/редактирование/удаление тех или иных документов и их видов.
← →
ANB © (2007-05-23 12:28) [75]
> Месить бухучет и торгово-складской учет в одну кучу еще
> неудобней.
В моей бухгалтерии они ведуться параллельно. Т.к. даже несчастная операция закупки превращается минимум в 2 проводки по бухгалтерии.
← →
ANB © (2007-05-23 12:32) [76]
> Месить бухучет и торгово-складской учет в одну кучу еще
> неудобней.
Вот сколько я видел реализаций спец.торгово-складского учета не по правилам бух.учета, таки они все жутко кривые. И работать с ними было неудобно.
← →
deras © (2007-05-23 12:32) [77]При перемещении как определить, с какой приходной ценой перемещается товар?
← →
Сергей М. © (2007-05-23 12:41) [78]
> операция закупки превращается минимум в 2 проводки по бухгалтерии
Это уж самой бухгалтерии решать, сколько и каких проводок должно быть создано в рез-те проведения док-та с тем или иным видом операции.
Задача же разработчика - автоматизировать, если необходимо, процесс генерации/удалении группы необходимых проводок при проведении/откате торгово-складского документа.
Посему ничто не мешает ассоциировать с каждой операцией список из одного или более шаблонов проводок и дать юзерам с бухг.ролями права редактирования этих списков.
← →
ANB © (2007-05-23 12:45) [79]
> deras © (23.05.07 12:32) [77]
я сделал тупо - 2 цены. Одна - по какой забираем, вторая - по какой приходуем. И все сошлось.
Для количественного учета завел :
Таблица объектов учета (склады, магазины и прочее с атрибутами, деревянная для удобства получения отчетов в разных разрезах)
Таблица справочника товаров (тоже деревянная, хотя потом пришел к выводу, что удобнее плоская + деревянная таблица групп)
Таблица остатков, в которой храним чего, сколько, где и по какой цене прямо сейчас валяется (хранил только текущие остатки без промежутков, начальные получал обратным счетом, для периода до года - довольно быстро даже на клиппере).
Таблица документов - тупо заголовки документов чисто для удобства
Таблица движения товаров, подвязанная к документам. Слегка денормализовал, т.е. часть атрибутов (откуда и куда), которые можно было взять из заголовка документа хранил тоже в этой таблице - для скорости построения отчетов.
По минимуму - достаточно. Но только если везде, в том числе и в магазине вести количественный учет (т.е. кассы со сканнерами).
Точные атрибуты каждой таблицы определяются по особенностям учета.
На дорогую складскую систему такая структура не тянет, т.к. там все сложнее намного (учитываются партии, сроки, что где лежит, условия хранения, есть процедуры инвентаризации и прочие полезные вещи).
← →
Сергей М. © (2007-05-23 12:47) [80]
> deras © (23.05.07 12:32) [77]
>
> При перемещении как определить, с какой приходной ценой
> перемещается товар?
Каждая операция перемещения отражается в справочнике движения двумя смежными и логически неотъемлемыми актами - расходным и приходным, ссылающимся на расходный.
Расходный акт в контексте операции перемещения, в свою очередь, ссылается на свой приходный акт, оттуда и берется приходная стоимость. Соотвестствующий приходный акт в контексте данной операции перемещения, естественно, отражает ту же стоимость.
← →
ANB © (2007-05-23 12:47) [81]
> Посему ничто не мешает ассоциировать с каждой операцией
> список из одного или более шаблонов проводок и дать юзерам
> с бухг.ролями права редактирования этих списков.
Дык так и сделано было. Пробовал эти шаблоны анализить на лету уже при построении отчетов (первая версия :) ), получилось хреново и медленно.
Посему на основании шаблонов просто создавал/корректировал/удалял проводки в отдельном слое чисто суммового учета. Получилось удобно.
← →
Сергей М. © (2007-05-23 12:59) [82]
> Посему на основании шаблонов просто создавал/корректировал/удалял
> проводки в отдельном слое чисто суммового учета. Получилось
> удобно
Не спорю, так удобней.
← →
deras © (2007-05-23 13:21) [83]>ANB © (23.05.07 12:45) [79]
Очень полезная (для меня) информация. Спасибо
>Каждая операция перемещения отражается в справочнике движения
Может я чет не понял, но это не та ли таблица KUB, о которой я говорил в вопросе темы (в самом начале)?
← →
Сергей М. © (2007-05-23 13:29) [84]
> то не та ли таблица KUB
Нет, не та.
Та самая KUB - это вообще невесть есть что.
Главный признак, характерный для любого движения - логическая связность последовательностей его отдельных актов. В KUB этим даже не пахнет.
← →
ANB © (2007-05-23 13:34) [85]
> Главный признак, характерный для любого движения - логическая
> связность последовательностей его отдельных актов.
Это если проводка = 2 записи. Если Проводка = 1 запись то она самодостаточна. Я предпочитаю второй вариант.
← →
Сергей М. © (2007-05-23 13:40) [86]
> ANB © (23.05.07 13:34) [85]
Я совсем о другом, и ни проводки ни бухгалтерия здесь вообще ни при чем.
← →
ANB © (2007-05-23 13:43) [87]
> Я совсем о другом
Почему бы операцию перемещения товара не представить в виде "проводки" ? Разница только в том, что вместо суммы и валюты нужно записать код товара, цены и количество. Впрочем в реале и суммовые проводки не ограничиваются только суммой.
← →
Сергей М. © (2007-05-23 13:54) [88]
> ANB © (23.05.07 13:43) [87]
Ты меня не понял.
Если таки речь идет о партионном учете, то расх.акты должны ссылаться на приходные. Я именно об этих связях в Справочнике движения товаров.
Иными словами, справочник движения должен иметь многокорневую древовидную структуру.
← →
ANB © (2007-05-23 14:10) [89]
> Если таки речь идет о партионном учете, то расх.акты должны
> ссылаться на приходные.
А я бы просто подвязал к партии и не мучился. По идее можно смоделировать ситуацию, когда приход по разным документам можно сложить в одну партию. Тогда в цепочке возникнет непонятка.
Впрочем, на уровне частника/мелкой торговой конторы партионный учет обычно нафиг не нужен посему я его с нуля никогда не делал - разве что в готовых системах с ним работал (а там запись о движении и подвязывали к партии).
← →
DrAndrey © (2007-05-23 14:18) [90]>ANB © (23.05.07 12:45) [79]
>На дорогую складскую систему такая структура не тянет, т.к. там все
>сложнее намного (учитываются партии, сроки, что где лежит, условия
>хранения, есть процедуры инвентаризации и прочие полезные вещи).
Реализация описываемой структуры тоже тянет не на 100$.
Учитывая отсутствие ТЗ, неопределенность требований заказчика, отсутствие опыта у разработчика, смешную цену, неопределенную перспективу и т.д. рекомендую автору ориентироваться на максимально простой и дубовый вариант, чисто склад, никаких проводок и бухгалтерии.
Для начала набросай прототип с минимальной функциональностью и продемонстрируй заказчику. После этого многое прояснится. Готовы ли они к внедрению ПО вообще. Обязательно узнай условия эксплуатации: где будет стоять программа, кто с ней будет работать? За такую цену однозначно д/быть однопользовательская. Очень важен уровень подготовки персонала, не берись ликвидировать компьютерную безграмотность. Посмотри кто непосредственно будет сидеть за компьютером.
← →
Сергей М. © (2007-05-23 14:19) [91]
> ANB © (23.05.07 14:10) [89]
> я бы просто подвязал к партии и не мучился
Можно и к партии. Но это, imho, в случае Автора неоправданно усложнит реализацию.
> приход по разным документам можно сложить в одну партию.
> Тогда в цепочке возникнет непонятка
Непонятки не будет, если приходный акт ссылается на партию.
← →
ANB © (2007-05-23 14:21) [92]
> Непонятки не будет, если приходный акт ссылается на партию.
А если приходный акт не один - к которому из них потом подвязывать расход ?
← →
Сергей М. © (2007-05-23 14:26) [93]
> к которому из них потом подвязывать расход ?
>
К удовлетворяющему условиям принципа FIFO/LIFO.
← →
ANB © (2007-05-23 14:33) [94]Первый акт - 100, второй - 80. Расход 120.
Какой должна быть связка ?
← →
Сергей М. © (2007-05-23 14:40) [95]
> Какой должна быть связка ?
>
Два расходных акта: один снимает с первого приходного 100, другой со второго приходного 20.
Оба расх.акта ссылаются на один и тот же расх.документ.
Для бухгалтерии формируются миниму 2 проводки.
Проблемы не вижу.
← →
Сергей М. © (2007-05-23 14:41) [96]
> Первый акт - 100, второй - 80. Расход 120.
При условии, разумеется, что по дате этот расход не ранее обоих приходов ?
← →
Сергей М. © (2007-05-23 14:51) [97]
> ANB
Давай уже не спорить и не выяснять "истину" - оно Автору не на пользу.
Еще раз скажу лишь, что, imho, "движение товара" с т.з. торгово-складского учета, не имеет ничего общего с "оборотам по счетам" с т.з. бухучета, и месить справочник ФХ-операций со справочником движения товаров в одну кучу - тупиковый путь.
← →
deras © (2007-05-23 14:58) [98]>DrAndrey © (23.05.07 14:18) [90]
Учту Ваши предложение
..Помнится Ві обещали пример базу отослать. Жду с нетерпением...
← →
ANB © (2007-05-23 14:59) [99]
> справочник ФХ-операций со справочником движения товаров
> в одну кучу - тупиковый путь.
Не, этож совершенно разные таблицы.
Таки я одного не понял - зачем для одной партии в 180 единиц при расходе в 100 бить расход на 2 записи ?
Когда я писал бухгалтерию одной из проблем было предупредить непомерное разрастание базы. Посему несколько приходов вполне укладывались в одну партию поставки, чтобы потом не вводить слишком много записей о расходе - просто неудобно и база пухнет.
← →
ANB © (2007-05-23 15:00) [100]
> ..Помнится Ві обещали пример базу отослать. Жду с нетерпением.
> ..
:) Вообще то даже рисование примера базы будет стоить больше всего вашего гонорара.
← →
deras © (2007-05-23 15:07) [101]>Вообще то даже рисование примера базы будет стоить больше всего вашего гонорара.
Я не просил, просто по-дружески предложили и я не отказался :-)
← →
Сергей М. © (2007-05-23 15:18) [102]
> ANB © (23.05.07 14:59) [99]
> Таки я одного не понял - зачем для одной партии в 180 единиц
> при расходе в 100 бить расход на 2 записи ?
Партия-то одна, но документов-то по ней два)
А приходные акты движения, imho, логичней связать с приходным документом в полном комплекте документов по поставляемой партии, а не с "общепартийным" документом.
Заметь - отчетным документом в фиск.органы является накладная и счет-фактура, в них никакие "партии" не фигурируют и в помине.
← →
DrAndrey © (2007-05-23 15:28) [103]>Я не просил, просто по-дружески предложили и я не отказался :-)
Да речь шла именно о рисовании примера, лови. Но как и обещал все очень примитивно.
← →
deras © (2007-05-23 16:12) [104]>DrAndrey © (23.05.07 15:28) [103]
Мне пока большего и не надо. Благодарю!
← →
deras © (2007-05-23 17:40) [105]>DrAndrey © (23.05.07 15:28) [103]
Получил Ваше письмо. Надо переосмыслить... Вопросы конечно же будут, если Вы не против отвечать.
← →
DrAndrey © (2007-05-23 17:55) [106]>deras © (23.05.07 17:40) [105]
Не против, но асинхронно и не в форуме, пиши в мыло.
:-)
← →
deras © (2007-05-23 18:10) [107]>DrAndrey © (23.05.07 17:55) [106]
ответил на мыло
Страницы: 1 2 3 вся ветка
Форум: "Базы";
Текущий архив: 2007.09.30;
Скачать: [xml.tar.bz2];
Память: 0.78 MB
Время: 0.057 c