iBase.ru Forum

Никому не приходилось сталкиваться с такой задачей, как организация FIFO (склад) в Firebird?

покупаем 100 единиц товара А по цене 100,
покупаем 50 единиц того же товара по цене 105
... и т.д.

Затем продаем скажем 120 единиц товара А и программа расчитывает складскую цену по принципу First In First Out.

операций купли-продажи естественно может быть очень много...
также возможно исправление данных задним числом. Например, после продажи 120 единиц оказывается, что в первый раз мы купили не 100 а 90 единиц, мы исправляем количество и программа сама исправляет продажную накладную.

tihhanovski писал(а):продажи 120 единиц оказывается, что в первый раз мы купили не 100 а 90 единиц, мы исправляем количество и программа сама исправляет продажную накладную.

Ага. И клиент никогда не узнает что он купил оказывается 90 штук, а не 100. И документы у него не правильные, а 10 штук он просто спи...л.
Перед тем как делать такие вещи надо ознакомиться хотябы с основами бух учета, и узнать что никогда не меняют исходный документ а делают корректрующий.

eugeney писал(а):

tihhanovski писал(а):продажи 120 единиц оказывается, что в первый раз мы купили не 100 а 90 единиц, мы исправляем количество и программа сама исправляет продажную накладную.

Ага. И клиент никогда не узнает что он купил оказывается 90 штук, а не 100. И документы у него не правильные, а 10 штук он просто спи...л.
Перед тем как делать такие вещи надо ознакомиться хотябы с основами бух учета, и узнать что никогда не меняют исходный документ а делают корректрующий.

Да нет, он имел ввиду, чтобы для отпущенных товаров пересчиталась закуп. цена.

2tihhanovski Я делал такое. Это гемор такой, что дай дорогу. Работай с актуальным пересчетом.

Я уж думал, что никто не ответит, тема-то по-моему интересная - sql и стэки

eugeney, ты своим потенциальным клиентам тоже отвечаешь, используя "ненормативную" лексику, когда они такие вещи спрашивают?
В реальности и исходные документы меняют (хотя вроде как бы и нельзя), а еще чаще всплывают вовремя невнесенные в программу покупочные счета, а это значит, что какое-то время надо продавать "в минус" и. т.д. и т.п. Ты похоже действительно знаком только с основами бухучета (или работаешь в налоговой инспекции), так что попрошу **********************************.
[вырезано администрацией форума. предупреждение за грубость.]



Slava Ekimov, я тоже такое делал, причем три раза:
в первый раз пересчитывалось на клиенте (delphi), но это ужасно тормозило в сети и даже с localhost при росте количества записей.

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

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

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

А что ты имел в виду под "актуальным пересчетом"?

tihhanovski - уверен, что это относится к теме форума ?

hvlad писал(а):tihhanovski - уверен, что это относится к теме форума ?

Если есть более подходящий thread, то буду признателен за информацию

tihhanovski писал(а): Например, после продажи 120 единиц оказывается, что в первый раз мы купили не 100 а 90 единиц, мы исправляем количество и программа сама исправляет продажную накладную.

ответь на вопрос как программа исправляет продажную накладную которая находиться у клиента?
Еще если двигать все продажи то тогд ане сталкивалсяя с тем что есть вещи которые идентифицируют товара например серийные номера, номера ГТД и т.д.? Нельзя так просто двигать продажи.

Если тебя интересует только расчет склада то проще считать вначале сумму пришедшнго товара потом сумму ушедшего (в приходных ценах), и вычитать. ТОгда все будет на сервере и бытро.

Можеш использовать 2 паралельных курсора для чтения прихода и расхода в начала времен. Это позволит делать все вычисления на сервере без временных тиаблиц.

Вот этот алгоритм называется LIFO

tihhanovski писал(а):для каждого товара делалась как на клиенте табличка куда загонялись все приходы, а затем они оттуда в обратном порядка выбирались в соответствии с "уходами".

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

Небольшой оффтоп.
2tihhanovski
Нечто подобное есть у меня. Работает, по скорости устраивает. Никаких доп.таблиц для расчета не потребовалось. Выполнено в виде хп на вход которой идет пк номенклатуры, пк склада; а уж эта хп вызывается либо в модуле отчета остатков, просмотра документа, ведомостей продаж и т.д., т.е.расчет делается на лету по запросу клиента. В моем случае (на моих задачах) сложностей никаких не было, продумать и попричесать запросы и все.

eugeney писал(а):Перед тем как делать такие вещи надо ознакомиться хотябы с основами бух учета, и узнать что никогда не меняют исходный документ а делают корректрующий.

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

eugeney писал(а):ответь на вопрос как программа исправляет продажную накладную которая находиться у клиента? Еще если двигать все продажи то тогд ане сталкивалсяя с тем что есть вещи которые идентифицируют товара например серийные номера, номера ГТД и т.д.? Нельзя так просто двигать продажи.

Речь не о том, точнее, не о таких задачах.

tihhanovski писал(а):

hvlad писал(а):tihhanovski - уверен, что это относится к теме форума ?

Если есть более подходящий thread, то буду признателен за информацию

http://www.sql.ru/forum/actualtopics.aspx?bid=36
http://www.sql.ru/forum/actualtopics.aspx?bid=58

tihhanovski писал(а):Никому не приходилось сталкиваться с такой задачей, как организация FIFO (склад) в Firebird?

Я пока написал пару складских программ. Списание шло по среднему, однако, сути это не меняет. Есть две проблемы реализации: расчет остатков на определенную дату, форма их хранения (это описано во многих источниках в сети) и проверка на "корректность" проведения документа на указанную дату (описание этого я нигде не видел, но реализация зависит от формы хранения остатков). У тебя только отличается алгоритм пересчета остатков, а проблемы те же.
Конкретно алгоритмы тут приводить бессмысленно, потому что все зависит от конкретных условий (важную роль играет интенсивность товаро-движений на складе). Задача на проверку корректности проведения сводится примерно к следующему: посчитать остатки на указанную дату для каждого товара в документе и пересчитать ВОЗМОЖНЫЕ остатки, если документ будет проведен. Если и в первом и во втором случае получаются корректные результаты, то можно смело проводить документ, в противном случае - выдавать ошибку

sag писал(а):Небольшой оффтоп.
ведомостей продаж и т.д., т.е.расчет делается на лету по запросу клиента. В моем случае (на моих задачах) сложностей никаких не было

sag, спасибо большое за ссылки, у меня просто глаза разбегаются, в том форуме столько интересных заголовков!

А сколько у тебя записей в таблице передвижений товаров, ведь при росте количества записей будет расти и время, потраченное на пересчет?

eugeney писал(а): ответь на вопрос как программа исправляет продажную накладную которая находиться у клиента?

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

eugeney писал(а): Еще если двигать все продажи то тогд ане сталкивалсяя с тем что есть вещи которые идентифицируют товара например серийные номера, номера ГТД и т.д.? Нельзя так просто двигать продажи.

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

eugeney писал(а): Если тебя интересует только расчет склада то проще считать вначале сумму пришедшнго товара потом сумму ушедшего (в приходных ценах), и вычитать. ТОгда все будет на сервере и бытро.

Так оно и есть, но сначала надо знать цены(в приходных ценах) ушедших товаров, в этом и есть весь вопрос.

eugeney писал(а): Можеш использовать 2 паралельных курсора для чтения прихода и расхода в начала времен. Это позволит делать все вычисления на сервере без временных тиаблиц.

А в хранимой процедуре в firebird можно открывать курсоры? Как?

eugeney писал(а): Вот этот алгоритм называется LIFO

LIFO в нашей стране использовать к сожалению нельзя. запрещено законом.

eugeney писал(а): В общем не заморачивай голову, делай все расчеты в момент закрытия периода, и замараживай изменения.

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

tihhanovski писал(а):А сколько у тебя записей в таблице передвижений товаров, ведь при росте количества записей будет расти и время, потраченное на пересчет?

Не очень много. В приложении, в котором применяется эдакий расчет, цифирьки примерно такие: складов 6, номенклатур ~30-40тыс, постоянно присутствует на складах ~15тыс наименований, табличка с движеньями ~2-2.5млн.
Расчет по позиции (номенклатуре) производится отталкиваясь от текущего остатка (отдельная табличка) отматывая приходы/расходы.
Чтобы меня не сильно побили за полный оффтоп, скажу, что на fb1.5.2wincs, сделав хорошие и нужные индексы, местами насильно направив оптимизатор в нужном направлении, на железке о двух гловах, скорость такого обсчета приемлемая.

tihhanovski писал(а):

eugeney писал(а): Вот этот алгоритм называется LIFO

LIFO в нашей стране использовать к сожалению нельзя. запрещено законом.

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

sag писал(а):В приложении, в котором применяется эдакий расчет, цифирьки примерно такие: складов 6, номенклатур ~30-40тыс, постоянно присутствует на складах ~15тыс наименований, табличка с движеньями ~2-2.5млн.

RESPECT!!!

мне до такого еще расти и расти...

Slava Ekimov писал(а): Может, в официальной бухгалтерии?
А как я внутри учитываю, никого не должно касаться.

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

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

tihhanovski писал(а): мне до такого еще расти и расти...

Эх мнебы ваши цифры, у меня максимум 5000 записей в секунду влазиет. Не успевается входящая инфа обрабатываться

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

Ага. Вот и видится не возможность в конкретном случае оторвать учет товара от фактического движения. Вот если мы будем работать по LIFO, копить гоклый хлеб. А по документам будет учет по ср. себистоимости?
Интересно как ср. себестоимость будет выглядеть в случае с хлебом Крошкам перемешивать?

P.s. Сегодня пятница этот пост немного юмора

tihhanovski писал(а):Да и вообще, я не вижу смысла использовать LIFO, ведь в реальности это значит, что на складе остаются самые "старые" товары и продаются всегда самые новые, а это искажает доход и денежное состояние склада.

Так продавать можно, потому что товары продаются такие, какие нужны, просто цены списания этих товаров беруться "старые".

Метод FIFO, насколько я понимаю, уменьшает себестоимость (при производстве) или просто затраты (при торговле), а сответственно увеличивается прибыль и налоговое бремя, а также размер оперативных (кажеться это так называется) средств, а метод LIFO - наоборот.

Gust писал(а): Метод FIFO, насколько я понимаю, уменьшает себестоимость (при производстве) или просто затраты (при торговле), а сответственно увеличивается прибыль и налоговое бремя, а также размер оперативных (кажеться это так называется) средств, а метод LIFO - наоборот.

Вот поэтому значит LIFO в нашей полицейской республике и запрещено

eugeney писал(а): Эх мнебы ваши цифры, у меня максимум 5000 записей в секунду влазиет. Не успевается входящая инфа обрабатываться

Двойной RESPECT!!!

это типа сети универмагов в каждом городе страны типа России или США?
и все в онлайне? (если не секрет)

eugeney писал(а): Интересно как ср. себестоимость будет выглядеть в случае с хлебом Крошкам перемешивать?

ага, допустим, покупаем 1000 буханок хлеба весом 400кг. После прихода мы их пропускаем через огромную мясорубку, потом все время мешаем чтобы добиться лучшего усреднения, и когда клиент покупает буханочку, ма насыпаем ему в пакетик 400г хлебной трухи. На удивленные возглас покупателя гордо отвечаем: "А у нас так склад устроен!"