Отчет 'Запасы в наличии'

[DreamCreator]

День добрый!

Хочу иметь возможность печатать отчет 'Запасы в наличии' в разрезе склада (т.е. выводить все что есть на данном складе).

Стандартный вариант, как я понял, с этой заачей не справляется -- если не указать код аналитики, печататется некорректно -- а этот вариант меня не устраивает.

Отчет физ.наличие по складам не устраивает.

[MironovI]

Что-от я не понял, зашел в отчет, кнопуля Выбор, выбираю склад, печатаю - вот он.. что не так?

[DreamCreator]

А тепрь сравни результаты с теми которые выдаст отчет 'Физ Наличие по складам'!

У меня результаты совершенно разные и не в пользу Запасов в наличии.

[Mamuka]

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

[DreamCreator]

Запросы: (в начале SELECT и перечисление суммируемых полей)

1. В наличии (некорректен)

PHP код:

    FROM InventSum GROUP BY InventSum.ItemId ASC 
    
    JOIN * FROM InventDim WHERE InventSum.InventDimId = InventDim.inventDimId 
    
    EXISTS JOIN * FROM InventLocation 
        WHERE InventDim.InventLocationId = InventLocation.InventLocationId 
        AND ((InventLocationId = 01КазДек) 


2. Физ наличие по складам (корректен)

PHP код:

    FROM InventSum GROUP BY InventSum.ItemId ASC 
        WHERE InventDim.inventDimId = InventSum.InventDimId 
        
        EXISTS JOIN * FROM InventTable WHERE InventSum.ItemId = InventTable.ItemId 


Вызывает сомнение Физ наличие по складам -- InventDim фигурирует только в условии. Однако работает корректно.
С другой стороны, я не вижу ошибок в запросе 'В наличии' -- но результат некорректен!

[Yars]

2DreamCreator: А что именно некорректно?
2 разных отчета, отображают разную информацию.

Разнесенное количество, Получено и Физически зарезервировано есть в 2х отчетах.

Для получения информации о наличии по конкретному складу можно воспользоваться запросом "В наличии" (Аксапта / Управление запасами / Запросы). Отобразить только нужный склад. При необходимости, распечатать.

Либо доработать стандартный отчет.

Какую информацию вы хотите получить в этом отчете?

[DreamCreator]

Цитата:

Изначально опубликовано Yars
2DreamCreator: А что именно некорректно?

При указании склада в Запасах в начличии выходит только одна строка, хотя должно быть (проверяя по Физ Наличию по складам) больше.

Цитата:

2 разных отчета, отображают разную информацию.
Разнесенное количество, Получено и Физически зарезервировано есть в 2х отчетах.

Да, эти поля нужны в результирующем отчете, а вот себестоимость категорически нет.

Цитата:

Для получения информации о наличии по конкретному складу можно воспользоваться запросом "В наличии" (Аксапта / Управление запасами / Запросы). Отобразить только нужный склад. При необходимости, распечатать.

Странная ситуация -- нельзя установить новые фильтры при формировании автоотчета -- в этом основной минус!

Цитата:

Либо доработать стандартный отчет.

Видимо придется резать дубликат Физ наличия по складам.

Цитата:

Какую информацию вы хотите получить в этом отчете?

Различные количества без себестоимости, все что есть на выбранном складе.

[UNRW]

Исользовать InventSum в Аксапте как-то "не по-пацански". Надо использовать InventTrans чтобы собрать остаки на дату + если нужна сумма в деньгах то надо использовать InventSettelment и смотреть коррекции себестоимости. Кроме того не надо забывать, что в InventTrans есть DatePhicical и DateFinancial и в зависимости от того что хочется получить.

Короче... надо строить свои отчеты Аксаптовские стандартные отчеты мало удобны для использования. Да и еще в зависимости от SP могут выдавать разную информацию (пример - оборот по складу в SP1 и SP3)

[mazzy]

Цитата:

Изначально опубликовано UNRW
Исользовать InventSum в Аксапте как-то "не по-пацански". Надо использовать InventTrans

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

Если вы будете делать отчеты, которые обращаются только к InventTrans (как это сделали при локализации в русских отчетах), то очень быстро ваш отчет станет жутко тормозным поскольку будет суммировать проводки от начала времен.

Разберитесь таки с InventSum, зачем он нужен и с обслуживающими классами.

[Axapta]

Полностью поддерживаю Mazzy. Правильно рассчитывать остатки лучше с помощью классов наподобие InventSumDate*, которые остатки на дату считают через InventSum и куски InventTrans и InventSettlement.

А запрашивать весь InventSettlement с начала времен - это неправильный подход.

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

[Axapta]

Оборотку по складу писали в России. А местные разработки, как не жаль констатировать, зачастую менее качественны, чем международный слой.

[dn]

Цитата:

Изначально опубликовано Axapta
Полностью поддерживаю Mazzy. Правильно рассчитывать остатки лучше с помощью классов наподобие InventSumDate*, которые остатки на дату считают через InventSum и куски InventTrans и InventSettlement.

Сам подход с точки зрения теории - верный, только не стоит в отчетах тупо использовать классы InventSumDate*. Для одной номенклатуры они отработают звёздно, но гнать их в цикле по номенклатуре не стоит...

[mazzy]

Цитата:

Изначально опубликовано dn
Сам подход с точки зрения теории - верный, только не стоит в отчетах тупо использовать классы InventSumDate*. Для одной номенклатуры они отработают звёздно, но гнать их в цикле по номенклатуре не стоит...

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

[Axapta]

Цитата:

Изначально опубликовано dn


Сам подход с точки зрения теории - верный, только не стоит в отчетах тупо использовать классы InventSumDate*. Для одной номенклатуры они отработают звёздно, но гнать их в цикле по номенклатуре не стоит...

А почему бы и не "гнать"?

[dn]

Цитата:

Изначально опубликовано Axapta
А почему бы и не "гнать"?

По-времени как-то тоскливо получается, на этом фоне оптимизированный запрос "с начала времен" уже не кажется таким ужастным...

2 mazzy
Извини, не понял про "групповую обработку номенклатуры".
Вроде бы речь шла о получении остатков на дату в разрезе определенных складских аналитик...

[Axapta]

[QUOTE]Изначально опубликовано dn
[B]

По-времени как-то тоскливо получается, на этом фоне оптимизированный запрос "с начала времен" уже не кажется таким ужастным...

Один запрос (даже оптимизированный) не всегда работает быстрее, чем много мелких.... =)

Ну у меня есть практический пример - 70000 номенклатур, 15млн складских проводок, 40млн складских сопоставлений, система эксплуатируется 2 года, СУБД - SQL.

Остатки на дату по всему ассортименту с помощью стандартного отчета - 10 мин., через InventTrans даже без группировки по складской аналитике - в разы дольше (+ большие чтения с диска из-за глобальной выборки, что приводит к более медленной работе как этой сессии, так и других пользователей).

[Владимир Максимов]

У отчета по InventTrans с "начала времен" есть еще один недостаток.

"Начало времен" - это этап внедрения AXAPTA. Перевод данных из старых программ и хранилищь в новые. Т.е. это время такого "бардака", что и не сразу опишешь.

Как следствие, нет никакой гарантии, что данные "начала времен" достаточно корректны. Есть очень большой шанс, что InventSum в "начале времен" было заполнено не по фактическим значениям InventTrans, а по результату инвентаризации.

Т.е. расчет по InventTrans "с начала времен" будет отличаться от того, что храниться в InventSum.

[mazzy]

Цитата:

Изначально опубликовано Владимир Максимов
Есть очень большой шанс, что InventSum в "начале времен" было заполнено не по фактическим значениям InventTrans, а по результату инвентаризации.

Так делать нельзя.

inventSum - сугубо служебная таблица. ее нельзя править, поскольку эта таблица пересчитывается автоматически
http://forum.mazzy.ru/index.php?showtopic=3419

Данные можно вводить только проводками + коррекция себестоимости.

[dn]

Цитата:

Изначально опубликовано Axapta
Один запрос (даже оптимизированный) не всегда работает быстрее, чем много мелких.... =)
Ну у меня есть практический пример - 70000 номенклатур, 15млн складских проводок, 40млн складских сопоставлений, система эксплуатируется 2 года, СУБД - SQL.

Хороший результат. У нас InventSumDate* отрабатывет на Oracle как-то не так шустро...

[MironovI]

[QUOTE]Изначально опубликовано Axapta
[B]

Цитата:

Изначально опубликовано dn

Ну у меня есть практический пример - 70000 номенклатур, 15млн складских проводок, 40млн складских сопоставлений, система эксплуатируется 2 года, СУБД - SQL.

Похожие объемы - все нормально - все дело в наличии индексов - тогда суммирование 1-го мильена проводок не сильно отличается от 15, и в том что выборка падает в память серваку и если ее у него мало - будет свопить и за месяц не сделается..