[fed]

Цитата:

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

Возможно, мой вопрос неправильный, но спрошу всё же.Закрытие склада, класс InventCostClosing, метод createInventCostList() (версия Ax4.0), там 4 похожих куска кода:

    while select forceplaceholders ItemId from inventTable
        index hint TypeIdx
        where inventTable.ItemType == ItemType::Item
    exists join inventTrans
        index hint OpenItemIdx
        where inventTrans.ValueOpen == InventTransOpen::Yes     &&
              inventTrans.ItemId    == inventTable.ItemId
    {
        this.createInventCostListItem(inventTable.ItemId,recordInsertList);
    }

Вопрос: может, стоит добавить еще условие по попаданию inventTrans.DateFinancial в закрываемый период? например, для ускорения расчета. Или это ничего не даст и вообще неправильно?

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

Во вторых - я не думаю что вы что-то сильно ускорите. В текущей реализации вы просто создаете запись в inventCostList, потом система загружает только приходные проводки (поскольку если расходные проводки в открытом периоде есть, то ваше предложение точно не сработало бы и мы можем этот вариант в рассмотрение не брать), а потом не найдя расходных проводок просто тихо забывает про данную номенклатуру. То есть - сэконоите вы от силы процентов 10-15 времени и только на НУЛЕВОЙ итерации закрытия. Которая сама по себе обычно занимает процентов 15 времени закрытия. Соответственно, сэкономите вы 2-3 процента общего времени закрытия, а всяких рисков дополнительных получите по полной программе.

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