Deletion of Internal PoD

former_member199650 · ‎2014 Jul 01

Hi All,

Can you please guide me whether we can delete the internal PoDs or not as these are getting created as and when any utility installation is getting created?

Can the deletion of internal PoD create any discrepancy? Is it recommended?

If we can delete the internal PoDs, then please guide how?

Also, please guide whether we can restrict the internal PoD to get created at the time of creation of new utility installation.

Also guide about the following point please:

If the internal key for PoD no. which is getting stored in the table EUIINSTLN and in table EUIHEAD with only EUIROLE_DEREG = 'X' whereas table EUITRANS is empty, then can we say that we have PoDs maintained in our system?

Please guide.

Thanks and Regards

william_eastman · ‎2014 Jul 17

Why do you want to delete the internal pod? These are valid for deregulation processes, interval data processes, and CRM integration. Are they invalid or causing an issue?

NTeunckens · ‎2015 Sep 17

Hi Mahavir

Did you get your requirement adressed in some way?

We too have some (limited) inconsistencies regarding the Technical Objects Replication from our IS-U to CRM (7.0 EhP3) ...

In my case we see wrongfully assigned Installations (ANLAGE) connected to the Premise (VSTELLE) in CRM (through PoD EUIHEAD table) while the IS-U records are correct (table EANL holds the correct Premise & Installation) ...

What I've been able to test so far in our QA :

As of ECC 6.0 ISU 617 EhP7 Transaction "ES64" provides a means to Re-Allocate a PoD to a Premise / Installation. In our QA-system I managed to reassign a new PoD, connecting the right Premise with the right Installation ...
However, the 'incorrect' PoD is still present in the tables, thus still appears in the WebUi Interaction Center ... I haven't found a way to 'delete' this incorrect PoD as of yet, but I stumbled on :
- Some SAPNotes indicating programming errors could reside in trx. "ES64", possibly enabling the correction together with a delete of the 'incorrect record' through a program correction?
- Report "ECRM_ISU_DELETE_TECHOBJ" indicated that 1 Installation could be deleted ... I'm checking with our BASIS-team whether I'm granted permission to execute the program in a non-testmode so I can see whether this report picks up the incorrectly linked Installation ...

I'd be very interested to learn how to address this issue because in my case (as in yours?) it's clear that the original PoD is faulty. There's a real business need to 'disconnect' this link ...

SAPNotes that could be of interest :

1810101 - IS-U: Reassigning a point of delivery to a new premise
1771112 - ECRM_ISU_DELETE_TECHOBJ does not delete historical data
2077489 - ES64 no Replication of Point of Delivery (POD)
1872576 - CRM-IU: No update of technical objects after reassign in transaction ES64
2117005 - ES64: Search for PODs via EXT_UI shows two connection objects

Hope all of this is of any help.

If you or anyone else could confirm or elaborate these findings, it would be much appreciated ...

Kind regards

Nic

Former Member · ‎2016 Sep 02

Hello,

did anyone ever find a solution to this issue? We have tried using the report ECRM_ISU_DELETE_TECHOBJ, but it deletes the whole Installation with all pods only in CRM. All is as before in ISU. Deleting the whole Installation is not appropriate since usually only single pods are obsolete.

We could move them to another dummy Installation and then delete that Installation. This still leaves ISU untouched.

Changing elements in IB52 is possible, (cutting out single pods) but the Change is not reflected by is-u?

We will open an oss for this issue but I assume there must be a way to do this already, Rendering this into a Consulting issue rather than a shortcoming of SAP functionality.

Thanks in advance,

Greetings,

Lutz Morrien

NTeunckens · ‎2016 Sep 02

Hello Lutz

Our issue is (partially) resolved by :

Applying a new Note 2358981 which updates the CodeBase in prgr. "ECRM_CORRECT_PREMISE_POD" as a result of our created SAP Incident ;
Our CodeBase for the ISU trx."ES64" was not up to snuff. Introducing Notes like 2133048 has removed some of the inconsistencies we experienced ...

Down to it's core, we found "EUIHEAD / EUIINSTLN"-table is not always populated with the actual Techn.Objects ... Note 2358981 should enable you to correct this via the report "ECRM_CORRECT_PREMISE_POD", rather than deleting stuff via report "ECRM_ISU_DELETE_TECHOBJ" ...

PS : Trying to foresee the inconsistencies is hard ... That's why we're looking into the CRM "Utilities Check Cockpit" (UCC) as a Monitoring Tool => see info on SAP-Help and SAP-SCN ...

Hope this is of some value ...

Former Member · ‎2016 Sep 05

Hello Nic,

thank you for your response. I have had a look at the sap notes you mentioned. They are interesting, but our goal is to delete inconstistant pods. They can not be fixed, they are just obsolete.

ES64 and the Report ECRM_CORRECT_PREMISE_POD are aiming at correcting the pod / Installation in ISU.

Will keep you informed on the results.

We have UCC up and running. There are three built in checks for pods and connobjs.

One Displays entries in ECRMREPL and two Focus on inconsistencies.

None of these two find errors in our system.

Greetings, Lutz

NTeunckens · ‎2016 Sep 14

Hello Lutz

OK. Yes, I have the same experience in running "ECRM_ISU_DELETE_TECHOBJ", deleting the whole bunch of linked Objects in CRM.

After testing in Sandbox, I could use "ECRM_ISU_IMPORT_TECHOBJ" to re-create the 'correct' PoD's, leaving out the erroneous PoD. This should work, although somewhat cumbersome.

I do not have another solution right now ...

Kind regards

Nic Teunckens

Former Member · ‎2016 Sep 14

Hello Nic,

the issue was somehow solved by SAP Support. We created a dummy connobj in ISU, then moved the obsolete pods to a premise in this connobj by Transaction ES64.

Afterwards the old connobj is correct. The pods however remain in a data graveyard.

Since this graveyard does cannot be selected by mistake in CRM, the solution was accepted by our customer. This approach was proposed by SAP.

Greetings,

Lutz Morrien

NTeunckens · ‎2016 Sep 14

Thanks for that reply, Lutz.

I'll keep that procedure in mind when we face similar issues ...

Regards

Nic