Shipment Cost Document - Settlement Date Issue

[SimoneMilesi]

Hi all,

i'm facing a problem on Shipment Cost Document about the Settlement Date determination.

Scenario

-The users create the Shipment via VT01N and save it

-In BADI_LE_SHIPMENT, at SAVE event, the "Shipment start" Actual date (VTTK-DATBG), if the user already pushed the Shipment Start button, is overwritten with the 1st delivery GI date (LIKP-WADAT_IST)

-The user create the shipment cost document with VI01 or VI04 standard transaction.

-Then the user can transfer the SCD via a custom transaction which only show with a better layout and additional infos a list similar to VI05. There is also a button to relase SCD which basically run a call transaction of VI05 with BDC to release the SCD.

All pretty standard (except the overwritting of "Shipment start" Actual date (VTTK-DATBG)

In customizing, the consultants set up the pricing and settlement date to take the VTTK-DATBG

The issue
Now, I have a 70% of the SCDs' dates correctly set up with this configuration but i also have a 30% of SCDs with "random" settlement dates like this situation

Shipment

SCD

What i did

I tried to replicate the situation in QA system, without success.

I tried to remove the overwrite of Shipment Start date, without success.

I tried to check for OSS Notes but none seems to fit the situation.

So, there is anything i could check? I'm an ABAPer so all i can do is to debug and check a bit of customizing, but it seems all ok (and our consultants said it's all ok)

Ty

Simone

[VeselinaPeykova]

Hi Simone,

have you looked at the settings for the date rule in transaction T_60?

If you are using the standard cost calculation, there should be the sequence from where the settlement and pricing dates are determined.

I checked in an almost standard system - for this date rule the sequence is:

Is this different from what you have both in QA and PRD?

If it is the same, check the values for these dates in the 30% of documents, which don't look logical. If your settings are different, you can check when and why this was changed and see if the dates from the rule make sense to what you see in PRD.

Also, the users can manually change the date in VI01/VI02, did the consultants check with the business if they did this for some reason?

If the pricing date was not changed manually and if the dates that you get in PRD do not correspond to the standard setup, then I would start checking for custom code.

[SimoneMilesi]

Hi Veselina,

Thanks for your answer and sorry, i did not attached the T_60 screenshot: it looks exactly like yours in every enviroment (DEV, QA, PRD).

So, if I understood well, the system should take the "Shipment start" Actual date (VTTK-DATBG) according this setup.

And no, the users do not even know the VI02 (except the key users who can update the price manually and my cases are all with automatic price and without changes).

Any other thing i can check or you can think about.

[VeselinaPeykova]

This means also no access to VI01, I assume (this one is harder to confirm, you need to rely on the information by the user, if they have sufficient authorizations to execute the transaction).

From these settings in T_60 , the first checks are from leg start, then you get the checks for shipment start actual and planned.

Here is one example from IDES (not 100% like your settings, but you will get the idea):

Shipment execution:

Shipment stages (I have just one delivery and direct leg, a way too simple scenario, usually it is more complicated):

Delivery dates (I used a very old document and reversed the shipment statuses, business people should not be authorized to do that, but still worth checking and usually you restrict the delivery selection criteria if shipments are created manually):

Now look at the dates, which I get at document creation (I don't think, that we have custom developments for TCC in this system:

Try to check these dates as well and compare what you see in PRD to what you create in QA.

If still no luck, I can try to get you a list of possible places, where these dates can be modified, but considering that you are a developer and assuming that custom developments are documented somewhere, you probably won't need that. 🙂

By the way - are you using any third-party software for shipment creation? Or everything is done via VT01N?

30% of deviations does not look good.

[SimoneMilesi]

Thanks again for your support

If still no luck, I can try to get you a list of possible places, where these dates can be modified, but considering that you are a developer and assuming that custom developments are documented somewhere, you probably won't need that. 🙂

Yeah, i know them pretty well since the Transportation project was developed by me for the coding part so I already put any possible breakpoint in my code 🙂

By the way - are you using any third-party software for shipment creation? Or everything is done via VT01N?

The only custom software is my transaction allowed to simulate the VI05 with a better layout.

The shipment is created via VT01N (enhanced to retrieve the distances between stages via Google Maps API) .

SCD are enanched to get default Account Assignment (so no dates!) and to force ESSR date when released and transferred to the PO (but it works only with ESSR structure).

Now i try to look into the legs dates!

Ty again!

[SimoneMilesi]

Ok, basically i'm a big big big dumb!

The issue was the following:

when you massively recall the deliveries you want to put in a shipment

And just put one or two of them in the shipment, at save SAP brings all of the found.

I had a little code which read the first delivery and retrieve the GI date to be forced into the settlement date.

But in my tests i always had 1 or 2 deliveries so i was not aware of the "massive list".

In production this meant that the date copied was one random off the big list in Shipment creation (as well then in Shipment Cost Document ones).
Then, when scd got released, the same badi on shipment is triggered and the check in order to force the date is called, this time with the correct deliveries only and the date is overwritten.

Sadly those dates are not under change history so i was not able to see find it until i did the "massive selection" in production...