Post Receipt grid showing split lines rather one consolidated lines

Hello Guys,

I am currently investigating an issue for one of the clients who recently went from AX 2012 R2 CU7 to AX 2012 R2 CU9. Let me try to explain.

Scenario :

The client is facing an issue after going to CU9 i.e. prior to the update, while posting an arrival journal, if they have some quantity lets say 2 and they split it into two lines and assign different locations for both the lines, then post it. After posting, when they open the post receipt screen, under lines tab, they would see a consolidated line (i.e. the lines that they splitted before posting now appearing as single line with qty 2 instead of two separate lines with qty 1). However in CU9 version, they would see two different lines of quantity 1.

I tried looking for differences within PurchEditLine forms of both the environments (CU7 and CU9), no siginficant difference. Actually tried comparing code within layers of both the environment, debugging both the environments simultaneously i.e. for both puchEditLine form and code/objects involved in posting item arrival journal.

one work around is when in CU9 version, if the user change Quantity parameter to something else and then change it back to Registered qty , the lines on the grid start appearing as single consolidated line (as it appears in CU7) version on form start. I tried debugging that code as well (i.e. Modified filed for SpecQty on datasource purchParmUpdate) however nothing significantly different there as well.

since all the code seems same to me till this point in my investigation (i.e. CU7 and CU9), i tried building AOT, generating full CIL and synching database in CU9 environment, however the issue persist. while i am still trying to further investigate using trace parser and comparing the results from both the environments.

While going thru a post by Martin ,(i.e., i thought to create a method myself and call it from executeQuery (leveraging the same approach / code as specified in the post). but not getting the result. definitely i am not doing it right. I am writing the following cod on a custom method on the form PurchEditLines and calling it after super from within executeQuery of the PurchParmLine dataSource.

Copy the query
Query query = new Query(PurchParmLine_ds.queryRun().query());

QueryBuildDataSource qbds = query.dataSourceTable(tableNum(PurchParmLine));
QueryRun qr;
PurchParmLine summedUpGridRows;

// Sum Quantity field on PurchParmLine (PurchParmLin.ReceiveNow) and adding group by clause
qbds.addSelectionField(fieldNum(PurchParmLine, ReceiveNow), SelectionField::Sum);

qr = new QueryRun(query);
// Run the query;

// Get the data
summedUpGridRows = qr.get(tableNum(PurchParmLine));

// Setting the form datasource with updated data

//re-reading and refreshing datasource.


however I still see two separate rows instead of 1 consolidated with qty 2. The Automatic Addition parameter is checked in Inventory and warehouse management parameters.

Can anyone advise anything like if I should take any other approach? or is there a hotfix already available for such issue. i was not able to search that due to some issue with my account and not able to get into partner source website.

any help would be highly appreciated and i am sure would be a great learning for me from you all.

if i missed any detail i would provide more if you need. even the trace parser results.



PS: I have posted same question at Martin’s post as well. However i thought to post it here as well just to increase visibility.

Maybe I’m missing something after briefly going through your post, but it seems to me that you need a completely different thing than what I’ve described in my blog post, therefore using that code doesn’t make a good sense.

The idea of the blog post is summarize values from all records to a single number. But you won’t get a single number; your query may return several numbers because of grouping. You also don’t want a number at all; you want to a list of records in a grid. And there are other problems with your attempted solution.

You said that you compared the form in CU7 and CU9, but what you should really look at (and possibly change) is the logic generating PurchParmLine records. The form merely displays them. The PurchFormLetterParmData class may be a good place to start with.