cancel
Showing results for 
Search instead for 
Did you mean: 

Determination of First Date in Sales Order

satish_waghmare3
Active Contributor
0 Kudos

Hello SAP Friends,

Below is the issue we realised during the testing. The issue is with First date in the Sales Order which is not updated as per Unloading Point Calendar .

As per details I received, it should refer Unloading Point Calendar for ShiptoParty and populate the next working day as First date into Sales Order.

How is First Date determined in the sales order? Is there any config settings which is based on Route to do this? Or Is it controlled purely based on settings done in Tcode: VOV8, Leadtime days? I do not think VOV8 settings is controlling that in our APO system.

I have checked MAD, Pick/Pack, GI date all are populated correctly, But First Date did not follow the logic Unloading Point Calendar of ShiptoParty.

Please let know your inputs in this regard.

Thank you

Satish Waghmare

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Satish

My understanding is First Date is calculated at the the time of Sales Order Entry based on the lead time. I have not checked in details, but I don't think First Date comes from APO - probably other experts from this forum can confirm. However, MAD calculation follows all the required set-up (e.g. unloading point etc.). I am also curious to know why you would like to change First Date - normally a correct MAD is sufficient for business.

Thanks,

Prasun

satish_waghmare3
Active Contributor
0 Kudos

Hi Prasun,

Thanks for the reply.

You are right, First Date is calculated at the the time of Sales Order Entry based on the lead time.

But as per logic given by Business here it should refer Unloading Point Calendar for ShiptoParty and populate the next working day as first date into Sales Order.

The above is working in test system, but not in Production. So want to know any input to resolve the matter.

Additionally you can refer old thread on the similar topic, http://forums.sdn.sap.com/thread.jspa?threadID=1784990

Awaiting any inputs.

Thank you

Satish

michael_thinschmidt
Contributor
0 Kudos

Hi Satish,

This might have several reasons:

1. The ship-to is known in APO (has master data) and you have not maintained a receiving calendar.

2. The RFC call to R/3 can not happen during the APO scheduling...not working RFC connection?

3. APO scheduling userexit 002 deletes/change the calendar ?

4. no valid receiving hours maintained for ship-to

5. database inconsistency in R/3

Please check on the scheduling explanation if you see the receiving calendar at the ship-to level ? Usually you see a generated timestream ID, something like SAP........ (and a number). This Code e.g. "SAP6544331" can be entered in /SAPAPO/CALENDAR to check the periods.

If you cant find the reason it will be necessary to have a look at the system. Raise a SAP message and I will analyse this if possible.

best regards,

Michael

satish_waghmare3
Active Contributor
0 Kudos

Hi Michael,

Thanks for the inputs given by you, I have verified things mentioned by you. Here are the details.

1. The ship-to is known in APO (has master data) and you have not maintained a receiving calendar.

--- We do not have Ship-To maintained/transferred to APO.

2. The RFC call to R/3 can not happen during the APO scheduling...not working RFC connection?

--- I have verified, there is no issue with RFC call.

3. APO scheduling userexit 002 deletes/change the calendar ?

--- I think you mean, User Exit: APOSC002 Extend Data Determination, but it is not implemented in our system.

4. no valid receiving hours maintained for ship-to

--- Receiving Hours are mained in for Ship-To. Verified in ECC.

5. database inconsistency in R/3

--- I am not sure on what data inconsistency in R/3 you mentioned here. Anthing I can check and run a report etc.

Please see if you have any additional inputs to help resolve this matter.

Thank you

Satish

michael_thinschmidt
Contributor
0 Kudos

Hi,

I mean the table KNVA..check that the data in the table is the same you see in the ship-to master data in R/3.

Have you checked the scheduling explanation ?

Sorry, no further ideas then...

best regards,

Michael

satish_waghmare3
Active Contributor
0 Kudos

Thanks Michel, I checked the Table KNVA, the data in the table is matching with ShiptoParty master data in R/3. Calendar Details and receiving hours maintained for ship-to are matching.

Thank you

Satish

Former Member
0 Kudos

Satish,

I unfortunately don't have a solution for you. However, here are a few observations, and a question.

My experience is that 'First Date' in R/3 is not determined. In every sales order I have ever seen, First Date is proposed (matches the requested delivery date in the Sales order header) by the system, but can be overridden by any changes that the user may elect to make.

Generally, then, after First Date is entered, the R/3 system then may be configured to determine certain master data: Shipping Point, Unloading Point, Route, Route Schedule. From this master data, if you are performing ATP in R/3, the system will then also calculate various dates (if configured) for the confirmed schedule proposal: Normally these calculated dates are Delivery Date, Goods Issue Date, Loading Date, Material Availability date, Transportation Planning Date. If you have configured Route Schedules in R/3, other dates may be determined.

If you are performing ATP in APO, then any such scheduling must be performed in APO. Relevant Master data that was determined in R/3 is carried across to APO during the ATP check and is then used to calculate appropriate durations. This does not happen automatically, you have to configure the scheduling technique you wish to use in APO.

So, my first question: Are you performing ATP in APO? If not, then you should probably close this post, and re-enter in one of the SD forums, since it is an SD issue. If you are performing ATP in APO, then what scheduling technique are you using?

Best regards,

DB49

satish_waghmare3
Active Contributor
0 Kudos

Hi DB49,

I completely agree with you First Date is proposed and not determined. and can be overridden by any changes that the user may elect to make.

ATP check is performed in APO, scheduling is performed in APO too.

We are using scheduling technique for condition type : PICK and TRAN. With these settings defined in APO, Sales Order has correct Delivery Date, Goods Issue Date, Loading Date, Material Availability date, Transportation Planning Date. This all is working fine.

But only issue is with the First Date, which is not updated as per Unloading Point Calendar of Ship-to-Party(as desired by the design). This is where I need input.

Thank you

Satish Waghmare

Former Member
0 Kudos

Satish,

Sorry, but I have never seen APO touch 'First Date' except when it is creating subitems (RBA). First Date is the 'rock' upon which all other dates are determined. I suppose it would be possible to force a date into this field with an R/3 ehancement. However, such a change would have to analyzed extensively, since so many other dates are derived from First Date.

Best Regards,

DB49

michael_thinschmidt
Contributor
0 Kudos

Hi DB49,

SAP offers a modification note 833272 where the first date gets changed if its in the past, but in standard the first date is not touched. If I understand the issue correctly the confirmed delivery date is not adjusted according the ship-to receiving calendar..this might be not a confirmation at requested delivery date, but on a later date...so they get a second schedule line.

Best would be to raise a message at SCM-APO-ATP-SCH and to check this on the system.

best regards,

Michael

satish_waghmare3
Active Contributor
0 Kudos

Hell All,

FYI, This is done by using custom enahncement in R/3. It is found that by using User-Exit: MV45AFZB -> INCLUDE zv_i_mv45afzb_check_vbep_edatu.by referring couple of variables from tvarvc table, the required logic was achieved to populate First Date as per unloading point calendar for ShiptoParty. We maintained the required values for TVARVC varaible and then it started working.

Thank to all of you for valuable inputs/insight given.

Thank you

Satish Waghmare