SCHEDULING AGREEMENT; RELASE NUMBER, EXPERT HELP NEEDED

[Former Member]

Dear All,

I trying to implement an automatic process for one customer, getting in an EDI 862; transferring this in an IDOC message type DELINS of Basictype DELFOR02 and updating the scheduling agreement accordingly.

This is working fine, for simple cases, but this customer is sending different release numbers for the same product at one time, and also sending the release numbers multiple times.

e.g. today I am getting for product A a release number 111 with multiple schedule lines, and also a release numberr 112 for the same product with multiple schedule lines.

tomorrow I might get again an EDI 862 for this same product, containing revised information for release number 111 and 112.

This is in my understanding not matching the SAP logic, where it's clearly stated, that a new release number is replacing completely the old release number.

Does anybody has any idea how to implement such a process?

I already have studied all documentation, tried to implement it in different ways, but I am reaching every time only a 80 % solution.

Do we have in this community any experts on scheduling agreements on the SD side, which might be able to help me?

Thanks for any possible help.

[Former Member]

Hi Maritam

If you are planning to maintain sales orders instead of scheduling agreements, then you may have to use 850 IDOCS instead of 862. As 862,s are specific to scheduling agreements.

Message type for 850 would be ORDCHG - Change order and for create ORDERS OR ORDERS03

Regards,

Syed Nasir

[Former Member]

Dear Marita,

thank you for your response. From my practice unfortunately I do not know any customers which use EDI 862 to create or change the standard orders. I am sure that technically it is possible, but the effort here will be quite large, the maintance possibilities from ERP standard are quite restricted and you cannot use many scheduling agreement functionalities, which are often quite nice and useful.

May be, there are such customers, but in my practice at SAP I did not know any customers doing this. I am sorry.

I hope nevertheless that my information could help you a little bit further.

Cordial regards,

Akmal Vakhidov

Development Support SD IMS, SAP, Walldorf/Germany

[Former Member]

Thanks for your help, and your fast responses.

One last question from my side:

My idea with going to OrderCreate / OrderChange has included on our side to have standard sales orders and not a scheduling agreement. So my question here fianlly is, do you know of any Company using SAP and handling in incoming 862 message via standard sales orders in SAP and not scheduling agreement related information.

Marita

[Former Member]

Dear Marita,

everything which you have found out is absolutely correct. If the customer sends you a DELINS-IDOC with the delivery schedule number 111 and then a new delivery schedule with the number 112, then the delivery schedule number 111 will be removed and new delivery schedule with the number 112 created. You have no chance to restore the delivery schedule number 111 back and then change it. This process is not supported in the ERP standard (I expect that 111 and 122 have the same delivery schedule type: both forecast or both JIT schedules).

If the MM-customer would like to change the existing delivery schedule, then he/she should send a DELINS-IDOC with the ODETTE-Logic (E1EDP10-LABKY = '1'). In this case the customer changes only schedule line(s) in the frame from E1EDP10-ABRAB (schedule valid from) bis E1EDP10-ABRBO (schedule valid till). This process is described very in detail in the SAP note 507522. Please read this note very carefully. This note describes how the schedule lines will be created in the scheduling agreement in dependance on the fields in the IDOC.

But even in the ODETTE-case, the partially replacement of schedule lines lead to creating a new delivery schedule. It is generally impossible to change the existing delivery schedule via IDOC (like ORDCHG). With the DELINS-IDOC you always create a new delivery schedule.

And you are absolutely right that the new schedule always replace the old one (schedule lines can be replaced partially or completely, but delivery schedule header - always completely), and if the schedule with the number 111 will be sent again, it will be considered as a new delivery schedule. If no gaps in numbering delivery schedules are allowed by you then it will lead to the error and IDOC will end in the status 51.

The note 507522 should in any case help you if you will contact your MM-customer and say him/her that the process (how they use it) is not supported in this design.

I hope, this information will help you a little bit further.

Kind regards,

Akmal Vakhidov

Development Support SD IMS, SAP, Walldorf/Germany

[Former Member]

Thanks for your suggestions. I have had already looked in the SAP note you mentioned.

I have used VDA logic so far, and uses the requirement status key for copying in schedule lines from old releases.

At the moment I am tinking about the following solution:

Instead of creating the delivery schedule header with the customer's release number, to create it with own number (somehow an internal number assignment) and to keep the customers release numbers somewhere else.

The right place would be VBEP, but here there is no possibility to my knowledge to extend VBEP without a core modification.

A z-table will not be easy to fill in the same LUW, specific if you are using the SAP standard functionality with the BDC session for the IDOC processing.

There are user fields available at the delivery schedule header, but here I would need to do some stuff, like tie schedule lines with a requested delivery date less than to this external release number and schedule lines with a requested delivery date less than that date to this external release number.

I also looked already in VBLB and VBEH, but they are also not so helpfull.

I have concerns using the Odette logic, because for me this looks like, that as soon you will update an exisiting scheduling agreement manual because of any reason, this will not work any longer (You are missing one IDOC) and it will not solve my issue.

Another approach would be to transfer the incoming 862 in OrderCreate / OrderChange messages / IDOCs, but here you have already the issue to decide should it go to OrderCreate or OrderChange.

Thanks for your help and let me know if you have any further ideas.

Marita

P.S. Our customer is not using SAP at all, he is using a Oracle based ERP solution.

[Former Member]

Dear Marita,

thank you for your information. I understand your process, but the solution which you would like to elaborate is not so simple. First of all, you will be never able to realize it without a modification. I work at SAP with scheduling agreements already many years, and I would recommend you (very honestly) not to do such a deep modification. So, the solution is only possible as a hard modification of the standard system.

Your second problem will be then the use of many standard functionalities (for example, fiscal year change: what to do if you get a delivery schedule in the new year but as a changed delivery schedule of the old year). And you probably know (I feel that you are very experienced) that a simple error tzo order correctly the schedule to the fiscal year will lead to impossibility to apply the next IDOCs (errors like V4 014 or V4 242). The next problem will be standard maintanance and application of corrected functionalities with support packages, It can cause more problems.

The next problem: your Forecast and JIT schedules should always be compatible. It will be very difficult for you to have such a compatibility after restoring the old delivery schedule with some changes.

Also your idea with ORDERS/ORDCHG IDOCs is very critical, because IDOC_INPUT_ORDERS(ORDCHG) will not ba able to update the scheduling agreement correctly.You have to write then the complete coding for creation of BDCDATA by yourself. If you really reach this, it would be a great job. But it will be an absolutely new functionality which you practically develop independent from SAP standard.

Currently the standard DELINS process is developed on the basis of VDA recommendations (german car manufacturing union). And I would recommend you to speak with your customer to send the delivery schedules sequentually, one after another so that every new delivery schedule will replace completely the old delivery schedule. It will be then the standard of VDA and SAP. So, never restore and change the old delivery schedule.

Then you would have the only problem is the numbering. Here you can create a simple solution by yourself (simply replace the customer number by your own one). Moreover, you can simply use the alpha-numeric numbering. For example, if you applied the schedule 111 and then should apply it again, then simply change 111 to 111a. As the last name is the alpha-numberical one, no error will be given.

So, the problem with numbering is solvable with some small modification (but in any case in VBLB, delivery schedule number is the delivery schedule header information, not in VBEP). But the problem to restore the old delivery schedule and then change it, is not so simply solvable and i would recommend you not to try to develop the solution for it, as the changes will be very deep there and the newly developed solution can have many critical problems concerning its impact with the standard functionalities and maintanance.

I hope, this info helps you further.

Cordial regards,

Akmal Vakhidov

Development Support SD, SAP, Walldorf/Germany

[Former Member]

<b>Hi Marita,</b>

Could you please clarify - 1) whether you want the next release schedule coming in form the customer to replace the existing one in the scheduling agreement

or 2) you want the next release schedule to just update the existing schedule in the scheduling agreement.

If your answer to point 1) is yes, then in the DELINS IDOC - Segment EIEDP10 and field LABKY should be equal to 2

If your answer to point 2) is yes, then in the DELINS IDOC - Segment EIEDP10 and field LABKY should be equal to 1

<b>Regarding release numbers:</b> Each time customer sends in schedules, the Release numbers have to be different (standard procedure)

Say release number 111 gets updated in scheduling agreement, then once again customer cannot send the same release number 111. System will throw an error.

Customer needs to send 112 and once this is updated in the scheduling agreement, then he can send 111 again and the system will accept this. I mean to say same release numbers cannot be sent sequentially.

Hope this will help you out !

Feel free to revert back with questions

Regards,

Syed Nasir...