cancel
Showing results for 
Search instead for 
Did you mean: 

Block PGR if PO is blocked in GTS

0 Kudos

Hi Experts,

with ref to a blocked PO in GTS when we do PGR via MIGO, my expectation is that the PGR should be blocked.

Currently we are doing upgrade of GTS system from 8.0 to 10.1 & ECC upgrade from previous R/3

What we see is in old system PGR is getting blocked, but in case of ECC we dont get any block and PGR is allowed.

Can some one please suggest if this is a standard functionality in ECC / GTS10.1 or do we need to changes in BADI for same.

Please  find below details with my analysis and probable root cause

FM /SAPSLL/CD_STATUS_GET
is getting called under MIGO.

In Release4.6 C under FM:  /SAPSLL/CD_STATUS_GET another FM CALL FUNCTION 'SLL_LEG_CDPIR3_001'   is being called to get the value for flag CUSRV_r3 lsmes_r3, idxrc_r3.

Screenshot 1

Once the FM execute code control checks whether the doc
should be blocked for PGR or not.

However in case of ECC once the FM executes there is call
for BADI MM0A,then it checks  whether the
doc should be blocked for PGI or not.

It seems BADI should not be called in case of PGR because
this BADI should only be triggered when we are changing the PO. Triggering the
BADI results in clearing the flag gs_transfer-cusrv_r3 due to which blocking of
Document while PGR is not done hence it allows to do PGR although it should be
blocked.

Screenshot 2

Not sure why the new code in ECC is designed to call MM0A BADI while doing PGR

Regards,

Santosh

Accepted Solutions (0)

Answers (4)

Answers (4)

former_member194424
Active Participant
0 Kudos

Hello Santosh,

We're upgrading to 10.1 as well but I see different code in FM /SAPSLL/CD_STATUS_GET and this does prevent PGR.

Thanks,
Satish

0 Kudos

hi All,

Thanks for the inputs.

@ Satish - In my ststem when /SAPSLL/IF_EX_CTRL_MM0A_R3 badi is called values for

ls_ekko & lt_ekpo are blank. further we are having custom code in this BADI which is clearing CUSRV_R3 if the ls_ekko & lt_ekpo are blank.

If in case the block is working for you I hope you would be getting values in ls_ekko & lt_ekpo.

Can you please confirm.

@Dave - As this blocking functionality is working in R/3 - GTS8.0 we were testing if same is available in ECC/GTS10.1 Your question is valid enough because even if the PO is blocked goods would have already arrived at plant gate. At this point only business justification is to have compliance controller play a major role to have his reports updated that the goods are arrived inspite the PO being blocked. We are also cross verifying with business how this was useful in older version.

@Mouaz  BEN REDJEB / Dhilipan -

CUSRV_R3 is getting cleared only in case of PGR for PO transfer we are getting values in ls_ekko & lt_ekpo and CUSRV_R3 is not cleared.

Regards,

Santosh

former_member194424
Active Participant
0 Kudos

Hello Santosh,

I have exactly the same problem so I had to alter the code in my BAdI implementation. SAP is passing internal tables to the BAdI but they're all empty (except document number, purchase org).  Use these 2 data elements to populate the ekpo in BAdI implementation and CUSRV_R3 might be set to the correct value.

If you need more details, let me know.

Thanks,
Satish

former_member215181
Active Contributor
0 Kudos

Hi Santosh,

I don't think I need to contribute further to the technical discussion here, but for my interest - and perhaps that of other readers - could you please explain the logic of wanting to block the GR for a non-compliant P.O?

Please explain the business thinking, perhaps with an example.  And also suggest what should be done with the goods whilst the GR cannot be performed - thanks.

Regards,

Dave

0 Kudos

hi Dave,

With further discussions with Business the scenario is now clear. Business requirement is if we have a PO that is not initially blocked in GTS, but then before the material is received in plant if vendor gets on SPL list PO will be subsequently blocked during any change or while PGR. Now as per legal agreements business is not liable to pay the vendor even if the goods are arrived at plant.

So requirement is either we block payment processing MIRO for this PO or we block GR so that the blocked vendor gets noticed.

We have also seen that in standard GTS 10.1 there is no block for GR against blocked inbound delivery. Now requirement is given to develope a routine to block PGR

Just thought to have your view point and also need confirmation if std GTS is blocking PGR for inbound delivery or not.

Thanks & Regards,

Santosh

former_member194424
Active Participant
0 Kudos

Hi Santosh,

If the vendor is later on SPL, you must screen the documents with delta SPL so the PO is blocked. In standard SAP, MIGO & MIRO are not allowed for blocked POs. To prevent PGR from inbound delivery, you must write a VOFM routine. Call FM /SAPSLL/CD_STATUS_GET to get the status of the document from GTS.

Thanks,
Satish

mouaz_benredjeb
Contributor
0 Kudos

Hello Santosh,

FM /SAPSLL/CD_STATUS_GET has been updated with following OSS note:

1936839 - BAdI interface and user exit function module EXIT_SAPLSLL_LEG_CDPIR3_001 are not used consistently

In my opinion, this update is a good news as now FM /CD_STATUS_GET is consistent in terms of user-exit and BADI (before the update, only the user-exit was called within the FM). I had struggled in the past due this non-consistency.

From you post, I understand that you have implemented the BADI /SAPSLL/IF_EX_CTRL_MM0A_R3.

After OSS note 1936839 is implemented in ECC, the BADI implementation will be called within following 2 FMs:

- /SAPSLL/CD_MM0A_R3 (Transfer of PO to GTS)

- /SAPSLLCD_STATUS_GET (Retrieval of document status in GTS)

As the BADI is consistently called for the 2 FMs, hence the transfer of the PO and the status retrieval of the PO status are consistent too: either no PO goes to GTS or the PO goes to GTS and you can get its status.

As you have done an ECC and GTS upgrade, I would recommend that you test with a brand new PO to check this consistency.

Regards.

Mouaz BEN REDJEB

0 Kudos


hi Mouaz BEN REDJEB,

Thanks for the reply ...

yes we have implemented BADI - /SAPSLL/IF_EX_CTRL_MM0A_R3 and flag CUSRV_r3 is getting cleared inside this BADI, because of which the standard logic for blockling PGR is not getting executed.

we would like the PGR to be blocked. in this case should we modify the BADI implementation code so as the flag should not be cleared for PGR scenario. Here we are not able to diffrentiate how we can identify if the BADI is getting triggred for PGR or PO transfer/change.

Regards,

Santosh

mouaz_benredjeb
Contributor
0 Kudos

In my opinion either:

- CUSRV_R3 is cleared for both the PO transfer and the PGR

or

- CUSRV_R3 is not cleared for both the PO transfer and the PGR

Or may be you have a business scenario that does not fit in what I have wrote above ?

Have you tried to create a new PO and process it till PGR ?

Former Member
0 Kudos

Hi Santosh,

If the MM0A badi is clearing CUSRV_R3, it means the BADI is not considering PO document type for Compliance management. So, the question is how did the PO got replicated in GTS the first time when it was created.

If I am not wrong, the PO should not be transferred to GTS right? if the BADI is clearing CUSRV_R3. The same BADI is going to be called when PO is saved.

Can you please check and confirm?


As Mouaz said, CUSRV_R3 should be cleared/not cleared for both the PO transfer and the PGR. Not like what you are experiencing( Not getting cleared while PO transfer and getting cleared while PGR).

Regards

Dhilipan

thomasrausch
Active Participant
0 Kudos

Hello Santosh,

have you installed the newst plug in (SLL_PI 900_604 0015 SAPK-90A15INSLLPI GTS-Plug-In).

Regards

Thomas