Структура себестоимости

[Starling]

Структура себестоимости
DAX2009 RU3
Помогите сделать выбор. Стоит задача – объяснить формирование себестоимости списания.
Перечень складских аналитик:
• Склад
• Партия
Складская модель ФИФО.
Протекания БП:
• Закупили на склад А
• Перенесли на склад С
• Перенесли на склад В
• Продали со склада В
Рассматривается два варианта:
1. С включением партии в фин. склад.
2. Без включения партии в фин. склад.
Вариант №1:
• Позволяет объяснить себестоимость без больших трудозатрат, но сталкиваюсь с проблемой усреднения себестоимости в рамках лота.
• Т.е. для решения данной задачи мне необходимо дробить все строки журнала переноса до партий. Это чистая модифа.
• Количество переносов будет очень большим, пользователям работающим с переносами сущность партия ни о чем говорить не будет.
• Особое опасения вызывают корректировки ошибок.
Вариант №2:
• Не содержит в себе модификаций по разбиению строк журнала переноса до партий
• После закрытия склада необходимо предоставить отчет, который будет содержать в себе все приходы и корректировки, на основании которых была сформирована себестоимость списания.
• Аналог такого отчета есть в стандарте – «Анализатор затрат». Я прогнал цепочку с 3-мя закупками, 4-мя переносами и 1-ой продажей. В запросе «Анализатор затрат» информации столько, что я в ней запутался. В реальном бизнесе, количество операций можно смело умножать на 1000. Т.е. мне необходимо перегруппировать инфу из этого запроса и предоставить ее в удобоваримом виде.
Я склоняюсь к варианту №2, но меня смущает следующее:
• Цикличные ссылки при закрытии склада, на сколько сложно будет учесть их в отчете.
• Корректность работы «Анализатор затрат» в целом. На живых проектах я никогда не использовал эту фишку.
• Высказывание из этой ветки

Цитата:

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

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

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

З.Ы. : На самом деле складских аналитик гораздо больше, все из них (кроме партии) будут входить в фин. склад.

[mazzy]

давайте определимся с терминологией.
Denis Fedotenko: Себестоимость и закрытие склада

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

[Starling]

Одну багу (может конечно фичу) в работе "Анализатор затрат" я уже нашел.
Последовательность действий:
1. Купить 1 шт
2. Продать 1 шт
3. Дооценить закупку через корректировку НР
4. Дооценить закупку через периодич. операции
5. Закрыть склад.
Получаем нормальную картинку в форме "Анализатор затрат"

Меняем последовательность действий:
1. Купить 1 шт
2. Продать 1 шт
3. Закрыть склад
4. Дооценить закупку через корректировку НР
5. Дооценить закупку через периодич. операции
6. Закрыть склад
В форме "Анализатор затрат" корректировки по п.4 и 5. не отображаются.

[mazzy]

Цитата:

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

• Аналог такого отчета есть в стандарте – «Анализатор затрат».

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

нужно смотреть ПОСЛЕ закрытия.
Закрытие создает inventSettlement, которые и связывают реально проводки прихода и проводки расхода.

[fed]

Мне кажется, что анализ структуры затрат имеет смысл только для партионного учета. То есть - если на всех этапах все пользователи сознательно, а не авторезервированием, проставляют партию, тогда дейтсвительно можно эти партии анализировать.
От идеи собирать структуру себестоимости по inventSettlement я отказался, поскольку хотя при закрытии склада сопоставления рождаются по принципу FIFO, внутри одной даты они достаточно случайный характер имеют (ну то есть - на самом деле не случайный конечно, но завязанный на внебухгалтерский артефакт - recId таблички inventTrans). Ну то есть - получается что если мы, например, до финансовой разноски складской проводки порасщепляли ее ручками - в порядке баловства, то результат анализа структуры себестоимости будет совсем не такой как мог бы быть если бы мы не баловались
В связи с этим - на мой взгляд подобный анализ просто не будет иметь экономического смысла. Правильнее было бы анализировать ЗАТРАТЫ отнесенные на себестоимость (наверное в разрезе разных групп номенклатуры и тп), а потом тупо множить каждую статью затрат на соотошение между себестоимостью списания данной группы продукции и общей суммой затрат по данной продукции.

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

[Starling]

Цитата:

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

давайте определимся с терминологией.
Denis Fedotenko: Себестоимость и закрытие склада

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

Под партией я действительно понимаю финансовую аналитику. Но с утверждением, что если партия фин аналитика, то ее должны указывать кладовщики, я не согласен. Дело тут не в кривых БП. У меня получилась очень интересная дискуссия с fed в этой теме denisfed: Обновление статьи о закрытии склада.

[Starling]

Цитата:

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

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

нужно смотреть ПОСЛЕ закрытия.
Закрытие создает inventSettlement, которые и связывают реально проводки прихода и проводки расхода.

Вот этого я не понял.
Данные в запросе "Анализатор затрат" покажут структуру себестоимости только в случае, если проводка была обработана закрытием склада, т.е. по ней сформированы записи в inventSettlement. Такое поведение меня вполне устраивает.

[Starling]

Цитата:

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

Мне кажется, что анализ структуры затрат имеет смысл только для партионного учета. То есть - если на всех этапах все пользователи сознательно, а не авторезервированием, проставляют партию, тогда дейтсвительно можно эти партии анализировать.
От идеи собирать структуру себестоимости по inventSettlement я отказался, поскольку хотя при закрытии склада сопоставления рождаются по принципу FIFO, внутри одной даты они достаточно случайный характер имеют (ну то есть - на самом деле не случайный конечно, но завязанный на внебухгалтерский артефакт - recId таблички inventTrans). Ну то есть - получается что если мы, например, до финансовой разноски складской проводки порасщепляли ее ручками - в порядке баловства, то результат анализа структуры себестоимости будет совсем не такой как мог бы быть если бы мы не баловались
В связи с этим - на мой взгляд подобный анализ просто не будет иметь экономического смысла. Правильнее было бы анализировать ЗАТРАТЫ отнесенные на себестоимость (наверное в разрезе разных групп номенклатуры и тп), а потом тупо множить каждую статью затрат на соотошение между себестоимостью списания данной группы продукции и общей суммой затрат по данной продукции.

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

Логика в этом есть, но работает она не всегда. Я когда только анализировал эту задачу, тоже подумывал о котловом методе, но…
В моем случае идентифицированный учет все таки есть. Я не стал сразу приводить полный перечень аналитик, так как меня больше интересовали технические детали.
В целом структура аналитик следующая:
Склад:
• Серийный номер – это идентифицированный учет. С данной сущностью кладовщики работают.
o Партия 1 = строке приходной накладной
o ….
o Партия K
• Серийный номер N
o …
Т.е. каждый раз, когда регистрируется складские операция, «Склад» и «Серийный номер» указывают обязательно. Эти аналитики финансовые.
Мне нужно объяснить сумму себестоимости ПОСЛЕ закрытия склада. Механизмы расчета мне понятны, понятны они уже и заказчику. Я склоняюсь к тому, что бы по результатам закрытия склада формировать отчет, который покажет, как же получилась эта сумма в себестоимости. За основу хочу взять механизмы, заложенные в «Анализаторе затрат». Вот и пытаюсь понять, на сколько ему можно доверять. Как минимум две ошибки я уже нашел:
• Если включить вторичный склад, то в этом запросе будет каша из корректировок первичного и вторичного складов. Я думаю это победим.
• Вторая – описана в моем посте выше в этой ветки.

[fed]

Цитата:

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

Вот этого я не понял.
Данные в запросе "Анализатор затрат" покажут структуру себестоимости только в случае, если проводка была обработана закрытием склада, т.е. по ней сформированы записи в inventSettlement. Такое поведение меня вполне устраивает.

Я так подозреваю, что mazzy говорит о форме трассировки лота (которая действительно на сопоставления не обращает внимания), а Starling говорит о форме Анализатор затрат, которая как раз пляшет от inventSettlement. Форма эта появилась только в Dax2009, насколько я помню.

[Starling]

Вопрос по циклическим ссылкам.
В моем случае они могут возникать в результате возвратов ошибочных переносов.
В RU3 появилась функция сторно переносов, которая маркирует проводки по переносу, но делает это только с одной стороны.
Перенос 1:
1. - 10 склад 1
2. + 10 склад 2
Перенос 2:
3. -10 склад 2
4. +10 склад 1
При использовании сторнирования переносов проводки 2 и 3 будут отмаркированы, но это не избавляет от циклов.
Если я вручную дополнительно отмаркирую проводки 1 и 4, то в примере, который fed привел в своей статье, циклы возникать уже не будут.
В связи с этим вопрос – какие сложности может принести модификация, в рамках которой я допиляю функцию сторнирования переносов, так чтобы она автоматом маркировала проводки группы 1 и 4.

[fed]

Цитата:

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

Вопрос по циклическим ссылкам.
В моем случае они могут возникать в результате возвратов ошибочных переносов.
В RU3 появилась функция сторно переносов, которая маркирует проводки по переносу, но делает это только с одной стороны.
Перенос 1:
1. - 10 склад 1
2. + 10 склад 2
Перенос 2:
3. -10 склад 2
4. +10 склад 1
При использовании сторнирования переносов проводки 2 и 3 будут отмаркированы, но это не избавляет от циклов.
Если я вручную дополнительно отмаркирую проводки 1 и 4, то в примере, который fed привел в своей статье, циклы возникать уже не будут.
В связи с этим вопрос – какие сложности может принести модификация, в рамках которой я допиляю функцию сторнирования перенеосов, так чтобы она автоматом маркировала проводки группы 1 и 4.

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

[Starling]

Цитата:

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

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

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

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

[Starling]

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

Тогда, наверно, остается одно округление.
Щас попробую.

[fed]

Ну вообще-то может быть ничем плохим это не кончиться. Я последствиями зацикливания маркировок по переносам сталкивался очень давно - еще кажется во времена 3.0sp2. Может быть и вправду там эти корректировки порождались из за каких-то старых ошибок

[Starling]

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

[Starling]

Я так понимаю - с Анализатором затрат еще никто толком не работал.
Поставлю вопрос по другому.

На сколько на ваш взгляд реально построить отчет на основании складских сопоставлений (inventSettlement), в котором бы себестоимость расхода расписывалась бы до уровня приходных проводок. Производства не будет, но будут журналы спецификации. Примерная структура отчета:
Накладная по продаже №X со склада Tо - 4 шт на сумму 500:
- Накладная по закупке №Y на склад From - 1 шт на сумму 100
- Журнал спецификация №Z на складе From 2 шт на 300
--- Накладная по закупке №L на склад From - 2 шт на сумму 300
-- Журнал проводка №M на склад From – 1 шт на сумму 100
Т.е. себестоимость продажи сложилась у нас из приходных накладных №Y, L и прихода по складскому журналу №M. При этом номенклатура, закупленная по накладной № L, прошла через журнал спецификаций. Переносы со склада From на склад To я из примера отчета исключил, хотя понятно все корректировки по складским проводкам переноса пройдут.

Я понимаю, что теоретически такой отчет построить можно, но на практике я с такой задачей никогда не сталкивался. У кого был опыт решения такой задачи? На сколько, она оказалась выполнимой?

[Starling]

Цитата:

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

Одну багу (может конечно фичу) в работе "Анализатор затрат" я уже нашел.
Последовательность действий:
1. Купить 1 шт
2. Продать 1 шт
3. Дооценить закупку через корректировку НР
4. Дооценить закупку через периодич. операции
5. Закрыть склад.
Получаем нормальную картинку в форме "Анализатор затрат"

Меняем последовательность действий:
1. Купить 1 шт
2. Продать 1 шт
3. Закрыть склад
4. Дооценить закупку через корректировку НР
5. Дооценить закупку через периодич. операции
6. Закрыть склад
В форме "Анализатор затрат" корректировки по п.4 и 5. не отображаются.

Исправление от MBS.
Класс метод InventSettlementTreeNodeCalc метод expandInventTransIssue

protected void expandInventTransIssue()
{
    InventSettlement    inventSettlement;
    InventSettlement    inventSettlementReceipt;
    InventSettlement    inventSettlementReceiptSum;
    InventTrans         inventTransReceipt;

    real                ratioCaller;
    real                ratio;
    InventQty           qtyToExplain;
    ;

    if (inventTransCaller.Qty > 0)
        return ;

    ratioCaller = this.ratio(qtySettled, inventTransCaller.QtySettled);

    while select sum(QtySettled) from inventSettlement
        group by SettleTransId
        where inventSettlement.TransRecId           == inventTransCaller.RecId          &&
              inventSettlement.SettleType           == InventSettleType::Issue          &&
              inventSettlement.InventTransId        == inventTransCaller.InventTransId  &&
              inventSettlement.QtySettled           <  0                                &&
              inventSettlement.Cancelled            == NoYes::No
    {
        qtyToExplain = inventSettlement.QtySettled * ratioCaller;

        select sum(QtySettled) from inventSettlementReceiptSum
            where inventSettlementReceiptSum.SettleTransId  == inventSettlement.SettleTransId   &&
                  inventSettlementReceiptSum.SettleType     == InventSettleType::Receipt        &&
                  inventSettlementReceiptSum.Cancelled      == NoYes::No;

        while select sum(QtySettled),sum(CostAmountSettled) from inventSettlementReceipt
            group by TransRecId
            where inventSettlementReceipt.SettleTransId  == inventSettlement.SettleTransId  &&
                  inventSettlementReceipt.SettleType     == InventSettleType::Receipt       &&
//KB979110 -->
//                  inventSettlementReceipt.QtySettled      > 0                               &&
                  inventSettlementReceipt.QtySettled     >= 0                               &&
//KB979110 <--
                  inventSettlementReceipt.Cancelled      == NoYes::No
        {
            inventTransReceipt = inventSettlementReceipt.inventTrans();

            ratio = this.ratio(qtyToExplain, inventSettlementReceiptSum.QtySettled);
            listInventSettlementTreeNode.addEnd(InventSettlementTreeNode::newInventTrans(inventTransReceipt,inventSettlementReceipt.QtySettled * ratio,inventSettlementReceipt.CostAmountSettled * ratio,UnknownNoYes::Unknown));
        }
    }
}

З.Ы.: Анализатор затрат очень плохо дружит со вторичным складом. MBS ошибку признал, и пообещал исправить в dax60, для 2009 исправлять не хотят...