Transfer Orders - "Receive Remain" show weird value after multiple shipments and received (2)

Just debugged and found it was caused by following code under InventPickingListJournalRegistrate class - updatePickingListJournal method.

It seem like used to handle over-delivery but I'm wonder how to get the calculation method.

//handle potential overdelivery for transfer orders
if (inventPickingListJournalLine.InventPickRequesterType ==
InventPickRequesterType::Transfer)
{
inventTransferLine = inventMovement.buffer();
if (inventTransferLine)
{
if (inventTransferLine.QtyRemainReceive < abs(inventTransferLine.QtyShipped - inventTransferLine.QtyRemainShip))
{
inventTransferLine.QtyRemainReceive = abs(inventTransferLine.QtyShipped - inventTransferLine.QtyRemainShip);
inventTransferLine.updateEstimatedReceipt();
}
}
}

For me, over-delivery should be:
Over-delivery quantity = total received quantity - total transfer quantity

//handle potential overdelivery for transfer orders
if (inventPickingListJournalLine.InventPickRequesterType ==
InventPickRequesterType::Transfer)
{
inventTransferLine = inventMovement.buffer();
if (inventTransferLine)
{
if (inventTransferLine.QtyTransfer < abs(inventTransferLine.QtyShipped + inventTransferLine.QtyRemainShip))
{
inventTransferLine.QtyRemainReceive = abs(inventTransferLine.QtyShipped + inventTransferLine.QtyRemainShip - inventTransferLine.QtyReceived);
inventTransferLine.updateEstimatedReceipt();
}
}
}


Note:

1. I have tried to use the over-delivery function and configured TO Line\Setup tab. It seems like not working. Probably someone can enlighten to me how to activate the function.

Transfer Orders - "Receive Remain" show weird value after multiple shipments and received

I was come across the standard bug in TO that will increase "Receive Remain" value when user tried to do multiple shipments and receive posting.

Let said we try to transfer item A 200 pcs from Warehouse GW to MW.

By using partial transfer, we are going to ship 8 times (each time 25 pcs) through Picking List, Picking List registration, Shipment, and Receive Posting.

We have encountered the "Receive Remain" value increased in the 7th times when we update picking list registration.

Below is the simulation chart (Refer to TO Line\Receive Now tab) after update picking list registration process:

No	Shipped quantity	Received quantity	Receive remain
1	0	0	200
2	25	25	175
3	50	50	150
4	75	75	125
5	100	100	100
6	125	125	75
7	150	150	100 (shoule be 50)
8	175	175	150 (should be 25)

It was applicable to AX4.0 SP1 and SP2.

To be continue... for solution...

AOT Find function

"The Find function in the AOT will only retrieve the outer most layer objects. For example if an object has a GLS and VAR layer, Find retrieves the VAR layer. Add an option to the find to retrieve all objects in the specified layer regardless whether another layer is involved. Refer to incident 8945146 if need be."

MS Community Article

I have quickly run some testing and found out the "bug" (maybe it considered as bug). ^^

The SysAOTFind form will only used the outer most layer tree node, so we got to modify and add conditional logic to retrieve code in other layer. Look at the searchNode method, and modify the code accordingly.

Original code:
if (!sysTreeNodeSearch.isNodeInRange(_treeNode))
return;

Modified code:
TreeNode otherLayerTreeNode;
str strlayer;
boolean mustCheckLayer;
UtilEntryLevel uel;

//make sure only compare layer if specified
strLayer = enum2str(applObjectCache.utilLevel);
if (strscan(applObjectLayerRange.text(), strLayer, 0, strlen(applObjectLayerRange.text())))
mustCheckLayer = true;
else
mustCheckLayer = false;

//We change the layer here, in order pass another layer code for validation
uel = applObjectCache.utilLevel;
if (uel != _treeNode.applObjectLayer())
{
otherLayerTreeNode = _treeNode.getNodeInLayer(uel);

if (!sysTreeNodeSearch.isNodeInRange(otherLayerTreeNode))
return;
}
else
{
if (!sysTreeNodeSearch.isNodeInRange(_treeNode))
return;
}

Last thing is to show the source code we have to modify to pass in layer code.

Original code:
if (showSource.value() == true)
{
this.addSourceLines(_treeNode);
}

Modified code:
if (showSource.value() == true)
{
if ((uel != _treeNode.applObjectLayer()) && (mustCheckLayer))
{
this.addSourceLines(otherLayerTreeNode);
}
else
{
this.addSourceLines(_treeNode);
}
}

Note:

1. The above modification just only able to found the source nodes. When you double click and open the editor, it still show the layer code as you login (e.g: find var layer source but login in usr layer).

Transaction Reorganizing

Recently I have working on one interesting standard bug in AX 4.0 SP1. As far as I concerned, no hot fixes available for the particular bug description.

Below is the link for all hot fixes (requires PartnerSource logon)

Hot fixes List

How to reproduce the scenario:

1. Create an open AP payment journal and select any one voucher as settlement.
2. Go to Vendor form and click on “Open Transaction Editing” button, and select another voucher for transaction reorganizing. Now you will see “red hand” exist for previous open settlement record.
3. Click on Transaction Reorganizing button, you will notice Amount Currency was wrong. It was calculated based on all open settlement records (included previous AP payment journal amount).
4. Try to fill in the grid. Let’s said you will use percent as parameter. Add 2 lines each will denote 50% of Amount Currency.
5. Click on Accept button and system freeze.

It is applicable to Vendor and Customer.

How to resolve:

1. Open your VendOpenTrans Form, and look in “\Forms\VendOpenTrans\Designs\Design\[ButtonGroup:ButtonGroup]\ Button:CustVendTransReorgButton\Methods\Clicked” method.
2. Modified code as below. Save and compile. Done.

Current Code:

while select vendTransOpenLocal
where vendTransOpenLocal.AccountNum == vendTrans.AccountNum
join specTransLocal
where specTransLocal.RefTableId == vendTransOpenLocal.TableId
&& specTransLocal.RefRecId == vendTransOpenLocal.RecId
{
amountCurLocal += vendTransOpenLocal.AmountCur;
}

New Code:

while select vendTransOpenLocal where vendTransOpenLocal.AccountNum == vendTrans.AccountNum join specTransLocal where specTransLocal.RefTableId == vendTransOpenLocal.TableId && specTransLocal.RefRecId == vendTransOpenLocal.RecId
&& specTransLocal.SpecTableId == common.TableId //source tableid
&& specTransLocal.SpecRecId == common.RecId //source recid
{ amountCurLocal += vendTransOpenLocal.AmountCur; }


Updated on 25 July 2007: I just received june 2007 hot fixes and the bug was fixed.

Welcome to my home!

Welcome to my AX blog site.

This blog will concentrate on all topics related to MS Dynamics AX (formerly known as Axapta) as well as provide some sample code or finding.