| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
---|Ветка была без названия|---
Dmitry1 © (2002-10-16 13:58:00)Кто нибудь может посоветовать где можно посмотреть реализацию метода списания товара по FIFO.
MsGuns (2002-10-17 11:16:00) [41]>Наталия © (17.10.02 09:46)
1. Хранить готовые остатки. Я так раньше и делал, но при необходимости иметь "горячие" остатки, (т.е. когда один оператор выписал "молока" 6 л, а другой через СЕКУНДУ должен видеть уже оставшееся кол-во) надо постоянно автоматически править отот остаток в некой таблице (условно назовем ее "Таблица остатков").При этом сам механизм (триггер или локал-процедура) по большому счету роли не играет. Вот и получается, что эта "Таблица остатков" при активной работе нескольких операторов перманентно в режиме Edit. Т.к. мои таблы были в основном на Paradox, все это при нестабильности питания регулярно "выбивало" таблицу остатков. В конце-концов я вообще отказался от ее существования.
2.Большая скорость.
Как раз наоборот ! Т.к. движение линкуется к позиции через внешние ключи (Master-Detail), то курсор ДВИЖЕНИЯ имеет не более 100 записей (одна позиция редко движентся более 20-30 раз, но бывает и до сотни), просчет суммы по ОДНОЙ колонке времени занимает мизер. В отличие от времени, затрачиваемого при записи в таблицу остатков, которая правктически всегда "под напряжением".
Впрочем, это относится к БД с весьма интенсивным базовым трафиком. Для средних и мелких фирм такая проблема обычно не стоит
Digitman (2002-10-17 11:03:00) [42]При реализации FIFO в момент оприходования док-та на расход/списание snapshot складов, упорядоченный по возрастанию даты и количеству(иногда - себестоимости), по каждой позиции в спецификации док-та сканируется на предмет локализации записей, удовлетв. условиям расхода/списания. Приходные акты движения, на которые ссылаются найденные записи, становятся первичными up-ссылками при формировании соотв.расходных актов. После формирования расх.актов локализованные записи в snapshot"е корректируются (либо уничтожаются, если расх.акт вычерпывает весь остаток от поставки). В конечном итоге документ помечается как оприходованный и транзакция подтверждается.
Расприходование (откат) документа на расход/списание ведет к следующему :
- стартует транзакция,
- по каждому эл-ту спецификации док-та локализуется акт (либо группа актов) движения,
- по up-ссылкам локализуются первичные приходные акты (возможно - в цикле до up = nil),
- в snapshot"е локализуются записи со ссылками на найденные акты поставки, если найдены - корректируются (инкремент), если не найдены - воссоздаются со ссылками на локализованные первичные акты поставки
Вот , собствено, и вся "кухня")... Как ни обзови ее "потроха", но она отвечает на вопрос
Digitman (2002-10-17 11:01:00) [43]- элементы справочника тов.документов (накладные разл.типа - приходные, расходные, списание, подотчет и т.п.) являются первичными при осуществлении складских транзакций; документы могут быть созданы/модифицированы/уничтожены лишь в состоянии "неоприходованности", каковое никак не влияет на изменение в объектах "акты движения" и "оперативное состояние";
реальное изменение в "актах движения" (и в конеч.итоге - "оперативном состоянии") происходит лишь в транзакциях, стартуемых индивидуально для "оприходования"/"расприходования" (если угодно - отката) указанных (уже сформированных ранее в отдельных транзакциях и, соответственно - проверенных на корректность и целостность) документов;
иными словами - документ остается просто ничего не значащей электронной "бумажкой без печати" до тех пор, пока не будет "оприходован";
- реальные учетные данные (по каждой номенкл.единице в приходуемом/расприходуемом документе) меняются и объявляются достоверными/недостоверными лишь в результате успешного выполнения транзакции в рамках операции оприходования/расприходования документа;
- после оприходования документ нельзя ни удалять ни модифицировать - он является основанием для проведенной складской операции, в результате которой сформированы акты соотв.движения по каждой номенкл.единице в документе для каждого фигурирующего в док-те склада, а также модифицированы соотв.элементы оперативного состояния склада/складов;
- операция расприходования(отката) документа запускает транзакцию, в рез-те которой после успешной проверки на корректность ссылок и лог. допустимость ранее сформированные при оприходовании док-та акты движения объявляются недостоверными (удаляются) и, как следствие, соотв.записи об оперативном состоянии склада/складов корректируются/уничтожаются таким образом, чтобы snapshot отражал момент "до" оприходования; сам же документ не уничтожается - становится снова просто электронной "бумажкой без печати";
- в любой момент времени при формировании любых отчетов (отражающих контекст достоверно зафиксированных скл.операций) из рассмотрения исключаются неоприходованные док-ты, ибо это - просто "бумажки", не более того;
в результате :
по достоверно зафиксированным записям об актах движения (в связке с заголовками и спецификацией достоверно оприходованных документов) можно получить отчетность любой сложности, не заботясь об оперативности ее формирования; нужно это в 1-ю очередь бухгалтерам и менеджерам - т.е. тем специалистам, которые ответственны за ведение разного рода отчетности установленных форм и содержания, а так же анализ и формирование потенциальных заказов по результатам анализа/прогнозирования;
по достоверно зафиксированным записям в справочнике опер.состояния складов (если необходимо - опять же в связке с актами и документами) можно во много раз быстрее получить инф-цию о наличии в данный момент интересующей номентклатуры, ее остаточном кол-ве, ценовых и себестоимостных хар-ках, дате поставки, документе-основании поставки и пр.; нужно это, кр. специалистов вышеуказанного звена, в 1-ю очередь коммерч.руководству, работникам склада, продавцам-консультантам и кассирам - т.е. тем специалистам, которые имеют необходимость принимать немедленное решение, исходя из статической картины сток-объектов и их номенклатуры.
Теперь - собственно по изнач.вопросу
Классическая реализация такой схемы позволяет очень легко задействовать и переключать учетные механизмы - стек, очередь, расход/списание по среднеуч.стоимости и пр. Ибо первичной инф-цией для последующего поиска/фиксации актов движения при проведении транзакций расхода/списания будет являться все тот же объект - оперативное состояние складов : он наиболее компактен, включает достаточную инф-цию (для любого механизма расхода/списания) и не содержит избыточных сведений, обработка которых может привести к неоправданному расходу ресурсов
(и даже иногда - к коллизиям)
Digitman (2002-10-17 10:58:00) [44]Еще раз хочу подчеркнуть - приведенная схема далеко не самая худшая :
- справочник оперативного состояния складов (что, где, сколько, на какую сумму, и на основании какого акта) по каждой номенкл.тов.единице изменяется как результат отработки механизма фиксации/уничтожения актов в таблице движения по складам; объект, отражающий оперативное состояние складов, позволяет в любой точке корп.сети для любой цели мгновенно получить инф-цию о наличии товаров (своего рода - snapshot), дате постановки на учет и их количественных/ценовых характеристиках;
- акты тов.движения (обзови их как угодно, но все они имеют как минимум знак : "+" для приходных и "-" для расходных актов любого субтипа) формируются/уничтожаются на основании оприходования/расприходования(если угодно - отката) тов.документов - накладных; в зависимости от типа документа-накладной по каждой ее позиции в результате транзакции формируется/уничтожается один или более актов движения, на основании которых изменяется snapshot складов; в любой момент времени на любую интересующую дату на основании выбоки записей-актов можно получить любой отчет - те самые оборотки/сальдовки и иже с ними; запросы такие, разумеется, более тяжелые и длительные, но ведь и преследуют они иную задачу - дать состояние товара в динамике ! snapshot же складов дает статику и цель его - дать именно оперативные, самые свежие данные о состоянии интересующей номенклатуры, поставленной на учет в интересующий момент времени;
Digitman (2002-10-17 10:54:00) [45]
> не могу сказать, что предмет (торговля) Вы знаете неважно.
Не можешь сказать, что "неважно" - не говори)
Схема сия взята из софта, который достаточно успешно существовал и работал задолго до того, как появился 1С - это сетевой торг.-бухг.комплекс Lanx Supermanager. А "умер" в основном из-за ограничений, которые вносила изначально задействованная в пакете СУБД FoxPro (и даже перенос ядра на MSSQL не дал полного разрешения проблем мультиклиентского доступа)
Не скажу, что комплекс идеален по гибкости бизнес-логики и надежности, но я изучал "потроха" и наблюдал/контролировал его работу в течение 5 лет. И могу с достаточной долей уверенности сказать, что при всех его очевидных недостатках (а их немало, как, впрочем, и во многих иных похожих продуктах) бизнес-логика сего пакета в части склада (о бухгалтерии я не говорю здесь, ибо о ней речь и не идет) концептуально задумана и реализована достаточно грамотно.
Не пытайся изо всех сил показать, что в терминологии и понимании складских операций ты "крут" как никто другой. Не стОит того, сударь)
Наталия (2002-10-17 09:46:00) [46]>MsGuns © (16.10.02 22:08)
На мой взгляд, Вы не правы, категорически отрицая необходимость таблицы ОСТАТКОВ товаров, так как при вычислении остатков по даблице ДВИЖЕНИЯ товаров на текущий момент это может занимать слишком много ресурсов при больших базах. А при изменении какой-либо позиции в ДВИЖЕНИИ (Digitman под актами движения подразумевал как раз то, что Вы называете "накладные" - не суть важно) триггер автоматически изменяет запись в таблице ОСТАТКИ. Этим достигается бОльшая скорость при работе со списком товара.
Zlob (2002-10-17 08:35:00) [47]А все же проблема списания существует в бухгалтерии, по причине учета стоимости остатков товара по карточке. Ведь приходы идут по разным ценам даже если товар идентичный,хотя бы за счет инфляции, и результат будет зависеть от того, с какого прихода,
дорогого или дешевого списан товар. Правда ни FIFO,ни LIFO не реализуются нормально и вызывают множество проблем как уже было указано, поскольку основаны на сортировке записей. Более удовлетворительно решается задача методом усреднения цены, что и было нами реализовано. Правда при этом оказалось что для совпадения остатков приходится тянуть не только кол-во товара, но и суммы, или хранить цены с точностью до 6 знака, но это уже мелочи.
MsGuns (2002-10-16 22:08:00) [48]>Digitman © (16.10.02 18:05)
При всем к Вам уважении как к профессионалу-ПРОГРАММИСТУ не могу сказать, что предмет (торговля) Вы знаете неважно.
Акты на складе действительно бывают, но весьма редко и называются актами списания. Все остальное суть "накладные", которые бывают приходными, расходными и возвратными. В том числе и по внутреннему перемещению (склад-склад, склад-магазин, магазин-склад и т.д.)
Понятие "откат" применительно к документу-накладной скорее всего "свистнутый", т.е. от 1С, где, простите, даже пукнуть нельзя без "отката". В НОРМАЛЬНЫХ софтах складского учета документ (накладную или акт) можно просто удалить (а не откатить, это Вам не расчет з/пл с аннулированием последних изменений). При этом, как Вы справедливо заметили, записи о ФАКТУРЕ НАКЛАДНОЙ удаляются из СКЛАДСКОЙ КАРТОТЕКИ (раздел движение) и ОСТАТОК НЕ НАДО ПЕРЕСЧИТЫВАТЬ И ТЕМ БОЛЕЕ КУДА-ТО ТАМ ПИСАТЬ. Остаток подсчитывается каждый раз, когда юзер выбирает позицию (или группу позиций) по фактическому движению на карточках. Для различных отчетов (сальдовки, оборотки и проч) все остатки ПОДСЧИТЫВАЮТСЯ, а не берутся из каких-то там суррогатных полей таблиц.
Замечу, что это действенный и надежный способ раз и навсегда избавится от проблемы, называемой бухгалтерами "Остатки не идут".
Извините, если чем-то обидел.
С уважением. Примите и проч.
petr_v_a (2002-10-16 18:27:00) [49]режим-то ессно д.б. полуручной, т.е при выписке ( или проведении) документа юзер указывает код партии, но систма поумолчанию предлагает правильный с ее точки зрения, и эти коды партий обязательно должны быть в печатной форме, на которой склад должен расписаться, что он принял/отгрузил именно это, и склад должен расписываться на товарном отчете в разрезе партий. В противном случае отгружать будут что первое попалось на глаза, система будет списывать по-своему, к реальным остаткам через непродолжительное время база иметь не будет никакого отношения, виноватыми выставят программистов, поставят 1С :))),
в ней будет то же самое, надут программистов под собственную систему и см. п.1 :)))))
Digitman (2002-10-16 18:05:00) [50]должна быть таблица, фиксирующая акты движения по складу.
каждая ее запись (или группа записей) ссылается на запись в таблице, содержащей соотв.элемент спецификации товарного документа, на основании которого при его оприходовании акт движения создается
на основании же акта движения модифицируется таблица, содержащая оперативные сведения об остатках товаров по складам/секциям : записи, ссылающиеся на акт либо добавляются (товар пришел на склад/секцию в результате "чистого" прихода или отката документа/ возврата ранее реализ.товара) либо удаляются (группа актов списания полностью вычерпывают скл.запас по приходу от данного числп за данным документом) либо модифицируются (очередной расходный акт снимает со склада/секции N-ное кол-во товара, пришедшего ранее по соотв.приходному акту)
такая схема позволяет организовать достаточно надежный откат складских транзакций
MsGuns (2002-10-16 18:00:00) [51]Поверь старому складушнику-бухгалтерщику. Метод списания (расхода) по принципу давности хранения для ТОВАРОВ неприменим.
Когда бухи или кладовщики этого требуют, они не представляют себе все последствия их "экономичности" при работе с программой складского учета.
Я его применял много раз, но потом переделывал на полуручной или вообще выкидывал на фиг.
Кстати, на тему обязательного заведения новой карточки на каждом приходе товара. Это мог посоветовать только свистун (пардон, я так называю 1С-ников), у которого остатки "сбрасываются" не реже раза в месяц. Совершенно тухлая технология. Кроме того есть товар, МНОГОКРАТНО приходящий не только в течении месяца, а даже дня. Хлеб, молоко, например. И что же , если молока за день пришло по бидону 15 раз (часто даже с одного молокозавода), мне что, прикажете держать 15 позиций на складе ? Чушь собачья.
Polevi (2002-10-16 17:26:00) [52]есть таблица остатков товара
ТоварID ПриходID Колво
таблица содержимого счета ТСС
СчетID ТоварID Колво
расширенная таблица содержимого счета РТСС
СчетID ТоварID ПриходID Колво
юзер вводит данные в ТСС
при переводе счета в состояние, изменяющее остатки (у меня называеться СПИСАН) создаем курсор на таблице остатков и курсор на ТСС и добавляем записи в РТСС, вычитая из остатков, то есть одна строка
товар №1 100 штук в ТТС
может превратиться в 3 строки в РТСС
товар№1 20 приход1
товар№1 50 приход2
товар№1 30 приход3
при переводе счета в обратном направлении, количества из РТСС прибавляются к таблице остатков а строки из РТСС удаляются
у меня таким образом учитываются ГТД
если подобная схема кому то кажется кривой, буду рад познакомитсься с другими вариантами решения проблемы
Dmitry1 (2002-10-16 16:11:00) [53]вот я и прошу примерчик. чтобы посмотреть как другие это делают.
неужто никто не делал такие вещи.
Mike Kouzmine (2002-10-16 15:34:00) [54]Формируй накладную на отгрузку как обычно, а списывай столько, сколько нужно. Можно сделать так, что запись в накладной будет ссылаться на строчки прихода.
Dmitry1 (2002-10-16 15:28:00) [55]почему не FIFO ведь возможна же ситуация есть 2 прихода с суммарным количеством товара = "а" и один расход с количеством "а"
Александр Спелицин (2002-10-16 15:10:00) [56]>>а если мне необходимо продать товар из разных поставок...
то это уже не FIFO
Dmitry1 (2002-10-16 14:30:00) [57]а если мне необходимо продать товар из разных поставок?
Dmitry1 (2002-10-16 14:28:00) [58]откатыватся - допустим накладную перевели в статус продано (поставили галочку), клиент отказался от товара тогда эту накладную переводят в статус выписано. соответственно товар вернули на логический склад.
так вот я и хочу посмотреть как это другие реализовывают на уровне таблиц. возможно ли при этом использовать SQL или самому по таблицам бегать?
AndreyAG (2002-10-16 14:27:00) [59]В таблице приходов каждуую поставку товара делай уникальной по данному товару и после полной продажи товара освобождай поле индекса.
Mike Kouzmine (2002-10-16 14:15:00) [60]По дате.
А что значит откатываться?
Смотршь по номеру, складу и группе, какие были приходы, первая запись соответствует самому первому приходу, следующая - следующий и т.д. (сортировка по убыванию и , естественно, по дате в том числе)
| |
Страницы: 