Hi all,
Id like to analyse the number of PO items which have been created for one and the same PR, e.g. PR 12341234 is related to 5 PO items. I tried using the pull function but always when combining PO item data with PR data from table EBAN I get following error message: Undefined exception occured. Table EBAN is not a parent of EKPO. Use non pull up function instead.
I guess this should be an easy formula but unfortunately didnt figure out how to achieve the result Im looking for.
Any ideas?
Thanks, Oli
Page 1 / 1
Hey Oli,
Disregarding the error you are getting, the way the EBAN Table is structured (Primary Key: MANDT, BANFN, BNFPO) and the way it references to the EKPO Table (MANDT, EBELN, EBELP --> Primary Key EKPO) it is not possible for one EBAN item to point to more than one entry in the EKPO, thus meaning it is a 1:1 OR N:1 (EBAN:EKPO) relationship. So there could possibly be 1 or more PRs for one PO, but not 1 or more POs for one PR.
The is only one, very unlikely, case that in your system the EBAN reference only to EKKO by leaving the EBELP entry empty, then you just need to count the entries for the respective EBELN.
What you maybe mean and looking for is how an EKPO entry can interact with the combination of AUFK / AUPO and that a single EKPO entry can be split to multiple entries, or the other way around, how many small orders can be consolidated to one bigger order.
I hope I could clarify the topic a bit,
Best Regards,
Benedict
Disregarding the error you are getting, the way the EBAN Table is structured (Primary Key: MANDT, BANFN, BNFPO) and the way it references to the EKPO Table (MANDT, EBELN, EBELP --> Primary Key EKPO) it is not possible for one EBAN item to point to more than one entry in the EKPO, thus meaning it is a 1:1 OR N:1 (EBAN:EKPO) relationship. So there could possibly be 1 or more PRs for one PO, but not 1 or more POs for one PR.
The is only one, very unlikely, case that in your system the EBAN reference only to EKKO by leaving the EBELP entry empty, then you just need to count the entries for the respective EBELN.
What you maybe mean and looking for is how an EKPO entry can interact with the combination of AUFK / AUPO and that a single EKPO entry can be split to multiple entries, or the other way around, how many small orders can be consolidated to one bigger order.
I hope I could clarify the topic a bit,
Best Regards,
Benedict
Thanks for your reply Benedict!
You are right, there shall be no cases where one PR item is referenced in different POs. However, those cases occur unfortunately anyway from time to time in our SAP systems and thats the reason why we want to analyze those undesired cases with Celonis.
The SQL statement to analyze those cases would probably look something like that:
Select * for EBAN - EBELP
Where
Count of (EKPO - BANFN = EBAN - EBELN
&
EKPO - BNFPO = EBAN - EBELP) > 1
Can you help me translating that to PQL so that I can analyze based on PR item level the cases which have a 1:N relationship (EBAN:EKPO).
Thanks in advance, Oli
You are right, there shall be no cases where one PR item is referenced in different POs. However, those cases occur unfortunately anyway from time to time in our SAP systems and thats the reason why we want to analyze those undesired cases with Celonis.
The SQL statement to analyze those cases would probably look something like that:
Select * for EBAN - EBELP
Where
Count of (EKPO - BANFN = EBAN - EBELN
&
EKPO - BNFPO = EBAN - EBELP) > 1
Can you help me translating that to PQL so that I can analyze based on PR item level the cases which have a 1:N relationship (EBAN:EKPO).
Thanks in advance, Oli
Hey Oli,
The EKPO.BANFN never (logically correctly) equals the EBAN.EBELN field,
its either EKPO.BANFN = EBAN.BANFN or EKPO.EBELN = EBAN.EBELN.
Id recommend Creating an OLAP Table with these informations:
Dimensions:
EBAN.BANFN
EBAN.BNFPO
KPI:
COUNT_TABLE(EKPO)
And then sort by the KPI descending and see if there are actually cases, that match your thought process. What also would work, is using only EKPO, like this:
Dimensions:
EKPO.BANFN
EKPO.BNFPO
KPI:
COUNT_TABLE(EKPO)
Its basically like a SQL script saying
SELECT BANFN, BNFPO, COUNT(1)
FROM EKPO
GROUP BY BANFN, BNFPO
Best Regards,
Benedict
The EKPO.BANFN never (logically correctly) equals the EBAN.EBELN field,
its either EKPO.BANFN = EBAN.BANFN or EKPO.EBELN = EBAN.EBELN.
Id recommend Creating an OLAP Table with these informations:
Dimensions:
EBAN.BANFN
EBAN.BNFPO
KPI:
COUNT_TABLE(EKPO)
And then sort by the KPI descending and see if there are actually cases, that match your thought process. What also would work, is using only EKPO, like this:
Dimensions:
EKPO.BANFN
EKPO.BNFPO
KPI:
COUNT_TABLE(EKPO)
Its basically like a SQL script saying
SELECT BANFN, BNFPO, COUNT(1)
FROM EKPO
GROUP BY BANFN, BNFPO
Best Regards,
Benedict
Thanks - the second option (using only EKPO fields) actually works and shows exactly the cases we were looking for. Thanks for the always fast and great support 
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.