Суммирование и разбиение складских проводок

[Aquarius]

1. в Акс3 складские проводки (финансово разнесенные) можно было разбивать и суммировать. например можно разбить приходные складские проводки закупки ( не закрытые) и потом их объединить.
я нашла,что в updateSumUp таблицы inventtrans перед суммированием стоит проверка:
if (! this.isUpdatedFinancial() || ! this.hasSettlements())

2. В Акс9 SP5 складские проводки (финансово разнесенные) можно разбить, но нельзя суммировать. Почему так сделали в Акс9? Это не ошибка?

я нашла,что в updateSumUp таблицы inventtrans перед суммированием стоит проверка if ((! this.isUpdatedFinancial() && ! this.isUpdatedPhysical()) || ! this.hasSettlements())

Нам возможно понадобится суммировать финансово разнесенные проводки ( которые до этого были разбиты). Например приходные складские строки закупки.
В рамках Акс9 такое действие может считаться корректным?

[fed]

Цитата:

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

я нашла,что в updateSumUp таблицы inventtrans перед суммированием стоит проверка if ((! this.isUpdatedFinancial() && ! this.isUpdatedPhysical()) || ! this.hasSettlements())

Если посмотреть на код внимательно, то суммировать можно, если:

• нету сопоставлений (то есть - финансово или физически обновленные проводки не попавшие ни в какие закрытия и пересчеты могут быть просуммированы),
• если проводки вобще не были разнесены

Соответственно - суммировать финансово разнесенные складские проводки можно даже в версии 2009.
Изменение между версиями 3.0 и 2009, по всей видимости, было вызвано исправлением бага. Первоначальная версия кода была написана тогда, когда закрытие и пересчет вообще не трогали физчески разнесенные складские проводки. Соответственно - если код видел что проводка разнесена финансово - он лез проверять сопоставления, а если видел что не разнесена - разрешал суммирование без проверки сопоставлений. Где-то в ранних rollupах к 3ей версии, код пересчета и закрытия изменили таким образом, что он начал сопоставлять физически обновленные проводки (если в складской модели стоит галочка "Включать физические операции в себестоимость"). В результате этого могла возникнуть ситуация, когда физически обновленная складская проводка имела сопоставления в inventSettlement (с ссылкой по recId), а потом эту складскую проводку суммировали и удаляли. В результате в inventSettlement оставалась запись с висящей ссылкой на удаленный recId.

[Aquarius]

fed, большое спасибо за ответ.
хочу уточнить.
1. я разбила проводку закупки (статус куплено) на две проводки.
пытаюсь объединить их. объединения не происходит (все верно),т.к. по этой проводке были корректировки и поэтому есть запись в inventsettlement, что и не дает объединить проводки.
я отменила корректировку данных проводок.
пытаюсь объединить проводки ,все равно они не объединяются.
Правильно ли то что при проверке наличий сопоставления, не проверяется статус cancelled у записи. т.е. получается не важно отмена запись или активна в inventsettlement.
вот этот метод
public boolean hasSettlements()
{
return (select inventSettlement
index hint RecIdTypeIdx
where inventSettlement.TransRecId == this.RecId).RecId;

}
2. нам возможно понадобится в исключительных случаях объединять проводки , даже если они были скорректированы
я так понимаю,что если мы уберем проверку hasSettlements из
((! this.isUpdatedFinancial() && ! this.isUpdatedPhysical()) || ! this.hasSettlements()),
у нас это получится.
Но насколько это правильно с точки зрения логики Аксапты?
Мы хотим объединять те проводки ,которые возможно будут ошибочно разбиты.

[fed]

Оно не проверяет поле cancelled. Поскольку суммирование проводок может привести к удалению записей из inventTrans, это грозит появлением записей-сирот в inventSettlement -пусть даже отмененных.
В вашей ситуации есть только один простой выход:
Во первых где-то в периодических операциях модуля управления запасами есть операция очистки сопоставлений, которая тупо удаляет записи в inventSettlement, помеченные как отмененные/отменяющие. (Естественно - оставляя при этом записи в главной книге).
Во вторых - можно подумать и переделать процедуру суммирования inventTrans, таким образом чтобы она при удалении складских проводок перекидывала соответствующие записи в inventSettlement на новый inventTrans. Правда тут надо крепко думать насчет суммирования коррекций в самой проводке, но мне кажется (с вероятностью процентов 90) что этот режим можно реализовать.

Я бы начал с варианта 1, но если пользователи будут очень бастовать насчет производительности чистки сопоставлений - можно пытаться реализовать вариант 2.

[Raven Melancholic]

На мой взгляд, суммирование проводок, разнесенных финансового или физически особого смысла не имеет.
В той же строке заказа на покупку (или любого другого прихода) может понадобится суммирование проводок с статусе "Заказано" в тех случаях, когда используется резервирование в заказанных или маркировки. В этом случае, действительно, если ожидаемый приход разбит на несколько десятков или сотен проводок физический приход, который раскладывает не первичные аналитики под потребителей (особенно ,если потребителем является заказ на перемещение ,в котором далее протягиваются аналитики на сторону прихода) может занимать очень существенное время, так как нужно менять аналитики в потребителях для каждой из строк приходных проводок.
После же физического прихода каких-то причин суммировать проводки, на мой взгляд нет. Состояние склада зафиксировано, если нужны отчеты по складским проводкам то, все равно, в большинстве случаев в стандарте используется select sum(...). Конечно, какая-то выгода от того суммировать две проводки ил двадцать есть, но, мне кажется, небольшая.
Хотя ,естественно, могу ошибаться и оптимизатор SQL, увидев, что есть sum(...) .. group by... ведет себя очень сильно отличающимся образом зная, что в выборку попадают 3 записи или 30.