cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Warehouse task creation from PPF-Action delayed

0 Likes
1,945

Hello everyone,

my collegues from the logistics department brought a very odd system behaviour to my

attention. When the production is posting a goods income, two PPF actions are triggered.

/SCWM/PDI_02_GR_POST & /SCWM/PDI_02_WT_CREATE

Usually these two work just fine. When the goods income is posted

the warehouse tasks are created right away.

Yesterday, for some inbound deliveries from production,

the /SCWM/PDI_02_WT_CREATE didn't work as intended.

The Inbound delivery was created at 09:03:47 AM.

The PPF actions for goods income posting and warehouse task creation started at 09:03:47 and 09:03:48. Everything fine so far.

Now comes the problem. The warehouse task which was created by the PPF action was created 3 hours later at 12:05:05.

I've checked the SLG1 logs for this inbound delivery from 09:03 and 12:05. Both look identical to me but the first one didn't create the warehouse task.

In between the inbound deliveries for which the warehouse task creation didn't work properly there were always a few that worked just fine.

Has anyone encounterd something like this before.

Thanks in advance.

Greetings Tobias

Accepted Solutions (0)

Answers (1)

Answers (1)

Daniil
Active Contributor
0 Likes

Hi Tobias,

Die LB Erstellung läuft durch SMQ2.

It could be some error during WT creation, lock or stock shortage or whatever, and therefore you had an error queue in SMQ2, this queue can be automatically started again.

You can check how often RSQIWKEX is running in the background. Maybe it is once per hour, or once per day.

You can as well try to check SLG1 for external identifier WMDPPDO000180838420* or WMDPPDO*180838420*

maybe you find some error records in the log.

BR,

Daniil

0 Likes

Hi Daniil,

thanks for you quick response. The RSQIWKEX is running every 2 minutes. 🙂

I have checked the SLG1 again with the external identifier *180838420*.

Sadly no error records.

A lock on one of the involded storage bins is possible. But that would mean that

it's a regularly reapearing lock that opens up from time to time. 🙂

One thing i forgot to mention in my orignial post is that all the warehouse tasks for the 39 inbound deliveries which didn't worked properly where created roughtly at the same time at 12:05 over span of like 15 seconds.

Very weird. 🙂

Greetings Tobias

Daniil
Active Contributor
0 Likes

Hi Tobias,

One thing i forgot to mention in my orignial post is that all the warehouse tasks for the 39 inbound deliveries which didn't worked properly where created roughtly at the same time at 12:05 over span of like 15 seconds.

For me it looks like SMQ2 to check 🙂 Easiest way probably would be to define variant in the warehouse management monitor where you select all deliveries which are created more than 5 minutes ago and Planned Picking status is still 1.

If you found such a delivery you can take a look into smq2 to see what is going on there.

Or if you do not have a lot of records in SMQ2 you can just check it from time to time.

There are some possible problems, like Performance bottleneck for example could lead to not processed queue, but since you said that other deliveries were processed it shouldn't be performance issue.

You can check logs of the RSQIWKEX , I guess it writes Queue names which are restarted. At least at 12:05, maybe you'd see what was previous status. But it could be some issues with a planner itself which could be corrected with OSS Notes.

And you can activate SMQ2 trace as well to see what happens there.

BR,

Daniil