AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.03.2018, 16:33   #1  
Cathome is offline
Cathome
Участник
Аватар для Cathome
 
54 / 23 (1) +++
Регистрация: 10.11.2010
Адрес: Москва
? Пересчёт склада в пакетном режиме
DAX ядро 4.0.2503.454, приложение 4.0.2501.122, СУБД не знаю.

Всем добрый день.
Вот такой вопрос. Мы в нашей компании каждую неделю считаем склад. Делаем это руками - до тех пор, пока при очередном пересчёте не будет чисто в плане сопоставлений. Это занимает 3-4 повторения.

Мне не нравится, что приходится это делать руками. Хотелось бы как-то наладить пересчёт в пакетном режиме, но тут возникают вопросы.
  1. В пакете нельзя запускать пересчёт несколько раз. Конечно, можно поиграться со значениями макс. пропускной способности, но экспериментальным путём мы пришли к тому, что в разы быстрее посчитать несколько раз, чем поставить большую макс.пропускную способность, да и нет гарантии, что при ней склад всегда пересчитается в ноль за один присест.
  2. Если даже и можно как-то запустить несколько раз, как можно узнать, что предыдущий раз завершился?

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

Поиском по форуму внятных ответов на вопрос, как в пакетном режиме правильно пересчитать склад, не нашла..
__________________
"казалось бы, зачем виртуализировать виртуализаторы виртуализаторов виртуальных ява-машин, но Оракл было уже не остановить..." © Башорг

Последний раз редактировалось Cathome; 12.03.2018 в 16:36.
Старый 12.03.2018, 16:49   #2  
twilight is offline
twilight
MCTS
MCBMSS
 
704 / 126 (6) +++++
Регистрация: 17.10.2004
Адрес: Москва
Всегда думал, что количество запусков не влияет на результат. А как у вас получается, что при нескольких запусках результат изменяется?
__________________
I could tell you, but then I would have to bill you.
Старый 12.03.2018, 16:57   #3  
Cathome is offline
Cathome
Участник
Аватар для Cathome
 
54 / 23 (1) +++
Регистрация: 10.11.2010
Адрес: Москва
Да, сопоставления-то формируются, следовательно, себестоимость меняется. Ну вот приведу пример, легкий был пересчёт, всего за 2 повторения все рассчиталось. Обычно 3-4 раза считаем.
Миниатюры
Нажмите на изображение для увеличения
Название: Склад.jpg
Просмотров: 90
Размер:	173.2 Кб
ID:	11850   Нажмите на изображение для увеличения
Название: Склад2.jpg
Просмотров: 83
Размер:	114.8 Кб
ID:	11851  

__________________
"казалось бы, зачем виртуализировать виртуализаторы виртуализаторов виртуальных ява-машин, но Оракл было уже не остановить..." © Башорг
Старый 27.03.2018, 17:10   #4  
Cathome is offline
Cathome
Участник
Аватар для Cathome
 
54 / 23 (1) +++
Регистрация: 10.11.2010
Адрес: Москва
В общем, решила сделать класс, который будет делать то, что мне нужно. Но это оказалось весьма нетривиально.
Сначала думала отнаследоваться от InventCostClosingRecalc, но оказалось, не судьба, т.к. у него только статические конструкторы.
Тогда решила отнаследоваться от RunBaseBatch, но тут встал вопрос, как получить параметры из диалога пересчёта, ведь он запаковывается до того, как распаковывается мой класс. Использовала xSysLastValue, чтобы достать параметры пересчёта, и параметр getLastCalled, что бы это ни было (не смогла нагуглить о нём ничего вразумительного), для того, чтобы делать это только при создании пакетного задания, но не при его просмотре и запуске.

Всё это наводит лишний раз на мысль о том, что я чего-то не понимаю в стандартном функционале пересчёта, если никому до нас это не надобилось.
__________________
"казалось бы, зачем виртуализировать виртуализаторы виртуализаторов виртуальных ява-машин, но Оракл было уже не остановить..." © Башорг
Старый 27.03.2018, 18:53   #5  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,837 / 3733 (182) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от Cathome Посмотреть сообщение
Делаем это руками - до тех пор, пока при очередном пересчёте не будет чисто в плане сопоставлений. Это занимает 3-4 повторения.
...
В общем, я думаю над тем, чтобы сделать класс, который бы запускался в пакетном режиме и крутил бы пересчёт по условию.
скорее всего, не надо делать никакого класса.

у стандартного функционала есть два параметра

1. число повторений. по умолчанию = 100
2. минимальное изменение себестоимости. по умолчанию = 1

это значит, что стандартный функционал будет повторять процедуру закрытия до тех пор,
ПОКА себестоимость изменяется сильно (больше, чем второй параметр)
ИЛИ будет выполнено максимальное число повторений

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

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

а вот первый параметр обычно оставляют по умолчанию = 100.
хотя в вашем случае "3-4 повторения" означает, что фактически вы делаете 300-400 итераций.

поэтому поставьте в первый параметр 400 или 500.
а второй параметр не уменьшайте слишком близко к 0.01, сделайте 1.0 или хотя бы 0.10
Миниатюры
Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 69
Размер:	73.2 Кб
ID:	11865   Нажмите на изображение для увеличения
Название: 2.PNG
Просмотров: 70
Размер:	73.7 Кб
ID:	11866  

__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.

Последний раз редактировалось mazzy; 27.03.2018 в 18:55.
За это сообщение автора поблагодарили: alex55 (1).
Старый 27.03.2018, 19:10   #6  
Cathome is offline
Cathome
Участник
Аватар для Cathome
 
54 / 23 (1) +++
Регистрация: 10.11.2010
Адрес: Москва
Макс.пропускную способность 2 раза пробовала 500, и в этом случае, честно говоря, за весь рабочий день не дождалась результата. Не могу понять, с чем это связано, при 100 3-4 пересчёта занимают минут 20-30. Со вторым параметром, честно, не пробовала играться, т.к.подозреваю, что он замедляет процесс ещё больше.
__________________
"казалось бы, зачем виртуализировать виртуализаторы виртуализаторов виртуальных ява-машин, но Оракл было уже не остановить..." © Башорг

Последний раз редактировалось Cathome; 27.03.2018 в 19:19.
Старый 27.03.2018, 19:35   #7  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,837 / 3733 (182) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от Cathome Посмотреть сообщение
500, и в этом случае, честно говоря, за весь рабочий день не дождалась результата. Не могу понять, с чем это связано, при 100 3-4 пересчёта занимают минут 20-30.
deadlock к каким-то периодическим заданием в пакетнике.

==============================
общий совет, как контролировать и оптимизировать процедуру закрытия

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

заглядывайте туда. смотрите какие номенклатуры там появляются, с каким номером итерации.

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

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

далее список упорядочивается по уровню и номеру расчета.

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

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

в идеале, закрытие должно выполняться за (1-2 * максимальная_глубина_спецификации) итераций. максимум за (10 * максимальная_глубина_спецификации) итераций.


Цитата:
Сообщение от Cathome Посмотреть сообщение
Со вторым параметром, честно, не пробовала играться, т.к.подозреваю, что он замедляет процесс ещё больше.
судя по вашим скриншотам, у вас там 0.01 )
сделайте чуток больше.
Миниатюры
Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 73
Размер:	187.9 Кб
ID:	11868   Нажмите на изображение для увеличения
Название: 2.PNG
Просмотров: 72
Размер:	111.4 Кб
ID:	11869  

__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.

Последний раз редактировалось mazzy; 27.03.2018 в 19:40.
За это сообщение автора поблагодарили: Cathome (1).
Старый 27.03.2018, 19:54   #8  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
266 / 346 (12) ++++++
Регистрация: 08.08.2007
Цитата:
Сообщение от mazzy Посмотреть сообщение
судя по вашим скриншотам, у вас там 0.01 )
сделайте чуток больше.
В стандарте нельзя указать значение меньше, чем значение в общем правиле округления x10(в случае если указано 0, то берется точность как 0.01, ну и как правило никто там ничего не ставит), т.е. в большинстве случаев меньшем чем 0.1 просто не укажешь.

Использование данного параметра отличается от типа пересчета, корректировка себестоимости создается в случае, если используется типа пересчета = закрытие, посмотрите например в код InventcostItemDim\updateTransIdReceipt (подобные условия есть не только там)

X++:
                    if (inventClosing.AdjustmentType == InventAdjustmentType::Closing)
                    {
                        if (abs(adjustNow) < inventClosing.MinTransferValue || inventClosing.NumOfIteration >= inventClosing.MaxIterations)
                        {
                            // <GEERU>
                            if (countryRegion_RU)
                            {
                                this.createErrorAdjustment(receipt,-adjustNow, false);
                            }
                            else
                            {
                            // </GEERU>
                               this.createErrorAdjustment(receipt,-adjustNow);
                            // <GEERU>
                            }
                            // </GEERU>
                        }
                    }
Поэтому некоторые используют схему сначала пересчет, а потом закрытие, чтобы получить более точную себестоимость, другое дело, что параметр 1 в пропускной способности более чем достаточно, но не все готовы видеть разрыв себестоимости строки переноса или заказа на перемещение
__________________
Sergey Nefedov,
IT Magnet
За это сообщение автора поблагодарили: mazzy (5), Ivanhoe (2), Cathome (1).
Старый 28.03.2018, 12:10   #9  
Cathome is offline
Cathome
Участник
Аватар для Cathome
 
54 / 23 (1) +++
Регистрация: 10.11.2010
Адрес: Москва
Хочу сказать, что мы сначала делаем пересчёты для уточнения себестоимости, и только потом закрываем, но речь о закрытии, в данном контексте, не идёт вообще. Мы делаем пересчёты еженедельно для отчётности в головную компанию.

Цитата:
Сообщение от mazzy Посмотреть сообщение
в идеале, закрытие должно выполняться за (1-2 * максимальная_глубина_спецификации) итераций. максимум за (10 * максимальная_глубина_спецификации) итераций.
Вот тут я не совсем поняла, имеется в виду количество программных последовательностей (NumOfIteration)?

И разве уровень спецификации не имеет отношения только к производственным номенклатурам?

count(ItemId) BOMLevel

6463 ------------- 0
320 --------------- 1
99 ---------------- 2
6 ------------------ 3

Я посмотрела, у нас макс. уровень 3, дело в том, что производство и движение гп - капля в море на нашем складе, в основном, это переносы и перемещения товаров (между центральным складом и 15 филиалами и переносы между местами хранения). Поэтому глубина спецификации - это не то, что сильно влияет на наш склад.

Цитата:
Сообщение от mazzy Посмотреть сообщение
судя по вашим скриншотам, у вас там 0.01 )
сделайте чуток больше.
Не, у нас стандартно, единичка там.

Сегодня попробовала разные комбинации, вот с таким результатом:



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

Макс.число программных последовательностей (NumOfIterations) при пересчётах в любых вариантах получилось = 3.

Что касается того, что я писала раньше, по поводу того, что на пропускной способности (MaxIterations) = 500 не дождалась результата. Может быть, это был deadlock, но скорее, какие-то проблемы в складских проводках, потому что количество номеров в расчёте обычно стоит 2000-2400, а тогда оно было около 50 000. Правда, в те 2 раза я решила, что на большом параметре MaxIterations это нормально и не стала разбираться более детально. Сегодня воспроизвести подобный результат мне не удалось.

__________________
"казалось бы, зачем виртуализировать виртуализаторы виртуализаторов виртуальных ява-машин, но Оракл было уже не остановить..." © Башорг

Последний раз редактировалось Cathome; 28.03.2018 в 12:40.
Старый 28.03.2018, 20:34   #10  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
266 / 346 (12) ++++++
Регистрация: 08.08.2007
Цитата:
Сообщение от Cathome Посмотреть сообщение
Макс.число программных последовательностей (NumOfIterations) при пересчётах в любых вариантах получилось = 3.
Максимальное кол-во программных последовательностей сверху ограничено значением максимальной пропускной способности, если это значение было бы равно 100, 400 и т.д., то тогда смысл увеличивать его имеется, а так если у вас максимум 3, то можно хоть 5 поставить ничего не поменяется.

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

Поэтому берите отладчик в руки, запускайте итеративные пересчеты по одной номенклатуре(благо это не так сложно воспроизвести), ищите место в коде закрытия, где работает не так как вам надо, а дальше уже по результатам анализа будет понятно что и как можно\нужно делать, по другому думаю не получится, если только кто то не сталкивался с подобной проблемой
__________________
Sergey Nefedov,
IT Magnet

Последний раз редактировалось SRF; 28.03.2018 в 20:37.
За это сообщение автора поблагодарили: Cathome (1).
Старый 29.03.2018, 10:18   #11  
Cathome is offline
Cathome
Участник
Аватар для Cathome
 
54 / 23 (1) +++
Регистрация: 10.11.2010
Адрес: Москва
Цитата:
Сообщение от SRF Посмотреть сообщение
Максимальное кол-во программных последовательностей сверху ограничено значением максимальной пропускной способности, если это значение было бы равно 100, 400 и т.д., то тогда смысл увеличивать его имеется, а так если у вас максимум 3, то можно хоть 5 поставить ничего не поменяется.
Извините за глупый вопрос, т.е. maxIterations и NumOfIteration - понятия одного порядка? Неужели у кого-то бывает больше 100?

По поводу копеек. Да, вы правы. На втором пересчёте уже идут коррекции менее 10 коп. (при мин.коррекции 0.1). Проблема в том, что всё равно эти коррекции порождают проводки в ГК. Сегодня проверила. И проанализировала наши операции за прошлое время, почти везде на втором пересчёте есть операция ГК и почти везде есть суммы коррекции менее 10 коп., разнесённые в ГК (даже при пороге в рубль).

Откуда они берутся, я и без отладчика знаю. В закупках на количество, кратное 2, постоянно приходится сумма, не кратная 2. И эта лишняя копейка в рамках партии потом гоняется туда-сюда до тех пор, пока не закроется склад или пока партия не спишется. Я думаю, это у всех есть, но не у всех при этом получаются фин.проводки. У нас очень часто партия расщепляется на разные бух.счета. Допустим, по одной такой партии приход на 41 потом корреспондирует с 10, 91, 20, или даже банально происходит смена фин.аналитики при перемещении. Вот и проводки от этой копейки. В рамках всего склада много таких операций набирается. Работает ли пересчёт не так, как нам надо, или мы работаем не так, под что заточена Аксапта, это вопрос риторический..

Другой вопрос, что в пересчёте для отчётности, возможно, нет такой острой необходимости получить точную себестоимость, которая всё равно в рамках месяца неточная. А при подготовке к закрытию всё равно запускается всё вручную и нет разницы, 1 или 3-4 раза это сделать.

Я вообще против каких-либо модификаций и сама считала бы для отчётности 1 раз. Но т.к. это делаю не я, то только могу высказать своё мнение на этот счёт.
__________________
"казалось бы, зачем виртуализировать виртуализаторы виртуализаторов виртуальных ява-машин, но Оракл было уже не остановить..." © Башорг

Последний раз редактировалось Cathome; 29.03.2018 в 10:23.
Старый 29.03.2018, 11:08   #12  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
1,708 / 881 (33) +++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Cathome Посмотреть сообщение
Извините за глупый вопрос, т.е. maxIterations и NumOfIteration - понятия одного порядка? Неужели у кого-то бывает больше 100?
NumOfIteration это сколько реально итераций было при закрытии (пересчете)
MaxIterations - это то, чем вы ограничиваете Аксу в размере NumOfIteration, то есть больше итераций она делать не будет и при закрытии просто спишет разницу (при пересчете не будет перебрасывать разницу дальше).
При боле-менее сложной логистике (производство и сборка спецификаций, склады хранения, распределительные склады, склады филиалов, склады торговых точек и т.п.) вполне нормальным бывает 30-40 итераций. Возможно все может быть настолько сложным в плане логистики, что нужно и более 100, но мне пока встречались ситуации, то такое количество возникает тогда, когда есть какое-то "зацикливание" (было списание со склада на другой склад, потом возврат с другого склада обратно, потом опять отгрузка и т.д., в результате, сумма коррекции гонялась по кругу).
За это сообщение автора поблагодарили: Cathome (1).
Теги
пересчет себестоимости, складские запасы

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
модификация taxTrans_RU в пакетном режиме в классе GoodsInRouteUpdate_RU Владимир Максимов DAX: Программирование 0 13.08.2015 18:13
DAX 2009 - Трассировка долгих SQL-запросов в пакетном режиме N.D.P. DAX: Администрирование 4 18.03.2015 09:13
Denis Fedotenko: Себестоимость и закрытие склада Blog bot DAX: База знаний и проекты 44 29.03.2010 14:54
Вывод отчета в файл в пакетном режиме Egor_bl DAX: Программирование 3 09.11.2006 09:36
Вывод отчета в файл в пакетном режиме Egor_bl DAX: Программирование 16 09.10.2006 19:10
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:03.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.