on 05-05-2015 7:32 AM
Hi SD experts,
From ATP check logic, and enter into "Availability Overview", about "C.u.m. ATP qty"'s logic, we are not so clear.
Please refer to the pictures attached.
For "Availability overview",
4/20 received 92pcs from stock
4/22 received 40pcs from production order, C.u.m. ATP qty is 132pcs
4/23 received 20pcs from another production order, C.u.m. ATP qty is 132pcs, we think it should be 152pcs, why is 132pcs?
4/29 cusomer order demand 5pcs, then we think C.u.m. ATP qty is 147pcs, but it still 132pcs
5/6 another customer order demand 15pcs, then we think C.u.m. ATP qty is 132 pcs based on 147 - 15 = 132pcs
Could you please help to explain what is the logic of C.u.m. ATP qty?
Best Regards,
Bu Fanchao
Hi Bu Fanchao,
"4/23 received 20pcs from another production order, C.u.m. ATP qty is 132pcs, we think it should be 152pcs, why is 132pcs?"
No, it is correct to be 132. You have a customer order for 29th April & again on 6th May which are confirmed against your production order on 23rd April (A requirement is always confirmed against the nearest preceding receipt). Therefore, it would not make sense that it says you have 152 available on 23rd April, as 20 of this is already committed to the 2 sales orders (and therefore this 20 is not available).
If you manually changed the confirmed quantity of the 2 sales orders to zero in CO06, then I think you would see a C.U.M ATP quantity = 152. But at the moment, the display is correct.
Hope this helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Noel,
This is a continuation of the previous screenshot. Please kindly check the below screenshots. Could you please explain how to calculate the c.u.m ATP qty. is always 17 or 32? Many thanks.
For "Availability overview",
5/11 received 23pcs from PrdOrd, I think it should be 10+(23-5)=28pcs, but why is 10+(23+10+4-5-5-20)=17pcs?
Best Regards,
Bu Fanchao
Look at the customer order on 13th May. Here, you have a required quantity = 20 and a confirmed quantity = 20. The system is saying that there are 20 available. This means that this 20 must come from somewhere. It comes from the stock & receipts on your system.
If the system displayed 28 as you suggest, then it is displaying a quantity that is NOT available as it has been committed to the requirements. The purpose of the C.U.M field is to display the available quantity. If CO09 displayed 28 as being available & a new sales order was to be created with a date = 12th May and a quantity of 20, then the system would confirm it. But this should not happen as we do not have 20 available! We only have 17 available and the other quantity has already been committed to the order on 13th May. The system is correct to display 17 as being available in this case as otherwise, there is potential to over-confirm any newly created orders.
So in summary, there are only 17 available on 11th May as some of the production order (from 11th May) quantity is used to confirm the sales order on 13th May.
You can look at it like this:
Requirement of 20 on 13th May = 20. Confirmed Quantity on 13th May = 20.
4 of this confirmed quantity comes from the planned order on 13th May. This leaves us with 16 still to be fulfilled.
Requirement of 5 on 10th May. Confirmed quantity = 5.
5 of this confirmed quantity can come from planned order on 12th May. The other 5 of the 12th May planned order can fulfil some of the 13th requirement. So 16 - 5. Now, the 13th May requirement is down to 11.
Requirement of 5 on 11th May. Confirmed quantity = 5.
5 of this confirmed quantity can come from production order on 11th May. 23 - 5 = 18. We still have the 11 on 13th May to fulfil. So 18 - 11 = 7. We have 7 of the production order quantity remaining. But we also have the stock of 25 (- requirement of 15) = 10. So 10 + 7 = 17.
If you manually changed the confirmation of the requirement on 13th May, I think the C.U.M ATP quantity on 11th May would inevitable change as CO09 would not have to use the production order of 11th May to cover the requirement on 13th May.
Requirements also look for receipts that lie BEFORE them in the timeline. In your example, the way the receipts and requirements fall means it makes sense to calculate between 5/11-5/13. If there was a sales order on 5/14, then I guess that requirement would also look backwards and try to use the available 17 to cover the 5/14 requirement. The 17 is not just calculated between 5/11-5/13 - all of your requirements & receipts in CO09 would be considered for it. I started at 5/13 as that was a logical starting point to explain where the 17 came from! If there was a requirement on 5/14, then that would be a logical starting point. I could start at 5/27 but then it would take longer! 🙂
User | Count |
---|---|
97 | |
9 | |
8 | |
6 | |
3 | |
3 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.