Help! WO's status was changed to 91.

[Nancy_x]

Help! WO\'s status was changed to 91.

Hi, list,

Yesterday, most of our Work Orders' statuses were changed to 91 (including all the Work Orders with status of "10,40, some of 45, some of 95"). We can not find any evidence from F4801, it left no trail in this table. We could not find out how it was changed.

Does anyone has this kind of experiences? Which interactive or batch version can change the Work Order status except P48013?

Thanks for any responses.

 

[DSD]

Re: Help! WO\'s status was changed to 91.

Greetings Julia X!

You can make use of R31410 where the desired status can be set and Work Order Status Can be changed to the required status.
Hope this Helps.

Dhanu

Functional Consultant

 

[Saskia]

RE: Help! WO\'s status was changed to 91.

Hi,

Indeed one of my customers experienced this 3 times (also on 8.9). In the end we determined that the R31802A was causing this. We hade one version that was not updating the status (so dataselection on all status below production complete), the processing option was for status update was thus empty.

The first time the problem was (temporarily) removed, by submitting the specs of all the R31802A versions that were running in the batch again to the server. For two weeks the problem did not occur. I did not understand what was the reason that this solved the problem as processing options should not be kept in a table and nowhere else. I discussed it with various of my colleagues (including CNC-consultants of PSFT), some even laughed at me. I dropped the issue as I did not find any ground for it and could not reproduce.

The next time, I was able to reproduce the problem and could pin-point the correct R31802A version. Submitting specs solved it again. After doing that I could not reproduce the problem, as I still do not know the cause.
Two days later it happend again. I then decided, to create a version of the R31802A for each status that was in the data-selection of my original version and selected only on this status and put the processing option for status update on that status value.

The problem did not occur again (the last two month). Of course this is a work around, but as I had no solid case to present to the helpdesk I decided to leave it alone.

If there is anybody who is able to believe that submitting specs changes something somewhere for processing options, I would really appreciate to discuss this, as the sole fact is sometimes giving me the creeps.

Hope that this helps you and I would really appreciate to hear from you when you do find the cause.

Saskia

 

[Saskia]

Re: Help! WO\'s status was changed to 91.

Hi,

Indeed one of my customers experienced this 3 times (also on 8.9). In the end we determined that the R31802A was causing this. We hade one version that was not updating the status (so dataselection on all status below production complete), the processing option was for status update was thus empty.

The first time the problem was (temporarily) removed, by submitting the specs of all the R31802A versions that were running in the batch again to the server. For two weeks the problem did not occur. I did not understand what was the reason that this solved the problem as processing options should not be kept in a table and nowhere else. I discussed it with various of my colleagues (including CNC-consultants of PSFT), some even laughed at me. I dropped the issue as I did not find any ground for it and could not reproduce.

The next time, I was able to reproduce the problem and could pin-point the correct R31802A version. Submitting specs solved it again. After doing that I could not reproduce the problem, as I still do not know the cause.
Two days later it happend again. I then decided, to create a version of the R31802A for each status that was in the data-selection of my original version and selected only on this status and put the processing option for status update on that status value.

The problem did not occur again (the last two month). Of course this is a work around, but as I had no solid case to present to the helpdesk I decided to leave it alone.

If there is anybody who is able to believe that submitting specs changes something somewhere for processing options, I would really appreciate to discuss this, as the sole fact is sometimes giving me the creeps.

Hope that this helps you and I would really appreciate to hear from you when you do find the cause.

Saskia

 

[Nancy_x]

Re: Help! WO\'s status was changed to 91.

Thank you, Dhanu

I know R31410 can change Work Order Status, but there is only a few people can access to this report. If someone used R31410 to make the changes, the F4801 will record the PID, USER and dates. But the fact is that no this kind of evidence, it seems only the field SRST is changed. We can make sure that no one want to make this change, it must be an operation by mistake or something others. It is the second time that occurred.
I have no method to change it back in database but have to change it back manually. No one knows when it will be changed to 91 again.

 

[Nancy_x]

Re: Help! WO\'s status was changed to 91.

Hi, Saskia

What you mentioned is very important to me. I'm wondering that it must be a person who can do global update made this error. That day the cost account did several reports, I asked her the result, and her answer is: It could be no better. But I still think the reports she submitted should be checked.

I will do some investigations tomorrow in our real environment. Thanks again, I'm appreciate your help. We can discuss this later.

 

[JCJN]

Re: Help! WO\'s status was changed to 91.

Greetings Julia,

Although I am not directly familiar with 8.9, perhaps a World perspective can give some ideas.

In my mind, one of the Accounting programs is the most likely culprit. Both the WIP and Variance Accounting programs (31802 and 31804, respectively) have a Processing Option (your "Spec"?) that allows the update of the WO Status. They can also be given Data Selection parameters that will limit what WO Status they will affect. These programs are usually run in robot night-jobs. If you have a poorly set-up (i.e. unspecified parameters) version running in this batch, it could have this affect.
You can look at the Item Ledger (4111) for a clue as to whether or not any acct'g programs have touched the affected WO's. In World, the 31802 and 31804 tend to overwrite the USERID, DATE, TIME and PROGRAMID of the IM's (Material Issues) and IC's (Inventory Completions) that they process. I don't know if the same issue ("feature"), exists in 8.9.
Other than the 31410 (as Dhanu mentioned), other programs which can update WO Statuses are 31112 (WO Inventory Receipt, which can call the next), 31113 (WO Inv Issues), 31114 (WO Completions) and 31123 (SuperBackflush, which can also call the previous two). They could easily have similar results.
Another "gotch'a" to watch for (as hinted at above), is sub-versions (versions of programs called by the original program). If you call one, but a specific version is not specified or available, the default is usually the standard "ZJDE" version, which may have completely different specs than what was intended (again, I don't know if this is an issue in 8.9).

My apologies for the lengthy post, hope this helps some anyways...

 

[b_gilmore]

Re: Help! WO\'s status was changed to 91.

Don't know how large your F4801 table is but if it is a UBE that's performing this update you can possibly locate the PDF in the PrintQueue folder on the enterprise server (assuming you don't run UBE's locally) that corresponds to the UBE that was submitted. What you'll want to look for is an abnormally large PDF compared to other PDFs of the same report. You can then track it back to a specific user.

 

[b_gilmore]

Re: Help! WO\'s status was changed to 91.

On the topic of getting the statuses rolled back correctly, you can use Log Explorer (http://www.lumigent.com/products/le_sql.html) to display the updates recorded in the transaction logs for the F4801 and use the before image to determine the previous order status for each WO. You are running Full database logging on the JDE_PRODUCTION aren't you?

 

[Nancy_x]

Re: Help! WO\'s status was changed to 91.

Dear all,

Thanks to Saskia and Normandeau who give us much help, we think we have found a bug in JDE.

Here are some event rules in R31802A:
=======================================================================
SECTION: Work Order Selection Processing [GROUP SECTION] (S1)
=======================================================================
OBJECT: SECTION
EVENT: Do Section
0078 //
0079 If PO szStatusCodeWo is equal to <Blank>
0080 PO szStatusCodeWo = BC SRST (Status Code W.O.) (F4801)
0081 End If
0082 //
.
.
.
0087 // Call the Work Order bsfn to process each work order
0088 //
0089 Work Order Processing

According to the logic of the event rule, if the PO szStatusCodeWo is equal to <Blank>, all the selected WO Statuses will be overwritten to the first record's status that processed.

Solution:
1. Make a version for every status that need to process, just as Saskia.
2. Modify the event rule:
0079 If PO szStatusCodeWo is equal to <Blank>
0080 VA rpt_workstatus = BC SRST (Status Code W.O.) (F4801)
0081 End If
VA rpt_workstatus should be initialized to PO szStatusCodeWo at the beginning. The BSFN (Work Order Processing) should use VA rpt_workstatus instead of PO szStatusCodeWo.

Thanks to all.

 

[Saskia]

RE: Help! WO\'s status was changed to 91.

Dear Julia,

Thank you, for making clear that it was just a simple bug in the
program.

Appreciating your feedback,

kind regards,

Saskia