MM Purchasing BAPIs offer flexibility on interacting with purchasing documents in a custom program, like creating a Purchasing Order (BAPI_PO_CREATE1) or updating a Purchase Requisition (BAPI_PR_CHANGE).
But these functions have a few quirks that when not observed correctly may produce unexpected results. A developer should have these points in mind when creating new code with these BAPIs:
1) Purchasing BAPIs have the same behavior as their equivalent transactions
The idea behind this design is to ensure that purchasing documents remain correct, preventing that misuse of a function produces a inconsistent outcome. If a human user operating the system cannot perform a specific action, BAPIs cannot do it either.
While this idea is intuitively correct and desired for the majority of users, it leads to one of the most common misconceptions when using BAPI to create or change a document:
trying to input or modify a field that cannot be updated in the transaction.
Example:
Using a custom developed report you attempt to change the Cost Center in a list Purchase Orders. This report implements a call to BAPI_PO_CHANGE. In a few POs from the list this alteration is never accepted by the system.
When checking this field in transaction ME22N, you can verify that for a few POs it is either disabled or hidden on the screen. On other cases where the field is enabled, when you update it the change reverses back to old value.
When a BAPI call does not achieve the desired result, follow the same steps manually in the equivalent transaction, the same limitations applies to both actions. The equivalences are:
BAPI |
Transaction |
|---|
BAPI_PO_CREATE1 |
ME21N |
BAPI_PO_CHANGE |
ME22N |
BAPI_PO_GETDETAIL1 |
ME23N |
BAPI_PR_CREATE |
ME51N |
BAPI_PR_CHANGE |
ME52N |
BAPI_PR_GETDETAIL |
ME53N |
BAPI_CONTRACT_CREATE |
ME31K |
BAPI_CONTRACT_CHANGE |
ME32K |
BAPI_CONTRACT_GETDETAIL |
ME33K |
BAPI_SAG_CREATE |
ME31L |
BAPI_SAG_CHANGE |
ME32L |
BAPI_SAG_GETDETAIL |
ME33L |
How to workaround this issue?
- Try to find if there is a way to achieve this action in the transaction, if it is not possible in any way the BAPI will never achieve it.
- If you find a working combination of values and conditions in the transaction, ensure to run the very same steps with the BAPI call. An important detail may be missing.
- Also, check in SPRO the Screen Layout settings for that document, if the fields are enabled, disabled or hidden correctly.
2)
A BAPI can only create or update a document in a single step, without manual interference from a user
This is another design piece that is intuitively understood: after all, the BAPI is executed by a program and that cannot have interaction with a human being.
But this correct design also limits the execution of the BAPI when compared to the use of the Enjoy transaction by a user: when
encountering an error or when
a decision needs to be made, the human user takes an action and provides the necessary inputs.
The BAPI doesn't have this capability, and this applies to certain situations where an undesired result seems to be a program error.
Example:
An user runs ME52N to update Account Assignment fields in a Purchase Requisition, and change Account Assignment Category from Unknown (U) to Cost Center(K).
Two things happen after this action: Account Assignment tab that was initially hidden, now appears; and error message "Enter Cost Center" is displayed. User acts on the error message and provide a valid Cost Center number.
Now a developer wants to create a program that calls BAPI_PR_CHANGE to execute the same update for PRs with Category U. The parameters passed to BAPI include the new Category K and a valid Cost Center number in a single call.
Cost Center value is ignored as this field is initially hidden (as explained in topic 1), resulting in "Enter Cost Center" error. There is no possibility to execute BAPI in two steps to first change the Category, then provide a valid Cost Center. As such, these changes cannot be performed with BAPI_PR_CHANGE.
The scenario described above is a common example where the execution of the BAPI does not always follow common sense. But mind that this design is necessary to maintain program correctness and consistency of purchasing documents.
3)
Use "X" table parameters for correctly set or clear a field value, or having the program to determine these automatically.
When users create purchasing documents several fields may be automatically determined, their values depending other field inputs, master data and system settings.
Additionally, the user has the option to
overwrite these predetermined values, which should no longer be automatically rewritten by the program. Even when this new value is
zero or
blank.
In BAPI call by a custom program or external system certain parameters can be left blank. How could the SAP program creating/changing the document understand if that call intends for the document to be created with a
blank field or if it should be
determined automatically?
This is the role of the
X tables paired with the input parameters, that lists the same field names while having a
boolean type. For example, POITEM and POITEMX, POCOND and POCONDX, etc.
For the majority of the BAPI parameters, system checks its equivalent boolean pair in the X table. If it is marked as
True ('X'), it means that this
input should be adopted even when it is blank.
If it is marked as
False (' ') it means that
system should try to determine this value automatically (when possible).
Example 1:
BAPI_PO_CREATE1 is called by third party system without Purchase Info Record (POITEM-INFO_REC) for the PO items, as this system doesn't have pre-existing Info Records data. The Purchase Order items end up created with a Purchase Info Record determined automatically by the system, in accord to the system settings.
Upon inspecting the parameters passed to the BAPI, the developer notices that the boolean pair for Purchase Info record (POITEMX-INFO_REC) is False. By marking this field as True, the program understands that no PIR should be assigned to this item.
Example 2:
BAPI_PR_CREATE is called by the same system to create Purchase Requisitions, but the Cost Center (PRACCOUNT-COSTCENTER) number from origin is never adopted in SAP ERP.
Developer finds a bug in the calling program, that the boolean pair for Cost Center (PRACCOUNTX-COSTCENTER) is always set as False, so the system is not adopting the correct input parameters.
Mind that not all fields have a logic to be automatically determined by the SAP system. You can confirm this by using an Enjoy transaction to create the purchase document, as the behavior of BAPI and the transaction should determine the same values as discussed in topic 1.
Important: these topics are valid for
materials only. Service and Limit documents have their particularities that will be discussed in a future blog post (to be linked here).
