Скл.аналитика сайт, перенос и фин.аналитик

[Bega]

DAX 2009, ROLLUP 3.

Есть два склада 01 и 02. Необходимо, чтобы при переносе сырья (бух.счет 10.00) происходила смена фин.аналитик, то есть генерилась бух.проводка 10.00<-10.00 с разными значениями фин.аналитики "Подразделение" по дебету и кредиту.

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

Может я что-то неверно настроил? Можно без доработок решить эту задачу в DAX 2009?

[TasmanianDevil]

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

[S.Kuskov]

Цитата:

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

Финансовая аналитика - одна на весь журнал.

А разве в AX2009 расходная и приходная проводки по переносу садятся не на разные лоты? И тогда записей в InventTransPosting (а следовательно и фин аналитик) должно быть две, для расхода и прихода соответственно.

[kashperuk]

Хмм. А что именно не получается? Вроде попробовал только что - создалось нормально 2 проводки с разными фин.аналитиками, соответствующими сайтам.
Вы уверены, что вы активировали линк складской аналитики и фин.аналитики?

Вот картинки

InventTrans с сайта на сайт, с разными фин.аналитиками на закладке аналитик


LedgerTrans с 4мя проводками с разными фин.аналитиками (счета не русские, из демо-данных АХ)


Или что-то не то?

[Bega]

Цитата:

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

Хмм. А что именно не получается? Вроде попробовал только что - создалось нормально 2 проводки с разными фин.аналитиками, соответствующими сайтам.
Вы уверены, что вы активировали линк складской аналитики и фин.аналитики?

Вот картинки

InventTrans с сайта на сайт, с разными фин.аналитиками на закладке аналитик
Вложение 5748

LedgerTrans с 4мя проводками с разными фин.аналитиками (счета не русские, из демо-данных АХ)
Вложение 5749

Или что-то не то?

Просуммируйте в разрезе фин.аналитики - ничего никуда не перемещается, по обоим двум оборот = 0.

[fed]

Цитата:

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

Просуммируйте в разрезе фин.аналитики - ничего никуда не перемещается, по обоим двум оборот = 0.

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

[TasmanianDevil]

Цитата:

Сообщение от S.Kuskov

А разве в AX2009 расходная и приходная проводки по переносу садятся не на разные лоты?

Упс, ошибся - под рукой дома 2009-ой не имеется, потому и написал по памяти, как оно в 3-ке и 4-ке было.
Все именно так и обстоит, как Вы написали ...

P.S. А почему стало 2 проводки(4 LedgerTrans'а) по 1 строке переноса рождаться ? Можно ли где-то про сии чудеса и трактовку их физического смысла прочитать ? Или это просто включена разноска как физических, так и финансовых операций ?
P.P.S. Становится совсем непонятно и тревожно за семейство InventAdjustPost - какие оно теперь чудеса таить стало

[fed]

Цитата:

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

P.S. А почему стало 2 проводки(4 LedgerTrans'а) по 1 строке переноса рождаться ? Можно ли где-то про сии чудеса и трактовку их физического смысла прочитать ? Или это просто включена разноска как физических, так и финансовых операций ?
P.P.S. Становится совсем непонятно и тревожно за семейство InventAdjustPost - какие оно теперь чудеса таить стало

Ну как раз все вполне логично: одна складская операция (списание или приход) - одна проводка-две записи в ledgerTrans. Собственно все так было начиная с версии 2.1; как раз приходилось некоторые усилия предпринять чтобы при включении проводки по переносу не порождалась вторая пара проводок...

[d&m]

Цитата:

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

Активизировал и настроил сайты, для каждого склада отдельный сайт. Привязал к ним фин.аналитику "Подразделение".

При обновлении сайта в строке журнала переноса у вас обновляется фин аналитка в этой строке? При наличии связи сайта и фин аналитики - "Подразделение" должно обновляться в зависимости от сайта!

Цитата:

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

Вы уверены, что вы активировали линк складской аналитики и фин.аналитики?

очень похоже что линка как раз нет. Связь делается тут Управление запасами / Настройка / Разноска / Ссылка аналитики

[TasmanianDevil]

fed, речь как раз и об этом - 1 строка журнала переноса, 2 складских проводки и 4 (!!!) записи в LedgerTrans (т.е. две полноценные проводки вместо одной). Потому вопрос и возник про дополнительные проводки - это новая багофича или просто для складской модели обрабатываемой номенклатуры включена разноски обоих типов операций ?

[fed]

Цитата:

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

fed, речь как раз и об этом - 1 строка журнала переноса, 2 складских проводки и 4 (!!!) записи в LedgerTrans (т.е. две полноценные проводки вместо одной). Потому вопрос и возник про дополнительные проводки - это новая багофича или просто для складской модели обрабатываемой номенклатуры включена разноски обоих типов операций ?

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

[CDR]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

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

[CDR]

Цитата:

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

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

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

Цитата:

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

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

Ну вот, это даже не заплатка... Хотя наш консалтинг это позиционируют именно как "специальную функциональность от вендора для складского переноса с проводкой по ГК".
По поводу дыры... Я, конечно, не гуру западного учета, но не ужели в западном учете никогда не возникает задачи переместить номенклатуру не только физически со склада на склад, но и финансово со счета на счет (например, из товара в материалы)?

[Ivanhoe]

Я так понимаю, анализировать остатки по ГК нужно будет не по аналитике (по сути и закупка номенклатуры на сайт 1 даст сальдо по аналитике 1 равное 0), а по паре "счет - аналитика".

Тогда мы и увидим, что по одному счету списалось с аналитики 1 и пришло на аналитику 2 (в приведенном примере Ивана еще и счета поменялись, но они могут быть и одинаковыми, например 15025).

[Bega]

Цитата:

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

Я так понимаю, анализировать остатки по ГК нужно будет не по аналитике (по сути и закупка номенклатуры на сайт 1 даст сальдо по аналитике 1 равное 0), а по паре "счет - аналитика".

Тогда мы и увидим, что по одному счету списалось с аналитики 1 и пришло на аналитику 2 (в приведенном примере Ивана еще и счета поменялись, но они могут быть и одинаковыми, например 15025).

Ваня, у нас более общая задача - это выявление расхождений между оборотами по бух. счетам в разрезе аналитики Подразделение и ОСВ по движению сырья и полуфабрикатов в разрезе цехов. Допустим, Цех 1 (склад 01) отправляет сырье Цеху 2 (склад 02), я должен с одной стороны видеть в анализе счета 10, что сумма ушла с аналитики 01 и пришла на аналитику 02. Параллельно запускаю ОСВ по складам и вижу там что сумма ушла из одного цеха и пришла в другой.

Может быть это не очень обычная задача, но таковы требования - полное соответствие движения ТМЦ и бух. проводок.

[Geo]

Эммм... Разве правильно вообще пытаться что-то увидеть в складском движении в разрезе фин. аналитик? Для того, мне кажется, и существуют СКЛАДСКИЕ аналитики, чтобы по ним материальное движение и остатки смотреть. Финансовые же для этого просто не предназначены, так что с ними наверняка что-нибудь окажется не слава богу.

И второе. Надо ли выдумывать задачу сверки АХ с самой собой, при этом вынужденно прибегая к методу, который, в сущности, вообще не должен работать?

[TasmanianDevil]

Цитата:

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

Эммм... Разве правильно вообще пытаться что-то увидеть в складском движении в разрезе фин. аналитик?

Не в складском(InventTrans), а в финансовом движении(LedgerTrans), отражающем складское.

Цитата:

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

И второе. Надо ли выдумывать задачу сверки АХ с самой собой, при этом вынужденно прибегая к методу, который, в сущности, вообще не должен работать?

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

[fed]

Цитата:

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

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

С другой стороны - если физические и финансовые движения учетных сущностей получены из одного и того же исходного документа с помощью одного и того же программного обеспечения, то какой смысл в этой выверке ? Если у нас баги в программе, то выверка нужна только на стадии запуска (пока не отладились); Если у нас пользователи могут данные руками удалять - то вообще грош цена такой учетной системе.
То есть - выверка несет ценность только в том случае, если один и тот же исходный документ проводится двумя разными сотрудниками и порождает два разных набора проводок (и финансовых и модульных). Может быть - в других системах что-то подобное есть, но в Аксапте я таких мест не вскидку не могу вспомнить. Можно конечно упомянуть о физических и финансовых складских движениях, но для того чтобы поймать закупки/продажи которые мы забыли отинвойсировать в конце периода, совсем не нужно тяжелых механизмов сверки. Вполне достаточно простенького отчета по inventTrans с комбинацией условий по datePhysical и statusIssue/statusReceipt. Да и не обязаны финансовые складские проводки всегда идти одним учетным периодом с физическими. Вполне возможно - что мы физически товар списали 31ым числом, а накладную оформили и выручку признали только в тот момент когда товар до точки консигнации доехал.

[Bega]

Во-первых такая подробная сверка - это требования наших методологов от бухгалтерии.

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