"Refresh" for production orders wrong calculation (holiday)

schpidi

Hi all,

we have a problem with the "Refresh" for production order.
It calculates wrong results when using calendar holidays (christmas - new year) in combination with the safety lead time (item card).
Therefore it always creates production orders, refreshes it (wrong) and
the next planning run wants to cancel the wrong orders again and recreate the initial orders.

I found two errors during my analysis:
- system is generally recalculating "due date" forwards, even if the parameter is set to calculate backwards
- system does not consider holidays during this forward lead time calculation of the due date

I already wrote a detailled description of the problem in a small problem specification, therefore I simply copy it after this.

Maybe someone made the same experience and have a hint for me?

Until now I have other chance than to comment this wrong lead time calculation.
But I can not be totally sure that I will not generate other problems with this.

Thanks & Kind Regards,
schpidi

Here the details:
=================

Situation / User’s view

The situation in the production planning looks currently chaotic and not reliable. The users can not understand the results of the planning process any more.

The users run the “Calculate Net Change Plan” two times, without data changes or a bigger time difference than some minutes. The Planning process always produces different results.
The second planning run wants to change the fresh created orders of the second ones:

(see screenshot)

Single Test Scenario

Goal of the analysis was for the first step to understand, why the planning process changes its own results again. Therefore we had a closer look on one item where the situation occurred:
• 0863650561 “Alusatz – RW – O”

Here the following situation can be found:
• Demand situation
o Sales order line with a planned delivery date for 2009-01-12
• Item settings
o Replenishment is “Prod. Order” with “Make-To-Order”
o Planning and Flushing Method is “Backwards”
• Production calendar settings
o Daily working time is from 8:30 until 16:30
o Holidays are entered from 2008-12-24 until 2009-01-02

Expected Result

The system should find the demand for 2009-01-12 from the sales line. This is the “due date” for the production order. Then the backwards calculation would calculate an ending date for production at 02.01.2009. Because this is a holiday the system will find the 2008-12-23 16:30 as ending time. From this ending date the system continues with the backwards calculation and finds the starting date somewhere before 2008-12-23 16:30 (belongs to quantity and run time).

This expected result can exactly be found at the second planning run, where the system wants to cancel the “due date” 2009-01-02 and wants to create a new order with due date 2009-01-12. So the next question is why the system created the production order with the wrong due date 02.01.2009 before or when the due date is changed from 2009-01-12 to 2009-01-02.


Analysis / Test Plan

To find out more about the wrong due date, the planning was done again completely for this one part (look single test scenario).

1. Planning Worksheet -> Calculate Net Change Plan
a. Item number filter = 0863650561
b. Low level code filter = 0
c. MPS and MRP options are checked (TRUE)
d. Starting date filter is set to today (WORKDATE)
e. Ending date filter is set to 2009-02-28
f. Use forecast = “FORECAST”
2. Planning Worksheet -> Carry Out Action Message
a. Creating Production Orders with Status “Planned”
3. Planned Production Order -> Refresh
a. Direction = Backwards
b. Options Lines, Routings, Component Need are checked (TRUE)
4. Planned Production Order -> Update Unit Cost
a. Selection “Calculate” is set to “All Levels”
b. Option “Update Reservations” is checked (TRUE)
5. Planned Production Order -> Change Status
a. Selection “New Status” is set to “Firm Planned”
b. Parameter “Posting Date” is set to Today (WORKDATE)
c. Option “Update Unit Cost” is checked (TRUE)

The result of steps 1 and 2 is correct, but the error happens in step 3!
During “Refresh” the system works different than during initial planning!

Therefore we need to have a closer look on this process. Please see next chapter.


Analysis / Debugging “Refresh”

As we found in the “Analysis / Test Plan”, the process for refreshing planned orders is not working correctly. It is changing the results from the initial planning process, but it is not supposed to do so.

Therefore we started debugging this process.

Result of the debugging is the following:

The system is generally calculating backwards like it this is configured in the basic data and parameters, and it comes to the correct data:
• Production ending date/time: 2008-12-23 16:30
• Production starting date/time: 2008-12-23 …

But at the end of the calculation it wants to refresh the “due date”.
For the main level (finished product ^= low level code 0) it recalculates the “due date” with a forward calculation! So the system does not consider the holiday during this forwards calculation and it calculates the current production ending date + 10 days security lead time.

The wrong result is the due date 2009-01-02.

Because the next planning worksheet / calculate net change is working correctly again, it wants to cancel the order with the due date 2009-01-02 and it wants to create the new correct one on the 2009-01-12 again… Until the refresh changes it again…

The error is located in code unit 99000773 “Calculate Prod. Order” in procedure “CalculateProdOrderDates”


Result / Hotfix

Because the system is not supposed to do any kind of forwards calculation during a backwards calculation,
we disable the forward lead time calculation for the low-level-code 0

==============

//+ ****1* 17.11.08 *isc-beg* EHPPS013
{
IF ProdOrderLine."Planning Level Code" = 0 THEN
ProdOrderLine."Due Date" :=
LeadTimeMgt.PlannedDueDate(
ProdOrderLine."Item No.",
ProdOrderLine."Location Code",
ProdOrderLine."Variant Code",
ProdOrderLine."Ending Date",
'',
2)
ELSE
}
IF ProdOrderLine."Planning Level Code" > 0 THEN
//- ****1* 17.11.08 *isc-beg* EHPPS013
ProdOrderLine."Due Date" := ProdOrderLine."Ending Date";

ajhvdb

In which version?

schpidi

sorry i forgot to mention... we are using NAV 5.0 SP1

ajhvdb

In 5.01 planning has been recoded and works different from 5.00. One of the reasons we don't use it until some bugs are fixed. We couldn't even get the correct PO's in the cronus company. Maybe you can test it with the 6.00 code.