Skip to Content

Business Case:

Most Often Business come across this situation, once a PO is created through a contract they do not want to allow Users or the Concerned to change the Item Prices which are maintained through the conditions of the PO. This will cause the accounting document Posting value issues Once a pricing condition is changed and posted with a MIGO document. The PO condition Types be in changeable mode only when a PO item is in Open condition.

This Blog would help consultants who face such business case and briefly gives an idea about how to develop the solution on the same .

What SAP says on this:

SAP as a standard functionality provides, the condition Types of the Condition Category B will be in Non changeable mode and Others will be on Changeable mode allowing users for a Price change as certain Business requires this change.

 

 

 

How to Achieve this Business Case:

We have two solutions to achieve this functionality

 

  1. Through standard Configuration change at the path

 

MM–>Purchasing–>Purchase Order–>Document Type–>FSK-AKTY /Selection Group –Quantity and Price —>Display

 

However, this change applies to the all the document types and this makes the condition records in display mode. Since this has got its own limitations alternatively we could use the below BADI for the purpose.

2. Alternatively, we can use the User Exit ME_PROCESS_PO_CUST 

What is a BADI and How this functionality can be made:

 The below paragraphs briefly explains the same .

This BADI normally enables the business logic of the ME22N (Enjoy Purchase Order Screen) .Using this BADI we can make

Processing of own objects

Processing of additional data on standard Objects

Additional checks and derivations can be done.

Standard fields change data with ensuring data integrity

Change in field selection.

 

In general, changing the BADI includes the below steps in brief and in Broad.

 

Start of Transaction – BADI method Initialize

Opening of a PO – BADI Method Open

Checking of Data – In this case Item Data of the PO BADI Method Process –Item

Field Selection at Item Rules –BADI Method FIELDSELECTION_ITEM

Overall check —BADI Method CHECK

Post – BADI Method POST .

Concluding Work – BADI method CLOSE .

 

In Order to achieve the functionality of the Purchase Order  Item Conditions non editable since we cannot make the conditions in Grey mode, we can best use of the above BADI to incorporate the functionality which can stop changing the PO item conditions.

 

BADI functionality to be provided:

This change will not allow the User to SAVE the PO document once an Item Condition amount in the PO is changed after a GRN is made and we can make to issue a Message saying that the PO XXXXXXXXXX Item YYYY price is changed and unable to save the PO.

If needed, we can limit the change to the Company Code and or Plant and or for PO Document Types.

For example Purpose I have used the Company code and Plant and Document Type as the Limiting factor as Conditions .

Changes to be done:

BADI : ME_PROCESS_PO_CUST

CLASS : ZCL_IM_ME_PROCESS_PO_CUST

Method : IF_EX_ME_PROCESS_PO_CUST~PROCESS_ITEM

 

IF sy-tcode eq ‘ME22N’.
*–>Check Company Code xxxx for *Description of Company Code
IF lw_header-bukrs = ‘XXXX’.
*–>Check for plant A601
IF ls_mepoitem-werks = ‘YYYY’ AND
( lw_header-bsart = ‘aaaa’ OR
lw_header-bsart = ‘bbbb’ OR
.
* Get Item Conditions
CALL METHOD im_item->get_conditions
IMPORTING
ex_conditions = lt_komv.

ENDIF.
ENDIF.
ENDIF.

 

As soon as the conditions are provided to the BADI,

 

METHOD: IF_EX_ME_PURCHDOC_POSTED~POSTED

 

Write the logic to find out the PO is posted with a GR and if a change is being made to the Item Condition to an item already being posted with GR and after changing the Item condition when SAVING the PO issue an error message GR is already done for PO &, Item &. Do not modify the item prices

 

Once added with the requisite coding System while saving the PO, will identify the Changes to the Items for the Item condition prices and will check whether the PO item is Open for GR or made with a Full GR or Partial GR and allow to change accordingly by issuing the message if not a line item is Open. However as it is earlier said we can limit the effect of this change with the Conditions.

 

 

Conclusion:

The above paragraphs briefly explain and give a broad idea on how the PO items can be protected from any changes for their prices in the conditions Based upon the conditions which we provide.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo

    Nice!  A real live example and one I’ve heard gumbled about before.  It’s great that you give two different options that you’ve thought about.  Which one did you use? (I can guess, but…)

    Can you do me a favor and add ABAP Developer to the tag?

    Thank you!

    Michelle

    (0) 
  2. Michael Keller

    Nice example. Little addition: I think SY-TCODE is in this case not reliable. If I remember correctly there was another possibility. And I have to check if this BAdI is affecting the logic of BAPIs BAPI_PO_CREATE1 and BAPI_PO_CHANGE. Unfortunately I don’t have system access at the moment. I will have look.

     

    (0) 

Leave a Reply