Reservation Date Conflicts

LibertyMountain

Can anyone explain the purpose behind the reservation date logic between purchase line reservations and sales line reservations? To reserve a sales line against a purchase line, default functionality requires that "Sales Line"."Shipment Date" >= "Purchase Line"."Expected Receipt Date".

For an ASAP distributor like us (we do not manufacture) this rule is frustrating. If take an order today (shipment date = 9-JUN-09) and I don't have stock, by default I am only able to reserve this sales line against an incoming purchase line with receipt date <= 9-JUN-09 ... when what I really would like to do is reserve the sales line against a future incoming purchase line. The fact that I am out of stock naturally implies that I do not have a purchase line ready to be received today (and with a customer on the phone, I don't have time to hunt for the next available purchase line so that I can match my sales line's shipment date to that purchase line's expected receipt date).

We have a modification in place that relaxes the date conflict rule, thus allowing a sales line shipment date to be before the purchase line receipt date. So far this has not caused major trouble. Does anybody have experience with this that would suggest major trouble is looming?

Also, when we adjust purchase line expected receipt dates, the date conflict rule comes into play and requires that I break all my reservations against the purchase line before I am able to adjust the expected receipt date. I am considering a modification that would keep the reservations in place but would modify the "shipment date" field on the related sales lines and reservation lines so that date conflicts don't come into play.

kapil4dynamics

NAV does all this by default , u just need few things, reservation selected as always for all these kind of JIT sales item (which i assume u wud have done).

Use "Order promising" so that system will find which is the nearest receipt of same item and will reserve it. If it is <= shipment date no issues, if it is greater then system will find it and reserve it, u need not do that.

Even if u change the receipt date go to sales order run the planning and click on functions update shipment date it will bring to the nearest receipt irrespective of < or > ,then u can change it either manually or go to Order Planning again calculate Available-to-Promise and system will change the dates on sales order by itself u need not find.

But yes in all the circumstances u need to have something in hand or on purchase line to have this work i hope u will agree to that.
Dates is not an issue this is handled quite well by NAV. So i don't think there was any need of modification.

David_Singleton

LibertyMountain wrote:

We have a modification in place that relaxes the date conflict rule, thus allowing a sales line shipment date to be before the purchase line receipt date. So far this has not caused major trouble. Does anybody have experience with this that would suggest major trouble is looming?

I am curious how this came about. As Kapil says, this is handled by standard Navision using Order Promising. Did your partner discuss Order Promising with you before they made the modification?

kapil4dynamics

I think they (partner) just need to explore Order Promising next time they come to u, as Order Promising can create orders (Purchase based on Sales) as well with auto-reservation if u want. It has quite a lot capabilities.

LibertyMountain

sorry in advance for the long post ... but here's all the info and assumptions we are working with:

To be honest, we didn't spend a lot of time with our NSC discussing this (for various reasons that are not relevant to this post). And, we don't own the order promising granules. This customizations we made to reservations, we made ourself.

I did however play with the order promising functionality over the weekend, and it's not as quick and practical as I would hope. We are an ASAP distributor where most of our orders are taken over the phone, and there is commonly (not always) no time for discussion or give and take between customer and sales rep if items are not in stock. The reps taking the orders wanted the following:

1. Put in a qty. If on hand, reserve it against ILE. (NAV does this perfectly without customization)
2. if not on hand, find the first incoming PO and reserve it against that (and make it obvious to the rep the date of the future PO for quick communication to the customer). (NAV won't do this because of the date conflict rule.)
3. if not on hand and no unreserved future po's, then display the standard reservation message "Automatic reservations not possible ... Reserve manually?" (NAV does this just fine too.)

The reason they want this is becasue the more common dialogue that happens between customer and sales rep is "I don't have it, but it comes in on xx/xx/xx. Do you want me to send it when it arrives?" Order promising just doesn't facilitate that quick communication (to use order promising would require 5 or 6 keystrokes, and waiting for an engine to reply with a date, then the reply to the customer, then whether or not to accept.) For the less common customer who is willing to engage in a conversation and find out how long it will take to get the item and will want to book their order for a future delivery, order promising shows promise (no pun intended).

In addition our PO process is not as JIT as we would like. And it would be prohibitively expensive to get it as such given our market and our volume. We have freight minimums and order minimums to meet and given that we are a distributor and compete with the manufacturer in many markets, our po dates and quantities are most often not modifiable.

Here is the customizaiton we have in place: when you drill into the sales line "Reserved Quantity" field (or when the "Sales Line".AutoReserve function executes), standard NAV is to show ILE records and PO records with receipt date <= ship date. We have a simple modification that comments out the purchase line setfilter on expected date, thus giving the rep access to reserve against PO's with a receipt date > shipment date:

// CalcPurchLine.SETFILTER("Expected Receipt Date",GetAvailabilityFilter(AvailabilityDate)); //2008-085

Now when a rep types in a quantity (we have all our customers set to reserve::Always), NAV tries to make an ILE reservation, then a PO reservation (and DOES consider future POs). if it makes a PO reservation, the rep is 2 clicks away from telling the customer the date (1 arrow over to the reservation field, and f6 to see the reservation's expected receipt date) and thinking about this out loud, we could easily just pop this date onto the info pane to make it 0 clicks.

So back to my original question ... with the customization we have, we allow sales shipment date < purchase expected receipt date. And as we know, NAV's standard date conflict engine does not allow this. Are we asking for trouble?

Furthmore, the fact that we cannot re-date a PO's expected receipt date without breaking reservations is also a frustration. We're contemplating a customization that would automatically redate the SO lines so the conflict rule doesn't get violated.

Perhaps after all this typing, the simple answer is that I need to consult with our NSC on this, but before doing so I wanted to get as educated as possible.

David_Singleton

The reason for my earlier post was to make sure that you look at standard functionality before making customizations, and that you at least look at what the base does for inspiration.

Its important to realize that order promising does a lot, which is why it takes time, it is looking at a lot of stuff that is not relevant to your business.

In your case, you basically need something like order promising but with out all the key strokes, and much simpler so it calculates faster. Look to see if you can stream line promising to your needs, and if not then you need to look at dates and make a change to change the ship date on the sales line to match the receipt date on the purchase order.

Though there is still a lot more to allow for, most specifically what to do with partials, i.e. customer orders 10, 3 are in stock, an order for 5 comes in next week and another order in a months time. There are a lot of conditions to allow for.