Отвечу по шагам. В текущей (2009RU7) версии аксапты есть два подхода к принудительному (без нормального сопоставления и рассчета себестоимости) закрытию проводок:
- Услуги. В версии 4.0sp1, появилась специальная ветка (inventCostItemDim,updateServiceItemTrans()), которая принудительно закрывает складскип проводки по услугам. Закрывает она их по умному, заполняя сопоставленное количество, сопоставленную сумму и создавая в складских сопоставлениях запись специального типа (InventSettletModel::ServiceItem). Из за того что все эти поля заполняются и запись сопоставления создается, такая проводка для всех (ну или почти всех) стандартных и нестандартных отчетов выглядит как закрытая и сопоставленная 'по честному'
- Нефинансовые переносы. В DAX2009RU7 отбэкпортили из DAX2012 фичу, которая позволяет при закрытии игнорировать нефинансовые переносы (то есть - проводки переноса у которых у прихода и расхода одинаковые складские аналитики финансового склада). При этом такие проводки помечаются как закрытые 'по грубому'. То есть - просто тупо у проводок ставится признак закрытия и дата закрытия (и еще в некое совсем новое поле вешается ссылка на запись в inventClosing по закрытию). Из за этого, по моим ощущениям, заметная часть складских отчетов на такие проводки будет плохо реагировать. По крайней мере часть моих самописных отчетов - точно будет плохо реагировать.
Когда я по поводу этого подхода высказал некоторые сомнения в уже упомянутой дискуссии, участник Ievgenii, написал что "Наши ПМы убедеждены что этого делать не надо, чтобы не терять времени. По-этому для не финансовых переносов убрали. Для услуг - это легаси код, который не меняли." Я так подозреваю, что под термином "Наши ПМы" скрывался конкретно Anders Girke, ответственный за костинг в Аксапте
Теперь о твоей конкретной ситуации: Во первых - со своим советом насчет того чтобы подхакать закрытие чтобы считало всю номенклатуру сервисами - я был не прав. Дело в том, что у тебя тогда ВСЕ проводки пометяться как закрытые, а задача состоит в том чтобы пометить как закрытые только те проводки, которые НЕ ВХОДЯТ в текущий остаток. Соответственно у тебя есть два подхода к решению проблемы:
1. Написать собственную процедуру закрытия. Просто надо бежать по текущим складским остаткам в разрезе аналитик финансового склада и для каждой комбинации аналитик отсчитывать назад от текущей даты достаточно складских проводок в статусе "Закуплено" чтобы покрыть текущий складской остаток. Затем все остальные складские проводки надо пометить как закрытые (с использованием кода inventCostItemDim.updateServiceItems() как прототипа). Да - еще замечу что если у тебя в складских остатках, допустим 5 штук, а приходная проводка на 12, то тебе надо ее рассплитить на две проводки по 7 и 5 штук, первую закрыть, а вторую - оставить. Я бы лично пошел по этому пути.
2. Если ты не чуствуешь себя достаточно увереным для варианта N1, по прежнему можно пойти по пути обычного закрытия склада. Я бы, к рекомендациям mazzy, сделал такие поправки:
- Ставьте модель FIFO - она самая быстрая.
- Поскольку себестоимость вам не важна, поставьте максимальное число итераций в 1. Тогда у вас на нулевой итерации все проводки сопоставяться и закроются, а на первой итерации вся зависшая себестоимость спишется на прибыли и убытки.
- Можно закрывать склад ЗА ВСЕ ВРЕМЯ, но вам понадобится очень много хелперов. В принципе, если ты за все время склад закрываешь, то ограничивающим является только память, в которую система загружает сразу все проводки по данной номенклатуре и аналитике для сопоставления и прогонки коррекции. Чтобы оценить то, сколько времени займет закрытие одной номенклатуры в худшем случае (и чтобы посмотреть хватит ли памяти и тп), попробуй пересчитать склад по одной номенклатуре (с максимальным числом записей в inventTrans) за все время. Потом попробуй то же самое для номенклатуры со средним числом записей в inventTrans. Потом подели ваш временной промежуток (48 часов) на это время и получишь (грубо приблизительно) число хелперов, которые нужны чтобы закрыть склад за это время.
- Попробуйте запустить пересчет по самой популярной номенклатуре с тем числом хелперов которые получились на предыдущем пункте, и помониторьте загрузку сервера БД. Если у вас там полный содом с утилизацией, памятью и очередью к диску - значит номер заведомо не пройдет и надо разбираться с вариантом N1 и принудительным закрытием.
- Когда будете планировать закрытие, заложитесь с приличным запасом по времени.
- Наконец - возможен вариант комбинации больших и маленьких закрытий Сначала закрыть за выходные и (если понадобится) понедельник и вторник длительный период (первые 6 лет работы), потом по вечерам потихоньку позакрывать по месяцам.
- Если будете закрывать склад параллельно пользовательской работе, можно попробовать понизить макрос CommitCountMax в заголовке класса inventCostItemDim с 50 до, скажем, 15. Производительность закрытия понизиться (потому что транзакция будет коммититься после каждых 15 обновленных проводок), но шансы на откаты транзакций и retry из за того что несколько станций обновили inventSum - уменьшаться.