SY-DATUM of Batch running on sunday results in dates of monday and sunday in a z-table

[christofs]

Hello,

I have no clue what I am doing wrong here.

I start a batch job that is doing some cost allocation. A report is submitted which then calls a FM that selects set of sales document numbers and loops over those, does some calculations for the PSP elements of those SD no. and in the end the lines of that sales document number get the SY-DATUM as changed date.

After the loop is done with all the sales document numbers around 7.000 lines are altered and outside the FM that has the loop a commit is done via commit work and wait.

The job usually starts at 17:00 and finishes around 45 min later.

Now this is where my problem starts: I now have 741 lines with the changed on date (derived from the SY-DATUM) 19.09.2021 and 6.401 lines with 20.09.2021 and I get this result on Sunday the 19th. the job starts and ends long before midnight (I even got this result with a job scheduled to start at 14:00 and end before 15:00).

When the job runs during the week everything is fine, no dates of the next days are stored.

I have no clue why I get those different dates. I even get different dates per sales document number.

Systeminfo: EHP8 FOR SAP ERP 6.0 Any input is appreciated!

[RaymondGiuseppi]

Check with the server administrators,

• Is the server stopped and restarted on Sundays, so some tasks do not finish until Monday?
• Is the server so busy on weekends that tasks take a very long time to run, long time waiting in queues?
• Are some 'exotic' task performed on weekends that could change the time, time zone?

If allowed look at SM21 for message during the weekend that could explain this phenomenon.

[christofs]

Thank you for your input, here are my remarks:

• Even if so, it does not matter. I've logged in on sunday and I got the date from monday in the tables.
• No, the job only runs about 45 minutes

[FredericGirod]

could check also SM13 & the dates send to the FM

[RaymondGiuseppi]

• The main program run in 45 mn but it trigger some update tasks?
• When you logged in on sunday were some background job processes active, were the update (and update v2) processes active ?
• Do you actually perform a single COMMIT for the 7000 updates as written?
• Could you check the change documents related to the changed SO items, for the CPU timestamp?

[Sandra_Rossi]

christofs You say "I've logged in on sunday and I got the date from monday in the tables" so either it's a feature of your Z program and we can't help you, or it's the time configured in one of your application servers which is wrong.

[RaymondGiuseppi]

Does your Z-report use some (standard, factory) calendar that could (sometimes) bypass Sundays and holidays or if some abaped played with syst-tzone?

[FredericGirod]

Do you have the same timezone between: You, the system, the database ?

does anyone plays with timezone on plant or something else ?

[joltdx]

Which is the exact date field you're talking about here. "SY-DATUM as changed date" and "the changed on date (derived from the SY-DATUM)".

There is config in SAP to "allow" or not things and actions on specific days, according to factory calendar. As this works just fine for you on normal days, could the date you talk about not be the actual "change date", but some field that is affected by these settings? Or maybe the change date is also actually adjusted according to these settings?

I don't know SD enough to guide you to any settings though, sorry 🙂

[christofs]

Factory Calendar is something that came up in a discussion with a co-worker. But I couldn't find a reason why the sy-datum should use the next monday instead of the sunday. And why are there couple of right entries and a lot of wrong one... (I don't think it is SD related as we are talking of a Z-Programm and a Z-Table)

This is the place where I set the sy-datum:

x_psp-aenam = sy-uname.
x_psp-aedat = sy-datum.

Information of the field:

Name: AEDAT
Type: AEDAT
Dataelement: DATS
Length: 8

I have no clue...

[joltdx]

Then, @christofs, you can disregard my comment. I was not sure if you used the SY-DATUM directly, but apparently you are and the factory calendar would not affect that at all. Only if you were getting some date from an SD document in some way.

I would check server settings and time zones, as already mentioned elsewhere...

[matt]

What Frederic Girod wrote. What time zone are you in, what time zone is the server running? If you're five hours before UTC, and the server is on UTC, that would explain the issue.

[christofs]

Both the server and me are in Germany, so UTC +2...

[FredericGirod]

christofs a quick way to test is to compare SY-DATUM / SY-DATLO SY-UZEIT / SY-TIMLO.

You have to use SY-DATUM when it is a background task, and SY-DATLO when it is a foreground task (user action).

Does your update was made using a FM background task ? do you see it in the SM13 ?

[christofs]

The report runs via a schedlued task. So yes, background job. And I use sy-datum within the report.

[matt]

OK... last straw to clutch at.

What does table TTZCU contain (for the active record)?

What are the results of running RSDBTIME?

[christofs]

Universal Time Coordinated UTC....: 1632723776
Date and time of database.........: 27.09.2021 08:22:56
Date and Time of R/3-Kernel.......: 27.09.2021 08:22:56
Date and Time of ABAP-Processor...: 27.09.2021 08:22:56
ABAP Timezone Setup ..............: 3.600
Date and Time / localtime ........: 27.09.2021 08:22:56
No Time Inconsistencies detected !

I will try this report again next sunday, maybe it really depends on the day when it is run...

Yesterday the job again was unning in a way, that I got a lot of entries with todays date. Well, at least the "bug" is stable! 😄

[FredericGirod]

christofs did you check if there are log in SM13 ?

[christofs]

Yes. Nothing...

[FredericGirod]

I think you need to add to your development a manual log with some information (date started, hour started, hour commited ..... )