БД и Delphi

Серый ёжЬ 10.06.2004 - 10:56 | Есть 2 таблицы - главная и подчинённая. Главная - приход на склад, подчинённая - расход. Как сделать, чтоб в таблице прихода автоматически высчитывался остаток товара на складе по каждой записи? Ссылочку дайте чтоль...
FWP 1 - 10.06.2004 - 11:22 | А что значит "автоматически"?
Серый ёжЬ 2 - 10.06.2004 - 11:42 | ну если на AfterPost зависимой таблицы функцию какю-нибудь повесить... нашёл способ через SQL, там есть функция SUM... Может, есть способ попроще?
Delphist 3 - 11.06.2004 - 00:34 | А почему "приход" - главная, а "расход" - подчиненная? И почему вообще это две таблицы, а не одна? Делаешь одну таблицу с полями "prihod" и "rashod". Пришло десять единиц товара - пиши строку (10; 0) Ушло четыре единицы товара - пиши строку (0; 4) Ну, и т.д. Потом делаешь в отчете SELECT-запрос типа SUM("prihod") - SUM("rashod") Это и есть текущий остаток. Не забудь группировку по товару :)
Серый ёжЬ 4 - 11.06.2004 - 09:53 | Delphist, объясняю: на склад приходит товар от поставщика, данные забиваются в таблицу (15 полей), потом это товар распределяется между несколькими покупателями, и это тоже забивается в таблицу, но уже другую! (тоже около 10-15 полей). Пример: пришло 1000 ящиков макарон от ЗАО "Производитель" (записываем все данные в таблицу "Поставщик"). Затем приезжает ООО "Покупатель - 1" и покупает 300 ящиков макарон (заносится в таблицу "Покупатель"), после него приезжает ОАО "Покупатель - 2" и покупает 500 ящиков макарон (опять заносится в таблицу "Покупатель"). Остаток - 200 ящиков долже отображаться в таблице "Поставщик" по строке "ЗАО "Производитель"! Вот так, вкратце.
FWP 5 - 11.06.2004 - 10:06 | Возможна еще и такая ситуация: осталось 200 ящиков от ЗАО "Производитель", но имеется 500 ящиков от ООО "Делатель". Затем приезжает ООО "Покупатель - 77" и берет 600 ящиков. Что в этом случае?
Серый ёжЬ 6 - 11.06.2004 - 10:27 | FWP, резонный вопрос... Что в этом случае? - "Покупатель - 77" покупает 200 ящиков от ЗАО "Производитель" и 400 ящиков от ООО "Делатель" - так по документам должно проходить, т.е. после этой опреации останется по первой строке - 0, по второй - 100!
silly sad 7 - 11.06.2004 - 10:30 | мягкий знак в конце существительных в дореформенной грамматике указывал на женский род. и сейчас частично его роль сохранилась.
Серый ёжЬ 8 - 11.06.2004 - 10:41 | silly sad, в современном русском языке мягкий знак в окончании существительных также указывает на женский род, примером тому могут служить слова "мышь", "печь", "ночь", однако в данном случае определяющим становится прилагательное, идущее на первом месте в словосочении, кроме того, слово "ёж" является существительным мужского рода... Учите руссий, чтобы понимать юмор (С)
FWP 9 - 11.06.2004 - 11:46 | to#6 Тогда двумя таблицами не обойдешься. Нужно еще несколько. Причем решения м.б. разными. К примеру: - контрагенты - продукты - поставки - отпуск продуктов. Причем программа может минимизировать/максимизировать затраты/прибыль выбирая поставки и покупателей с лучшими характеристиками. В момент оформления покупки из соответствующих поставок списывай кол-во. Не забудь оформить это в одной транзакции.
Delphist 10 - 11.06.2004 - 15:45 | А чем мой вариант из #3 не укладывается в ситуацию #4 ? Распишу подробнее свою мысль: Делаем таблицу "Товарооборот" со следующими полями: "Контрагент", "Приход", "Расход". Тогда описанная в #4 ситуация превращается в три строки этой таблицы: ЗАО "Производитель", 1000, 0 ООО "Покупатель - 1", 0, 300 ОАО "Покупатель - 2", 0, 500 Чтобы узнать текущий остаток, делаем запрос select SUM("Приход") - SUM("Расход") from "Товарооборот" И все. . Для полного нормального учета, конечно, потребуется куда более сложная структура таблиц. Серый ежЪ, ты поделись информацией о задаче: это теоретическая разработка или автоматизация реального предприятия? Если второй вариант - пляши от существующего на фирме документооборота и бизнес-процессов. В частности, как они оформляют возвраты от покупателей и брака к поставщикам, как проводят инвентаризации и списание недостач/пересортиц, есть ли укомплектация/разукомплектация. Эти учетные задачи при кажущейся легкости (пришло/ушло) имеют нехилую подводную часть.
Серый ёжЬ 11 - 11.06.2004 - 16:06 | Delphist, спасибо, я к этому варианту и сам пришёл, хорошо, что не я один так думаю! Да, это реальное предприятие, но документы там не особо важные, просто для отчёта!
Grigoriy 12 - 13.06.2004 - 14:31 | А почему нельзя сделать поле "Колво" и поле "Тип Операции"? И тогда писать 200 1 70 2 где 1 - приход, а 2 - расход И в этом случае легко запросами оперировать и нулей не надо
Delphist 13 - 14.06.2004 - 03:25 | Grigory, не клади две логические сущности в одно поле таблицы - потом доставать замучаешься. Изобрази здесь запрос, который выдаст текущий остаток товара
x77 14 - 14.06.2004 - 03:44 | есть другой вариант. разделять не операции, а контрагентов. т.е. таблица будет вида "поставщик, получатель, кол-во, etc.". это более универсальный вариант, т.к. ты можешь, например, завести контрагента "Списание", и сливать ему всё на свете. остатки высчитываются по таблице ревизий. т.е. по текущему контрагенту находим результат последней ревизии, (если его нет - принимаем равным 0), суммируем все приходы и вычитаем все расходы). . приходы и расходы делим на подтипы. (например, для приходов - приход от поставщика, возврат покупателя; для расходов - отгрузка покупателю, списание, возврат поставщику). тогда можно вести учёт по отдельным видам операций. . сам по себе механизм достаточно гибкий. это простейший аналог бухгалтерской двойной записи - при любой операции у тебя всегда у кого-то станет меньше, а у кого-то больше. по тому же принципу можно организовать учёт финансовых потоков, выдачу товара под реализацию, и т.д.
Gunny 15 - 17.06.2004 - 09:22 | Простые все такие, как мой друг один - сделай, говорит как в 1С, но чтоб не 1С - ну я и сделал... за полгода, нормальную базу по учету торговых операций качественно, без разработки всех моделей, нормализации отношений, быстро и просто не сделаешь, либо так, либо так, а вообще, я в сделал три таблицы - приход -> буфер/склад -> расход. Весь приход в приходе сидит, расход в расходе, а буфер каждый раз пересчитывается в плюс или минус, когда приход или расход постится, короче, типа регистры в 1С, только в одном измерении. Подробную лекцию скину на мыло если че, задавайте вопросы внятно и пространно.
x77 16 - 18.06.2004 - 05:28 | нормальную базу для складского (не бухгалтерского) учёта можно сделать за месяц, максимум - два. а если делать через пень-колоду - то и жизни не хватит, imho.
Delphist 17 - 18.06.2004 - 07:32 | Жизни не хватит, если Заказчик сам не понимает, что творится у него на складе. Заню одних таких :) Солидная фирма, а в учете любой налоговик заблудится :) Причем сделано это не специально, а "исторически сложилось".
Sabrian 18 - 18.06.2004 - 14:08 | А SUM то чем плох? Куда ж проще то?
x77 19 - 18.06.2004 - 20:01 | в конечном итоге и будет sum. сальдо = остаток на начало + приход - расход, никто ничего нового здесь никогда не придумает :)

>>