Posting a product receipt for a load can be done from two places in the new warehouse management module:
- For a selected load, whether that is from the All loads list page, Load details or from the Load planning workbench. This will execute the posting right away
- For 1 or more loads, running as a batch job in the background, using the periodic operation "Update product receipts"
The actual business flow is more or less the same regardless of where you launch the update from, and I am going to describe it below, also doing a small demonstration of the forms and data that are relevant.
One thing that I specifically want to call out in this blog post is a piece of functionality related to receiving ASN documents, namely the receiving exceptions for items missing from ASN.
Preparation
So, i guess it's clear that the first step for us to look into the product receipt process is to get a load created and corresponding work created/executed for it. This is described in my post about importing an ASN and using License plate receiving to register their arrival and complete the put-away, so I will start here by just briefly listing the data I am going to work with in this demo:
- A load with 2 purchase orders on it, with shipping carrier specified as JB Hunt:
- PO #1 with 1 line for item 000148_202, qty = 2 PL (150 ea), WH = 42
- PO #2 with 1 line for item 000147_202, qty = 1 PL (100 ea), WH = 42
- A packing structure for this load (based on ASN received from the vendor)
- 1 pallet with License plate LP2POs006
- 75 ea of 000148_202
- 100 ea of 000147_202
- 1 pallet with License plate LPMissASN001
- 75 ea of 000148_202
- Work is created and executed for LP2POs006 through License plate receiving.
- LPMissASN001 has not been received, as it did not actually arrive on the truck.
What the last line essentially means is that the vendor planned to and believes he sent us the entire order (thus it is in the ASN document), but in reality, one of the pallets is missing. So somebody needs to get notified about this exceptional situation and act on it, ensuring we do not get billed for the missing goods.
In order to showcase the receiving exception related to items missing from load as compared to the ASN I have also specified the corresponding work exception code in the Warehouse management parameters, as shown below:
In order to showcase the receiving exception related to items missing from load as compared to the ASN I have also specified the corresponding work exception code in the Warehouse management parameters, as shown below:
Flow description
Warehouse management parameters |
The "Update product receipts" menu item is located under Warehouse management \ Periodic, and opens into a dialog, where you can select the loads you want to post product receipts for. The criteria could be, for example, the shipping carrier bringing in the loads. If you know that "JB Hunt" delivers before lunch, we can try posting product receipts for their deliveries at, say, 2 pm.
Note
The batch job flow is per my understanding going to be used more often, so this is what I am going to describe in this post. Manual posting is pretty much identical, with 1 difference mentioned below.Once you confirm the processing, the job will be added to the queue on the batch server, and will be executed based on the recurrence you have selected on the Batch tab page.
For this demo I have not enabled it to run in the batch, so the execution happens right away.
Here's an attempt at capturing what is going to happen with the selected loads when you schedule the product receipt update for them:
- Loop through all the selected loads
- If Load has not yet been Received
- check if the load has been ship confirmed, or the state of the related route (TMS functionality) if a load is part of a route. If it is not confirmed
- ship confirm the load and all related loads that need to be confirmed at the same time (because they are on the same route)
- if at least one of these loads cannot be ship confirmed, none of the loads will be confirmed. A number of things are checked here, but they are part of the transportation management flow, which is not the focus of this post, so I will omit describing them
- As a result, the status of the load changes to Shipped
- check the document status of the purchase orders related to the load
- if the purchase order is not confirmed, confirm it.
- This entire step is executed within 1 transaction, while the below steps are part of another transaction. So if you for example cancel the actual product receipt, your loads would stay ship confirmed.
- Loop through the load lines
- Compare the load line to the related ASN item lines, finding discrepancies between the "planned" receiving quantity on the load line and the quantity work was actually created for based on the ASN packing structure. To rephrase, we compare, how much we ask the vendor to deliver in the selected load and how much he actually delivered.
- If a discrepancy is found, create a receiving work exception with exception code selected in Warehouse management parameters \ Code for missing items from ASN
- For each purchase order linked, prepare the order for posting product receipt. All load lines will be posted as part of 1 large update, so if multiple orders exist they will be posted in 1 go, with the same ParmId.
- Actually post the product receipt for all relevant orders.
- Display the Posting product receipt dialog. Note the product receipt IDs are generated as
_#, so you should be able to later identify all product receipt documents posted for a load based on such a condition (if you do not override the number with the actual vendor IDs) - Select to update only the Registered quantity, as that is what we have received according to the warehouse
- As a result, the status of corresponding purchase orders is updated to Received, or stays Open if some of the quantity was not received in full.
- Update the load, removing load lines that were not received at all and decreasing quantity on those that were only received partially.
- Update load status to Received
- Update status of all shipments that are part of the load to Received
Manual posting difference
When posting the product receipt manually, the button to post is actually disabled until the purchase orders in the load are all in Confirmed status.
Demonstration
Navigate to Warehouse management \ Periodic \ Update product receipts, and configure the criteria for updating all loads delivered by JB Hunt that have not been Received yet.
Update product receipt selection criteria |
When you confirm the update, the above flow is going to execute, confirming the inbound shipment and displaying the product receipt posting dialog with both purchases shown. Notice the product receipt numbers assigned, and that only the registered quantity is updated. Confirm the processing.
Product receipt posting dialog |
Once the update is complete, we can go back and check on the load. As you can see, the Load Status has changed to Received, and the quantity on the first load line has been decreased to match what we actually received.
Received load information |
At the same time a receiving work exception has been logged in the system, pointing to a discrepancy of type "Missing item from ASN", as shown below:
Work exceptions log |
If you now take a look at the purchase orders from the All Purchase orders list page, you will see that one of them was fully updated and thus has a status of Received, while the other is still Open and has an expected delivery for the quantity that was missing from the ASN. We'll now need to contact the vendor/carrier and figure out what went wrong with this shipment.
Youtube video walkthrough
As an experiment, I have also recorded the above flow in a screen cast and uploaded it to my Youtube channel. Take a look and let me know what you think. Is that helpful at all? (I take any kind of feedback very well :))
Summary
This post was trying to address two main goals:
- Explain and demonstrate, what happens behind the scenes when posting a product receipt for loads
- Show, how you can set up a receiving exception, that will allow more easily tracking cases where something went wrong and we did not get the goods we were supposed to.
I hope it's more clear now and you'll be able to use AX to the full extent when it comes to inbound ASNs.