Поле "Стандартная себестоимость"

[glibs]

В отчете много полей:

Физ. наличие (Physical inventory)
Стоимость запасов (Inventory value)
Известная величина (Known value)
Плавающая величина (Floating value)
Физическое значение (Physical value)
Разнесено физически (Physically posted)

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

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

----- Регистр. ---------- Отб. накл. ---------- Накл. ---------->


1. Если вы строите отчет после регистрации номенклатуры

----- Регистр. ----- (Отчет) ----->

то в отчете отображается зарегистрированное количество номенклатуры в поле Физ. наличие отображается зарегистрированное количество номенклатуры, а в поле Физическое значение отображается нормативная стоимость номенклатуры. Нормативная стоимость также отображается в поле Плавающая величина.

Физ. наличие ................... +
Стоимость запасов ...........
Известная величина .........
Плавающая величина ...... Нормативная стоимость
Физическое значение ....... Нормативная стоимость
Разнесено физически .......

2. Точно такая же катрина показывается в случае, если вы обработаете Отборочную накладную.

----- Регистр. ---------- Отб. накл. ----- (Отчет) ----->

Физ. наличие ................... +
Стоимость запасов ...........
Известная величина .........
Плавающая величина ...... Нормативная стоимость
Физическое значение ....... Нормативная стоимость
Разнесено физически .......

3. Если вы смотрите отчет после регистрации Накладной

----- Регистр. ---------- Отб. накл. ---------- Накл. ----- (Отчет) ----->

то в поле Физическое значение отображается фактическая стоимость закупленной номенклатуры, и она же отображается в поле Стоимость запасов.

Физ. наличие ................... +
Стоимость запасов ........... Фактическая стоимость
Известная величина .........
Плавающая величина ......
Физическое значение ....... Фактическая стоимость
Разнесено физически .......

Но это еще не все.

3.1 Предположим теперь, что в ситуации 3 вы строите отчет несколько более ранней датой.

----- Регистр. ---------- Отб. накл. ----- (Отчет) ----- Накл. ---------->

Казалось бы, ситуация такая же, как и в случе 2... Но на самом деле не совсем.

В поле Физическое значение теперь показывается фактическая стоимость закупленной продукции. Она же показывается в поле Известная величина.

Физ. наличие ................... +
Стоимость запасов ...........
Известная величина ......... Фактическая стоимость
Плавающая величина ......
Физическое значение ....... Фактическая стоимость
Разнесено физически .......

Ну и процесс расхода. Он состоит из следующих основных стадий:
- Комплектация (одноименная функция в заказах, закупках и складских журналах, а также операции в рамках функциональности уравления складом)
- Обработка отборочной накладной (Packing slip)
- Обработка накладной (Invoice)

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

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

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

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

Ну и наконец, отчетность по стоимости запасов на дату рассчитывает себестоимость следующим образом. Она берет себестоимость в проводке и прибавляет к ней все корректировки себестоимости (это табличка InventSettlement) на дату меньше или равно дате построения отчетности.

AlexeyBP, судя по той информации, которую вы предоставили, у вас могло произойти что-то вроде приведенного ниже примера.

05/07 вы закупили (зарегистрировали) нечто (предположим для наглядности, что это новая номенклатура). Накладную по закупке вы при этом еще не обработали.

10/07 вы продали это нечто. При этом себестоимость номенклатуры была неизвестна, и в проводке подставилась нормативная себестоимость из карточки номенклатуры.

15/07 вы, наконец, обработали накладную по закупке, указав при этом дату накладной 05/07, естественно.

31/07 вы выполнили закрытие склада.

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

Поэтому существует

Правило №2 Правильной себестоимости в Аксапте

Если вы хотите получать корректную отчетность по стоимости запасов на произвольную дату, корректную отчетность по АВС-классификации номенклатуры по стоимости и марже на произвольную дату, а также некоторые другие отчеты в системе, то склад необходимо закрывать ежедневно.

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

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

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

[Recoilme]

Цитата:

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

Поэтому существует

Правило №2 Правильной себестоимости в Аксапте

...
склад необходимо закрывать ежедневно.

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

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

[glibs]

Цитата:

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

...
Не самое тривиальное, но порой более оптимальное
...

Если вас не затруднит, м.б. вы сможете аргументы назвать.

[Recoilme]

Цитата:

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

Если вас не затруднит, м.б. вы сможете аргументы назвать.

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

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

Рассмотрим путь 2. Минусы:
- надо программировать (на самом деле алгоритм примитивен)
- система отчетности заживет своей жизнью (данные в ней и в аксапте разойдутся в открытом периоде, соответсвенно нужна процедура сверки после закрытия. )
- заказчику надо объяснять что то, за что он заплатил деньги не работает как надо , и надо заплатить ещё раз
- саппорт. На форуме не спросишь, где ошибка в коде.
Плюсы:
- Оперативная информация непосредственно в системе отчетности
- Возможность реализации одновременно нескольких моделей (стандартная, фифо)
- Оперативность, сегодня изменили цены, завтра в отчетности поменялась маржа
- независимость от основной системы, на время пересчетов нет блокировок, не тратятся ресурсы

Есть ещё один неплохой путь. Развитие пути 1
Путь 3. Оптимизировать алгоритм рассчета себестоимости. В случае ускорения алгоритма примерно в 40 раз - можно оперативно актуализировать себестоимость. Данный путь, в виде законченного решения, я надеюсь, будет предложен в ближайшее время на коммерческой основе всем желающим в разделе рынок ЕРП систем.

Путь 4. Комплекс отчетов и алгоритмов анализа, как развитие пути 2, тоже надеюсь будет предложен, но позже

[glibs]

Цитата:

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

...
- после даты закрытия невозможна разноска (а как же вчерашние документы??)
...

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

Цитата:

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

...
- желателен момнопольный доступ на время выполнения (блокировки, тяжелый алгоритм)
...

1. Закрытие склада за один день происходит быстро. Гораздо быстрее, чем за месяц.

2. В случае, если делать закрытие склада раз в месяц, то эта проблема не решается, а усугубляется. Вообще, данная проблема решается запуском закрытия в пакетном режиме в ночное время. Хотя один раз я лично наблюдал, как в течение дня происходило закрытие склада за месяц (день за днем). Я был удивлен, но всем работалось довольно хорошо (никто не жаловался на торможение системы).

Цитата:

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

...
руководство в данном случае интересует оперативное получение информации по марже.
...

Вы не находите, что то, что написано выше, противоречит тому, что написано ниже?

Цитата:

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

...
в случае разноски операций задним числом
...

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

[Recoilme]

2 glibs:
У нас принципиальное различие в подходах. Мне кажется Вы в первую очередь думаете о "простоте" реализации, а я больше о "полноте" реализации.

По существу:
Дело в том что не всякое руководство устроит получение информации с отставанием в 10 дней. Если многие компании и мирятся с такой ситуацией, то это от безысходности, а не от "бест практис". Я же просто хотел осветить и другие варианты решения данной проблемы, но не настаиваю на них, отметив что предложенный путь не тривиален. Но реализуем вполне.

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

[AlexeyBP]

По поводу трудоемкости закрытия склада ежедневно:
Как корректно посчитать рост базы данных при ежедневном закрытии/пересчете и сравнить с ежемесячным закрытием?
При закрытие участвуют таблицы: InventTrans, InventSettlement, LedgerTrans (если обновляем главную книгу). Корректно ли сравненить рост количества записей при закрытии / пересчете за месяц и за день?

Сравнить необходимо при разной спецификации закрытия: Общее количество, Ном. группа, номенклатура.