Adding fields to PurchPurchaseOrder (Purchase order confirmation)
Hi,
Sometimes we need to add fields to a report that uses transactional data. Normally these have their own transactional tables such as CustInvoiceJour, however this report is different. If you check the method \Classes\PurchPurchaseOrderDP\createData you can see that the DP class uses PurchLineAllVersions and PurchTableAllVersions to get its data for the report. We will need to change these tables and follow the structure to correctly store data for this report
In this example I will be adding a field to PurchTable, although the process will be the same if you are adding one to PurchLine.
As we are adding it to the header we will need to look at PurchTableAllVersions. Looking at the AOT you can see that PurchTableAllVersions is a view not a table. This view points to a query:
If we look at query you can see it points to two new views:
This views in turn point to new queries, which in turn point to the tables we need:
So currently we have a list of the following objects that will need to be changed:
That’s quite a list for one field, and we are not finished either!
We can modify all of these objects by adding the field to PurchTable and PurchTableHistory. Once this is done remember that you need to add the code to move the new field value from PurchTable to PurchTableHistory by modifying initFromPurchTable. At this point if we check our best practices we see that we also need to create a new parm method on the class AxPurchTable.
With the new method written we can now continue. As the queries PurchTableArchivedVersions and PurchTableNotArchivedVersions have the dynamics field property set to ‘Yes’ our new fields should be there automatically but it is worth checking them by opening up the fields node in the AOT. If you cannot see then restore the query and they should be there.
Next up is to add our fields to the views PurchTableArchivedVersions and PurchTableNotArchivedVersions. Remember you might need to restore the views as well to see the new field.
Unfortunately the query PurchTableAllVersions does not have the dynamics fields set so we have to add these manually. Then finally we can add it to the view \Queries\PurchTableAllVersions.
Finally we can then use the field in our DP class and populate the TMP table. After we have added the field to \Data Dictionary\Tables\PurchPurchaseOrderHeader we can then refresh the SSRS report and use the field.
So our final list of changed objects is:
Comments
Comment from mike
Time 13th September 2017 at 13:32
Thanks for posting… However, if the context of the requirement is only to display the data on the PO why not add the extra fields you need to the PurchPurchaseOrderHeader table and populate them dynamically within PurchPurchaseOrderDP.setPurchPurchaseOrderDetails() before the call to purchPurchaseOrderTmp.insert()?
Not sure what having the data display as part of the PO confirmation journal gives you for the extra work involved?
Comment from mike
Time 13th September 2017 at 13:34
Was referring to the lines – I meant within PurchPurchaseOrderDP.setPurchPurchaseOrderHeader() but before purchPurchaseOrderHeader.insert() !
Comment from mike
Time 13th September 2017 at 16:35
I got the reason now – if you don’t store the additional data then you can’t keep track of changes between successive purchase order confirmations and lose traceability.
Comment from nakorn
Time 4th November 2015 at 10:14
I follow up your step and it’s work. But the new field is not stored to purchlinehistory table. I try to modify initFromPurchTable method but it’s not work. Do you have any suggestion?