Requisition work sheet Skips Qty in Transit

Dynamics 365 Business Central/NAV User Forum
1

Hi Experts,

I want to know why Navision does not include “Qty in Transit” when calculating the Planning work sheet?

So, I did a testing in Standard Navision 5.0 (Cronus International)

Below is my scenario.

SKU Card Setup:

Item No: 80212

Location Code: Blue

Replenishment System: Purchase

Reordering Policy: Maximum Qty

Reorder Point: 500

Maximum Inventory: 500

Qty in Hand: 100

Qty in Transit: 50

Note: I have checked and no Quantity exist in Sales Orders, Purchase Orders, Warehouse Transfer Orders, Production & Consumption Lines.

When I run the Requisition work sheet dated 01/01/10…20/03/10.

Navision calculates and suggests to Purhase Qty 400, but i think it should suggest Qty 350 as there is already Qty 50 in the Transit Location. This is shown in the SKU card.

So, why is Navision not considering the Qty in Transit?

We have huge quantities in the Transit Location and this will notw become an Issue for us.

Can some one please tell if I have missed out anything in my setup, spent lot of time but I can’t figure it out.

Any help is much appreciated.

Thanks,

Jack.

2

Hi Experts,

I want to know why Navision does not include “Qty in Transit” when calculating the Planning work sheet?

So, I did a testing in Standard Navision 5.0 (Cronus International)

Below is my scenario.

SKU Card Setup:

Item No: 80212

Location Code: Blue

Replenishment System: Purchase

Reordering Policy: Maximum Qty

Reorder Point: 500

Maximum Inventory: 500

Qty in Hand: 100

Qty in Transit: 50

Note: I have checked and no Quantity exist in Sales Orders, Purchase Orders, Warehouse Transfer Orders, Production & Consumption Lines.

When I run the Requisition work sheet dated 01/01/10…20/03/10.

Navision calculates and suggests to Purhase Qty 400, but i think it should suggest Qty 350 as there is already Qty 50 in the Transit Location. This is shown in the SKU card.

So, why is Navision not considering the Qty in Transit?

We have huge quantities in the Transit Location and this will notw become an Issue for us.

Can some one please tell if I have missed out anything in my setup, spent lot of time but I can’t figure it out.

Any help is much appreciated.

Thanks,

Jack.

3

When is the transfer order due into BLUE? If it is after 20/03/10 the system rightly ignores the 50 as per you telling it to do so.

4

Hi Adam,

The Transfer Order due date was 19/0310. I did check this out but it didn’t work.

This time i took the end date until 31/Dec/2010. But still the same result, it excludes the Qty in Transit.

I just want to know if this is “Standard Navision functionality” to include the "Qty in Transit" while running the Requisition work sheet. Does it work for you? in Cronus?

Appreciate your help in this.

Thanks,

Jack.

5

So what are the requisition settings against the item on the SKU card?

Yes it is working for me at the simplest level - set an item up with a reorder policy, two SKUs parameters set and a transfer in transit - no new suggestion. However there are so many fields and settings that impact it is not a fair comparison.

I suggest you setup a new item, set fixed reorder, two SKU records with reorder points. then test it as you build it.

6

Ok Thanks Adam!! The requisition settings are the same as I mentioned in my first post.

let me try it out in my Cronus Testing Data base again by changing the Reorder Policy

Will revert to you shortly.

Thanks for the help again…

Jack.

7

So as standard you purchase it into BLUE, but in this instance you have some in transit you would not normally have, the system would never plan for and you have no idea when they will be in (it states 19th but that has passed). What happens if you change the transfer date to next week? Anyway it still works with an in-transit in on a purchased environment. From the item card does the item availability show it as a scheduled receipt?

8

Adam, sorry for the late reply.

I spent almost 4 days to do Various testings and honestly the Manuals Microsoft provides are too high for an end user perspective, i mean’t it should be in lay men terms. Do you have any tailor made Documentation which you might have given to your clients?

SKU Card (Ordering Policy: Fixed Reordering Qty) Replenishment = purchase, only Safety stock was setup.

This is what we found out in Testing:

  1. Qty in Transit: It works given this scenario,

Receipt date : 26/03/10

and then we need to enter the Requisition date as below:

Order Date: 26/03/10

End Date: 26/03/10

or if there is a Demand (sales order) which falls in between the receipt date and end date then Qty in Transit tries to offset the Qty for Sales lines, so that it does not create a new purchase in Requisition lines.

  1. Expected Receipt Date ( lines): This is not taken care the way we expected.

We have set up “Safety Lead times” in SKU card, when we run the Requisition work sheet, it gives a “due date” this is equal to Order date which we enter before we run the MRP sheet or it gives the date picked from Sales Order demand (shipment date). We assume the logic is that it needs to be purchased on the Day of the Shipment for Sales Orders so that stocks are available for .

When the Purchase lines in planning work sheet are converted to Purchase Orders, the Expected receipt date is not calculated by Safety lead time + inbound warehouse handling time, but instead it has picked up from the Due date field from the Requisition lines. So, this is not logical!! we wanted the system to give us the Expected Receipt date based on our lead times so that we can plan for the incoming shipments.

Is there any way to make this work?

But when we create a new , it picks up the lead times from the SKU and includes the Inbound warehouse handling times and gives us the correct "Expected receipt date" which we think is correct

So, we were not sure why it doesn’t work with Planning work sheet.

The rest all Scenario’s worked fine as what we expected based on the setup’s we did for SKU.

Appreciate if you can share your ideas and to suggest if there is another way of setting up SKU to achieve the above missing functionalities.

Thanks,

Jack.

9

Those are the same manals we are trained upon. Nope no others from me I am afraid.

Set the reorder cycle to 30 days, I presume you have left this blank at the moment. This will then match off the sales and quantity in transit without it being the same date - basically if it is within 30, but feel free to play with the 30 setting.

  1. Expected Receipt Date (PO lines): This is not taken care the way we expected. Always dangerous to “expect” something in my experience [:D]

Basically the due date is the order date if you have a requirement and it is not met. So if you have 0 and you tell NAV you need 10 as a minimum it says you need 10 today. I would however have expected the expected receipt date to backschedule from the required date to include the inbound warehouse handling as a minimum.

I would need to have a look at it - have you asked your partner?