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

[Peter Savintsev]

Axapta 3.0.
Для номенклатуры настроена группа складской аналитки следующим образом:

Склад: первичная аналитика хранения, физ. наличие, финансовый склад.
Номер ГТД: пропуск для расходов, физ. наличие, финансовый склад.

На склад оприходована номенклатура. Для нее указан склад и номер ГТД.

Делаем журнал переноса для этой номенклатуры с одного склада на другой. Как известно, при это создается как минимум две складских проводки: одна для расхода, другая для прихода. Проводка расхода идет с той же аналитикой, как мы ее оприходовали. А вот с проводкой прихода получается лажа. Склад у нее стоит правильный, тот, на который мы перемещаем (собственно, как я понимаю, он берется из строки журнала переноса). А номер ГТД пустой. То есть можно, конечно, поставить руками его в журнале, тогда все будет правильно, но ведь это крайне неудобно.

В версии 2.5. проводка прихода учитывала аналитику расхода и номер ГТД автоматически брался оттуда. Здесь же такой механизм не работает. Подозреваю, что мы что-то не так настроили в группе складской аналитики, но что?

[snatka]

Действительно в Axapta 3.0 складская аналитика не переносится в журнале Перенос как в 2.5. Мы это кастомизировали.

[Peter Savintsev]

Цитата:

Действительно в Axapta 3.0 складская аналитика не переносится в журнале Перенос как в 2.5.

Понятно. Обидно.

Цитата:

Мы это кастомизировали.

Если не сложно, не могли бы Вы сказать, где чего править надо, или, еще лучше, проектик приаттачили? Понимаю, что это не должно быть очень сложно, но ковыряться в классах не хочется, да и времени нет. Был бы очен благодарен за помощь.

[raz]

перекрой методы modified для конролов в grid или у полей в datasource и там переноси.

[Peter Savintsev]

Цитата:

Изначально опубликовано raz
перекрой методы modified для конролов в grid или у полей в datasource и там переноси.

Эх, если бы все было так просто...

У нас используется автоматическое резервирование, то есть пользователь в строках журнала не указывает номер ГТД, а номер этот автоматически берется системой из того, что есть в наличии. Поэтому проводка расхода формируется с имеющимся номером ГТД.

Можно было бы, конечно, перехватывать процедуру резервирования и в строку журнала вставлять тот номер ГТД, с которым была создана проводка резервирования, однако как быть в случае, если перемещается, скажем, 10 единиц номенклатуры, 5 с одним ГТД и 5 с другим? По идее должно быть создано по 2 проводки расхода/прихода. То есть в строке журнала таким образом провести операцию не получится. Или придется делать две строки.

В общем, чувствую я, что решение тут не простое. Блин, но ведь в 2.5 все работало без проблем!

[Peter Savintsev]

Ну вот, оказалось все не так уж сложно. Для тех, кому еще приспичит исправить вышеуказанный баг (или все же фичу?)

В классе InventMov_Jour_TransferIssue необходимо перекрыть два метода следующим образом:

PHP код:

InventMovement newMovement_TransferReceipt()  {
       return InventMov_Jour_TransferReceipt(inventJournalTrans, inventType);
} 


и

PHP код:

void updateTransDimTransferReceipt(InventUpdate _inventUpdate, InventTrans _inventTransIssue, InventDim _inventDimIssueNew)  {      
    if (! this.transferReceipt())              
        _inventUpdate.updateTransDimTransferReceipt(_inventTransIssue,_inventDimIssueNew); 
} 


[renat]

тут видимо оЧепЯтка

InventMovement newMovement_TransferReceipt() {
return InventMov_Jour_TransferReceipt(inventJournalTrans, inventType);
}

а надо наверно

InventMovement Movement_TransferReceipt() {
return new InventMov_Jour_TransferReceipt(inventJournalTrans, inventType);
}


и что-то нифига автоматом не подставляет аналитики в журнал переноса...

[Peter Savintsev]

Да, прошу прощения. Конечно, new InventMov_Jour_TransferReceipt(inventJournalTrans, inventType);

[renat]

попробовал настроить аналитику СКЛАД+SN
СКЛАД - первичная
SN - пропускать при расходе

в журнале переноса ставлю
"ОТКУДА" : склад и SN
"КУДА": только склад

разношу , смотрю проводки - в приходной проводке нету SN

видимо в приведенном коде чего-то не хватает ?

[Peter Savintsev]

Кхм. Честно говоря не знаю. Я проверял этот метод только с партиями и номером ГТД. Может быть, с серийниками есть какая-то особенность, которую я не учел? Или настройка должна быть специальная...

[Firestarter]

Я наверно торможу, но в классе InventMov_Jour_TransferIssue вообще нет указанных методов

[Ruff]

Цитата:

Изначально опубликовано Firestarter
Я наверно торможу, но в классе InventMov_Jour_TransferIssue вообще нет указанных методов

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

[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;
}
В складских журналах перенос все работает.
Вопрос: не может ли это где-то в других случаях использоваться, т.е.не создадут ли эти изменения проблем в будующем в др. подзадачах?