Складская аналититика в журналах переноса

[Firestarter]

Цитата:

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


Зато есть у предков. Корень у них InventMovement.

Ок, спасибо, нашел, перекрыл методы как написано, но все равно не работает.
Что упустил? Или modify в форме надо тоже изменить? Если да, то как?

[Yprit]

Подниму тему. Интересная такая фишка получается.
Проблема: стали появляться в системе журналы переноса, у которых проводка расхода идет с полной комбинацией складских аналитик, а в проводке прихода все аналитики пустые, только склад указан. Один из путей, как этого можно достичь: создаем строку журнала переноса, указываем со склада/на склад и, например, из партии. А в партию не указываем. Резервируем лот. Готово дело - проводка прихода с пустой аналитикой. Хорошо, но для партии у нас НЕ установлен "Пропуск для приходов". А журнал с легкостью разносится. Недолгие копания в коде скорее породили дополнительные вопросы, нежели ответы

1) Класс InventUpdate, метод updateTransDimTransferReceipt(InventTrans inventTransIssue,
InventDim _inventDimIssueNew)


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

PHP код:

inventDimReceiptOrig = InventDim::find(_inventTransIssue.orig().inventDimId);
inventDimReceiptOrig.mergeUsedDim(movement.dimGroupId(),movementReceipt.inventdim());
inventDimReceiptOrig = InventDim::findOrCreate(inventDimReceiptOrig); 


а потом полученная аналитика джоинится к InventTrans при поиске приходной проводки

PHP код:

select forupdate inventTransReceipt
                where inventTransReceipt.inventTransId      == movement.transId()       &&
                      inventTransReceipt.statusIssue        == StatusIssue::None        &&
                      inventTransReceipt.statusReceipt      == StatusReceipt::Ordered   &&
                      inventTransReceipt.transChildType     == InventTransChildType::None
            #inventDimJoin(inventTransReceipt.inventDimId,inventDimReceipt,inventDimReceiptOrig,inventDimParm); 


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

2) Но это пол-беды. Почему появляется приходная проводка с пустой аналитикой, для которой "Пропуск для расходов" не установлен? Находим проверку в классе InventMov_Jour_Transfer

PHP код:

boolean dimAllowBlankReceipt(InventDimSearch _dimSearch)
{
    return _dimSearch.dimAllowBlankReceipt() || _dimSearch.dimAllowBlankIssue();
} 


Для "Пропуска для расходов" аналогичный метод.
Что интересно, в потомках этого класса InventMov_Jour_TransferIssue и InventMov_Jour_TransferReceipt эти методы не перекрыты. Вроде бы нигде в мануалах я не встречал указания на то, что галки "Пропуск для расходов" и "Пропуск для приходов" надо ставить только парами...

Если второй пример (с галками) я склонен считать откровенной багой, то с первым у меня такой уверенности нет. Объясните - в чем тут глубинный смысл, которого я явно не догоняю?

[ymv2000]

В Ax2009
аналитика Прихода автоматически дозополняется отсутствующей аналитикой из аналитики Расхода, т.е. если в Приходе не установлен ГТД, а в Расходе установлен, то в Приход будет проставлен ГТД из Расхода.
Для нас такая ситуация не приемлема.
В итоге в class InventMovement в метод mergeTransDimTransferReceipt
внесли изменения:
public InventDim mergeTransDimTransferReceipt(InventDim _toInventDim,
InventDimGroupId _dimGroupId = this.dimGroupId(),
InventDim _fromInventDim = this.inventdim(),
InventDim _origFromDim = _fromInventDim)
{
// _toInventDim.mergeUsedDim(_dimGroupId,_fromInventDim);
//Аналитика Прихода не объединяется с аналитикой Расхода, а берется в чистом виде..
_toInventDim = InventDim::find(_fromInventDim.inventDimId);
return _toInventDim;
}
В складских журналах перенос все работает.
Вопрос: не может ли это где-то в других случаях использоваться, т.е.не создадут ли эти изменения проблем в будующем в др. подзадачах?