Триггеры в master-detail

← →
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]

>Да, нужна.

Насколько я понял, все документы по приходу и расходу заносятся в одну таблицу? Приход - со знаком "+", а расход с "-"?
Это удобно?

> все документы по приходу и расходу заносятся в одну таблицу?

В подавляющем большинстве реализаций - да.

> Приход - со знаком "+", а расход с "-"?
> Это удобно?

Вряд ли.
Я бы даже сказал, что совсем не удобно.

Крайне желателен еще как минимум один справочник - Справочник товарных операций.
Он связывает тип операции (приход, расход) с видом операции (поставка, возврат поставщику, возврат от покупателя, реализация, внутреннее перемещение, списание и т.д.). Каждый акт движения должен ссылаться на элемент справочника тов.операций.

>Крайне желателен еще как минимум один справочник - Справочник >товарных операций.
>Он связывает тип операции (приход, расход) с видом операции (поставка, >возврат поставщику, возврат от покупателя, реализация, внутреннее >перемещение, списание и т.д.). Каждый акт движения должен ссылаться на >элемент справочника тов.операций.

это у меня есть и так и делаю - в каждом документе есть id операции

>Вряд ли.
>Я бы даже сказал, что совсем не удобно.

Тогда вопрос (хотя он может быть и не связан с Вашим ответом): как показать остатки на складе? Если есть отдельная таблица остатков, то как (при каких операциях) заносить в нее данные?

> Если есть отдельная таблица остатков, то как (при каких
> операциях) заносить в нее данные?

Это же очевидно - вставка записей при приходе, а обновление/удаление записи при расходе.

> Он связывает тип операции (приход, расход) с видом операции
> (поставка, возврат поставщику, возврат от покупателя, реализация,
> внутреннее перемещение, списание и т.д.). Каждый акт движения
> должен ссылаться на элемент справочника тов.операций.

Не удобно. Вполне достаточно делать двойную запись, как в обычной бухгалтерии - т.е. что, сколько, по какой цене откуда взяли и куда дели.
Тип операции - только для справки. Впрочем, его удобнее хранить в заголовке документа. При такой организации можно быстро выгребать приходы и расходы для каждого объекта.
ЗЫ. Вообще то обычно конторки типа пара складов и несколько магазинов используют систему триторга - т.е. на складах учет количественный (по товарам и ценам), в магазинах - суммовой. Если вести в магазинах количественный учет, то надо ставить кассы со сканнерами штрихкодов, а к этому не все готовы.

Хорошо.
Можно ли давать пользователю редактировать/удалять д-ты прихода/расхода? Если можно, то в каких случаях?

> ANB © (23.05.07 11:57) [72]

> Не удобно. Вполне достаточно делать двойную запись, как
> в обычной бухгалтерии

Месить бухучет и торгово-складской учет в одну кучу еще неудобней.

> deras © (23.05.07 12:09) [73]

> Можно ли давать пользователю редактировать/удалять д-ты
> прихода/расхода? Если можно, то в каких случаях?

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

> Месить бухучет и торгово-складской учет в одну кучу еще
> неудобней.

В моей бухгалтерии они ведуться параллельно. Т.к. даже несчастная операция закупки превращается минимум в 2 проводки по бухгалтерии.

> Месить бухучет и торгово-складской учет в одну кучу еще
> неудобней.

Вот сколько я видел реализаций спец.торгово-складского учета не по правилам бух.учета, таки они все жутко кривые. И работать с ними было неудобно.

При перемещении как определить, с какой приходной ценой перемещается товар?

> операция закупки превращается минимум в 2 проводки по бухгалтерии

Это уж самой бухгалтерии решать, сколько и каких проводок должно быть создано в рез-те проведения док-та с тем или иным видом операции.

Задача же разработчика - автоматизировать, если необходимо, процесс генерации/удалении группы необходимых проводок при проведении/откате торгово-складского документа.

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

> deras © (23.05.07 12:32) [77]

я сделал тупо - 2 цены. Одна - по какой забираем, вторая - по какой приходуем. И все сошлось.
Для количественного учета завел :
Таблица объектов учета (склады, магазины и прочее с атрибутами, деревянная для удобства получения отчетов в разных разрезах)
Таблица справочника товаров (тоже деревянная, хотя потом пришел к выводу, что удобнее плоская + деревянная таблица групп)
Таблица остатков, в которой храним чего, сколько, где и по какой цене прямо сейчас валяется (хранил только текущие остатки без промежутков, начальные получал обратным счетом, для периода до года - довольно быстро даже на клиппере).
Таблица документов - тупо заголовки документов чисто для удобства
Таблица движения товаров, подвязанная к документам. Слегка денормализовал, т.е. часть атрибутов (откуда и куда), которые можно было взять из заголовка документа хранил тоже в этой таблице - для скорости построения отчетов.
По минимуму - достаточно. Но только если везде, в том числе и в магазине вести количественный учет (т.е. кассы со сканнерами).
Точные атрибуты каждой таблицы определяются по особенностям учета.
На дорогую складскую систему такая структура не тянет, т.к. там все сложнее намного (учитываются партии, сроки, что где лежит, условия хранения, есть процедуры инвентаризации и прочие полезные вещи).

> deras © (23.05.07 12:32) [77]
>
> При перемещении как определить, с какой приходной ценой
> перемещается товар?

Каждая операция перемещения отражается в справочнике движения двумя смежными и логически неотъемлемыми актами - расходным и приходным, ссылающимся на расходный.

Расходный акт в контексте операции перемещения, в свою очередь, ссылается на свой приходный акт, оттуда и берется приходная стоимость. Соотвестствующий приходный акт в контексте данной операции перемещения, естественно, отражает ту же стоимость.

Триггеры в master-detail Найти похожие ветки