Коррекция по FIFO

[AS850]

Добрый день!

Система NAV5 SP1.

Дано:
Товар Х учитывается по FIFO.

5 сентября закупает товар Х 10шт. по цене 1.00.
6 сентября продаем товар Х 3 шт. по себестоимости 1.00.

После регистрации предыдущих транзакций, регистрируем еще одну закупку товара Х 20 шт. по цене 0.90 от 2 сентября.
Выполнив коррекцию себестоимости, себестоимость проданных 3 шт. равна 3, а не 2.70 (таблица 5802).

Вопрос:
1. FIFO не работает корректно?
2. Как решать данную проблему?

Спасибо.

[GalaM]

А почему FIFO работает не корректно.
FIFO - first in first out

По системе первая закупка (после учета документа от 2 сент) как раз и стоит 0,9 за шт, то есть за 3 шт. - 2.70.

Я правильно понимаю, что Вы пересчитывать уже проданный товар не хотите?

[AS850]

Должно было быть 2.70, а в системе 3.00

[apanko]

Цитата:

Сообщение от AS850

Должно было быть 2.70, а в системе 3.00

В момент списания расходная операция связывается (применяется) к приходной и при коррекции, стоимость из приходной операции переходит в расходную.
Новые операции, независимо от их даты, на уже проведенные операции не влияют (при методе ФИФО).

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

[GalaM]

Цитата:

Сообщение от AS850

Должно было быть 2.70, а в системе 3.00

Не могли бы Вы пояснить логику рассуждений почему же 3.00.

А как этого избежать - см. ответ от apanko.

[AS850]

2 gala:

Наверное, я не ясно высказался:
мне требуется чтобы было 2.70 (по логике FIFO), а система сосчитала 3.00. И то, что система не корректирует с 3.00 на 2.70 меня очень огорчает.

По поводу как избежать (спасибо за советы):
1. Перейти на средневзвешанное: клиент желает FIFO
2. Хронологически вводить данные: неплохо, но не реально. В конце месяца, появляются всякие счета и накладные за весь месяц
3. Использовать журнал приложений: попробывал - работает. Но если эта запись только начало цепочки, то тогда придется все пересвязывать. А при большом количестве накладных, это затруднительно.

Увы, но получается, что FIFO не корректируется.

[Arshak]

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

[RedFox]

Цитата:

Сообщение от AS850

Система NAV5 SP1.

Дано:
Товар Х учитывается по FIFO.

5 сентября закупает товар Х 10шт. по цене 1.00.
6 сентября продаем товар Х 3 шт. по себестоимости 1.00.

После регистрации предыдущих транзакций, регистрируем еще одну закупку товара Х 20 шт. по цене 0.90 от 2 сентября.
Выполнив коррекцию себестоимости, себестоимость проданных 3 шт. равна 3, а не 2.70 (таблица 5802).

Все правильно, так как:
операция 1 - 5 сентября
операция 2 - 6 сентября
операция 3 - 2 сентября (система, как и человек (а она работает по алгоритму от челолвека), в момент учета операции 2 совершенно не знает, что будет операция 3)! Задайте этот вопрос пользователю и пусть они расспишет на бумаге МНОЖЕСТВО операций!

Цитата:

Вопрос:
1. FIFO не работает корректно?

система считает не по дням, а по операциям прихода-расхода

Цитата:

2. Как решать данную проблему?

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

[AS850]

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


Вопрос:
делаем перемещение 20 шт. со склада А на склад Б. В результате, в товарных записях (таблица 32) получаем:
Запись №1: А -20 шт.
Запись №2: Б +15 шт.
Запись №3: Б + 5 шт.
Т.е. 1-й записи ухода со склада А соответствует несколько записей прихода на склад Б. Причина: уход осуществляется из нескольких приходов на склад А.

Возможно ли достичь того, что бы приходная запись была бы одна с полным количеством? Или есть подводные камни, и не стоит пытаться делать такую модификацию?

[RedFox]

Цитата:

Сообщение от AS850

Возможно ли достичь того, что бы приходная запись была бы одна с полным количеством? Или есть подводные камни, и не стоит пытаться делать такую модификацию?

Один украинский партнер тоже сделал объединение такого рода, но потом сильно пожалел об этом.
Если это товар, который потом заказчик слушайно захочет завозить партионно или по серийникам, то сразу скажу, что ВСЁ сломается, если не ставить какой-то признак например на Товаре или СКУ, а зачем разрезать учет по этому признаку.

У меня возник вопрос - а зачем такое делать??

[apanko]

Цитата:

Сообщение от AS850

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


Вопрос:
делаем перемещение 20 шт. со склада А на склад Б. В результате, в товарных записях (таблица 32) получаем:
Запись №1: А -20 шт.
Запись №2: Б +15 шт.
Запись №3: Б + 5 шт.
Т.е. 1-й записи ухода со склада А соответствует несколько записей прихода на склад Б. Причина: уход осуществляется из нескольких приходов на склад А.

Возможно ли достичь того, что бы приходная запись была бы одна с полным количеством? Или есть подводные камни, и не стоит пытаться делать такую модификацию?

Собственно вопрос: зачем?

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

Мне кажется оно того не стоит.

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


UDP. Для информации - при методе учета "По Средней" создается одна приходная операция.

[apanko]

Цитата:

Сообщение от Arshak

если нужен совет могу дать.. отключите применение операций в 22 кю и сделайте задание по применению (или пристройте его к коррекции)
и запускайте его после закрытия периода для изменений.. а на период до закрытия периода довольствуйтесь средней себестоимостью по которой будет идти учет на этот период. ИХМО

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

[Arshak]

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

[apanko]

Цитата:

Сообщение от Arshak

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

Спасибо.

[Arshak]

Цитата:

Сообщение от apanko

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

спортивный интерес заставил поэкспериментировать
после некоторого насилия над 22 КЮ я заставил перемещать не применяя..
а потом запускал применение. на удивление все отработало прилично. применило к нескольким приходам и потом откорректировало всю цепочку перемещения.
но есть одно большое НО! так как мы при перемещении не применяем операции то получаем одну приходную операцию после перемещения. Соответственно себестоимость этого прихода уже средняя и списываться в дальнейшем будет по средней для этого перемещения. Поясню
есть 2 прихода
2шт -100 руб=200руб
3шт- 120 руб=360руб
перемещаем 3 штуки
итого на другом складе
3 шт -320 руб.
Если с этого склада продать или переместить одну штуку то будем иметь 1шт - 320/3=106,66 а никак не 100 или 120!
Соответственно вывод если мы будем перемещать без привязки к конкретным приходным операциям то о FIFO можно забыть или если забить, то можно экспериментировать..
Но мой совет не насиловать систему и себя.. в текущем состоянии все работает вменяемо..

[GRIZZLY_imported]

По требованию клиента изменили механизм применения, т.к. с его точки зрения ФИФО работало некорректно. Оно ему требуется именно в том виде, в которой требуется трендстартеру. Суть идеи: применение делается не товарных операций, а учтенных документов. Обрабатывается учет документов задним числом, кредит-ноты продажи и покупки. Себестоимость продажи хранится прямо в строчке учтенного документа. Модуль Бухгалтерии не используетя (т.е. за проводки не паримся). Чем все закончится - доложусь

[Eugeny_F]

Чего-то ничего не понятно. Что такое применение на уровне учетных документов? Как у вас вообще будет привязываться приходы к расходам? Вы вообще не будете использовать данные таблиц 32, 5802 и 339? Изменится ли себестоимость продажи в строке учтенного докмента при коррекции стоимости связанного с ним прихода (вводе издержек)?

[GRIZZLY_imported]

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

[Eugeny_F]

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

[RedFox]

Цитата:

Сообщение от Eugeny_F

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

Был такой клиент - сначала накастомизировали кучу.. А потом он начала читать документацию и хотеть большего. В итоге - NAV свернули и поставили 1С 8.0 (потому что контора почти прогорела). Но!! Дело не в том, что заменили систему. А в том, что кучу бабла вбухали, а результат они не получили! ВОПРОС - зачем изначально было ерундой страдать и придумывать себе правила взамен экономики, обкатанной временем?