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

[Nick]

Цитата:

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

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

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

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

Цитата:

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

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

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

[pyramid]

Цитата:

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

Есть требования к учёту

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

[coolibin]

Цитата:

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

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

Кхе-кхе. А шахматку скорее всего уже сделали?

Требования к учету != Пожелания пользователя

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

[Alexius]

Цитата:

Сообщение от Raven Melancholic

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

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

PS. Вам "посчастливилось" пообщаться с ними как зам главбуха ?

[Lemming]

Цитата:

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

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

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

[Alexius]

Цитата:

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

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

Для принятия собственного решения для консультанта, гораздо важнее его "настойчивости", является наличие у него "административного ресурса". При присутствии первого и полном отсутствии второго получается классический "русский Левша" с пробиванием темы "... а англичане ружья кирпичом не чистят ..."

[TasmanianDevil]

Цитата:

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

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

Вы говорите про конкретные сводные формы отчетности, формат которых жестко регламентирован. Тут и Вы, и Михаил Андреев почти на все 100 % формально правы.

Однако у самого главного регулятора в данном моменте, а именно у федерального закона "О бухгалтерском учете" под номером 129-ФЗ от 21.11.1996 в ст. 1, п.3, есть формулировка, не меняющая во всех редакциях и дополнениях :
Основными задачами бухгалтерского учета являются:
формирование полной и достоверной информации о деятельности организации ...

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

Отступим на время от материалов, взглянем на финансовые вложения - приказ Минфина РФ от 10 декабря 2002 г. N 126н, ПБУ 19/02, "Общие положения" , пункт 6 - жестко выставляется требование аналитического учета вплоть до самой ценной бумаги:
По принятым к бухгалтерскому учету государственным ценным бумагам и ценным бумагам других организаций в аналитическом учете должна быть сформирована как минимум следующая информация: наименование эмитента и название ценной бумаги, номер, серия и т.д., номинальная цена, цена покупки, расходы, связанные с приобретением ценных бумаг, общее количество, дата покупки, дата продажи или иного выбытия, место хранения.
В этом направлении учета такие ведомости тоже не нужны и не нужно сверять книгу учета и движения векселей с соответствующими ведомостями по ГК, дабы доказать достоверность бухгалтерского учета и соответствующих граф регламентированных форм ?

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

[longson]

Цитата:

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

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

Я уже ответил.

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

[pyramid]

Правильно.

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

Цитата:

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

Правильно.

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

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

[pyramid]

Цитата:

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

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

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

[coolibin]

Цитата:

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

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

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