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

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

Цитата:

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

Вот это как раз-таки тот самый случай. У заказчика есть типовая форма отчёта, которую требуется реализовать. Пример формы прикреплён.
Счёт, по которому строится отчёт, выбирается пользователем.

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

А где в этом отчёте счета ГК? По ним фильтрация, если я правильно понял?
Т.е. нужно вывести данную оборотно-сальдовую ведомость по номенклатурам, относящимся к определённому счёту ГК, правильно?

[pyramid]

Правильно.

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

Цитата:

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

Правильно.

ИМХО, судя по форме, такой отчёт строится по InventSum (остатки), InventTrans и, возможно, InventTransPosting. Для остатков на дату где-то на форуме было обсуждение классов. А вот профильтровать номенклатуры по счетам ГК можно легко, если для всех операций по одной группе номенклатуры (или самой номенклатуре) прописывается один счёт (обычно так и делают), в этом случае можно взять счёт по любой операции из настроек разноски и профильтровать номенклатуры, у которых в настройке разноски указан этот счёт. Только это не будет выверкой, как ни странно, так как нужно сверять суммы по LedgerTrans и InventTrans.

А вот если умудрились прописать разные счета ГК для разных операций в разноске для одной группы номенклатуры...

[pyramid]

Цитата:

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

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

А корректно ли использовать настроенный в профилях разноски счёт? Например, если пользователь изменит счёт в середине отчетного периода, то наш отчёт станет неверен!

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

Цитата:

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

А корректно ли использовать настроенный в профилях разноски счёт? Например, если пользователь изменит счёт в середине отчетного периода, то наш отчёт станет неверен!

Конечно, будет неверен. Потому я и подчеркнул это условие.

[TasmanianDevil]

Цитата:

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

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

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

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

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

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

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

[coolibin]

Цитата:

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

ИМХО, судя по форме, такой отчёт строится по InventSum (остатки), InventTrans и, возможно, InventTransPosting. Для остатков на дату где-то на форуме было обсуждение классов.

При такой постановке задачи классы inventSum* не очень помогут. Отчет придется строить по InventTrans inner join InventTransPosting. Фильтровать по номеру счета из InventTransPosting . Остаток на начало считать как сумму всех оборотов от царя гороха.

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

При такой постановке задачи классы inventSum* не очень помогут. Отчет придется строить по InventTrans inner join InventTransPosting. Фильтровать по номеру счета из InventTransPosting . Остаток на начало считать как сумму всех оборотов от царя гороха.

Насчёт фильтрации по InventTransPosting согласен. Но, если у заказчика такой бардак, то это не поможет

А вот насчёт остатков. ИМХО, лучше использовать всё-таки InventSum - можно сразу отсечь все старые закрытые остатки и их не суммировать.

[coolibin]

Цитата:

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

ИМХО, лучше использовать всё-таки InventSum - можно сразу отсечь все старые закрытые остатки и их не суммировать.

Как отсечь старые закрытые остатки с помощью inventSum?

[ZVV]

Цитата:

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

Как отсечь старые закрытые остатки с помощью inventSum?

Птичка есть специальная. Closed.

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

Цитата:

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

Как отсечь старые закрытые остатки с помощью inventSum?

Например, по полю LastUpdDatePhysical и Closed.

[raz]

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

[Nick]

Цитата:

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

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

Михаил, а где есть требования в ПБУ и НК вести РСБУ и НУ в Аксапте?!
По вашему получается что для ведения учета требуется только калькулятор, как максимум - Excel ...
остальное - выпендрежь юзеров, которых нематериализованные консультанты не смогли обратить в свою "правильную" веру

ЗЫ предлагаю тему кто какой функционал мечтал бы видеть в Аксапте перенести в отдельную ветку и не "лечить" больше друг друга

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

Цитата:

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

Михаил, а где есть требования в ПБУ и НК вести РСБУ и НУ в Аксапте?!
По вашему получается что для ведения учета требуется только калькулятор, как максимум - Excel ...
остальное - выпендрежь юзеров, которых нематериализованные консультанты не смогли обратить в свою "правильную" веру

Хм. И где я это написал? Давайте не будем приписывать мне то, что я не говорил!

[coolibin]

Цитата:

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

Например, по полю LastUpdDatePhysical и Closed.

Ну да, это понятно. Я-то имел в виду семейство классов inventsum*, а не таблицу.

Что же касается указанных полей из InventSum - все бы хорошо, но и они не помогут гарантированно отсеять все лишние номенклатуры. Например, взять случай, когда одна и та же номенклатура на 10-м уже закрыта, а на 08-м еще болтается.

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

Цитата:

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

Что же касается указанных полей из InventSum - все бы хорошо, но и они не помогут гарантированно отсеять все лишние номенклатуры. Например, взять случай, когда одна и та же номенклатура на 10-м уже закрыта, а на 08-м еще болтается.

Если одна и та же номенклатура будет учитываться на разных счетах, то придётся от начала времён считать по InventTransPosting, другого варианта не видно. Мягко говоря, такой отчёт будет строиться очень небыстро

[longson]

Цитата:

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

Пытаюсь получить оборотно-сальдовую ведомость за произвольный период с разбивкой по счетам ГК.

А я думаю отчет, который буквально отвечает этим требованиям, не так нужен, с точки зрения функционала Axapta.

Понятно что бухгалтеры, которые привыкли работать в 1С и получают по ней отчеты, поставят именно такую задачу консультантам по Axapta.

Но логика работы Axapta, в отличие от 1С, разделяются финансовые и физические проводки, и данные вносятся в систему человеком, который непосредственно работает с этими данными. Соответственно, физические проводки - это участок, скажем, сотрудников складов, а финансовые проводки - работа бухгалтеров, финансистов.

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

Поэтому, я бы сказал, что отчет в такой постановке, как "Оборот и остатки по счетам ГК" - неправильный с точки зрения Axapta.

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

Таким образом для решения определенных задач бухгалтеры просто берут логику решения по 1С, накладывают их на Axapta, и требуют от Axapta не решение задачи, а реализации логики решения задачи привычных им средств.

Вот несколько из этих задач, перечисляю те которые я помню, думаю есть еще много:

• Узнать, сколько сырья было закуплено и списано в производство за определенный период (Отчет по оборотам и остаткам по счету 10)
• Узнать, сколько были выпущены готовые продукции и сколько было списано в себестоимость проданных товаров за определенный период. (Отчет по оборотам и остаткам по счету 43, 20)
• Узнать, какие товары и по какому объему были перемещены с одного склада (участка) на другой склад (участок) (Отчет по оборотам и остаткам по счету 21, 22, 20)

Все перечисленные задачи могут быть решены без использования счетов ГК, а только на основании InventTrans и с помощью семейства классов расчетов финансовых и физических остатков.
Думаю, что после закрытия складов (и только после этого можем надеяться на то что в отчете будут правильные финансовые суммы), эти отчеты не должны медленно работать. У меня не было практического опыта сравнения скорости выполнения этих отчетов до и после закрытия складов, поэтому могу только так предполагать. Если кто может утвердить, очень рад :-)

Цитата:

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

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

Это, по моему, неправильно. В РПБУ кроме финансовых отчетов (Форма №1, Форма №2 и т.д..., т.е Баланс, Прибыль и убытки, ДДС и некоторые другие отчеты) нет требований по отчетам для подтверждения внутреннего учета запасов.

В РПБУ есть требование к первичным документам и финансовым отчетам за период. Количество таких отчетов очень не много. Доказательство достоверности этих отчетов - это первичные документы, а не другие отчеты.

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

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

Цитата:

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

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

Совершенно согласен. Спасибо за то, что раньше предсказал мне именно так.

[Raven Melancholic]

longson - Замечательно!!!
Как правило, после долгих и нудных выяснений у бухов зачем им нужно то или иное (первоначально заявлялось, что это требования законодательства), выясняется, что "мы так привыкли".
Я сам год работал замом главного бухгалтера и могу подтвердить, что ПБУ гораздо мягче относятся ко многим вещам, чем заявляют бухгалтеры.

[Lemming]

Цитата:

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

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

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