ESTST Table data issue

[rohan_somji]

Dear All,

We have SAP EHS table ESTST which has surprisingly millions of data. I see this table is used to main status management. But we do not have status management updated in our entire SAP EHS setup. So we are not sure how is the table getting populated. What we noticed was we have 2 status SCCSS and ERROR in table.

In CG02, for every substance we have status tab at header level. But this is empty for every substance but still the RECNROOT is updated in table ESTST with status SCCSS. Somehow we see the table is continuously being updated and we can see business user IDs but they don't seem to know anything about this.

Does anyone know how is the table being populated if we are not using the status management functionality?

If yes then how do we get rid of this data in the table if we are not using it because this is now affecting one of our Expert rules set.

Regards,

Rohan

[christoph_bergemann]

Dear Rohan

quite strange story which you share... any how: you have identified how to solve the topic and get rid of issues

C.B.

[rohan_somji]

Hello Christoph,

Thanks for sending me your detailed analysis. In the last few days I was in touch with SAP and we figured out the root cause. Table ESTST is written when you re-index the data in the Enterprise search and have set environment parameter SP_ES_WRITE_INDEXED_RECNS . This parameter was introduced for analysis purposes due to another topic we had. SAP recommends to clear that parameter after you have re-indexed the data. It would be a good practise to clear table ESTST before you execute the re-indexing. Table ESTST could help us to find the issue of ticket 895738/2022. SAP recommend to unset parameter SP_ES_WRITE_INDEXED_RECNS and clear table ESTST.

So now we have uncheck the Env. Parameter and wrote a small code to delete the table ESTST.

Once again thanks for your support as usual.

Regards,

Rohan

[christoph_bergemann]

Hello

1.) as explained: the "Status" which you show are "not SAP Standard"

2.) According to your feedback: I have understood now that neither "ERROR" nor "SCCSS" is an allowed status according to customizing; this is a very "bad" situation from my point of view

3.) The "issue" is now this:

if you check SPRO we have at least three theoretical options of "reasons" why this is happening (may be we can list more, but these three are "clear" options)

Reason 1 + 2: If you check SPRO you will find two "extension" options in the "Status Management" customizing of EHS; I do not believe that these are used.. but you should check that

Reason 3. My "favorite" is a BADI as part of "core EHS Customizing". This BADI is called if a "save" is done. Check e.g. this: https://answers.sap.com/questions/135783/issue-of-bapibus1077change-in-atsavecheck-of-badi-.html

So my proposal would be: check especial this BADI (and other EHS extension) if you can find active ABAP code

(one of the "Rare" examples discussion the "Status" topic is e.g. this: https://answers.sap.com/questions/12689534/custom-statuses-for-specifications-in-ehs.html

Based in screenshot: whatever coding is used: STOP it.

We have the "ERROR" case and the field "Changed on" is not filled; for the "SCCSS" topic: we have a "Changed on" value and we have a "data origin". This is not a good status. Even if a "technical" process is "writing": there should be always data in "Changed on" / "Changed by" etc.

PS: potential additional reason are the use of "Enhancement Points" in some area.. I did not check.. but you should do that: In the "Enhancement Packages" sometimes SAP delivers additional option. I can not remember options for "Status Management" but check this (to be on safe side)

If you have a "Dev" or "Quality System" there you find the same "strange" data.. you can get in touch with an "experience" ABAPer... Just change data... if the "process" is triggered: you can "stop" using "Debug" in the "Save" process and then you will see all "calls" done (e.g. just may be add an identifier)

I strongly recommend to analye the "Change documents" (better the "Change pointers") using once again an experience "ABAPer". In > 99% of the cases a process is triggered if data is "inserted" "updated" etc. any by analysing one spec and by analysing the "Change pointers (or the EHS special Change log) : may be using the change log you will see the "data" which was "Changed" and "lead" to result as "ERROR"; this might help to understand the potential "E2E" process used

C.B.

PS: what is important (in your analysis): first you need to identify: is this a "synchron" process (result is showing up as part of the "Save" process) or is it an "asynchron" process (so data writing is handled by an ABAP report scheduled as a job)

For the "ERROR" Status: we can "assume" that the status should show issued in a "functional" or "technical" process. The "SCCSS" status: we can only assumed: one option could be we have a kind of simple "Ok" or "Not Ok" status handling (but we need to understand better the "functional" part of the process). So "ERROR" might be mapped to "Not Ok" and "SCCSS" might be mapped to "OK"

[christoph_bergemann]

Hello

to use "Status Management" by "Business User" the Business User need "Access rights". So there must be an "access concept" etc.

Normally we have "Status" like "Released" etc. A status like "Error" or "SCCSS" are "unusual" and according to my knowledge not part of SAP standard (refer to https://answers.sap.com/questions/6636493/specification-status-in-header-specification-workb.html)

But we need to pay "attention". With (i believe) Recipe Management there is a "different" Status (refer to https://answers.sap.com/questions/12980031/specification-header-status-mass-change.html) (here i do not have not enough knowledge about)

Which of the "Status" are in "scope" of your issue?

C.B.

PS: Proposal: please check: which "change documents" exist for the spec number... may be you identify: is there a "further" change at same date/time which "could" be trigger for the "update" of the "Status"

[rohan_somji]

Hello Christoph,

Thanks for the reply.

1. Business has no special rights.

2. In ESTST table we have ERROR and SCCSS. This is what we don't know where is this coming from?

3. I understand the status management of Recipe Management is different that Specification Mgmt. But in SPRO we do not have any status configured which can point towards SCCSS or ERROR. The ones we have in Specify Status are all standard and we do not use them.

4. We do not use status management in CG02. So we never had any entry here.

So we are not sure by which functionality is table ESTST getting updated. It looks more like system generated but how is what are not able to figure out.

I've hidden the Record Nos. in the below screenshot but they are present in our tables.

Regards,

Rohan