Отчёт Упр. Запасами \ Отчёты \ Статус \ Оборотная ведомость по складу

[Alks]

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

[mazzy]

Хм... к сожалению...

не пользуйтесь этими российскими отчетами.
пользуйтесь складскими проводками (включите подитоги по номенклатуре) и запасы в наличии.

и вообще предельно осторожно используйте отчеты из слоя dis.

[Alks]

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

Видел на форуме подсказки по получаению остатков на произвольную дату - там для скорости вместо суммирования проводок с начала времен предлагается вычитать проводки из текущего состояния склада (InventSum), но в InventSum нет номера лота, по которому можно было бы выйти на приходные и расходные цены, поэтому такой вариант для меня отпал. Сейчас уже близок к тому чтобы доделать отчёт суммирующий проводки с начала времен (еще недолго работаем, так что вроде не тормозит _пока_) и по номеру лота в проводках и ссылках на соответствующие таблицы вытаскивает из них информацию о приходных ценах и/или ценах реализации - процесс конечно муторный и до конца не отлаженный. Т.е. в главную книгу вообще стараюсь не лезть, а всё брать из проводок и породивших их документов.
Так вот... т.к. очевидно что при разрастании базы суммирование проводок окажется черезчур долгим, то хочу ввести дополнительную таблицу "итогов по проводкам", которая по структуре будет совпадать с InventTrans + доп. поле "дата итога". При закрытии склада некто будет запускать обработку, создающую в этой таблице итоги по интересующим нас полям и суммам, а отчёт будет отталкиваться от наиболее близких к его датам итогов, суммируя проводки начиная от них. (те кто хорошо знаком с регистрами в 1С на этом месте уже наверное хитро улыбаются ).
Так вот отсюда еще один вопрос - можно ли быть увереным что после закрытия склада проводки в InventTrans ниже даты закрытия гарантировано будут оставаться в неизменном виде?

[mazzy]

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

таблицы итогов (как в 1С ) делать не надо.
Поскольку inventSum больше напоминает ТА в регистрах накопления нежели бухитоги.

нач.ост/кон.ост получайте при помощи класса InventSumDateDim (и вообще, внимательно ознакомьтесь с семейством InventSumDate).
Финансовые показатели при помощи InventSumFinancial.
Приход/расход получайте из складских проводок за период...

Вот только... главная то проблема для постановщиков, знакомых с 1С, заключается вовсе не в классах. Главная проблема заключается в том, что Аксапта хранит 5 (пять!) дат с каждой складской проводкой. И главное - таки договориться что является расходом/приходом - дата отгрузки со склада или таки дата счета фактуры.

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

[mazzy]

На этом форуме было здесь
//axforum.info/forums/showthread.php?t=6873
может поможет...

[Alks]

Спасибо. На этих ссылках я уже был и про классы InventSumDate и его наследников знал - почерпнул из них многое. Мне они не подходят по той причине по которой я уже говорил - они отталкиваются от InventSum, а в InventSum нет номера лота. А я пока не вижу другого способа извлечь приходную и расходную суммы по проводке товара, кроме как ориентируясь на номер лота и накладные в которых он появляется и исчезает... Именно поэтому не могу использовать InventSum как некую "точку актуальности".

[Андре]

Если нет идеологических причин против использования не-аксаптовских средств, то можно посмотреть в сторону материализованных представлений. Особенно, если у Вас Oracle.
По желанию/необходимости можно подумать над поcтроением dwh и о использовании olap.

[Alks]

Цитата:

Сообщение от Андре

Если нет идеологических причин против использования не-аксаптовских средств, то можно посмотреть в сторону материализованных представлений. Особенно, если у Вас Oracle.
По желанию/необходимости можно подумать над поcтроением dwh и о использовании olap.

О да, о да... Насчёт OLAP согласен. Мешает только отсутсвие времени чтобы познакомится с этой технологией вплотную, знаю только в общих чертах. Что такое DWH не знаю вообще. Ну и плюс еще то, что пока я отчёт не сделаю я не буду знать откуда и какие данные надо брать для экспорта в кубы олап...

[Firestarter]

Мы в свое время делали специальной отчет Оборотная-ведомость по складу по физическим / финансвоым проводкам, с необходимыми суммами.
Расчет велся только по InventTrans

В зависиомсти от потребностей (аналитики / тип прихода-расхода) модернизация отчета была бы очень трудной

Решили сделать в OLAP - лучшего варианта (по гибкости / функционалу) пока пожелать трудно.

Дошло даже до того, что в этом отчете консолидировали данные из проводок разных компаний

[mazzy]

кто-нибудь статью написать хочет? поделиться опытом? прославить свое имя?

[Vadik]

Цитата:

Сообщение от Андре

Если нет идеологических причин против использования не-аксаптовских средств, то можно посмотреть в сторону материализованных представлений. Особенно, если у Вас Oracle.
По желанию/необходимости можно подумать над поcтроением dwh и о использовании olap.

Ой, не надо материализованных представлений, особенно если у Вас MSSQL, особенно на InventSum, InventDim, InventTrans. Да, скорость выборки при построении отчетности растет. Но количество (и качество ) блокировок возрастает просто до неприличия.

2Firestarter : какие объемы и как часто процессится куб? Удается ли обновить его в течение рабочего дня?

[Firestarter]

Объем данных конечно скромен для разговоров о производительности (куб обрабатывает 50 тыс записей).
Заливка данных во временную таблицу и пересборка куба занимает минут 5

Но по уровню детализации можно при этом реализовать практически любые капризы, при незначительных доработках

[Recoilme]

Во вложении пример расчета остатков на дату в буферную таблицу с начала периода. Может поможет чем-ть...

ОЛАП - тоже умеет это делать, но - в 2 словах не объяснишь, - выползут другие ограничения, - все равно надо сначала разобраться из каких таблиц и как тащить, а потом и олапом можно будет заняться.

[mazzy]

Цитата:

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

...с начала периода. Может поможет чем-ть...

Спасибо.

Но "с начала периода" - это неспортивно.
Может кто выложит реализацию, основанную на стандартных классах?

[Андре]

Цитата:

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

Ой, не надо материализованных представлений, особенно если у Вас MSSQL, особенно на InventSum, InventDim, InventTrans. Да, скорость выборки при построении отчетности растет. Но количество (и качество ) блокировок возрастает просто до неприличия.

Ну, во первых, я сразу подчеркнул, что в Oracle с этим дело гораздо лучше Во-вторых, view можно делать refresh on demand ,а не refresh on commit - что уменьшит описанные тобой проблемы. Ну и, я упоминул про MV скорее для тех, кто не знает olap - так как в данном случае, потратив несколько часов, человек может уже получить какой-то результат, в отличии от варианта, когда он возьмется за изучение olap.

[Vadik]

А я что, я ничего. Пробуйте, изучайте. Только не на production системе

[Alks]

Цитата:

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

[B]Мы в свое время делали специальной отчет Оборотная-ведомость по складу по физическим / финансвоым проводкам, с необходимыми суммами.
Расчет велся только по InventTrans

В зависиомсти от потребностей (аналитики / тип прихода-расхода) модернизация отчета была бы очень трудной...

Насчёт аналитик - дело нехитрое если уметь пользоваться классами InventDim / InventDimParm и их замечательными методами queryAddSortField и queryAddRange, ну или на худой конец пользоваться макросом #InventDimJoin. А так же классом inventDimCtrl и его наследником inventDimCtrl_Rep. Всё это позволяет делать приличные отчёты (да и Запросы тоже) с произвольной детализацией по складским аналитикам. Мне понравилось.

А вообще на вопрос быть OLAP-у в нашей системе или не быть ответ однозначный - быть. Но попозже.

Цитата:

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

Но "с начала периода" - это неспортивно.
Может кто выложит реализацию, основанную на стандартных классах?

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


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

[Alks]

Смотрю вот на класс InventSumDate и его наследников и вот что интересно:
Если в InventTrans есть проводка со статусом Purchased или Sold, но в соответствующей этому лоту записи InventTransPosting тип проводки стоит не Финансовый, а Физический, то класс эту проводку считает не за Purchased или Sold, а за Received или Deducted соответственно.
Никто не знает отчего такое расслоение в статусах между InventTrans и InventTransPosting может получится?

[tolstjak]

А кто-нибудь пробовал у этого отчета поставить галочку "Отражать нулевые обороты"?
У нас после установки этой галочки выводятся оборотны не принадлежавшие выбранному складу.

[BOAL]

Отчет InventTurnover_RU довольно глючный (тк со времен ах25 его особо не правили, а делали тогда от незнания всей глубины и сути)
Так что, писасть свой все равно нужно

вот скрин диалога нашего.



Далее он строится в Ексель(OWC) или бумажку (хотя бумажка - рудимент уже)
Основная прелесть - сходится с обороткой по ГК (складские счета), если врубить галку учета возвратов как сторно.
Правда, чтоб не врало ГК пришлось несколько пересчет склада побправить (там не делалось красное сторно при пересчете косвенных приходов)

По поводу скорости расчета от "рождества" - так там же можно select sum() получить - какая разница скоко там мильенов проводок?? запрос по сути своей один.

Или вы их все i++ делаете?