Складской контур

[rok1]

Добрый день уважаемые форумчане!

Наша Компания использует Ах03 уже с 2007 г., но до сих пор невозможно сформировать ОСВ по складам. Программисты наистаивают использовать куб который они построили. Но мне хочется, что бы отчет формировался напрямую из Ах.
Подскажите пожалуйста это прихоть пользователя или лень программистов? И наверняка возможности складского модуля шире чем куба?

С важением, Александр

[mazzy]

Цитата:

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

Наша Компания использует Ах03 уже с 2007 г., но до сих пор невозможно сформировать ОСВ по складам. Программисты наистаивают использовать куб который они построили. Но мне хочется, что бы отчет формировался напрямую из Ах.
Подскажите пожалуйста это прихоть пользователя или лень программистов? И наверняка возможности складского модуля шире чем куба?

давайте разобьем вопрос на два:

1. "до сих пор невозможно сформировать ОСВ"
это полный отстой. технологически все инструменты есть http://axapta.mazzy.ru/lib/inventsumdate/

опыт подсказывает, что с ОСВ проблема не в том, что ее нет.
а в том, что пользователи не могут договориться в какой момент движение товара должно попадать в ОСВ. а также не могут договориться какая именно сумма должна попадать в ОСВ.
дело в том, что Аксапта четко различает физическое движение и финансовое движение по складу.
физическое - когда товар действительно поступил на склад или ушел со склада.
финансовое - когда был оформлен бухгалтерский документ (акт приемки, ТОРГ-12) на движение этого товара.

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

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

2. "Программисты наистаивают использовать куб который они построили"
куб - это более быстрых движок, программистски более прогрессивный движок, в последних версиях аксапты майкрософт использует именно его.
с точки зрения пользователей, куб позволяет возможность строить отчеты в ширину (склады в колонках).
недостаток с точки зрения пользователей - невозможно от итоговых сумм в кубе вернуться к детальным данным по проводкам (drill-down).

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


Поэтому
скорее всего, ОСВ по складу у вас есть.
но этот ОСВ не принят некоторыми пользователями в вашей организации (а некоторые могут вполне им пользоваться).
скорее всего, программисты хотят сбросить с себя наконец-то задачу согласования отчета и тупо дать пользователям "стройте как хотите".

[rok1]

ответ программистов
Наконец-то нашелся один умный человек на компанию, а то в течение нескольких лет никто не знал как считать остаток на дату, просто суммируя имеющиеся операции до нужной даты. 
Остатки на дату у нас есть в нескольких кубах. Напомню, что кубы сами по себе у нас весьма сложные и многосоставные (потому бывает и глючат) из-за того, что стандартными средствами из-за большого объема данных запрос не возвращает данных в разумные сроки.
Таблица складских движений у нас содержит сейчас 17 000 000 записей, аналитик – более 43 100 000, таблица InventTrans – 43 400 000. Для данного отчета в запросах их придется «перекрестить» несколько раз, пристыковав еще несколько табличек поменьше. И это только в том случае, если ни о каких сложных стыковках с финансами речи не будет идти.

Остатки на дату можно получить из куба «Движение ТМЦ».

мой запрос программистам

http://axapta.mazzy..../inventsumdate/

добрый день коллеги, прошу запустить в работу складской модуль по формированию ОСВ.

Укажите пожалуйста срок выполнения или причины невозможности выполнения

спасибо




Кубы реально глючат, то есть не выгружают остатки по номенклатуре и при транслировании в Ех выдают савсем другие данные.
Помогите пожалуйста, какой запрос нужно дать программистам, что бы можно было получить одни и теже (желательно реальные) данные по складам
С уважением, Александр

[mazzy]

Цитата:

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

Таблица складских движений у нас содержит сейчас 17 000 000 записей, аналитик – более 43 100 000, таблица InventTrans – 43 400 000. Для данного отчета в запросах их придется «перекрестить» несколько раз, пристыковав еще несколько табличек поменьше.

э-э-э...

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

во-вторых, я не понял почему у вас отдельно выделены "Таблица складских движений" и "inventTrans". Вообще говоря, это должно быть одно и то же. Видимо под таблицей складских движений вы подразумевали что-то другое.

в-третьих, настораживает, что число записей в таблице аналитик сопоставимо с числом записей в InventTrans. Аксапта писалась из предположения, что таблица аналитик на порядок(порядки) меньше inventTrans. В этом случае нормально работает оптимизация, уже заложенная в Аксапте. В вашем случае нужно что-то делать с запросами и индексами. Совет: поискать на axforum.info по ключевому слову "селективный индекс".

в-четвертых, сильно настораживает слово "перекрестить" (join). Вообще говоря, принцип в Аксапте - данные из документов переносятся в проводки. Если для получения отчетов нужно обращаться во много других таблиц, то нарушен один из концептуальных принципов аксапты. Опять же - не смертельно. просто нужно заниматься оптимизацией индексов, запросов и базы. (абсолютно типовая работа администратора и программистов)

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