cancel
Showing results for 
Search instead for 
Did you mean: 

Identical Specs in Hitlist

Former Member
0 Kudos

Hi Everyone,

I'm running into a very odd problem.  This issue has occurred twice in the last two months and I have no idea what could be causing it.  We are getting identical entries in our hitlist for the same spec.  This is not a duplicate spec issue, but rather the same exact spec is showing up twice in the hitlist.

When I look at the table ESTRH I can see that there are two entries with overlapping dates, but I have no idea how or where to begin searching to figure out how this could happen.  Below is a screen shot of the table.  This seems to be triggered by using a copy template to pull data into a VAT from another spec.

Has anyone else seen this before?  Does anyone have any theories about what causes this?  Thanks in advance for any help.

- Jason

Accepted Solutions (0)

Answers (1)

Answers (1)

christoph_bergemann
Active Contributor
0 Kudos

Dear Jason

you did not attach the tables (ESTRH) entries. I can remember that in EHS 2.2 or something like that something similar has come up. I am sorry to say that this "odd" situation is quite long ago. What I can remember is this

a.) you use one database (this is mandatory)

b.) you use more than one application server (this is optional: one application server is minor: most companies use more than one to handle the "load" balance of many user actions)

With EHS 2.2 (a or b) some issues (similar kind) come up. To give you some understanding in that: the whole SAP tries to generate"unid" ID. Thererfore the application server get a "reserve" of numbers. long ago this mechanism was not stable Therefore the same number was on two servers. Now by some stupid user action one user was logged on via application server one and the other user logged on via application server 2 and they generated nearly in the same time a new spec. Then something like that happened

Never ever heard about it in our days.

With out the entries in ESTRH no additional help or idea can be provided. Do you use "Change numbers"? How do you generate "normally" a new spec. With reference from old spec (copy data from old to new) or just do it?

So first question: which user id generated the specs? Same one?

I assume both specs have been generated by user action and not by spec import?

There is a very special abap report availble to check "RECN" consistency. May be: RC1SUB_HIERARCHY_SHOW EHS: Display Hierarchy of All Relevant Objects for a Substance - SAP Report - ...

Try to use this report wiht both specs.

I hope that you: do not use ALE, SVT, DG, MSDS distribution, GLM  etc. and we talk about dev and qual system. For prod system this can be a "disaster". and you might get additional trouble.

C.B.

PS: in regards of:

This seems to be triggered by using a copy template to pull data into a VAT from another spec.

Can out please try to do the same once again? Did user used two sessions? And trying to create new spec using the same "old" one?

PPS: quite interesting ...

Former Member
0 Kudos

Thanks Christoph.  We're using EHS Management 2.7B.  We're on ECC 6.0 EHP 6.  We will be moving to EHP 7 in the next few weeks (hopefully).  I'm going to attach an image of the ESTRH entry for this.  We only have one application server, so I'm guessing this is a date overlap issue vs. an actual duplication issue.  I hope the image helps.  Currently when this happens we create a new spec and manually copy all the data into the new spec from the old and then delete the old spec.  When we create specs it's always manual (not from a copy from), but once we create the spec we do utilize the copy templates and inheritance templates.

Thanks,

Jason

Mark-Pfister
Active Contributor
0 Kudos

Dear Jason,

Unfortunately I have seen this before - and I currently face the same situation. (Not with copy template, but tons of older custom coding involved)

What I found strange from your screenshot is, that the first created record (the one without an ACTN) is not valid from the begin of time (01/01/01) but from the 06/09/2014 - and this without having a change number!
The CRDAT and CRNAM are empty as well which is normally not the case.

The only way to figure this one out, is to find a reproducible scenario that always leads to this DB inconsistency.

Once you have the reproducible scenario, check if any custom coding is involved at all.

If no, open an OSS note - if yes switch of the custom code and check if you can still produce the error.

Regards and best of luck

Mark

Maybe this is the Problem :


Jason King wrote:

We're using EHS Management 2.7B.  We're on ECC 6.0 EHP 6.

EH&S 2.7B was/is only available up to 4.6C - see OSS Note 122400.


christoph_bergemann
Active Contributor
0 Kudos

Dear Jason

as mentioned by Mark: if you use ECC 6.0 EnhPack 6 or 7 you don't use EHS 2.7b; starting with ERP 204 there is no EHS version numner any more in place.

But coming back to your topic:

ESTRH does have two fields which are "significant", RECN and ACTN; as they are different there is no issue. The "Issue" is: the RECn and RECNROOT of both sepcs is the same; never seen that.

Can you provide some ideas: My assumption is that the change number used "J1400436"  is valid

06/09/2014; As well I assume that the second line is created on "06/04/2014"; As i do not know your "date" format: I can only assume something: 06/04/2014 could mean "06. April" or "4. June"

E.g. 06/09/2014 could mean 6 of september; therefore somebody has maintained data in the future. The "maintenance" date would be "06/04/2014"; the first line does not have "CRDAT" etc. Something like that I have never seen. What we can imagine is that "UPDdat" is 12/04/2014 which is later as 06/04/2014 and indicates that somebody has maintained on the top.

My advice to you is now: you need to check the "change log" of both specs. It is "very" important to get some idea if the first line has been created as well on 06/04/2014

As I have not use changes numbers for a long tiomeI am not sure of the first line need to have a "change number" or not. But what is "curious" is that ACTN is "0".

So the first challenged is to "detect" if nboth specs might be created on same date and by whom (user id). can you chcek e.g. assigned identifiers? If you can detect that there is indication that first spec is as well related to userid: JPLEITNE this would help. Than you need to ask this user: what was your process to genearte your "spec"?

Quite interesting topic really

C.B:

PS: tipp of Mark is important:

Once you have the reproducible scenario, check if any custom coding is involved at all.

You need to identify: do you use standard CG02 or do you custom coding to generate new specs

PPS: if you use change numbers: the use of the "key" date is crucial in daily maintenance;  long ago we have done some experiments with EHS 2.7 and the "Change number"; based on the results we found we decided never to use the "change number" in CG02;

Mark-Pfister
Active Contributor
0 Kudos

Hello Christoph,


ESTRH does have two fields which are "significant", RECN and ACTN; as they are different there is no issue. The "Issue" is: the RECn and RECNROOT of both sepcs [records?] is the same; never seen that.

IMHO this is correct:

For DB Table ESTRH or RECN and RECNROOT are always the same (For all other EHS table the have to be different).

This does not change when you create "records splits" / use change numbers.

But maybe I misinterpret what you mean:
I'm not quite sure waht you mean by "both sepcs" - for me the two records are for the same Specification / SUBID = 200*10886.

Regards

Mark

Former Member
0 Kudos

Mark you are correct that the two entries in the ESTRH table are for the same spec.  I will work to reproduce this issue and do as you suggest by making sure there is no custom code causing the issue.  Thank you both for your assistance and advice. 

christoph_bergemann
Active Contributor
0 Kudos

Dear Jason / Dear Mark

I have checked our system. My last experiencee with the use of "Change numbers" was too long ago. Sorry.

So Mark: yes you are "right" and "wrong". Thanks for highlighting my "error" in thinking.

This is the story:

Let us assume you have the specification 2*10886 (as in your system). You have created this spec using normal process in CG02. Now you use a "change" number on this spec (e.g. you would like to change the color etc.); after save it seems to be that changenumber etc. is populated back to ESTRH and giving rise to two lines (as explained: my experience in using change numbers is quite old; we have had too many trouble in daily use).

Now Mark is right:

In ESTRH you must get two entries (as in your example); what is correct is as well that RECN/RECNROOT must be the same for both lines (this was my error !)

.

But now the difference is coming up:

The "old" version will get "ACTN" = 0 and the new version will get a "ACTN" from number range. So this is the correct behaviour as shown by you. But the data record with "ACTN = 0" will not get the "Change number" field populated; Here Mark is not right (according to the example I found in our system).

Now something "strange" happened. The data record "ACTN = 0" is valid within the same time period as the second one. This is "wrong". Normally the value"until"  to should be 06/09/2014 - 1 day. This does not happen in your example. VALFR is the same for both lines. On the top (this was highlighted by Mark) it is not allowed to have a "CRDAT" and "CRNAM" empty

If you now look from perspective CG02: both ESTRH lines are valid in teh same time period and therefore you get two lines in CG02 as shown. EHS can not react different. The field "spec id" is not something which does the values "distinct";

What could give rise to something like that? To answer this question it is quite critical to get an idea about first line of ESTRH as mentioned analyzing the "change logs". As shown in the figure: somebody must made an update on first line (UPDNAM = LNELSON and secondline UPDANAM = ACKER).

Therefore Jason: can you shortly answer this question:

- Has the spec 2*10886 be created using CG02 and then somebody used a changenumber in context of this spec?

- As there is some "indication" that you might have created the spec by using "copy"/"Inheritance" technique: can you figure out which source spec was used, which template was used and if on source spec a "changenumber" has been used?

- please help me in your "date" format: is "06/09/2014" = 6 september or 9 June of 2014?

The reason is: i have still some issues in understanding the "CRDAT" of second line in ESTRH

If 06/04/2014 is 6 of April then the first line seems to be more "logic" as there UPDDAT is 12 of april (if my assumption is correct)

.

Quite interesting topic; indeed

C.B.

Former Member
0 Kudos

Spec 2*10886 was created in transaction CG02BD and then a copy template was used to pull data into certain VATs.  I've asked the developer to tell me what spec was used as a copy from as well as the copy template and I'm awaiting a reply.  Our date format is MM/DD/YYYY so 06/09/2014 is June 9th, 2014.  I can tell you that the only reason the change number is associated with this record is because the spec was assigned to the material using that change number via the material master. 

christoph_bergemann
Active Contributor
0 Kudos

Dear Jason

we come closer to the "error". PLease check this;:

a.) use se16 with ESTRH and look for any data record there "Changenumber" not empty; please ignore "delflag"; we need all data records; it is important to check if any "similar" entries are related to "changenumber" and it is important to identify if always a material was linked to spec and in this context the change number was used

b.) copy any RECN you find to clipboard go back in ESTRH and check all ESTRH lines using the RECN numbers from clipboard. Using this approach you might get the numbers of "similar" issues

c.) do you make the link to material using "Cg02bd" or using "mm02"??

I still have the feeling that the use of the "change number" is the reason for this strange effect. I am not sure if really the "copy"(using inheritcance) is the issue; normally (as you seems to have done it) you can create a new spec using "reference via "interitance template" to an old spec; any data (according to template) is the "moved/copied" to new spec.

Based on your feedbeck we can assume this: on 04 of june you create the new spec; on 09 of junes somebody maintained something on this spec using change number.

But be need more info regarding first line of ESTRH; it sis quite important to check if there is any identifation on "lower data" level that user "JKING" has "done". Originally user  JPLEITNE create the spec; i "assume" that user JKING used the change number on 9 of june giving rise to the split; but afterwards and different user changed first line (update on 4 of december)

Quite interesting topic ! Recommenation to you: for both lines you should set "del" flag via debug replace and run correction reports; i hope this is not an example from prod because then you have trouble. My expectation is that non "subsequent process" can run; e.g. not SDS distrbution, nor SVT, nor GLM nor... because both ESTRH entries are valid at the same time.

The main issue with line "one" is: we need more indications that this line was in the system since 9 of september. Can you check change logs ? This might help

C.B.

PS: check corresponding ESTMJ entries related to ESTRH lines as well; if possible please show picture

PPS: did you enhance CG02/cg02BD by using the existing options ? (Exists or BADis?)

As mentioned by Mark (on some level) if you do not properly us the APIs/BAPIs in customer related coding etc. you will get a "mess" in EHS !

christoph_bergemann
Active Contributor
0 Kudos

Dear Jason

any update on this? Could you provide insight if you have solved the issue?

C.B.