conserving first date of sd order

[Former Member]

Hi,

This could be SD forum question but I felt this was a more relevant forum for this question.

Background:

For reasons of ATP check, scheduling within ATP, manual change to sales doc line item date, manual change to schedule line dates, re-scheduling, re-ATP after partual delivery etc, the first date on the sales line item will be lost esp. if there is a single confirmed schedule line for line item.

Question:

Other than change log, what should be the way out to store the first version of truth of first date at sales order line item transparently other than in VBEP-EDATU- schedule line delivery date that keeps changing and hence updating the first date at line item.

The reason it is important to know the orignal first date is subsequent shipment, transportation planning and physcial actions are dependent on this value but such is happening in external systems... not real time integrated to R/3. The first date is also needed for e.g .reporting service level metrics and other ad-hoc selections. It could have been used in several IDOCs

Could you share your experiences or sensible easy solution, with similar requirements if encountered

PS:

1) The first date on each line item could be different from header date (requested delivery date)

2) It is ok to have another confirmed schedule line proposed always but as I said but this does not happen if delivery date and ATP were both feasible.

Guru

[Former Member · Accepted solution]

Gulab,

Perhaps note 833272 may be of interest to you.

https://service.sap.com/sap/support/notes/833272

Best Regards,

DB49

[Former Member · Accepted solution]

Thank you DB49.

I did come across this note and all consulting notes on schedule lines and ATP and also verified that the corrections of this note is already implemented. I couldnt make out what it means when it says rules of customizing of schedule line. I checked the config of schedule lines and item category and scheduling etc. and couldnt really connect. They are as basic as it is supposed to be.

I have tested possible scenarios and learn from some corners that people have created a Z field to store the first date !! This is going the Z way though for something as basic and stable as SD schedule lines that seems to have been very understood and well documented to address all likely scenarios of sales order processing.

I will update any new findings I have

Thanks

Guru

[Former Member · Accepted solution]

Guru,

This note has not been implemented in any service pack. If it has been implemented in your system, then your company has done it.

The scheduling to which the note refers is found in OVLY. By default, all schedules in a sales order use backward/forward scheduling. You can override this behavior by setting all schedules to 'backward only' via OVLY. There are many business reasons why most companies do not usually select "backwards only".

This note allows you to continue to use standard sales order schedule scheduling (backward/forward) except under certain specific conditions. There is no guarantee that the original schedule will always be preserved, only that in most normal business cases it will be preserved.

If this note has already implemented in your system, and you are still unsatisfied, then I guess I don't really understand the nature of the exact scenarios that are causing you heartburn. If your requirement is that the original schedules will NEVER be altered, under any circumstances, by the ATP check, then I don't believe that SAP offers any solutions. Your only recourse is to create your own solution. This note offers a solution that will retain the schedules "almost always".

Best Regards & good luck,

DB49

[Former Member · Accepted solution]

Thanks DB49.

Almost Always phrases it all.

The scenario causing heartburn is.

- The requirement that re-scheduling of all nature (ATP, re-ATP, BOP, manual change to some dates in schedule line) is fine as long as we have the "visibility" (busiiness's favorite term) of the first date.

- The visibility I see is protected as long as we have a second schedule line for every item (first one being not confirmed) and change to schedule line date is only to the extent of planned GI date being <=Delivery date

Further I explore Fixed Date and Qty

- Fixed Date and Quantity indicator at schedule line protects the first date as long as second schedule line remains as initially proposed. This may be because of insufficient lead time or insufficient ATP.

- Further fixed date and quantity does not stop manual rescheduling of first schedule line (which is of course the sensible thing as it is manual)

- And second schedule line remains as long as I change first schedule line manually UPTO a certain extent (as long as Planned GI date <= Delivery Date), beyond which I loose both first original date and also the second schedule line which of course is logical but as I said (business says) visibility of customer requested first date is lost.

Guru

[Former Member · Accepted solution]

Guru,

I don't believe standard SAP sales order processing will support this requirement. You will need to create an enhancement.

Best Regards & good luck with your enhancement,,

DB49

[Former Member · Accepted solution]

Thanks DB49,

Appreciate your time and re-assurance

Guru

[Former Member]

Guru

The u2018Commitment Dateu2019 value assigned to the Sales Order Type determines if the system maintains the committed dates & quantities (as opposed to the confirmed quantities/ dates generated in the Sales Order Schedule Lines). This can be used to store the u2018first commitu2019 to the customer even after confirmed quantities change due to BOP, etc.

I believe a value of 'B' in this field should work, but you can explore other options.

Rishi Menon

[Former Member]

Thanks Rishi

Yes I tested this one too but this not a date field (domain). It tells that sales order is delayed but I havent checked what is the basis of that measurement - confirmed delivery date or requested delivery date at header or the first date of line snapshot.

I presume by commitment date you meant the "delivery time" field in schedule line !

Guru

Edited by: Guru Gulab Khatri on Oct 3, 2011 3:42 AM

[Former Member]

Guru,

The Committed date is implied.

When this field is populated in config (VOV8), the field 'Committed Quantity" will be calculated and populated in the schedule lines in VBEP. If the commited quantity exists in a schedule line, then the dates on that schedule line are the commited dates. The software may actually even create additional schedule lines, for the purpose of documenting the Commited Date/qty.

Best Regards,

DB49

[Former Member]

An extension to this question albeit stupid it may sound

-Is it possible and sensible to have have schedule line delivery date NOT update the line item first date !!!