Anyone who has cut their teeth into working with Winshuttle and SAP has probably come to realize that Sales Order Creation transactions like VA21 and VA01 work differently from transactions like FB50, ME21 or ME51.
In the sales order process, just as for procurement and some other areas of SAP, you have the ability to not only enter header data and order lines, but also schedule those lines for delivery to specific locations on specific dates. Depending on your SAP system configuration, however, you may run into pop-ups and other behaviors that make it difficult to build a robust Winshuttle Transaction script.
The good news is that if you own Winshuttle Studio, you can leverage an SAP application programming interface (API) as an alternative to a transaction recording, and this can make your life easier.
SAP APIs are often referred to as BAPIs or Function Modules. To leverage an API, you need to ensure that it’s remotely enabled for use (by default, all BAPIs are generally remotely enabled). This will allow you to invoke the API via a Remote Function Call—the standard way in which Winshuttle and many other products interact with SAP.
Several BAPIs for sales order creation exist. The latest available in the ECC6 system at the time of writing was BAPI_SALESORDER_CREATEFROMDAT2. While you can consider older ones, the latest contains the richest possible experience in terms of functionality and is mostly closely aligned to a variety of usage scenarios.
The above search results from a standard SAP IDES system indicate some of the sales order-related BAPIs available for you to consider.
The 3-step process for “distilling” a BAPI for use with Winshuttle Transaction involves first identifying the BAPI that most closely aligns with the transaction that you would normally record. After selecting the SAP object, the next step is to download the meta-data and logical fields and tables that form the structure of the API.
When leveraging a BAPI that will create or update data in SAP, you also need to check the “Commit Required” box, in order to invoke the COMMIT BAPI after the BAPI itself has been invoked.
SAP requires 2 steps with most BAPIs, sometimes more. The COMMIT BAPI is the equivalent of SAVE and required for transactional data to be saved.
The structure of BAPI SALESORDER CREATEFROMDAT2 at first blush is very daunting, containing many tables and fields. Depending on your specific requirements, you may need to use many or just a few of them.
It’s important to remember that Input Structures contain input and output fields, while Output Structures only contain outputs. In this BAPI, the sales order number is returned to the SALESDOCUMENT field. This result may also appear in the log field, but to guarantee that only the sales order number is shown, this is a good field to leverage.
Other fields to consider, particularly when you are prototyping your BAPI, are the RETURN table fields, which essentially include all of the messages you would receive as a part of the order creation process (e.g., rescheduling, ATP, errors, confirmations and warnings). There are many options associated with this, and it’s recommended to start with exposing all of them. The minimum requirements for creating a proper sales order with this BAPI are to expose fields in:
Since the Header is a structure, there are no repeating elements there. Partners, Items and Schedules are all tables, however, and thus have repeating elements, even if you are only ordering one item.
There is another important aspect to consider with sales orders created with a BAPI versus transaction recording. With a transaction recording, the ordering and ship-to parties are typically represented as individual fields.
With a BAPI, the sold-to and ship-to parties are just two different types of partners. Accordingly, you need to specify a minimum of 2 input lines for the partners; more can be specified if needed (e.g., salesperson and account contact are also business partners).
You can typically escape with selecting just 2 partner fields: PARTN_ROLE and PARTN_NUMB.
To make life easier, you can also aggregate lines and schedule lines into a single grouping, minimizing the number of loops that you need to have definitions for in your data.
In the example shown, partners are aggregated in group A for Partners and Lines, for ORDER_ITEMS and ORDER_SCHEDULES.
[do action=”wsh_image_lightbox” imageid=”11451″ container=”0″ caption=” “/]
After selecting all of the required fields, the next step is to jump across to Transaction and map the fields to Excel, Access or whatever data staging environment you prefer.
Most importantly, any tables that you bring across need to have parameters defined either with loop indicators in column-based format or as a defined array with cell-based mapping. In addition, the RETURN table needs indicators as well.
The following image illustrates a sample layout. In this instance, the RETURN table hasn’t been exposed. Also note that although in VA01 you can use order type “OR,” the German equivalent of “TA” must be used here. The same applies to “Sold To” and “Ship To” partner, with equivalents “AG” and “WE.”
A partner function is allocated to every partner. In the standard version, 6 partner functions are defined and cannot be changed: AG (sold-to party), LF (vendor), RE (bill-to party), RG (payer), WE (ship-to party) and RS (invoicing party).
[do action=”wsh_image_lightbox” imageid=”11454″ container=”0″ caption=” “/]
Questions or comments about this article?
Tweet @uploadsap to continue the conversation!