Why can ISO volume unit be changed vom CD3 to DMQ in LIKP without entries in T006 & T006a?

[BaerbelWinkler]

Hi All!

We've recently been running into a weird issue where volume units (field VOLEH) in delivery header table LIKP was changed from CD3 (or externally CDM) to DMQ when shipment confirmations were processed. When these LIKP-entries are later accessed, the following message is displayed: "No language-specific unit defined in language EN for internal unit DMQ".

It is not possible to select all affected LIKP-entries in SE16 because the system doesn't allow a selection with VOLEH = DMQ on the selection-screen but instead shows message "Unit DMQ is not created in language EN".

I was able to identify all affected items via the change documents in CDHDR/CDPOS because the change from correct "CD3" to wrong "DMQ" gets logged there.

As far as customizing of UOMs goes, this is what is defined in our NW750 EHP8 system:

Neither table T006 nor T006A contains an entry for DMQ, but T006 shows it as the ISOCODE. Table T006I does have an entry:

Question #1 is: are these entries okay as is, or should DMQ have entries in T006 & T006A as well?

Question #2 is: If this is as it should be and if the error messages we see are correct, then why does function module WS_DELIVERY_UPDATE_2 allow an update of field LIKP-VOLEH from a correct to an incorrect value? Shouldn't this update be rejected with a comparable error message instead?

I have already searched SAP Community as well as OSS but nothing really fit the bill. Am I missing something or could it make sense to create an OSS incident for this? The latter may however run into the "issue" that we are in parallel investigating of how to avoid getting the wrong VOLEHs into the system at all as they seem to be the reason for some update errors visible in SM13 later on. So we need to stop the root cause as soon as possible as well.

Thanks for any pointers any of you might have!

Cheers

Bärbel

[raymond_giuseppi]

Perhaps because WS_DELIVERY_UPDATE_2 is not yet released for customer use, so it's not certain that an incident will be processed by SAP.

• At the risk of taking time, could you consider processing by IDOC which will also call WS_DELIVERY_UPDATE_2 but in a standard code).
• Incidentally, I've never needed to create an ISO unit as an SAP unit (until now)

[Ryan-Crosby]

Hi Barbel,

Are these confirmations coming in via IDoc? If so, viewing the contents of the data in E1EDL24 for VOLEH will tell you if the code that is received is incorrect. I know in the sales transactions the system will convert the expected ISO code into the internal UoM, but not sure how the system behaves for shipment confirmation. The services for object -> relationships would allow you to view any incoming IDoc to see the data.

[BaerbelWinkler]

Thanks, raymond.giuseppi & ryan.crosby2

Yes, I'm aware that we are using the function module at our own risk but still find it weird that there doesn't seem to be a check before saveing the wrong VOLEH to the table - esp. as that content then triggers messages in later processing.

The entries come in via PI and AIF as far as I know but I don't have access to either. According to colleagues, there is no logic to convert the incoming VOLEH for LIKP which we might be able to correct on our end (such a conversion seems to happen in the comparable mapping of LIPS data). This thus far had "flown under the radar" because volume changes had been ignored in the processing triggered via AIF, but this was changed on July 20, coinciding with when this VOLEH-issue started to become visible. Took us a while to figure out what was happening there and why.

Cheers

Bärbel

[Ryan-Crosby]

Hi Barbel,

I was able to confirm in our test system (S/4 2020) that if I pass DMQ as the ISO Code for VOLEH the processing function converts it to CDM automatically before FM 'WS_DELIVERY_UPDATE_2' is called. Given that it would appear that you are expected to handle the appropriate external -> internal conversions for units (and possibly other fields).

[raymond_giuseppi]

Basically those ISO codes are intended for exchange between different systems (so IDOC, BAPI) so they are converted in the exchange process not in the final internal process (the FM)

(they should have left that dog lie.)