InventMovement/InventUpdate classes

(This is an attempt to create some documentation for the above classes. I completely understand these classes and I know the functionality. What I do not know is how to create a documentation for object oriented systems. If you have an example of documentation please email it to me. It will help me to create the above documentation and put it on this website)

InventMovement and InventUpdate class framework forms the basis of Axapta inventory management. However, sometimes programmers find it too confusing and difficult to understand.

In a nutshell, both the classes manipulate the records in table “InventTrans”. InventMovement is responsible to do inventory related ledger postings and supply the various reference fields where as InventUpdate does the actual manipulation such as calculate the quantity or change the status from ordered to purchased etc. etc. etc.

Let us take an example of posting a sales invoice.

To post a sales invoice, another interesting framework called FormLetter comes into play.

The “updateNow” method on the SalesFormLetter_Invoice class will create the customer related transactions in the general ledger like Debit customer and Credit Sales etc etc. After this is done, control is passed to “UpdateInventory” method on the same class.

An instance of InventUpd_Financial is created in this method (if you are posting a packing slip then InventUpd_Physical is created) and “UpdateNow” method on InventUpd is called.

Now all the quantities as calculated and inventory related ledger postings are created using InventMovement class and finally using “UpdateFinancialIssue” method the status if inventory transactions is updated to “Sold”.

This should give you a very general idea as to how these classes interact.

The following classes form the InventUpdate framework.

InventUpd_Estimated : Physical state ordered, on order

InventUpd_Registered: Physical state registered

InventUpd_Reservation: Physical state reserved

InventUpd_Arrived : Physical state arrived

InventUpd_Picked: Physical state picked

InventUpd_Financial: Physical state purchased, sold

InventUpd_Physical: Physical state received, deducted

In addition to the above, following classes are also part of the InventUpdate framework.

InventUpd_ChangeDimension: Changes the dimension

InventUpd_DeleteMovement: Deletes inventory transaction

In addition to the above there is one more member that you should be very familiar with. It will save you a lot of programming code lines in the future. This member is

InventUpd_ChildReference

What does this class do? Let us take an example.

Open an Axapta installation (say with demonstration data). Make sure that “Set inventory transactions to picked” is set to false (on AR parameters) and post a picking list. Now click on inventory transactions. On the general tab you will notice that the child references have been updated.

The same thing happens in Production journals.

Go to a production order that does not have any “Reported as Finished” journals that have been created.

There is no child reference.

Now create a reported as finished journal (don’t post it) and check inventory transactions again.

So how does this help you?

Let us take a practical example. Axapta sales order lines do not have any way of defining a delivery schedule. Let us create a project that will allow such delivery schedule to be specified. Further master planning should recognize such delivery dates.

Please download and import the xpo file SalesDeliverySchedule (Version 3.0 SP 3.0).

Create a sales order for an item that has the same unit of sales and invent. Say create a line for quantity of 100

There is a new button on sales table form called schedule, click on this button and split the single line that appears into two lines one for quantity of 40 and another for quantity of 60, now check Inventory transactions. In stead of 1 transaction now you should have two inventory transaction lines. Check the status date on “Other tab” this will be the date as specified on the schedule. Now delete the lines in the schedule and check inventory transactions again. Now you will have a single inventory transaction with status date same as delivery date on sales line. Further the child references will be cleared.

Now put a debugger on insert and update method of table “SalesLineDlvScheduleSTM” and repeat the above exercise again to get a feel of what is happening behind the scenes.

Please note that there is some more work to do before you can use this in live system.

I have written a purchase shipment module using this class. You would not believe how easy it is to write such a module using child classes. Less modifications, no bugs and a piece of cake to upgrade. Of course initially you will have to spend some time understanding InventMovement and InventUpdate classes but it’s a time worth spent.

For a simple project table a look at Sales duel unit of measure project.

For an advanced project take a look at by-product project.

Send mail to harry@systomatics.com with questions or comments about this web site.

Disclaimer: I am working with Microsoft Business Solutions. The code on this site may or may not be related to my official duties with Microsoft. I do not claim in any expertise in modules represented on this website. Essentially there is just one person doing functional specifications (in head), design specifications (in head), coding and some testing. There is no way the project on this site will be free of bugs. The projects are intended as guidelines and may god help you if you decide to implement the projects without making any changes. If you implement any project resulting into data corruption or anything like that then do not even think of suing me because a. I have already warned you and b. I don't have any money. I may or may not respond to your emails about supporting the project. I may or may not upgrade the projects to the next service pack / version.