Обороты и остатки номенклатуры по счетам

[pyramid]

Друзья!

Пытаюсь получить оборотно-сальдовую ведомость за произвольный период с разбивкой по счетам ГК.
Обороты получил, связав LedgerTable, LedgerTrans и InventTrans.
А вот как получить остатки - непонятно совсем, кроме как посчитать всё от начала учёта.

Может быть, я не тем путём двигаюсь?

[lev]

вам нужны остатки на дату, или на текущий момент? в разрезе складских аналитик?

[coolibin]

Цитата:

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

вам нужны остатки на дату, или на текущий момент? в разрезе складских аналитик?

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

Вот, было уже не раз:
Остатки на дату.

[Alexius]

Хм, а InventTransPosting не может заменить вам LedgerTrans ?
А остатки, увы, придеться считать с начала времен.

[coolibin]

Цитата:

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

А остатки, увы, придеться считать с начала времен.

Ну или с конца

[Alexius]

Цитата:

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

Ну или с конца

А можно поподробнее, в какой таблице лежат остатки хотя бы в связке Номенклатура - Счет ГК ? Или как вы их хотите получить ?

[lev]

Цитата:

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

Хм, а InventTransPosting не может заменить вам LedgerTrans ?
А остатки, увы, придеться считать с начала времен.

Есть специальные классы для подсчета остатков. На форуме упоминалось неоднократно.

[Alexius]

Цитата:

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

Есть специальные классы для подсчета остатков. На форуме упоминалось неоднократно.

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

[Nick]

Помнится года 2 назад надо было быстро решить такую задачку на проекте... получилось, но отчет в среднем около 20 минут формировался (клиента устроил).
Для РСБУ это один из стандартных аналитический отчетов, его бы по хорошему надо в новое московское подразделение Microsoft переадресовать

[coolibin]

Цитата:

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

Для РСБУ это один из стандартных аналитический отчетов, его бы по хорошему надо в новое московское подразделение Microsoft переадресовать

Сомневаюсь, что он так уж нужен с точки зрения РСБУ. Просто бухгалтерам привычнее по нему сверять склад.
А вообще, задача вполне себе для OLAP сервера. Пусть себе родной по ночам считает копеечки.

[TasmanianDevil]

Цитата:

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

Для РСБУ это один из стандартных аналитический отчетов, его бы по хорошему надо в новое московское подразделение Microsoft переадресовать

Для РСБУ любой отчет по сверке любого внутримодульного учета(ОС, номенклатура, ЦБ и пр.) и соответствующих разрезов синтетического и аналитического учетов в ГК - стандартен, поскольку является доказательством достоверности отображения фактов хозяйственной деятельности , подкрепленных первичными документами, в ГК.

Чтобы их строить - нужны :
1) Нормальная архитектура связей модульного учета и ГК(единообразные по всем модулям, а не скачующие как бог на душу положит)
2) Нормальная архитектура аналитики самой ГК, могущая уместить на 5-6 физических уровнях все потребные для ведения учета по РСБУ аналитики (на основе коммутируемых реляций, а не прямом текущем фиксированном примитивизме ),
3) Нормальная архитектура остатков ГК (именно остатков, дающих более-менее фиксированное количество обрабатываемых записей при расчете сальдо, а не неуклонно растущее, как в случае с LedgerBalancesDimTrans).

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

А переадресовать в новое московское подразделение Microsoft ?
Можно, а толку ?
В лучшем случае очередной креатиффф из разряда InventTransPosting/LedgerBalancesDimTrans сваяют ...

[Nick]

Цитата:

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

Для РСБУ любой отчет по сверке любого внутримодульного учета(ОС, номенклатура, ЦБ и пр.) и соответствующих разрезов синтетического и аналитического учетов в ГК - стандартен, поскольку является доказательством достоверности отображения фактов хозяйственной деятельности , подкрепленных первичными документами, в ГК.

Чтобы их строить - нужны :
1) Нормальная архитектура связей модульного учета и ГК(единообразные по всем модулям, а не скачующие как бог на душу положит)
2) Нормальная архитектура аналитики самой ГК, могущая уместить на 5-6 физических уровнях все потребные для ведения учета по РСБУ аналитики (на основе коммутируемых реляций, а не прямом текущем фиксированном примитивизме ),
3) Нормальная архитектура остатков ГК (именно остатков, дающих более-менее фиксированное количество обрабатываемых записей при расчете сальдо, а не неуклонно растущее, как в случае с LedgerBalancesDimTrans).

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

Поддерживаю на все 110% процентов...

Цитата:

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

А переадресовать в новое московское подразделение Microsoft ?
Можно, а толку ?
В лучшем случае очередной креатиффф из разряда InventTransPosting/LedgerBalancesDimTrans сваяют ...

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

[Михаил Андреев]

Цитата:

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

Для РСБУ любой отчет по сверке любого внутримодульного учета(ОС, номенклатура, ЦБ и пр.) и соответствующих разрезов синтетического и аналитического учетов в ГК - стандартен, поскольку является доказательством достоверности отображения фактов хозяйственной деятельности , подкрепленных первичными документами, в ГК.

Хм. Сверка сверкой (она, кстати, есть, но проверяет только связи), а отчёт в разрезе "объект учёта" (ОС, номенклатуры, клиент, поставщик) - "Счёт ГК" зачем нужен? На основании какого документа он требуется?

[Nick]

Цитата:

Сообщение от Михаил Андреев

Хм. Сверка сверкой (она, кстати, есть, но проверяет только связи), а отчёт в разрезе "объект учёта" (ОС, номенклатуры, клиент, поставщик) - "Счёт ГК" зачем нужен? На основании какого документа он требуется?

Михаил, вы уверены, что этого аргумента будет более чем достаточно для аудиторов и других проверяющих?!
не говоря уж про несчастных (без 1с) бухгалтеров...

[Михаил Андреев]

Цитата:

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

Михаил, вы уверены, что этого аргумента будет более чем достаточно для аудиторов и других проверящих?!

Абсолютно. Есть требования к учёту - ПБУ и т.п. Нужно следовать им, а не слепо повторять то, что захотелось бухгалтеру. Но чтобы аргументированно это доказывать, нужно самим изучать "матчасть", а не слушать пересказы бухгалтеров.

[TasmanianDevil]

Цитата:

Сообщение от Михаил Андреев

Хм. Сверка сверкой (она, кстати, есть, но проверяет только связи), а отчёт в разрезе "объект учёта" (ОС, номенклатуры, клиент, поставщик) - "Счёт ГК" зачем нужен? На основании какого документа он требуется?

Вряд ли именно такая формулировка где-то есть ...
Тем не менее, несмотря на разнообразие правил, прописанных в учетных политиках по РСБУ у многих предприятий, не нарушающих все клятые ПБУ и Мриказы минфина, у них имеется одно "поганое" свойство быть почему-то шире возможностей "регулировочных" узлов DAX (профилей разноски, механизмом автоматического заполнение и подстановки аналитик) .

Михаил, Вам приходилось сталкиваться с ситуацией, когда несколько экземпляров некой учетной сущности, согласно учетной политики предприятия, могут учитываться на разных счетах ГК в зависимости от их неких параметров ее оперативного учета ? Причем имеется жесткая установка политику не менять.

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

А как в DAX обстоит?
Есть модульный учет достаточной степени гибкости и широты детализации, есть некое отражение этого учета в ГК(абстрагируясь на время от детальности этого отражения).
А вот когда встает вопрос о детальности учета неких модульных движений в ГК, достаточных для того, чтобы в огромном массиве данных оперативно найти ошибку, доказать достоверность этого учета - вот тут уже и возникает проблема, как обеспечить такую детальность. Можно с помощью "самостийных" для каждого модуля нашлепок типа InventTransPosting, а можно - как описано выше.

К сожалению, MS избирает первый путь ...

[Михаил Андреев]

Цитата:

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

Вряд ли именно такая формулировка где-то есть ...
Тем не менее, несмотря на разнообразие правил, прописанных в учетных политиках по РСБУ у многих предприятий, не нарушающих все клятые ПБУ и Мриказы минфина, у них имеется одно "поганое" свойство быть почему-то шире возможностей "регулировочных" узлов DAX (профилей разноски, механизмом автоматического заполнение и подстановки аналитик) .

Если требования есть в ПБУ или ещё где, есть хоть какая-то причина для запроса к вендору. А если это - требования, придуманные заказчиком, это его личные проблемы, согласны?

Цитата:

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

Михаил, Вам приходилось сталкиваться с ситуацией, когда несколько экземпляров некой учетной сущности, согласно учетной политики предприятия, могут учитываться на разных счетах ГК в зависимости от их неких параметров ее оперативного учета ? Причем имеется жесткая установка политику не менять.

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

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

[pyramid]

Спасибо за мысли.

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

Или есть менее экстенсивный путь?

[Alexius]

А сначала времен это долго считается ?

Цитата:

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

Может выходом будет создать дополнительные таблицы с предрассчитанными значениями остатков

Можно прикрутить такой расчет остатков например к закрытию склада.

[raz]

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