denisfed: Обновление статьи о закрытии склада.

[fed]

По поводу FIFO: Мне знакомые из одной крупной аудиторской фирмы говорили что в российском законодательстве НЕТ никаких регламентирующих документов по рассчету себестоимости по FIFO/LIFO/Средней. Более того, они мне рассказали что во время аудитов проверяют правильность рассчета себестоимости по FIFO следующим образом:
1. Берут остаток в рублях и штуках.
2. Суммируют себестоимость последних приходов, до тех пор пока не наберут число штук, равное количественному остатку.
3. Если себестоимость в приходов рублях не совпадает со складским остатком по номенклатуре - значит присутствует ошибка.

А вообще - если книжки по западному бухучету почитать, то FIFO/LIFO, это не методы оценки СПИСАНИЙ. Это методы оценки ЗАПАСОВ, то есть складского остатка. Поэтому допущение что каждое списание должно нести стоимость какого-то прихода - слишком сильное. На самом деле - достаточно чтобы стоимость запасов, равнялась стоимости последних (или первых в случае LIFO) приходов. И это условие выполняется даже с учетом странностей в журнале переноса, о которых ты пишешь.

То что в Аксапте себестоимость списаний обычно равна себестоимости приходов, это просто следствие применения самого распространенного (но не единственного) подхода к оценке ОСТАТКОВ. В принципе я мог бы написать код, который где-то в памяти считает себестоимость остатков по FIFO, потом себестоимость списаний, а потом себестоимость списаний размазывает по всем списаниям пропорционально количеству. Хотя эту схему тяжело выверить, но формально она вполне законна.

Кстати - отвлекаясь от теории: Да - можно было бы подправить логистику в Аксапте таким образом, чтобы элементарной единицей себестоимость было бы сочетание лот+аналитика финансового склада. Но в этом случае придется еще и сделать следующее:
1. Пришлось бы в складские проводки засовывать не только ссылку на родительский лот (inventTransIdFather), но и ссылку на родительскую аналитику. Причем главной сложностью при реализации, было бы придумать способ связать аналитику источника и приемника для всех случаев.
2. Запретить в обычном журнале переноса менять аналитику финансового склада.
3. Сделать какой-то новый тип журнала в котором, можно сливать/разделять партии или вообще аналитики финансового склада. НО: Их можно было бы менять не чаще одного раза в журнале (то есть - если склад тоже аналитика финансового склада, то нельзя было бы сразу и две партии слить и со склада на склад перенести).
4. Учитывая что в системе есть куча вариантов переноса (карантинный заказ, WMS-вские транспортировки, заказ на перенос), пришлось бы продумать и реализовать дисциплину переноса между аналитиками финансового склада и для этих типов складских документов.

[miklenew]

Цитата:

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

По поводу FIFO: Мне знакомые из одной крупной аудиторской фирмы говорили что в российском законодательстве НЕТ никаких регламентирующих документов по рассчету себестоимости по FIFO/LIFO/Средней.

Может я не правильно понял. Но здесь есть.
Глава 25. Статья 268. Особенности определения расходов при реализации товаров и (или) имущественных прав
http://www.garant.ru/main/10800200-025.htm#0

[fed]

Цитата:

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

Может я не правильно понял. Но здесь есть.
Глава 25. Статья 268. Особенности определения расходов при реализации товаров и (или) имущественных прав
http://www.garant.ru/main/10800200-025.htm#0

Конечно упоминания методов ФИФО/ЛИФО/Средняя в регламентирующей документации имеются. Но внятного описания алгоритмов - нет. Как например мне оценивать себестоимости списания ? Или как округлять при усреднении ?
Ну то есть - может мои данные об отсутствии регламентации устарели (Я вобще за нормативной базой не слежу), но именно в этом документе алгоритмов рассчета себестоимости запасов или себестоимости выбытия я не увидел.
Кстати - в качестве байки: Однажды я видел бухгалтершу, которая мне доказывала что если она оценивает складской запас в штуках на цену последней закупки - то это и есть ЛИФО (Оценка по стоимости последней закупки). Попытки объяснить ей что она не совсем права - натыкались на стену непонимания. Зависшие в конце месяца остатки в рублях при нулевом количестве, они там как-то закрывали на 90ый счет кажется.Не знаю уж как они там отчетность сдавали Возможно дело было в том, что это был крупный налогоплательшик и если они платили в бюджет региона столько сколько их просили, то до уровня нарушений в методиках учета никто не опускался.
Еще одна байка: Мои знакомые внедряли Аксапту на среднего размера предприятии, которое входило в большой холдинг. В холдинге было принятно решение об обязательности применения оценки запасов по средней. Мои приятели включили в аксапте среднюю, но поставив номер партии, как аналитику финансового склада Никто ничего не заметил, ни аудиторы, ни контролеры их холдинга, ни налоговая...

[Starling]

И все таки:

Цитата:

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

1. Берут остаток в рублях и штуках.
2. Суммируют себестоимость последних приходов, до тех пор пока не наберут число штук, равное количественному остатку.
3. Если себестоимость в приходов рублях не совпадает со складским остатком по номенклатуре - значит присутствует ошибка.

Вполне понятный и логичный способ. Если вернуться к моему примеру, то по описанному fed алгоритму должны получить в остатках: кол-во = 2, сумма = 40.
Дальше пробую получить этиже цифры играясь настройкой группы складских моделей.

Вариант 1 Фин склад = Склад, Метод ФИФО.
Кол-во = 2 Сумма = 35, так как 35!=40, то ошибка

Вариант 2 Фин склад = Склад + Партия, Метод ФИФО. В переносе одной строкой списываю две партии, как и написано в моем примере.
Кол-во = 2 Сумма = 35, так как 35!=40, то ошибка
Справедливости ради стоит отметить, что даже в случае исправление фичи с усреднением себестоимости в рамках лота, но имея разветвленную структуру складов, мы все равно не выйдем на цифры, рассчитанные по приведенным алгоритмам.

Вариант 3 Фин склад = (пусто), Метод ФИФО.
Кол-во = 2 Сумма = 30, так как 30!=40, то ошибка
Полученный результат для меня лично был неожиданным. Дело в том, что при закрытии склада переносы в рамках одного и того же финсклада, таки участвуют. Опять же на этой особенности теперь похоже работает закрытие по средней.

Вариант 4 как по мне, дальше можно не пробовать, так все логичные варианты настройки были приведены.

Цитата:

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

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

Похоже, что всетаки не выполняется.

Цитата:

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

Кстати - отвлекаясь от теории: Да - можно было бы подправить логистику в Аксапте таким образом, чтобы элементарной единицей себестоимость было бы сочетание лот+аналитика финансового склада. Но в этом случае придется еще и сделать следующее:
1. Пришлось бы в складские проводки засовывать не только ссылку на родительский лот (inventTransIdFather), но и ссылку на родительскую аналитику. Причем главной сложностью при реализации, было бы придумать способ связать аналитику источника и приемника для всех случаев.
2. Запретить в обычном журнале переноса менять аналитику финансового склада.
3. Сделать какой-то новый тип журнала в котором, можно сливать/разделять партии или вообще аналитики финансового склада. НО: Их можно было бы менять не чаще одного раза в журнале (то есть - если склад тоже аналитика финансового склада, то нельзя было бы сразу и две партии слить и со склада на склад перенести).
4. Учитывая что в системе есть куча вариантов переноса (карантинный заказ, WMS-вские транспортировки, заказ на перенос), пришлось бы продумать и реализовать дисциплину переноса между аналитиками финансового склада и для этих типов складских документов.

Я понимаю, что подобного рода модифы, требуют большого количество времени и сил.
Но я продолжаю утверждать, что с расчетом по методу FIFO в Аксапте все нет гладко. И дело тут не в кривых БП, а в архитектуре системы.
Если я ошибаюсь, то ткните носом в мой пример, и скажите где?

[fed]

Ну собственно - а какой результат лично ты считаешь правильным ?

Просто ответ зависит от того:
1. Считаешь ли ты допустимым смотреть сальдо не в разрезе аналитик финансового склада (или их НЕПУСТОГО подмножества).
2. Считаешь ли ты переносы полноценными приходами или согласен с тем что в выверку FIFO надо брать только ценоообразующие приходы (то есть - приходы извне хозяйствующей организации).

Ну и кстати - вот мне очень много кто жаловался на среднюю, и ты первый кто на FIFO жалуется. С одной стороны логика в твоих словах есть, с другой - статистика говорит о том что большая часть народа соглашается с аксаптовский трактовкой FIFO.

P.S. Я пожалуй что добавлю, что я не знаю, какая методика рассчета FIFO правильная. :-) То есть - прежде чем говорить что в Аксапте с себестоимостью что-то неправильно, надо сначала договорится как себестоимость должна считаться в принципе. А я внятного документа на эту тему никогда не видел.

[Starling]

Цитата:

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

Ну собственно - а какой результат лично ты считаешь правильным ?

Я считаю правильным результат при котором себестоимость остатка будет равна 40

А мой исходный вопрос наверно лучше разбить на 2.

Вопрос №1
Выключение переносов в рамках одного фин.склада из алгоритмов закрытия склада. Данный подход позволил бы реализовать схему, при которой переносы не считаются полноценными приходами. Тогда после закрытия склада себестоимость была бы 40.

Что будет при этом с новым алгоритмом закрытия по средней, я прогнозировать не берусь, но думаю, что ничего хорошего.
Я слышал о таких модификациях партнеров. Скорее всего, что читал на этом форуме, но ссылку привести не могу. И в контексте моего примера, я считаю данную модифу вполне оправданной.

Вопрос №2
Усреднение себестоимости в рамках лота. Я не могу согласиться с тем утверждением, что если хотите видеть нормальную себестоимость в разрезе партии, то будьте любезны выбирайте ее руками. В конце концов, при помощи системы мы моделируем БП и допускаем, что ряд параметров в ней будет учитываться в каком-то приближении. Это сплошь и рядом – мы же не заставляем никого стоять с секундомером у станка, для того чтобы корректно списать его амортизацию или распределить какие-то расходы. Мы просто выбираем базу боле- менее приближенную к жизни, и выполняем нужные нам расчеты. Тоже самое и при выборе партий – да кладовщик не указывает, какую партию он передал, но вполне допустимо предположить, что партии будут уходить по схеме FIFO и ожидать от системы соответственного расчета себестоимости, но система этого не делает.

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

Цитата:

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

Ну и кстати - вот мне очень много кто жаловался на среднюю, и ты первый кто на FIFO жалуется

Многие жалуются и на этом форуме в том числе. Просто вопрос обычно крутится вокруг того, что при переносе усредняется себестоимость по париям. Им говорят, что указываете партию руками при переносе и списаниях ибо нефик! Люди тихо делают модифы по рабивки лота до партии и с этим живут. Я вот решил немного расширить взгяд на эту проблему (ну или фичу).

Пример, который я привел, этот пример с реального проека. Очень много копий было об него сломано. Кончилось тем, что пригласили стороннюю консалтинговую компанию, которая сказал, что при продаже себестоимость была бы 10. Сделали разбивку лота до партии, что придумали с возвратами списаний я уже и не помню. Дело было давно.

Я ожидаю, что подобного рода задачи будут решаться в Аксапте без модиф. Просто многие гуру (в хорошем смысле этого слова) утверждают, что это кривые БП. Но если исходить из того, что логика в моих словах таки есть, то может попробовать заявить эту багу/фичу в майкрософте.

[Starling]

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

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

[fed]

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

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

Да - и кстати я в MS больше не работаю; Я теперь типа фрилансер. Так что это только если kashperuk заявит что-то

[Starling]

Цитата:

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

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

Как минимум будут закрыты варианты, при которых компания считает ФИФО по предприятию в целом, т.е. не важно как товар двигался внутри предприятия, главное чтобы первый «внешний» приход был закрыт первым «внешним» расходом. ИМХО – вариант 1 имеет право на жизнь, и то, как работает система можно считать логичным. Если таки хотите получать 40, то включайте партию в финсклад, только вопрос №2 не позволяет реализовать данную схему, т.е. я считаю, что:

Вариант 1 (Фин склад = Склад, Метод ФИФО) – работает корректно

Вариант 2 (Фин склад = Склад + Партия, Метод ФИФО) – требует исправление ситуации с усреднением себестоимости лота

Вариант 3 (Фин склад = (пусто), Метод ФИФО.) – требует исключение переносов в рамках финсклада из алгоритмов закрытия

Цитата:

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

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

Не я это не предлагал – пусть будут конечно)

Цитата:

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

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

Вот это не понял

[fed]

Цитата:

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

Не я это не предлагал – пусть будут конечно)


Вот это не понял

Ну просто те алгоритмы, которые ты предложил - они частные достаточно. Типа если аналитика финансового склада отсутствует, то закрываем без переносов, если склад включен как аналитика финансового склада - то и так хорошо; если номер партии-финансовая аналитика, то используем подход номер лота+аналитика финансового склада. В тоже время, наиболее генерализованный подход к закрытию склада - он примерно такой:
1. Сопоставляем приходы и расходы (примерно как счас)
2. Для каждого складского (кроме ценообразующих) через обход графа составляем список корневых, ценообразующих приходов, из которых сложилось данное складское движение.
3. Зная количество пришедшее на данный приход или расход из каждого ценообразующего прихода и себестоимость данного ценообразующего прихода - рассчитываем себестоимость данного складского движения.

Просто сейчас, закрытие склада фактически строит себестоимость списания на основании себестоимости предыдущего прихода в графе. А надо было бы в идеале строить на основании корневых приходов в графе.
P.S. Хотя с другой стороны - нынешняя прогонка себестоимости эту же примерно задачу и решает. Так что проблема не в подходе, а просто в том что связь между приходами и расходами по внутренним движениям - нечеткая и неформализованная...

[Starling]

Цитата:

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

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

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

А такой вариант имеет право на жизнь?
• Переносы в рамках аналитики одного и того же финсклада вообще не включаются в граф сопоставления
• При разноске таких переносов их себестоимость равна 0. Зачем нам гонять себестоимость по складским проводкам, если она все равно должна считаться по финскладу? Сам по себе ноль смущает, но в текущей реализации такие переносы могут привести к «+» в количестве и к «-» в сумме на остатках в разрезе аналитик не включенных в финсклад.

[fed]

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

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

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

[maxk]

Цитата:

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

Вопрос по статье, насчет обновленного механизма закрытия по
Получется нельзя использовать такие комбинации аналитик, когда есть нефинансовая, но обязательная для заполнения складская аналитика и одновременно финансовая, но не обязательная (след. проставленная не на всех проводках).

Это ошибка в приложении. Наличие нефинансовых обязательных аналитик не должно влиять на возможность закрытия склада.
Проблема втом что для создании фиктивного расхода и прихода используется функционал отвечающий за создание переносов и в некоторых случаях (как в описаном выше) проверки производимые этим функционалом препятствуют созданию этих фиктивных переносов.
Hotfix для этой проблемы уже доступен на customer и partner source в разделе хотфиксов за апрель (new WA blocking issue). После установки его описанная проблема решается.

[petr]

Цитата:

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

Это ошибка в приложении. Наличие нефинансовых обязательных аналитик не должно влиять на возможность закрытия склада.
Проблема втом что для создании фиктивного расхода и прихода используется функционал отвечающий за создание переносов и в некоторых случаях (как в описаном выше) проверки производимые этим функционалом препятствуют созданию этих фиктивных переносов.
Hotfix для этой проблемы уже доступен на customer и partner source в разделе хотфиксов за апрель (new WA blocking issue). После установки его описанная проблема решается.

Спасибо, что отписались. Мы получили хотфикс через день или два после того, как я написал свой пост (правда из других источников), и у нас все работает. Просто не стал об этом упоминать в этой ветке.