Помогите написать сложную для меня процедуру или функцию

← →
Rostislav Rotaru © (2005-02-02 11:52) [0]

Здравствуйте.
Дело касается учета склада. Есть расходный документ. В базе он под видом:
- шапка документа: t_documents: document_id (id документа), document_type(тип документа, bit) document_number (номер), agent_id (id покупателя), document_date (дата)...
- табличная часть: t_moves: move_id(id строки), document_id(ссылка на документ), move_quantity (количество товара).
Есть таблица t_products_parties(партии товара): party_id, product_id(ссылка на товар), party_stock(остаток товара), party_type(тип партии, bit), party_price(цена партии)...

Нужно написать процедуру, которая бы правильнее и быстрее сняла бы с остатков(партия товара) необходимое количество и записала бы в документ. Ситуация была бы проще если бы не один ньюанс: все должно зависеть от типа документа и типа партии. Например: если t_documents.document_type=1 тогда t_products_parties.party_type не имеет значения. Если же если t_documents.document_type=0, тогда нужно учитывать только партии где t_products_parties.party_type=0.
Логика такова: пользователь создает документ, заполняет шапку. Дальше идет заполнение самой табличной части. Пользователь выбирает из списка товаров нужный товар. При выборе, нужно получить список всех подчиненных партий где есть остаток (в зависимости от типа документа) и по принципу "первая партия пришла, первая ушла(метод FIFO)", заблокировать запись и перебросить количество в документ. Если в первой партии не хватает количества, тогда ищется остаток на второй партии и.т.д. Если операция проведена успешно, возвращается код успешного завершения и транзакция закрывается, если нет - тогда откат и вывод соответствующего сообщения.
Я реализовал все это на клиенте, через AdoCommand и AdodataSet и вроде работает. Но думаю, сервер с этим лучше справится в одной процедуре, если это возможно.
Постарался как можно подробнее описать проблему. Буду рад помощи. Готов предоставить любую дополнительную информацию.
Заранее благодарен.

← →
Соловьев © (2005-02-02 11:53) [1]

> Готов предоставить любую дополнительную информацию.

В деньгах?

← →
Rostislav Rotaru © (2005-02-02 11:57) [2]

← →
Rostislav Rotaru © (2005-02-02 11:57) [3]

← →
Rostislav Rotaru © (2005-02-02 11:58) [4]

> Rostislav Rotaru © (02.02.05 11:57) [3]
что-то не то нажал...

← →
stud © (2005-02-02 11:59) [5]

> Я реализовал все это на клиенте

так и в чем проблема реализовать на сервере??

← →
Nikolay M. © (2005-02-02 12:02) [6]

> > Готов предоставить любую дополнительную информацию.
>
> В деньгах?

А в же чем еще? При такой-то постановке вопроса.
Сегодня по фифе, завтра по лифе... Имхо, лучше с этим на rentacoder.

← →
Соловьев © (2005-02-02 12:02) [7]

> что-то не то нажал...

ну вот как сразу к делу, сразу не то нажал...

← →
Rostislav Rotaru © (2005-02-02 12:04) [8]

> stud © (02.02.05 11:59) [5]

Пока нет опыта работы с процедурами и функциями. Боюсь не справлюсь. Поэтому попросил помощи

← →
msguns © (2005-02-02 12:06) [9]

То, что в сабже, называется учетом товара по поставкам
Предусматривает деление всех документов на 2 группы:
- Приходы от поставщика (поставки)
- Все остальное движение (отгрузки, возвраты, внутреннее)

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

← →
Nikolay M. © (2005-02-02 12:11) [10]

> Пока нет опыта работы с процедурами и функциями.

Лекции читать тебе вряд ли будут - альтруистов сейчас нет. Начальные знания поднимай по БОЛ и книгам. Будут конкретные вопросы - обращайся.

← →
Rostislav Rotaru © (2005-02-02 12:12) [11]

> msguns © (02.02.05 12:06) [9]

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

← →
msguns © (2005-02-02 12:20) [12]

>Rostislav Rotaru © (02.02.05 12:12) [11]
>Вы не поняли, все уже работает, а метод учета как таковой - метод идентификации. Просто пытаюсь оптимизировать приложение и базу. Во всех форумах и статьи которые посмотрел рекомендуется все делать на сервере. Поэтому и возник вопрос.

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

← →
Rostislav Rotaru © (2005-02-02 12:35) [13]

> msguns © (02.02.05 12:20) [12]

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

← →
msguns © (2005-02-02 12:38) [14]

Вы что, продаете в розницу непосредственно со склада ? Тогда флаг в руки и железные трусы в придачу. Я Вам не помощник.

← →
Rostislav Rotaru © (2005-02-02 12:45) [15]

Да, у нас закон это позволяет.

← →
msguns © (2005-02-02 12:47) [16]

>Rostislav Rotaru © (02.02.05 12:45) [15]
>Да, у нас закон это позволяет.

А причем тут закон ? Закон не запрещает ходить на работе голыми, но Вы однако ж в брюках ?

← →
Rostislav Rotaru © (2005-02-02 12:53) [17]

> msguns © (02.02.05 12:38) [14]
> Вы что, продаете в розницу непосредственно со склада ?

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

← →
msguns © (2005-02-02 12:58) [18]

>Вы имеете ввиду правильный учет? Но в таком случае, если даже Вы продаете с розничного склада, то все равно это склад, и все равно есть партии...

Я так понимаю, что у Вас собственно склад находится в том же здании, что и магазин (офис, торгующий за нал через ЭККА) ?
Ну и что Вам мешает завести в прогу магазин, и весь очередной приход сразу же отправлять в этот магазин ? Если смущает "двойная работа" оператора, то у Вас плохо реализована фича отгрузки. Очевидно, что в ней отсутствует возможность списания на основании указанного документа. Но это уже совсем другая трабла и собственно к учету она имеет весьма отдаленное отношение.

Есть и в том же здании и удаленно. В локальном случае, используется та же база что и на складе. Со склада, через документ о передаче на розничный склад (в той же программе) фромируется остаток. А дальше - тот же принцип. Удаленно - используется документ о перемещении, там приход, потом продажа.

>Есть и в том же здании и удаленно. В локальном случае, используется та же база что и на складе. Со склада, через документ о передаче на розничный склад (в той же программе) фромируется остаток. А дальше - тот же принцип. Удаленно - используется документ о перемещении, там приход, потом продажа.

1. ИМХО, система не верна в принципе. Склад - это прежде всего ХРАНИЛИЩЕ, а не подсобка в магазине. Поэтому термин "розничный склад" считаю безграмотным.
2. Держать в магазинах копию базы, а потом заниматься объединением информации (репликацией) в данном случае - атавизм, оставшийся от досовско-фокспрошных времен, когда сети были еще в диковину. Используйте кассовые кэши и передачу информации о продажах напрямую (через модем, например).

> msguns © (02.02.05 13:10) [20]

1. Может неправильно выразился. Русский - не мой родной язык, трудно объяснить иногда. Но даже с этим у нас существует термин "depozit pentru vanzare en detail" - склад для продажи в розницу. Это румынский.
2. Согласен. В плане - терминал. Но сначала хотел программу довести "до ума", а потом заняться. Одному как-то трудно все сразу делать. Насчет команды - даже речи быть не может. Таковы условия.

1. Уговорите хозяев приобрести хороший кэш-драйв, поддерживающий буферированные транзакции.
2. Из софта к кэшу (или интструкции, если кэш только аппаратный) возьмите и проанализируйте структуру данных.
3. Свяжите коды товара в магазинах с Единой Базой Данных на складе. (Под складом понимается место, где товар хранится в программе и откуда возможна продажа только оптом). Если складов несколько и они удалены, то задача неусколько усложняется за счет того, что надо делать хорошую удаленную связь между складами. Ценник и приходы должны быть общими в БД для любого кол-ва складов.

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

Спасибо за Ваши ответы и советы. Все это будет, но наверное, не сейчас. Хозяев устраивает текущая схема, хотя то, что вы предложили намного лучше.
>3. Свяжите коды товара в магазинах с Единой Базой Данных на складе.
Это будет немного сложнее потому что в магазине может быть товар и с других складов, а в таком случае все идет напрямую.
Что вы имеете ввиду под учетом по поставкам и по товарам. Если я правильно понял, то у меня уже ведется учет по товарам. таблица партий товаров это есть таблица остатков. Движения (приходы, расходы) это отдельные табоицы

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

Мы с Вами так ни о чем не договоримся. Я ж дал Вам определение склада. А Вы опять все валите в кучу. Причем здесь магазин, даже если румыны и называют его "розничным складом" ? Если он привозят туда непосредственно товар, то это еще не значит, что накладная должна там и пребывать вечно. Фиксировать товар надо в одном месте. А оттуда "развозить" (в смысле компьютерного документооборота, а не грузовиками) по розн.точкам.

>Что вы имеете ввиду под учетом по поставкам и по товарам. Если я правильно понял, то у меня уже ведется учет по товарам. таблица партий товаров это есть таблица остатков. Движения (приходы, расходы) это отдельные табоицы

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

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

где речь идет о партиях и методе списания с разных партий. Если слово "партия" заменить на "поставка", все становится на свои места. Слово "поставка" более правильное и с т.зр. стилистики (у поставщика может быть свое понятие "партии") и т.зр. кладовщика (слово "партия" для него ничего не говорит, а вот срок хранения или дата поставки ему оч.хорошо понятны).
Такую классификацию, поверьте, не я придумал, а люди, много меня умнее и опытнее.

Учет же по товару "обезличен" с точки зрения идентификации происхождения товаров и на складе, и в движении. Т.е. списание идет не по поставкам, а по товарным карточкам, оприходование тоже делается на карточки. Т.о. один и тот же товар с разных приходов записывается на одну карточку. С этой же карточки он и списывается.

Я же Вам советовал полазить по этой конференции. Буквально на прошлой неделе был об этом подробный базар. Поищите, не ленитесь.

Спасибо, уже ищу...

Помогите написать сложную для меня процедуру или функцию Найти похожие ветки