cancel
Showing results for 
Search instead for 
Did you mean: 

BAPI_SALESORDER_CHANGE not same check than VA02

0 Kudos

Hello,

i'm trying to update order price date with bapi BAPI_SALESORDER_CHANGE.

  ls_order_inx-updateflag = 'U'.
  ls_order_in-price_date = i_datum.
  ls_order_inx-price_date = 'X'.

  CALL FUNCTION 'BAPI_SALESORDER_CHANGE'
    EXPORTING
      salesdocument    = i_vbeln
      order_header_in  = ls_order_in
      order_header_inx = ls_order_inx
    TABLES
      return           = lt_ret.

I face an error : (Function : SD_SALES_HEADER_MAINTAIN - after call FM: DATE_CONVERT_TO_FACTORYDATE)

Date 31.01.2020 is after the end of factory calendar XX. (V1 - 086).

This date is FVBAKKOM-VDATU (Requested delivery date).

But if I edit this same date with VA02, no problem.

I want to avoid batch input if possible.

Do you know why this check is done ?

Sales Org Calendar is indeed over. But if VA02 dont care, why dont BAPI do the same logic ..

Best Reagrds,

Guillaume.

Accepted Solutions (1)

Accepted Solutions (1)

VeselinaPeykova
Active Contributor
0 Kudos

guillaume.rosati the code from your screenshot looks like mine, but my test case so far was a bit different.

My understanding was that you are not modifying the requested delivery date via the BAPI. Was this date set before you ran the test sequence? For example, can it be that you had initially a factory calendar assigned that was extended until a later year and then you changed the customizing?

I ask, because if I try to set the requested delivery date manually to a date later than the calendar validity via VA02 I encounter the stop message that I showed you before. The only way for me to do this is by changing the customizing. In this case I can confirm that the BAPI behaves differently than VA02. As long as I do not try modifying the requested delivery date in VA02 I do not encounter V1086.

I have no logical explanation why VA02 was designed differently, still... why don't you extend the factory calendar for the sales organization?

It seems to me the right thing to do (in general).

By the way, BAPI_SALESDOCUMENT_CHANGE does not perform the same check as BAPI_SALESORDER_CHANGE and I was able to update the pricing date via it without errors. It is an unreleased FM, though.

Still, if I were you, I would ask the functional consultant what is the reason to keep the factory calendar in the sales organization with a date in the past.

0 Kudos

When order was created, requested delivery date was already after sale organization calendar.

I just check, in VA02, if I just edit Pricing Date, system doesn't check requested delivery date.

To me right solution is also extanding this calendar but functionnal cannot tell me the impact or why calendar is not maintained any more ...

BAPI_SALESDOCUMENT_CHANGE seem to do the job thanks !

I cancelled my enhancement point who change the calendar that was controlled.

Answers (2)

Answers (2)

Lakshmipathi
Active Contributor
0 Kudos

Have a look at OSS notes 1145413 and 1343682

0 Kudos

Thanks for notes but there are not applicable to our system and Symptom was not quite the same than mine.

VeselinaPeykova
Active Contributor
0 Kudos

Actually, in my system, if I enter in VA02 a date that is after the last date of the factory calendar, I see V1086 as an error message. For this to happen, you need to have unloading point with factory calendar maintained for the payer partner.

When you say that in VA02 you do not encounter this error, bit in BAPI - you can see it - was this test done for the same document? When you create an order the information for unloading point is transferred from the master data to the sales order, but you can also modify it yourself in the sales order. This means that if you used different sales orders for VA02 and for BAPI - check if there is unloading point maintained in them.

There are a few correction notes for V1086 not being issued in VA02, but these are for really old versions, e.g. 4.6C, so these are probably irrelevant to your case. If your system is really that old - please use V1086 as criterion to look for them.

0 Kudos

Yes, i have tested for the same document. We dont use unloading point.

In VA02, calendar is retrieve from VBKD and it is the good one. (VBKD-PERFK)

With BAPI, calendar come from TVKO.

I might use enhancement point at beginning of DATE_CONVERT_TO_FACTORYDATE to get right factory calendar ...

VeselinaPeykova
Active Contributor
0 Kudos

guillaume.rosati aaaa, you use invoicing dates calendar, right?

It is interesting though, that in this case I see V1086 as a stop message in VA02 - I set first invoicing dates calendar on header level, then I changed the requested delivery date (VDATU) and then I see this:

The check is done in FV45KF0V_VBKD-FKDAT_PRUEFEN, if this is not triggered in your case via VA02 maybe you already have some enhancement affecting this.

But why do you want to update requested delivery dates outside of the calendar validity?

0 Kudos

veselina.peykova

Yes, invoice dates of our orders have another value that sales organization calendar. (For example A0 for invoice date and A1 for sale org calendar).

A0 ends in the future, A1 ends in the past (few years ago).

I dont want to update delivery date, I try to update Pricing Date with bapi.

But there is an auto check on req delivery date. So in VA02 no problem because the check is done on the A0 calendar.

BAPI check A1, so process shutdown because of the error message.

Behaviour is not the same, depending on how we edit sales order.

VeselinaPeykova
Active Contributor
0 Kudos

guillaume.rosati apologies, I am very absent-minded and I did not read that you update only price_date.

I tried your code via the same BAPI and I do not encounter the error message.

I used invoice calendar IT with end 2020, 96 calendar with end 2029 for TVKO.

I set the pricing date as 18.05.2032 and all went well (no errors).

I even updated the billing date to 20.05.2032 - still no error messages (I do not use unloading points in this order just like you explained).

I tested in an old system (EHP4), so I wonder if the behavior that you describe is applicable for newer releases.

Have you implemented by any chance the customer improvement for considering goods receiving hours - 2482548 - Interface note for consideration of receiving hours for delivery date determination in sales orders or something similar to it?

If this is the case (sorry, no way to try this in a suitable system) would you please try setting via the BAPI the requested delivery date to the same value as it is in the current order?

0 Kudos

No need to apologies, it already very nice you take time for me.

So you have another behaviour .. things always come in threes

I'm in ECC6, SAP_APPL 701/12 (and no we haven't implement this note), but i tried to fill req dlvy date in BAPI with value i have in my order, same result :

I encoutered error in SD_SALES_HEADER_MAINTAIN :

My case : my req dlvy date is after end of my Sales Organization Calendar.

Pricing Date : any value, doesnt matter in this case, but i put sy-datum.