Send-Ahead Quantity

ldreamsl

I created a routing with the use of the "Send to-head Quantity" field.
This image shows the correct cycle.


After validating the "Send to-head Quantity", ont the last line of the routing (confirming the value), the dates of the cycle change incorrectly.


This happens on all versions of "Dynanics NAV"!!

There is a solution to the problem!?

Thanks.

ldreamsl

It seems that the back calculation does not work (with "Send-Ahead Quantity" only)!!!
But how is this possible? :-k

ldreamsl

Anyone happen to tackle the problem? :-k

bsturzo

Hi!
which operation no. are you trying to update?
In the "After" picture, Send Ahead looks unchanged.

Thanks,
Bogdan

ldreamsl

bsturzo wrote:

Hi!
which operation no. are you trying to update?
In the "After" picture, Send Ahead looks unchanged.

Thanks,
Bogdan

Yes,
In fact, you do not need to change the value, simply confirm it.
The problem is the direction of schedule.
Back does not work.

bsturzo

so you are typing the value 0 in the last operation?

ldreamsl

bsturzo wrote:

so you are typing the value 0 in the last operation?

Yes.

But you can also confirm "Ending Date" of the last line, or any other field that triggers the back rescheduling.

bsturzo

Could you post a detailed scenario?
I'm doing the following and it seems to work fine:

1. Create Released Production Order for item 1000, 100 PCS. Due date = 08 jan 2014.
2. Refresh Production Order.
3. Go to Line - Routing and add Send Ahead column to the view.
4. Set Setup Time = 0 and Run Time = 1 on all routing lines. (this is to simplify the calculation).
5. Add Send Ahead = 50 on operations 20 and 30.
6. Edit Ending Date-Time to be 07/01/2014 - 12:41.

Following the time back it correctly generates a Starting Date Time for operation 10 of 06/01/2014 - 15:41.
(the calendar for operation 10 is 08-16 every day).

Thanks,
Bogdan

StefanZimmer

I got the same issue using NAV2009 Classic when operation run times in sequences are different.
In our branch you often get output rates from 5 to 10 pieces / min, followed by one or two jobs with 5-10 pieces / second and then again a job with 5-10 pieces / min.

After calculate your Prod. Order “backwards” take a look at the "Prod. Order Capacities Needed". You will recognize that you only get the last send-ahead “position” in sequence. The other “send aheads” are completely added before the setup / start of the next operation. You got a gap in your work load. Every next job/operation backwards this gap raises by "setup-time" + "run time" * ("imput quantity" - "Send-Ahead Quantity")

You will find two operations as screenshots (sorry for german fieldcaptions) as attachements.

My idea was solving this problem by two ways:
1.) “next operation” cannot be interrupted --> using a higher “Send-Ahead Quantity”
2.) "next operation” can be interrupted --> reducing the “Concurrent Capacity” to a value < 1 --> so the "next operation" takes the same time
Unfortunately this didn’t work as planned. Reducing the “Concurrent Capacity” raised the gap.

Calculating forward my two ways above worked as planned but unfortunately Navision calculates backwards while generation the “Requisition Lines” and the Chaos starts.

Another question is, why the “send-ahead quantity” is defined as absolute value at the routing line. The send-ahead quantity is a matter of your producing quantity. Px. if the next operation is twice as fast and cannot be interrupted, then the send ahead quantity is 5 at a prod. qty. of 10 and 5000 if you produce 10000 pcs.

Bye Stefan

StefanZimmer

Update:

Today I tested this issue at Cronus-Company.
It's easy to reproduce this strange behaviour.

1.) Take the first firm planned Prod. Order
2.) Open the Prod. Order Routing Lines
3.) Display the Send-Ahead Quantity Field
4.) Enter a Send-Ahead Quantity in each line
5.) Change the "Run-Time" so that a long run time is followed by a short run time followed by a long run time ...
6.) Go Back to the Prod. Order Form
7.) Call Function Replan.. forward and note the starting date
8.) Call Function Replan.. back and you will see that the starting date is earlier than before.
9.) Look at the Routing / Prod. Order Capacity Need you will find the gap described above.

This issue is realy worse

StefanZimmer

Talking to myselve

today I got seven bugfixes for codeunit 99000774 and 99000810 from my NSC

and it now this issue is solved
:thumbsup:

SilverX

StefanZimmer wrote:

Talking to myselve

today I got seven bugfixes for codeunit 99000774 and 99000810 from my NSC

and it now this issue is solved
:thumbsup:

In fact not all of the seven are necessary for this specific problem, but there are some other scenarios with constraint capacities which will benefit from the other fixes

Cheers,
Carsten