Хорошее применение для метода LIFO в складском учете

← →
kaif © (2004-08-29 12:49) [0]

Я вот задумался о том, что применение метода FIFO в списании стоимости товаров приводит к неприятным вещам при межскладских перемещениях внутри одной компании. И предлагаю для перемещений использовать метод LIFO, даже если компания при продажах использует в основном FIFO.
http://www.gaapinvest.com/forum/konf.php?k=2&s=6059&b=1
Хотелось бы услышать Ваше мнение на этот счет.
Наверняка многим из участников приходится писать складские программы или иметь дело с таковыми.

← →
Nikolay M. © (2004-08-29 15:15) [1]

Какой метод использовать Фифо/Лифо/Средневзвес диктуется из соображения бизнеса в каждом конкретном случае. К тому же пример со складом некорректен. Изменения места хранения товара - это не его продажа, в твоем случае ты сам придумал грабли и сам же на них наступил. Имхо.

← →
Igorek © (2004-08-29 16:47) [2]

I>> применение метода FIFO в списании стоимости товаров приводит
> к неприятным вещам при межскладских перемещениях внутри
> одной компании
К каким именно? Можно пример?

LIFO нельзя применять ни в коем случае. У товара обычно есть срок годности. На складе обычно есть резервный запас. Так вот при LIFO некоторое колл. товара будет залеживаться. Или вообще никогда не покинет склад. А простроченный резерв никому не нужен. :-)

А есть еще разные учетные цены...

← →
kaif © (2004-08-29 16:58) [3]

Какой метод использовать Фифо/Лифо/Средневзвес диктуется из соображения бизнеса в каждом конкретном случае.
Так с этим никто и не спорит. Вопрос в том, что называть конкретным случаем. Конкретный случай бизнеса или конкретный случай конкретной строки конкретного документа? И как это сможет диктоваться в каждом конкретном случае, если одна и та же настройка метода списания в компьютерной программе задается для всех типов документов разом. А ведь именно так делается во многих складских системах.

К тому же пример со складом некорректен. Изменения места хранения товара - это не его продажа, в твоем случае ты сам придумал грабли и сам же на них наступил. Имхо.

Где это я перепутал изменение места хранения с продажей?
Я показал, как при межскладских перемещениях в большинстве случаев стоимость товара "нарушается", если применять FIFO и "не нарушается", если применять LIFO. И предложил применять FIFO при продажах, но при этом LIFO для межскладских перемещений. Где здесь путаница?
Мне кажется, Вы невнимательно читали то, что там написано.

← →
kaif © (2004-08-29 17:07) [4]

2 Igorek ©
Вы тоже, видимо, не читали ссылку. Речь идет об установках по умолчанию в складских программах. О том, как метод FIFO в большинстве случаев межскладских перемещений создает проблемы со стоимостью.
Так как исходную ссылку видно читать внимательно никто не хочет, привожу здесь текст полностью:
Если метод FIFO (first in/first out или первым пришел/первым ушел) используется в учетной политике компании, это не означает, что при создании учетной программы его следует понимать буквально и применять глобально. Давайте посмотрим, что произойдет в случае межскладского перемещения или возврата товара от покупателя при глобальном применении метода FIFO. Допустим, имеется 2 склада (и два складских счета). Некий товар в количестве 100шт присутствует на одном складе по стоимости 1000р/шт, а на другом - в таком же количестве по стоимости 1200р/шт. При перемещении со склада 1 на склад 2 всего товара произойдет списание его со склада 1 по стоимости 1000р/шт. Если его сразу "переместить обратно", то он вернется уже по стоимости 1200р/шт, так как "та партия" боле ранняя. Получается, что ситуация перемещение-возврат неэквивалентна просто отмене прежней операции. Я бы назвал это "необратимостью" операции. Похожая же ситуация возникнет со стоимостью, если средняя стоимость по каждому складу считается раздельно, а в учетной политике используется по средней стоимости. Тогда перемещение произойдет по стоимости 1000р/шт, а обратное перемещение - по стоимости 1100р/шт. ------------------------- Есть ли здесь проблема? По-моему есть. Довольна типична ситуация, когда приходит большая партия товара и сразу же распределяется по десятку складов подразделений компании, возможно, некоторые подразделения сразу возвращают часть товара обратно или перемещают его еще куда-то. При этом если на складах существовали остатки старых партий, то все стоимости начинают отклоняться от стоимости товара в этой партии, что может сбивать с толку менеджеров и складовщиков, которые склонны идентифицировать партии по стоимости (как правило так и бывает). Тогда возникает потребность всякий раз "отключить FIFO" и распределять всю партию "вручную", что чревато ошибками. ---------------- Какое здесь видится разумное решение? ---------------- А что если для учета межскладских перемещений и возвратов от покупателей применять (в основном) метод LIFO (last in/last out или первым пришел - последним ушел), даже в том случае, когда глобальная учетная политика продаж опирается на FIFO? Аргументы: 1. Методы FIFO, LIFO, средней стоимости, зарегистрированные в официальной учетной политике компании регламентируют лишь те ситуации, когда идентификация партии товара невозможна в принципе , например, при подсчете стоимости остатка топлива на бензозаправочной станции в условиях, когда топливо "разных артий" перемешивается и известно лишь, что на конец учетного периода там осталось "вот столько тонн". Исторически методы FIFO, LIFO, средней себестоимости происходят из ручного учета, при котором никто не отслеживал движение стоимости никаких партий online, а вместо этого делались периодические "инвентаризации" (опись) остатков имущества и нужно было как-то интерпретировать их состав для вычисления суммарной стоимости в ценах приобретения. Можно придерживаться точки зрения, в которой FIFO и LIFO не суть способы ведения бизнеса (когда что продавать), а лишь суть косвенные способы интерпретации остатков на конец учетного периода в условиях, когда иного (прямого) способа расчета стоимости остатков просто не существует. А во всех остальных случаях (когда каждая партия имеет свой отдельный счет) использовать любые иные методы, если они дают более прозрачный результат. 2. Корректная операция "возврата от покупателя" товара, который был продан в далеком прошлом (в предыдущих "учетных периодах) в условиях FIFO вообще невозможна, если не применять извращенных методов учета, которым наплевать на принцип периодизации учета. Вполне логично не восстанавливать "старую стоимость приобретения", которая, к тому же может быть еще и неадекватна из-за девальвации национальной валюты, а использовать стоимость последней партии такого же товара, если он присутствует на складе. Если же такого товара на складе вообще нет - можно использовать для начисления справочную закупочную или даже продажную стоимость (возвращаемые деньги) и это будет вполне адекватный подход. 3. Если во всех "межскладских перемещениях" применять метод LIFO при компьютерном учете, а в "продажах" - метод FIFO, то "стоимостная картина" получится максимально понятной всем и близкой к реальности. "Последняя большая партия" при распределении и перераспределении по складам не будет подвергаться искажениям в цене приобретения и будет легко узнаваема участниками процесса (менеджерами и кладовщиками). ------------------------ РЕЗЮМЕ ------------------------ Хорошие компьютерные программы складского учета не должны содержать глобальных настроек методов списания типа FIFO/LIFO/Ср.стоим/вручную, распространяющих свое действие на любые товарные приходно-расходные документы, а должны содержать эти настройки применительно к разным типам документов , как минимум. Чтобы можно было установить метод FIFO для "Продаж" и метод LIFO для "межскладских перемещений". Еще лучше, если имеются еще более тонкие настройки для документов "Продаж", позволяющие использовать разную политику списания партий для разных классов товара. Например, совсем необязательно партию колбасы, срок годности которой заканчивается через неделю, продавать после колбасы, срок годности которой заканчивается через месяц только потому, что первая партия "пришла позже". И ни один разумный человек так поступать не будет. Поэтому в этом классе товара нужна политика "в первую очередь выбирать партию с заканчивающимся сроком годности" или ручной выбор партии товара, тогда как в других классах товара (например, в "отделе пластмассы") может без заморочек использоваться обычное FIFO.

← →
Zacho © (2004-08-29 17:22) [5]

> Хорошие компьютерные программы складского учета не
> должны содержать глобальных настроек методов списания
> типа FIFO/LIFO/Ср.стоим/вручную, распространяющих свое
> действие на любые товарные приходно-расходные
> документы, а должны содержать эти настройки
> применительно к разным типам документов , как минимум.
> Чтобы можно было установить метод FIFO для "Продаж" и
> метод LIFO для "межскладских перемещений".

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

← →
kaif © (2004-08-29 19:22) [6]

2 Zacho ©
Насчет возможности "ручного выбора партии" я абсолютно согласен. И согласен с тем, что если этого не сделать, рано или поздно найдутся умельцы "вручную править базу", что намного хуже. Я вообще даже не хочу обсуждать то, как должна писаться программа. Я хочу обратить внимание на то, что для стратегии LIFO есть хорошая сфера применения (межскладские перемещения), что, как мне кажется, упускается из виду в самой философии учета. А что касается программ, то сам факт того, что я увидел такую возможную стратегию, наталкивает меня на мысль, что хорошая программа должна содержать не одну настройку, а массу настроек методов списания по умолчанию и самое важно деление настроек здесь:
1. Деление по типам операций (продажа, перемещение и т.п.)
2. Деление по классам товаров (уже в пределах продаж)
И если второе деление хорошо осознается разработчиками, то первое деление не осознается вообще (ИМХО). Поэтому я и поднял эту тему...

← →
KilkennyCat © (2004-08-29 19:51) [7]

> kaif © (29.08.04 19:22) [6]
> и самое важно деление настроек здесь:
> 1. Деление по типам операций (продажа, перемещение и т.п.)
> 2. Деление по классам товаров (уже в пределах продаж)
> И если второе деление хорошо осознается разработчиками,
> то первое деление не осознается вообще (ИМХО).

Гм... а у меня наоборот. Для меня класс товара - это просто некий тип, с набором свойств. Грамотно обрабатывать (реагировать) на эти свойства - это все, что меня занимает во втором пункте. А вот с первым пунктом я всегда мучаюсь до потери пульса, ибо видел ситуации, как искусственно "исчезали" товар при движении "склад магазина" -> "витрина" -> "клиент" -> "возврат от клиента (отказ в связи с поломкой) с возвратом денег" -> "склад ремонта отправка" -> "склад ремонта возврат" -> "возврат клиенту". На одном из этапов, информация, что клиенту вернули деньги, терялась. И готово - товар можно уносить.

← →
KilkennyCat © (2004-08-29 19:53) [8]

Оффтопом слегка... накрнец-то я могу заняться Аллегро! :)
Появилось время.

← →
DiamondShark © (2004-08-29 19:57) [9]

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

← →
Zacho © (2004-08-29 20:20) [10]

> Я хочу обратить внимание на то, что для стратегии LIFO
> есть хорошая сфера применения (межскладские
> перемещения)

Да, хоть у меня и весьма скромный опыт - но в 99% для межскладских перемещений требовалось именно LIFO. А для продаж - FIFO. А так как в системе с которой я тогда имел дело нельзя было выбрать FIFO или LIFO для конкретных операций, то приходилось или "шаманить" или непосредственно лезть в БД, и хрен знает, не аукнулись ли такие действия потом.
Так что, imho, настройки по типам операций - очень нужны.
Кстати, настройки для списания/возврата товара там были, а для перемещения - нет.

← →
Zacho © (2004-08-29 20:22) [11]

DiamondShark © (29.08.04 19:57) [9]
Для межскладских перемещений лучше вообще метод идентификации использовать.
А что это ?
P.S. Действительно, не знаю, не спец я в этом, а любопытно.

← →
DiamondShark © (2004-08-29 20:55) [12]

> Zacho © (29.08.04 20:22) [11]

Очень просто. Как только в обороте появляется какой-то товар (т.е. приходит "извне"), ему сразу присваивается идентификатор, который сопровождает потом товар на протяжении всего его жизненного цикла.
Это даёт возможность в любой момент времени мнгновенно по любому товару получить всю историю его движения.
А в межскладских перемещениях позволяет отписывать не просто "валенки левые, 17 штук", а "валенки левые, 17 штук, полученные по накладной №1234".

← →
Zacho © (2004-08-29 20:59) [13]

DiamondShark © (29.08.04 20:55) [12]
А зачем ? Обычный партионный учет и без всяких идентификаторов так и работает.

← →
KilkennyCat © (2004-08-29 21:05) [14]

> Zacho © (29.08.04 20:59) [13]

Это обычный. А есть - необычный :)

← →
DiamondShark © (2004-08-29 21:15) [15]

> Zacho © (29.08.04 20:59) [13]

Теперь уже я спрошу, что такое "обычный партионный учёт", и как он работает без идентификаторов.

← →
Zacho © (2004-08-29 21:24) [16]

DiamondShark © (29.08.04 21:15) [15]
Я сейчас не совсем трезв, так что буду немного косноязычен и краток :) Подробнее могу завтра.

В общем, все очень просто: есть документы: приход, расход, перемещение. Есть список номенклатуры. Имея эти документы можно отследить что угодно с партиями товара. Хм.. Кстати, вполне возможно, что мы с тобой говорим про одно и то же, только называем это по разному.

А маркировать каждую единицу товара.. Не реально, просто не реально.

← →
Zacho © (2004-08-29 21:29) [17]

> А маркировать каждую единицу товара.. Не реально,
> просто не реально.

Следует читать: уникально маркировать каждую единицу товара

← →
DiamondShark © (2004-08-29 21:30) [18]

> Zacho © (29.08.04 21:24) [16]

Не каждую единицу, а партию. Таки, возможно, говорим об одном и том же.

← →
DiamondShark © (2004-08-29 21:36) [19]

> Zacho © (29.08.04 21:29) [17]

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

← →
kaif © (2004-08-30 00:09) [20]

2 DiamondShark ©
Я думаю, что Вы действительно говорите об одном и том же. Партионный учет - техника, а уникальная идентификация единицы - решаемая этой техникой задача (если техника достаточно гибка, чтобы это позволить). Я полагаю, что в качестве партии может выступать любой набор атрибутов товара, в зависимости от класса:
1. В каких-то случаях это может быть просто закупочная цена, если купили еще раз по той же цене - считать той же партией, новую не заводить.
2. По сроку годности. Если он одинаков, то сколько раз бы не завозили "из этой партии сигарет", это та же партия (внутри партии применяем среднюю стоимость приобретения для списаний)
3. По цене+срок годности
4. По приходному документу (новый документ - новая партия). Этот метод я пока нахожу самым неудачным, хоть и самым распространенным.
5. По серийному номеру (для винчестеров и других товаров, имеющих длительные гарантийные обязательства или для ювелирных изделий, когда товар очень дорогой и уникальный).
Все это, ИМХО, настройки "политик списания" для разных классов товаров, имеющих, возможно, разную атрибутику.
Но при этом я хочу обратить внимание на LIFO, когда речь не идет о совсем уникальных идентификаторах и когда в принципе невозможно отличить единицы разных партий друг от друга физически, но нужно осуществлять продажи и межскладские перемещения, и таких операций много, и работать в "ручном режиме" эквивалентно отсутствию автоматизации вообще. А FIFO и, тем более, LIFO, становятся чем-то, что программист реализует лишь для "галочки", чтобы никто не сказал, что он этого не сделал. А на практике все его труды просто оказываются чем-то "очень важным" при покупке программы, но совершенно излишим при работе с ней.

← →
Сергей Суровцев © (2004-08-30 00:32) [21]

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

← →
Polevi © (2004-08-30 00:52) [22]

>[21] Сергей Суровцев © (30.08.04 00:32)
разные партии, разные цены
вопрос в том что при операции туда-сюда между скаладми по фйафо изменится денежное сальдо на скоадских счетах
другое дело что "Если его сразу переместить обратно" - на хрена спращивается это делать ? это помоему виноват не способ списания а культура работы... из той же оперы "а что будет если я откачу счет фактуру на транспотные услуги сумма которых легла на сырье из которго произвели товар и продали клиенту в прошлом перилде ?" Нефиг ! думать надо.. это в программе легко все между складами перемешается.. в реальной жизни никто не будет машинки туда сюда гонять..
учетная политика плохая, если такие вещи происходят

← →
kaif © (2004-08-30 01:22) [23]

Постараюсь еще более четко сформулировать то, как мне сейчас видится "идеальный склад" для большинства "больших задач", то есть с числом операций более тысячи строк в день:

1. Класс товара должен влиять на критерии образования новых партий. Назовем это "политиками партионного учета". Например, для микросхем номер ГТД нужен (хотя бы бутафорский), а для отечественного сыра - нет, но для последнего критична дата окончания срока годности.
2. Каждая партия, независимо от критерия, в соответствии с которым она создается, должна иметь "дату создания партии", если предполагается, что она будет хоть как-то участвовать в FIFO или LIFO. Одна партия не означает "один приход", но лишь (в общем случае) - способ группировки для мгновенного принятий решений о списываемой/начисляемой стоимости, так сказать, второй уровень после группировки по "товару". Одна и та же партия может многократно использоваться для приходов и расходов по ней, особенно, если у нее все признаки (цена, срок годности, ГТД и т.п.) совпадают.
3. Все способы выбора партий принципиально подразделяются на два: "ручной" и "автоматические" (FIFO, LIFO, ср.стоимость по складу). Назовем "автоматический" способ "политикой соотнесения с партией"
4. Каждый тип операции должен иметь отдельную настройку "политики соотнесения с партией" (продажа, межскладское перемещение, возврат на склад бракованной (подлежащей ремонту) продукции, перемещение с такого склада в ремонтную организацию, возврат поставщику и т.п.). Множество всех настроек по типам операций назовем "рабочей стратегией применения методов партионного учета".
============
В большинстве случаев (в обычной торговле и "ручной" способ не рассматриваем) представляется наилучшей "рабочая стратегия" в стиле:

1. При продажах применять "политику соотнесения партий" по FIFO
2. При обычных межскладских перемещениях применять LIFO
============
Основные аргументы:
1. Наиболее критичной в отношении обескураживающих учетных стоимостей единиц товаров является наиболее частая и типичная задача межскладского перемещения в условиях прихода "большой партии разных товаров", которые разные менеджеры "разносят по складам подразделений. Здесь ручной способ выбора партий очень плох, так как между моментом времени, когда менеджер видит, что осталось 100 штук и моментом подтверждения транзакции (сохранения готовой накладной) - этих 100 штук может уже на складе и не оказаться и менеджер получит сообщение о "провале проверки партии на неотрицательный остаток". Повторное редактирование накладной с указанием уже иной партии не гарантирует, что ситуация не повторится вновь.
2. Обратимость операций перемещения. В условиях FIFO или "средней стоимости по складу" операция перемещения приобретает необратимый характер (точно такое же обратное перемещение переместит уже совершенно иную стоимость). Если же работать по средней стоимости и при межскладском перемещении брать ее не "по складу", а "по двум складам", то мы изюежим необратимости перемещений, но в результате рано или поздно получим "ненулевой остаток стоимости" при нулевом остатке количества или сумасшедшую (неадекватную) стоимость "последней уходящей порции" товара.
3. Операция перемещения с встречным точно "таким же" перемещением вполне реальна, если товар вернулся со склада назначения (изменили решение). Представим себе физиономию менеджера, который отправил товара на $10,000, а ему на склад совершенно тот же товар вернулся уже по цене $13,000. И только потому что на складе назначения лежали "те же микросхемы памяти", но по старой цене, и FIFO аккуратно и неумолимо списало старую партию (как более раннюю) на новое перемещение. И еще представим себе, что зарплата или премия менеджера "зависит от прибыли", которую он приносит фирме, и которая считается по схеме "сумма продаж менеджера минус цена приобретения проданных товаров", а рынок микросхем бьется за каждый цент в текущей цене товара... При межскладских LIFO операциях ситуация искажения стоимости при распределении большой партии и многократных "встречных перемещениях" частей этой партии становится очень маловероятной, а при FIFO - наоборот, очень трудно избежать недоразумений и претензий к программисту со стороны обескураженных менеджеров.

← →
kaif © (2004-08-30 02:14) [24]

2 Сергей Суровцев © (30.08.04 00:32) [21]
Мне кажется отождествление прихода с партией (когда каждый приход инициирует партию) в условиях FIFO наиболее неудачным решением. Поясню, почему.
Допустим (а это очень типичная ситуация) фирма (скажем, ларек) продает сигареты Winston по цене 15р, закупая их по цене 12р на протяжении 6 месяцев:
===============
Закупка 1. 1000 шт
Продажа 1. 800 шт //списываем с Закупки 1
Закупка 2. 1000 шт
Продажа 2. 1000 шт //списываем 200 с Закупки 1
//списываем 800 с закупки 2
Закупка 3. 1000 шт
Продажа 3. 1000 шт //списываем 200 с Закупки 2
//списываем 800 с закупки 3
и так далее.
Итак, на каждую продажу мы заводим 2 строки списания, каждый раз из 2-х партий. В среднем это приведен именно практически к удвоению всех записей в таблице списаний, так как ненулевой остаток как правило всегда имеется, а закупается в среднем столько, сколько продается и мы всегда работаем "на стыке списания с двух приходов".

А теперь на секунду представим, что произойдет, если вдруг окажется, что в накладной месячной давности имелась ошибка и реально было поставлено 950 шт вместо 1000 шт. Юзер исправит "тот приход", наивно полагая, что так как "цена та же самая", ничего страшного произойти не может, так как остаток на складе сейчас более 300 пачек. Он рассчитывает, что остаток просто уменьшится до 250 пачек и результаты инвентаризации наконец сойдутся с документами.
Но не тут-то было. Оказывается, склад теперь весь нужно зачем-то "перепроводить" и "перетряхивать". Идеал программы, видимо, видится создателям таким:
Закупка N. 950 шт
Продажа N. 1000 шт //теперь уже списываем 150 с Закупки N-1
//а здесь уже списываем 850 с закупки N
и так далее....
А если несколько ошибок? А если в какой-то момент "в змейке" образуется минус количества? И все это из-за каких-то дурацких сигарет, которые всегда покупаются по одной цене и которые вполне можно считать совершенно проще, а именно так:

Товар Winston Light.
Партия по закупочной цене 12р
Заведена 13.02.2003 г.
Т-счет товарной партии:
Приход Расход по датам со ссылками просто на номера документов:
=============
1000
800
1000
1000
1000
1000
-------------(Итого)
3000 2800
=============(Остаток)
200

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

← →
Danilka © (2004-08-30 08:11) [25]

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

А чем плох вариант, когда все внутрифирменные движения между складами учитываются только количественно, но не в суммовом выражении?
А в суммовом, когда идет реализация, или списание.
В этом случае, можно вообще отказаться от партий, в общепринятом смысле, завести "упрощенные" партии. И все должно быть ровно, хоть по ФИФО, хоть по ЛИФО.

Просто, завести еще одну таблицу остатков с полями:
Товар
Дата прихода
Сумма
Количество прихода
Остаток

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

← →
Danilka © (2004-08-30 08:28) [26]

[20] kaif © (30.08.04 00:09)
Понятно. Просто я привык к партиям 1С-торговли, где в каждую партию жестко прописывается id документа-прихода, из-за чего возникают те-же грабли, что и с сигаретами в [24] kaif © (30.08.04 02:14).
Поэтому и обозвал такие партии "общепринятом смысле".. а они, оказываецца, совсем разные бывают. :)

← →
Danilka © (2004-08-30 09:19) [27]

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

← →
Polevi © (2004-08-30 10:01) [28]

>Danilka © (30.08.04 08:11) [25]
>А чем плох вариант, когда все внутрифирменные движения между >складами учитываются только количественно, но не в суммовом >выражении?
ну и по каким ценам склады будем счиать, по учетным ?
склады ведь разные бывают, на склад "производство" как предлагаете списывать ? как формировать себестоимость ГП ?
а бух. схема должна быть единая для всех перемещений имхо

>kaif © (30.08.04 02:14) [24]
>Юзер исправит "тот приход"
в номрмальной программе он не сможет этого сделать, для этого существует механизм сторнирования

>Danilka © (30.08.04 09:19) [27]
что значит "внутри фирмы" ? что такое "фирма" ?
внутри одной структуры может быть много складов по разным юр. лицам и для "внутрених" перемещений потребуются официальные накладные... с ценам

[29] Polevi © (30.08.04 10:04)
Если юрлица разные, то простым перемещением нельзя делать. Просто, по-закону нельзя. Это уже будет реализация.
А на счет производства - надо подумать. Конечно, там уже необходимо знать себестоимость материалов передаваемых в производство.

В конце концов, склад и производство - два разных понятия. Внутреннее перемещение со склада на склад это одно, а передача материалов в производство - другое. Даже формы док-тов разные.

поставщик -> склад 1 -> склад 2 -> производство
по какой цене последнее перемещение будем делать ?

[32] Polevi © (30.08.04 10:16)
Например, ФИФО:

1 20.08.2004 приход от поставшика 10 штук, по 5 рублей на 1 склад
таблица партий, новая запись:
дата=20.08.2004, стоимость=5, количество=10, остаток = 10

2 21.08.2004 перемещение с 1 склада на второй 1 штука
таблица партий - не трогается, меняем остатки на складах.

3 22.08.2004 приход от поставщика 5 штук, по 3 рубля на 1 склад
таблица партий, новая запись:
дата=22.08.2004, стоимость=3, количество=15, остаток = 15

2 23.08.2004 перемещение с 1 склада на второй 20 штук
таблица партий - не трогается, меняем остатки на складах.

5 24.08.2004 передача в производство 14 штук со второго склада.
считаем себестоимость по ФИФО:
приход от 20.08.2004 полностью закрываем, остаток = 0, общая стоимость товаров = 50р.
приход от 22.08.2004 уходит 4 штуки, общая стоимость = 12р.
итог, в производство ушло материалов на сумму 62р.,
а таблица партий выглядит вот-так:

дата=20.08.2004, стоимость=5, количество=10, остаток = 0
дата=22.08.2004, стоимость=3, количество=15, остаток = 11

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

[34] Polevi © (30.08.04 10:42)
Возможно. Я просто высказал предположение, вариант по которому не будет проблем вроде тех, с которых началась ветка. А у самого опыта работы в этой области почти нет.

← →
VICTOR_ (2004-08-30 11:03) [36]

>kaif © (30.08.04 02:14) [24]

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

При изменениии входной цены, а не количества, возникает все та же проблема с перепроведением партий.

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

VICTOR_ (30.08.04 11:03) [36]
Тут рассмотрен 1 конкретный случай, когда входная цена неизменна, а изменено количество.
При изменениии входной цены, а не количества, возникает все та же проблема с перепроведением партий.
Перемещение между скаладами действительно лучше делать из конкретных партий.
Параметры партии при изменении склада оставлять неизменными.

Совершенно верно. Однако я пишу универсальную систему (платформу) и мне нужно предусмотреть все возможные случаи, не заморачиваясь на конкретные реализации. Поэтому я и обсуждаю принципы. У меня есть конкретный пример заказчика перед глазами, у которого имеется 10 складов (магазины) и основной частой операцией, которая производится, является именно межскладское перемещение. И перемещаются как правило большие списки товаров. Уточнять руками партию для каждого совершенно бессмысленно. Вполне устраивает, если это будет делаться автоматически. И ситуация с ценой, которая долго не меняется, а если меняется, то это всегда сопровождается инвентаризацией остатков - тоже одна из возможных и очень частых ситуаций в бизнесе. Если у заказчика именно такая ситуация, а таких заказчиков много - засовывать ее в прокрустово ложе лотового учета означает, что ряд разработчиков просто откажутся от моей платформы в пользу более простых решений, в которых "перетряхиваниями" заниматься не нужно. Я вообще не сторонник существования в системе лишней информации. Сведение попартионного учета к "лотовому" (приход и есть партия) есть такой способ создавать несуществующюю информацию. На самом деле при ситуации
+1000 -800 +1000 -1000 +1000 -1000
совершенно искусственно говорить, что в третьем расходе оказались ровно 200 шт из второго прихода и 800 шт из третьего.
С таким же успехом я могу заявить, что все 1000 это 1000 из третьего прихода. А остаток лежит - из второго прихода 200шт. Здесь есть неопределенность, которая может использщоваться во благо (упрощать жизнь), а может использоваться во зло (создавать избыточные данные о "якобы движении") и эти данные, так как они построены на предположении, высосанном из пальца, всегда имеют вероятность придти в противоречие с реальностью, если какие-то данные исправляются.
Я пытаюсь все время разработать принципы учета и техники его реализации, которые были бы наиболее устойчивы к редактированию задним числом. Просто потому что это удобно. Но оказывается, что это не просто удобно, но и правильно. Правильно, когда не программа ограничивает человека в возможностях, а он сам ограничивает себя в возможностях. "Мы не будем исправлять задним числом то-то и то-то потому что...(далее должна идти фраза, диктуемая соображениями иными, чем "... потому что наша прогарамма этого делать не умеет")

>Polevi © (30.08.04 00:52) [22]
>учетная политика плохая, если такие вещи происходят

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

>kaif © (30.08.04 02:14) [24]
В целом правильный пример. Если Вы разложите эти
строки еще и по атрибутам партий, а не только по
сумме и количеству, то кроме чисто бухгалтерских
задач решите еще и управленчискую - паралельно и
безо всяких усилий увидите насколько быстро расходятся
партии товаров, полученных от разных поставщиков
и в разное время. Мы привыкли к нашим условиям,
когда цена прихода всегда разная, но в идеале это
может быть совсем не так. К примеру товар даже от
одного поставщика может приходить в течении года
по одной цене. И четко отслеживая приходы мы можем
отслелить к примеру некачественную партию, или же
наоборот увидеть, что партия в новой упаковке расходится
быстрее. Задачи учета сегодня намного шире чисто
бухгалтерских.

>Юзер исправит "тот приход", наивно полагая, что так
>как "цена та же самая", ничего страшного произойти не
>может

Ни в коем случае! Этот юзер в данном случае наивно
полагает что может безнаказанно скрыть свою ошибку
в лучшем случае незаметно, в худшем - свалив все на
программу.
Правильным решением в данном случае будет допровести
пропущенные 50шт. отдельно. И дальше они пойдут в списание
по общей схеме. Иначе Вы повесите себе головную боль,
растущую в геометрической прогресии.

Кроме того есть еще и такая гадская вещь как ГСМ, в
которых определить конкретную цену при перемещении
вообще невозможно, работает чисто условный механизм,
который в идеале все таки должен попадать в общую
схему учета.

А насчет 2х записей, может быть и больше. Особенно на
ГСМ. Но что тут поделать? На мой взгляд задача системы
позволять вести полноценный учет, а не экономить несколько
мегабайт на нынешних гибайтных винтах. :)

2 Сергей Суровцев ©
OK
Тогда скажите мне, зачем вообще существует принцип LIFO?
Для "галочки"?
Или его изобрели идиоты?
Какой вообще в нем смысл?
Если в нем смысла нет, то те, кто его вообще реализует - странные люди. Видимо, это просто рекламный трюк: у нас даже LIFO есть, которое на фиг никому не нужно! Следовательно, все, что нужно у нас уж как минимум есть. Так, что ли?
Ведь я веду разговор только об одном:
Нужны ли раздельные настройки по умолчанию FIFO/LIFO в зависимости от типа складской операции. А при этом выясняется, что LIFO вообще не должно быть. Но тогда его тем более не должно быть на уровне "всего склада вообще". Если же я спускаю настройку никому не нужного выбора в пользу LIFO с уровня "склада вообще" на уровень "операции данного типа", я всего лишь создаю вероятность применимости LIFO хоть в каком-то случае. Если мне говорят, что таких случаев вообще быть не может в принципе, то тогда зачем вообще говорить о FIFO, LIFO, средней стоимости и настройках? Тогда существует только лотовый учет и никакой другой учет не возможен в принципе. Так и запишем.
Если кому-то нужно считать количество мух, летающих в какой-то комнате, нужно сначала каждую муху снабдить штрих-кодом, окольцевать и далее заносить в базу данных каждое ее движение по комнате. Это и есть единственный и неповторимый способ считать мух компьютерным способом... Но заказчик не всегда думает так же. И я на его стороне. Если заказчик имеет дело с очень редким и ценным видом мух, занесенных в Красную книгу, то я готов ему предоставить инструментарий для кольцевания этих мух и создания паспортов для каждой мухи с именами "Машка", "Цокатуха", с любой степенью защиты и водяными знаками, но если это обычные мухи, то пусть у него будет возможность считать их поголовно и может быть даже приблизительно, если главная задача - избавиться от мух наиболее доходным способом, а не изучать повадки ценных вымирающих пород дивной красоты...

[37] kaif © (30.08.04 14:48)
Если взять этого конкретного заказчика у которого 10 магазинов и частые перемещения между ними, то почему ему не подойдет мой способ: перемещения учитывать только количественно, а реализацую уже по FIFO?
Просто интересно, какие здесь могут быть подводные камни. Если все равно, внутренние перемещения учитывать по-одному, а себестоимость реализации по-другому?

Хорошее применение для метода LIFO в складском учете Найти похожие ветки