Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Триггеры в master-detail [IB6.x]

Страницы: < 1 2 3 4 5 6 >
deras © (2007-05-21 15:36:00)
есть 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?

Сергей М. (2007-05-23 10:38:00) [41]

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

Да, нужна.

> для остатков нужна своя таблица?

Она не обязательна, но в ряде случаев желательна, а порой и просто необходима.

Если таковая имеется, то каждая запись в этой таблице должна ссылаться на соотв. приходнуюзапись в таблице движения.

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

deras (2007-05-23 10:27:00) [42]
>Сергей М. © (23.05.07 10:04) [65]
Вот это сила! С организацией цен понял.

Вопрос об отображении движения товара. Нужна ли отдельная таблица, куда заносить все приходы и расходы? Если нет, то как вычислить остаток? Или для остатков нужна своя таблица?

Сергей М. (2007-05-23 10:04:00) [43]

> deras © (23.05.07 09:49) [64]

А если копнуть чуть глубже, то всплывает возможность ситуации с разными ценами реализации (ЦР) для разных категорий клиентов-покупателей - обычный покупатель (цена без скидки), постоянный покупатель (скидки такие-то), оптовый покупатель (другие скидки) и пр. и пр. Это сразу наводит на идею хранить в справочнике цен не непосредственно ценовые характеристики, а ссылку на элемент Справочника ценовых шкал, где каждой категории покупателей сопоставлен процент скидки. При таком подходе ЦР вычисляется в динамике на основании коэф-та наценки для конкретного товара на конкретном складе/торг.точке, хранимого в Справочнике цен, и коэф-та скидки для конкретной категории покупателя. Разумеется, в движении товара и остатках при этом должна фигурировать себестоимость товара, а не ЦР.

deras (2007-05-23 09:49:00) [44]
>DrAndrey © (23.05.07 09:08) [62]
Cпасибо огромное!
kandriy2004@ukr.net

>Сергей М. © (23.05.07 09:26) [63]
Понял. Так и сделаю
Тогда очень просто решается вопрос с переоценкой! Просто меняется цена продажи для конкретного склада и товара в справочнике цен. Так? ... Супер!

Сергей М. (2007-05-23 09:26:00) [45]

> deras © (23.05.07 08:59) [60]

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

DrAndrey (2007-05-23 09:08:00) [46]
>Клиент хочет, чтоб на каждом магазине были разные продажные цены

Зачем в справочнике товаров цены?
Укажи email, брошу примерную схему БД.

Jan1 (2007-05-23 09:00:00) [47]

> В справочнике товаров заводить для каждого склада свою продажную
> цену?

Таблица развязки: ссылка на магазин, ссылка на товар, цена.

deras (2007-05-23 08:59:00) [48]
Здравствуйте, все!

Хотелось бы продолжить тему организации БД складского учета

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

ANB (2007-05-22 18:22:00) [49]

> А если клиент сам не может толком сформулировать задачу.

Тогда ему может помочь сформулировать консалтинговая контора. За пару десятков килобаксов. Всего то.
Можешь и сам взяться за эту работу, если хорошо разбираешься в складском учете.

deras (2007-05-22 17:30:00) [50]
>Сергей М. © (22.05.07 17:25) [57]

А если клиент сам не может толком сформулировать задачу. Тогда не браться за нее?

Сергей М. (2007-05-22 17:25:00) [51]

> не могу оценить степень требований

Если ты уже "подписался" на выполнение заказа и пути к отступлению нет, то теперь уж, говоря строго академическим языком, "поздняк метаться".

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

deras (2007-05-22 17:08:00) [52]
>DrAndrey © (22.05.07 16:57) [55]

Спасибо за поддержку!

Проблемка еще в том, что я не могу оценить степень требований.

Sergey13 (2007-05-22 16:57:00) [53]
> [51] deras © (22.05.07 16:42)
> Т.е. должен быть справочник складов и отдельно справочник магазинов?
Да не про это я. Я про то, что сижу за тыщи километров от тебя и не вижу твоих лотков. Но для меня например важно что нужно - склад или магазин. Если для тебя не важно - дело твое.

> [52] deras © (22.05.07 16:46)

> т.е. таблица остатков - это что-то этого?
> id, id_tovar, rest
Не обязательно отдельная таблица. Остаток можно прикрутить и к партии и к справочнику товаров - смотря и как что будет устроено.

> Данные (остатки) в ней меняются тригеррами при приходе/расходе?
Да.

ЗЫ: Все, я в командировке.

DrAndrey (2007-05-22 16:57:00) [54]
Делал подобную фигню в MS Access 7 лет назад, именно за $100. Но сутуация была проще - склад медикаментов в больнице, там нет никаких переоценок. Все переделки затем касались только отчетов и интерфейса, таблицы без единого изменения (нет убирал "лишние" поля). 3 года назад прилепил к mdb-шнику приложение на Delphi, работает до сих пор, все довольны.
Так, что "не боги горшки обжигают" и если у заказчика действительно очень скромные требования(как в моём случае), то почему бы и нет?

Сергей М. (2007-05-22 16:55:00) [55]

> Sergey13 © (22.05.07 16:38) [50]

Суть одна - скорость выборки данных о текущихостатках, если таковая критична.

Остатки на произвольную дату, разумеется, разумно расчитывать в динамике по инф-ции о движении. Хотя некоторые (довольно сложные, ориентированные в т.ч. на аналитику) системы в подобных таблицах позволяют хранить "снимки" остатков на заданную дату.

deras (2007-05-22 16:46:00) [56]
>Такая таблица нужна, ИМХО, для улучшения производительности системы.

т.е. таблица остатков - это что-то этого?
id, id_tovar, rest

Данные (остатки) в ней меняются тригеррами при приходе/расходе?

deras (2007-05-22 16:42:00) [57]
>> Для клиента это не надо.
>Надо. Только он не знает об этом

Т.е. должен быть справочник складов и отдельно справочник магазинов?

>Значит должен быть партионный учет, если твой знакомый имеет отношение >к заказчику и не врет. Это важный момент, который должен быть учтен в >структуре БД - нужно хранить информацию по партиям.

Можно подробней. Как хранить? Должна быть отдельная таблица с названиями партий? Как организовать партийность?

>Сергей М. © (22.05.07 16:33) [49]
Спасибо, понял...

Sergey13 (2007-05-22 16:38:00) [58]
> [49] Сергей М. © (22.05.07 16:33)
> Такая таблица нужна лишь для оперативного мониторинга.

Такая таблица нужна, ИМХО, для улучшения производительности системы.

Сергей М. (2007-05-22 16:33:00) [59]

> нет таблицы, где хранятся остатки. Вы посоветуете - надо?

Такая таблица нужна лишь для оперативногомониторинга.

> Какова ее стр-ра (минимально)

- Идентификатор поставки
- Идентификатор склада/торг.точки
- Идентификатор номенклатурной единицы
- Тек.остаток в количественном измерении

Sergey13 (2007-05-22 16:32:00) [60]
> [47] deras © (22.05.07 15:54)
> Для клиента это не надо.

Надо. Только он не знает об этом. Кроме того - тут сидят не клиенты твоей программы, а люди пытающиеся тебе помочь.

> Первый пришел, первый ушел (как подсказал мне знакомый бухгалтер)
Значит должен быть партионный учет, если твой знакомый имеет отношение к заказчику и не врет. Это важный момент, который должен быть учтен в структуре БД - нужно хранить информацию по партиям.

Страницы: < 1 2 3 4 5 6 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »