0

I'm trying to prevent a user from saving a Purchase Requisition through a BAdI implementation, checking lines and accounts. The error messages I throw do not stop the saving process, and I can't find a way to invalidate the line, as I would in PO's. So, a PR can be saved containing faulty data.

I extended the purchase requisition BAdI and implemented IF_EX_ME_PROCESS_REQ_CUST in ZCL_IM_EI_PROCESS_REQ_CUST. In methods PROCESS_ITEM and PROCESS_ACCOUNT I have access to several imports on account and item. Unlike the PO though, I can't find a way to invalidate an item. None of the classes used offer that functionality.

The PR item objects I have access to in the BAPI are of interface IF_PURCHASE_REQUISITION_ITEM, implemented as a local class in function pool MEREQ. This interface has a method IS_VALID but does not offer anything to invalidate, in contrast to the PO item interface, which has an INVALIDATE method.

edit

After more debugging it seems the invalidation is done through member MY_STATE-BROKEN_RULES from local class MEREQ/LCL_REQ_ITEM. Any idea how I can access this?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Jorg
  • 7,219
  • 3
  • 44
  • 65
  • Is it possible that you mean BAdI instead of BAPI? Or did you really extend a BAPI? This does not seem to make much sense... – vwegert Jun 13 '14 at 07:16
  • And checking the interface, would it be an option to move the logic to the method `CHECK`? – vwegert Jun 13 '14 at 07:18
  • @Jorg I see there is a method `IS_RULE_BROKEN`. Depending on which SAP version you are working with, you could use implicit enhancements to change the behaviour of this method as well as of any method in this local class. I also see there are quite a lot explicit enhancement created by SAP for this function group, as for example `MEREQ_LMEREQD02_01` – Jagger Jun 13 '14 at 07:32
  • @vwegert was right. Didnt move the logic because of missing data, but Check gets called after every BAPI call. There's a flag in there that can be used to declare the line invalid. If you post it as an answer I'll accept it. Otherwise I'll chuck my code in here later. – Jorg Jun 13 '14 at 12:08
  • @Jagger is that smart? The change in behavior is conditional and I cant expand the interface itself. – Jorg Jun 13 '14 at 12:09
  • @Jorg Well if you found a solution with the interface, then it is always better to use a BAdI than an implicit enhancement, so you should take vwegert's advice. – Jagger Jun 13 '14 at 14:10

2 Answers2

1

As @vwegert suggested, the trick was using the CHECK method. It gets called in the validation methods on the PR.

My solution was to add a member attribute FAILED of type MMPUR_BOOL. In all my other methods I can then set this flag on failure:

IF your condition fails
  me->failed = mmpur_yes.
ENDIF.

Finally, my CHECK method contains only

ch_failed = me->failed.

ch_failed is taken back to function module MEREQBADI_CHECK which is in turn used in the is_valid methods of the PR classes. This invalidates the PR and triggers the messages box you see with standard errors. Custom error message in the image below, on save.

enter image description here

Jorg
  • 7,219
  • 3
  • 44
  • 65
0

I've done it using MESSAGE 'My message' TYPE 'E' in the 'PROCESS_HEADER' method.

METHOD IF_EX_ME_PROCESS_REQ_CUST~PROCESS_HEADER.
DATA : it_items        TYPE mmpur_requisition_items,
       wa_item         TYPE mmpur_requisition_item,
       wa_item_data    TYPE mereq_item,
       wa_header_data  type mereq_header.

    it_items = im_header->GET_ITEMS( ).      " Purchase requisition positions
    wa_header_data = im_header->GET_DATA( ). " Header info

    LOOP AT it_items INTO wa_item.                      
      CLEAR wa_item_data.  
      wa_item_data = wa_item-item->GET_DATA( ).

      IF wa_item_data-loekz IS NOT INITIAL.
        MESSAGE 'Raise error' TYPE 'E'.
      ENDIF.
    ENDLOOP.
ENDMETHOD.

Hope it helps.

Nelson Miranda
  • 5,484
  • 5
  • 33
  • 54
  • Do you think raising an error message in such a way, when you use a BAPI, is a good idea? – Jagger Jun 13 '14 at 07:21
  • If it works the same as process_item this won't actually prevent saving. I'm sorry, I didn't try, I found a better way. – Jorg Jun 13 '14 at 12:10
  • Hi, yes it works, I'm sure of it. On the other hand, would you please post your solution on this issue? – Nelson Miranda Jun 13 '14 at 13:50
  • @nmiranda Your code will fail when it is executed for a mass creation of the objects, like for example in case of migration. If there are is at least one object that will trigger the error message, then all the other objects in LUW will not be created. – Jagger Jun 13 '14 at 14:13
  • @Jagger I understand your point however that situation shouldn't happen in this case because the COMMIT won't occur and it won't create/modify the record in the EBAN table. In a mass creation program an exception will raise but you would catch it and move to the other record. – Nelson Miranda Jun 13 '14 at 16:58
  • Checking @vwegert comment I think is the right answer and I should change my implementation. – Nelson Miranda Jun 13 '14 at 17:16