подсчёт кол-во в складской программе

← →
@k@DElpher (2005-04-22 20:00) [0]

Здравствуйте,
пишу программу по учёту склада(ну и остального:))
есть две таблицы Парадокса:
покупки, продажи
структуры почти одинаковые:
ID(ключ),IDDoc-номер,как документа, имя документа(накладная №3),
GOODID- номер товара из таблицы товаров,Amount -Кол-во и так далее...
Как вы заметили здесь даны не документы, а товары со свойствами на принадлежность к одному документу(IDDoc).
Так вот мне надо так подсчитывать суммы, чтоб оно относилось к одному документу, и выводить это юзеру, как таблицу накладных с суммами, и например остатки по этим таблицам...
в общем там разберусь- главное, что использовать? Куда думать:)? У кого подглядеть?
или, если, кто знает - где взять примеры, и где почитать касательно именно этой темы(разработки бухгалтерских и складских программ на Delphi...
( писать буду на Delphi 2005:) )
Заранее благодарен:)...

← →
DSKalugin © (2005-04-22 21:52) [1]

Надо сделать
отчет с группировкой по номеру документа
В делфи6 встроена система отчетов QReport, в Д2005 - без понятия

в каждой группе обнулять "S"
суммировать цены "S":="S" + цена * колво;
и печатать "S"

← →
GanibalLector © (2005-04-23 01:57) [2]

> писать буду на Delphi 2005
> есть две таблицы Парадокса

Однако ;) Вот уж удивили!

← →
GanibalLector © (2005-04-23 02:00) [3]

Что-же касается сабжа,то рекомендую скачать дайджесты этого форума.И внимательно читать посты msgans.

← →
@k@DElpher (2005-04-23 02:39) [4]

to GanibalLector:
Наверное:), но просто систему в действии увидеть охота.... Что касается тормозов- не будем обращать внимания:-D...
А qReport это случайно не, как FastReport...

← →
@k@DElpher (2005-04-23 02:43) [5]

QReport в D7 это Rave?

← →
@k@DElpher (2005-04-23 06:44) [6]

В общем QReport- это такие же отчёты, как и FastReport(Вроде)...
А можно ли сделать так, чтоб сгруппированые значения выводились не в таком виде(отчёта), а в DBGrid?

← →
ЮЮ © (2005-04-23 07:05) [7]

Можно, для этого написать запрос такой, чтобы возвращались данные в нужном виде, т.к. DBGrid предназначен для показа TDataSet-a.

Если получить данные в нужном виде не получается, то можно полученные данные уже на клиенте "записать" в виртуальный DataSet (TClientDataSet, TRxMemoryData, etc) и уже его отобразить в DBGrid

← →
@k@DElpher (2005-04-26 19:26) [8]

В общем я подумал, и решил, что так много мороки:)...
И решил использовать дргой способ... точнее 2(не могу определиться)
1) Две таблицы: покупки и продажи+ ещё две(для документов):
Когда делаем накадную, то все товары добавляются в покупки и плюс эта накладнаядобавляется в реестр...
Накладные Реализации
| |
Купленные товары проданные товары
\\ //
(Вывод информации)
Плюсы такой структуры:
Избавились от проблемыгруппировки в дркументы
Минусы:
Но самое главное программе- это возможность покаывать ОСТАТКИ.
И я не знаю на сколько сложно группировать товары из двух таблиц в одну...
2)1 таблица всех товаров, при чём у них есть свойство куплен или реализован.... При добавлении, всё пихается в одну таблицу и плюс документ прописывается в соответствующей таблицы(реестре):
ТОВАРЫ
/ \ /здесль не совсем сязь- это необ Купленные Реализованные /ходимо только для вывода ИНФЫ
|| /И нормального отображения || /товаров в докумете
|| /Вывод информации идёт прямо из товаров
(ОСТАТКИ)
Плюсы:
Удобно выодить остатки
Минусы:
вдруг мне ещё что-то понадобиться:) И Чтоб во время запроса всё было нормально прийдётся в кол-во для продаж ставить МиНУС?

Если сталкивались с этой проблемой, Помогите пожалуйста:)...

← →
Polevi © (2005-04-27 09:13) [9]

select goodid, sum(qty) from
(
select goodid, qty as qty from приходы
union all
select goodid, -qty as qty from расходы
) t
group by goodid

← →
Polevi © (2005-04-27 09:14) [10]

а вообще зря ты связался с парадоксом
прошлый век

← →
msguns © (2005-04-27 09:43) [11]

>@k@DElpher (26.04.05 19:26) [8]

Мрак..

← →
Sergey13 © (2005-04-27 09:46) [12]

2[11] msguns © (27.04.05 09:43)
Ну вот. Я 3 дня ждал, что ты с лекцией выступишь по этому вопросу как всегда.
А ты кратенько так. Но емко. 8-)

← →
@k@DElpher (2005-04-28 02:31) [13]

тогда на чём это круче сделать(и лучше, чтоб быстрее изучить:))

← →
Sergey13 © (2005-04-28 09:14) [14]

2 [13] @k@DElpher (28.04.05 02:31)
Вопрос не на чем, а как.

← →
ANB © (2005-04-28 09:14) [15]

Oracle 9

← →
msguns © (2005-04-28 09:18) [16]

DB2

← →
ANB © (2005-04-28 09:20) [17]

> msguns © (28.04.05 09:18) [16]
- Oracle круче !!!!

← →
Anatoly Podgoretsky © (2005-04-28 09:20) [18]

Хранить деньги в Парадоксе, останешься без денег.

← →
ANB © (2005-04-28 09:28) [19]

> Anatoly Podgoretsky © (28.04.05 09:20) [18]
- с BTriev работать не приходилось ?

← →
Johnmen © (2005-04-28 09:32) [20]

Круче только яйца. На них и делай.

← →
@k@DElpher (2005-04-28 13:17) [21]

Ни чего не остаётся, как послушать последнее сообщение:)...
Oracle- это сильно сложно:)?... Просто по идеи я в БД начинающий... И вообще самоучка. Потому что ещё школу не закончил:). Так что где-то знаю много где-то не знаю:)... Ладно попробуем с пародоксом и изучим оракл...

← →
@k@DElpher (2005-04-28 13:23) [22]

ANB, Нет не работал
А где почитать про Orcle в Delphi?

← →
Sergey13 © (2005-04-28 13:24) [23]

2[21] @k@DElpher (28.04.05 13:17)
Еще раз повторю - основная твоя ошибка не выборе БД (хотя Парадокс это не самый лучший выбор однозначно), а в проектировании БД. Твоя схема и на Оракле будет плохой.
Полазай поиском тут и вообще в инете. Склад не раз обсуждался.

← →
Sergey13 © (2005-04-28 13:26) [24]

2[22] @k@DElpher (28.04.05 13:23)
>А где почитать про Orcle в Delphi?
Его в нем нет, как и Парадокса. 8-)

← →
msguns © (2005-04-28 13:43) [25]

>@k@DElpher

Ты пойми, дело совсем не в базе. То, что ты наваял в [8] можно сделать хоть в обычных текстовыъх файлах хоть в оракле, хоть в хренакле,- оно не будет работать. Никогда. Потому что не может. В принципе. Как не может летать самолет без крыльев и двигателя. Разве что с обрыва ;)))

Ну почитай же дайджесты. Хотя бы ознакомься с такими понятиями, как "Карточка", "Номенклатурник", "Группы товара", "Счет", "Оплата", "Сальдо", "Прайс-лист", "Заявка", "FIFO" и т.д.
А еще лучше, посмотри как сделан 1С. Хотя бы меню и вид документов.

Ну хватит же строить из себя воинствующее невежество-то

← →
@k@DElpher (2005-04-28 17:37) [26]

Работать будет:)
в 1С сам работаю(я её отцу в фирме запускаю)(почему я- потому, что жиё далеко и тут специалистов ВООбще нет!).
Эту прогу пишу, потому что у нас точка в соседнем посёлке есть(магазин)(мы запчастями торгуем), и надо чтоб они у себя учёт вели... Ну в общем для того чтоб, когда это у нас это появлялось можно было разные запросы делать... Почему не 1С? Да потому что- во первых запустить, во вторых обучить, в третьих нужен только склад и приход расход...
Так что над структурой я долго думал, и из 1С многое уяснил(хотя бы концепцию справочников)... И думаю заработать она 100% заработает.
В общем решил так "Документы" буду хранить в одной таблице(с свой-вами на их вид), товары в другой...Добавлять и удалять синхронно... Ну и + все причиндалы типа справочника фирм, товаров, ед.изм., цен...
Конечно "Документы буду хранить в одной таблице" это не совсем правильно, но мне документов, то нужно!:)...
Я уже писал програмку Дебет/Кредит и органайзер статей- и с этим тоже справимся:)... Вобщем РАССКАЖУ(Сдулся или нет;))

← →
ANB © (2005-04-29 10:38) [27]

> @k@DElpher (28.04.05 17:37) [26]
- ты крут. Хм. Я сам в 22 первый раз сел склад писать. Тогда еще прог не хватало, инета не было, про SQL знали только самые продвинутые и сервер надыбать было не реально. Короче, я его на Clipper написал. Потом еще раза 3 переделывал и вырос он в полную бухгалтерию. Если нужна помощь - ответь, я нарисую примерный список таблиц. Да, а суммовой учет тебе нужен, или хватит количественного ?

← →
KSK (2005-04-29 11:43) [28]

Сам вроди и писал учёт готовой продукци начиная с FoxPro - и скажу не завидую кто сейчас пытается использовать локальные таблицы типа dbf или db. Сам мучался с создаванием кучи этих временных таблиц - время выполнения страшно и сказать..... эти индексы, связи, бизнес-правила... удалив в главной таблице запись - выполняй кучу запросов на удалении в подчинённых... Все через это проходят. А на счёт
> ANB ©
суммового учёта - за 10 лет так и не пришёл к единственному решению, в каждом случае по разному - по ситуации. Решений много - но оптимального, который бы мне понравился на все 100%, так и не нашёл. И для

> >@k@DElpher

почитай в каждой книге есть инсрукции по Interbase больше узнаешь о структуре баз данных, хранении и обработки информации. И на выбор много клиент-серверных субд. Interbase не плох - но мне больше по душе MS SQL Server. Удачи!!! Главное чтобы было желание и стимул!!! а всё остальное современем.

>KSK (29.04.05 11:43) [28]
>Сам вроди и писал учёт готовой продукци начиная с FoxPro - и скажу не завидую кто сейчас пытается использовать локальные таблицы типа dbf или db.

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

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

Неужели ? За 15 лет писано куча прог, исправно работающих до сих пор, в т.ч. и складского типа и не применял ни одной временной таблицы.
Для парадокса - да, есть грех - слет индексов. Для этого в каждой проге есть сервис с архивацией и восстановлением. Потери есть, но не существенные, пользователь привыкает довольно быстро самостоятельно забатиться о своей инфе. Я не говорю, что локалки - это хорошо. Я лишь утверждаю, что сваливать вину в уродливости программы на движок (BDE, например) - это "с больной головы на здоровую"

>суммового учёта - за 10 лет так и не пришёл к единственному решению, в каждом случае по разному - по ситуации. Решений много - но оптимального, который бы мне понравился на все 100%, так и не нашёл. Успехов в поисках оптимальных решений.

Тут ничего не надо искать - суммовой учет надо делать всегда - еще никому он не мешал.

>но мне больше по душе MS SQL Server

Представляю частника, купившего такую прогу для учета своего товара. Первый же бросок по питанию и что он будет делать со скалой, отказывающейся поднять базу ?

> >но мне больше по душе MS SQL Server
- Oracle рулез !!! Не ломается. А вот для локалки не факт. Транзакций же нету. От отсутствия транзакций и все проблемы. Даже без констрэйнтов не так страшно. У клиппера тоже индексы слетали, у меня больше года без почистки базы серьезно работать не могли.

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

>ANB © (29.04.05 12:42) [30]
>Правда у меня связка суммового с количественным учетом была на макросах построена.

Дааа, это неизлечимо ;(

> Дааа, это неизлечимо ;(
- а как бы это сделал ты, если формулы проводок нужно было дать возможность менять юзеру ? К тому же макросы я предварительно компилил.

← →
KSK (2005-04-29 14:04) [34]

> msguns © (29.04.05 12:22) [29]
> Для однопользователького учета (а таких пользователей великое
> множество, ЧП например) юзать сервера-изврат чистейшей воды.
> Локалки-самое то. Дело не в дб, а в руках и голове.

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

> >msguns

> Первый же бросок по питанию и что он будет делать со скалой,
> отказывающейся поднять базу ?
тошо дбф-ники портятся и при потери сети - такого шо не бывает
???
> За 15 лет писано куча прог, исправно работающих до сих пор,
> в т.ч. и складского типа и не применял ни одной временной
> таблицы.
я понимаю - спользование временных таблиц идёт от плохого знания SQL, но написать нормальний запрос используя Query BDE я не знаю как можно??? посмотреть скоко возможностей появилось возможностей в SQL при использовании ADO - это привело к тому что я почти прекратил пользоваться временными таблицами. ПРоблема такого рода (тоже от не знания - я не возражаю) - есть к примеру одна главная таблица - с ней связываем больше двух таблиц подчиненных черех join, в которых надо сделать расчёты (sum() и другие) используя group by - вот если присутствует вот этот group by - связь происходит не верно. Посему делал по примерам с книги Кен Хендерсона - сначала сгонял всю в одну таблицу потом группировал, и работает быстро и никаких тебе left join-ов, которые по всем книгам губительны для любой системы.

>Polevi © (29.04.05 13:22) [32]
>>msguns © (29.04.05 13:11) [31]
>а в майкрософт то и не знают

?

>KSK (29.04.05 14:04) [34]
>вот если присутствует вот этот group by - связь происходит не верно.

???
Запрос в студию

msguns © (29.04.05 12:22) [29]
>Для однопользователького учета (а таких пользователей великое множество, ЧП например) юзать сервера-изврат чистейшей воды. >Локалки-самое то. Дело не в дб, а в руках и голове.

Вот еще! Самое то? Назови мне хотя бы пару преимуществ BDE + dbf|db перед, например, Firebird Embedded? Никак не могу найти...
Я не говорю об Access и Foxpro, например, как полноценных средах, а именно о доступе из Delphi. Отвратно! Столько лишних телодвижений - все сам, проверки, целостность...
Кажется, последний раз я имел дело с локалкой в прошлом тысячелетии :)

Для парадокса - да, есть грех - слет индексов. Для этого в каждой проге есть сервис с архивацией и восстановлением. Потери есть, но не существенные, пользователь привыкает довольно быстро самостоятельно забатиться о своей инфе.
Несущественные потери? Ну-ну. Это ж, как правило, деньги. Такой склад, может, кладовщику и понравится... И что значит заботиться об инфе?! Если я ввел ее в БД, она там должна быть. Исключая стандартный форс-мажор вроде наводнения или пожара... А если записи исчезают - нафига такое надо?!
>Я не говорю, что локалки - это хорошо. Я лишь утверждаю, что сваливать вину в уродливости программы на движок (BDE, например) - это "с больной головы на здоровую"
Знаешь, хорошо писать на чем попало можно. Но зачем же мазохизмом заниматься?!

>Polevi © (29.04.05 14:13) [36]
>а не знают они того что знает msguns, про то как падают базы..

Ты хочешь сказать, что скала администится также просто, как, например, парадокс (Починить любую таблицу может даже ламер по инструкции из 4 строк или, на худой конец, просто разархивировать БД из сохраненного вчера архива) ?

>Romkin © (29.04.05 14:25) [37]
>Назови мне хотя бы пару преимуществ BDE + dbf|db перед, например, Firebird Embedded? Никак не могу найти...

Ясный ясень, что не найдешь. Особенно если искать и не собираешься. Преимуществ мало, но они есть. И главное из них - это то, что уже написано море работающих прог с использованием презираемых тобою локалок. Мне для того, чтобы "подкрутить" любую из них, надо от 5 мин до 5 дней. Ты что, предложишь мне все их переписать под FB ?

>Знаешь, хорошо писать на чем попало можно. Но зачем же мазохизмом заниматься?!

1. Вот это:
"Если я ввел ее в БД, она там должна быть"
или это
"А если записи исчезают - нафига такое надо?!"
и есть "что попало".

2. Что ты понимаешь под словом "мазохизм" ? Или есть необходимость пояснить тебе это слово ?

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

Просто охота почесать гондурас ?

Вдогонку:
Вот на это:

1. Вот это: "Если я ввел ее в БД, она там должна быть" или это "А если записи исчезают - нафига такое надо?!" и есть "что попало". 2. Что ты понимаешь под словом "мазохизм" ? Или есть необходимость пояснить тебе это слово ?

прошу не обращать внимание. Отвлекали и не врубился в смысл фразы.

> msguns © (29.04.05 15:20) [39]
- не кипятись. Вообще то автор сабжа собирается писать новую прогу. Вот ему и советуют не начинать с локалок. Хотя MS SQK мне не нравится. Хотя бы потому, что 2000 не хочет на проф становиться, сервер ему подавай. Oracle не так привередлив, а возможностей больше. Правда и геморроя с администрированием тоже. В том, что переписывать готовую прогу только для перехода на SQL не выгодно - ты прав. Хотя многие таки потихоньку переписывают. И эти же многие продолжают использовать локалки хотя бы для хранения локальных данных, чтобы реестр не мусорить.

подсчёт кол-во в складской программе Найти похожие ветки