Functional consultant comes across many business requirements where they need to design/consult business scenario where interaction of ECC is required from another system. I will describe a very simple business requirement related to this and how can functional consultant get it expedited with the help of technical team. In the future blogs, I will describe how to expedite the other simple business requirements of ERP interface with the other systems.
BUSINESS REQUIREMENT
Portal Screens contain fields which have values maintained in a drop-down, so that the end user can select values from it.
For these fields, they need to connect to the ECC system, where the values for each field are stored in customizing tables/maintenance views/value range in domains.
An interface is required to enable users in the portal to get the valid values of various fields from ECC.
This interface is supposed to read values from ECC and present the values to the users on the portal.
In portal, these fields are not available for the free text user input and can be filled only with values from drop downs coming from SAP ECC.
SOLUTION
Since the requirement is to get the values from ECC, for various fields belonging to different tables/views/domains, the need is to design a dynamic approach, where-in the user can fetch values for any field belonging to any table/view/domain, without having to worry for the scope of search help functionality.
We requested the technical team to build the code dynamically, with no single static value. This enables the end user to search for any field irrespective of any search location. Also there is a provision to restrict/filter values based on certain conditions.
REALIZATION
The interface takes the RFC approach for communication between the PORTAL and SAP ECC systems. The interface is synchronous and thus follows the request-response mode.
PORTAL places a request to ECC by providing the field name, table/view/domain name and the filter conditions. The ECC fetches values from the respective location and sends back the response to PORTAL with the relevant field values.
In lay-man terms following is the design
It is commonly understood among all the SAP MM Functional consultants that any field in SAP associated with a F4 value, has its value stored in the following three locations :
- TABLE [Values maintained in check tables]- Example, all the possible values of “Plant” can be searched in the table T001W
- VIEW [Values maintained in maintenance views]-For example all the possible values of “Product Hierarchy” can be searched from the view “V_T179”
- DOMAIN [Values maintained in the ValueRange of a Domain]- For example all the possible values of “Procurement type” can be searched from the domain “DD07T”
So our interface should support the above explained types of searches for the various fields.
SIGNATURE
Signature is very important in interfaces. In a lay-man terms, a signature is a discipline of interaction between two systems. Signature specifies the import & export fields between the two interface systems. Here our systems are portal & SAP ERP.
IMPORT
- Provide the nature of search the interface needs to perform
- Possible Values are TABLE , VIEW , DOMAIN
- SEARCH_LOCATION
- Provide the table/view/domain name of search
- Example: for Warehouse Number provide T300T.
- FILTER [ A table of field names & conditions]
- FIELD_NAME : The name of the field for which search help is to be performed
- FIELD_CONDITION: A Filter to restrict the values to be retrieved.
Example
For Sales Org, our input will look the following.
- SEARCH_TYPE = VIEW.
- SEARCH_LOCATION = V_TVKO.
- FILTER
- FIELD_NAME = VKORG
- FIELD_CONDITION = *
- FIELD_NAME = VTEXT
- FIELD_CONDITION = *
EXPORT
FIELD_NAME_VALUES: A table of entries containing the results grouped according to the fields given in the input.
FIELD_NAME_AND_VALUES: A table of 3 fields [Warehouse No, Descr. , Language]
Example
Assume 52 entries have been maintained in SAP ECC for Warehouse with English description.
Output:
- FIELD_NAME_VALUES [52 entries]
- [1st entry]FIELD_NAME_AND_VALUES [3 entries]
- LGNUM : WAREHOUSE 1
- LNUMT : WAREHOUSE 1 TEXT
- SPRAS : ENGLISH
- [2nd entry]FIELD_NAME_AND_VALUES [3entries]
- LGNUM : WAREHOUSE 2
- LNUMT : WAREHOUSE 2 TEXT
- SPRAS : ENGLISH
SO ON………
- [52nd entry]FIELD_NAME_AND_VALUES [3entries]
- LGNUM : WAREHOUSE 52
- LNUMT : WAREHOUSE 52 TEXT
- SPRAS : ENGLISH
An example of the support document is attached which can be provided to technical team with functional specifications.
CONCLUSION
Since the technical approach taken is dynamic, it is thus not limited to a specific project. It can be re-used across different SAP projects which need to carry out search help across SAP systems in the RFC mode.
Just by establishing the RFC connection across 2 SAP systems, this function module can be utilized to realize the search help functionality.
Hence RE-USABILITY is the object’s prime distinguishing attribute.
The algorithm can be further extended easily to support more search types. There is no need to disturb the signature of the interface. Just adding a small piece of code to support the additional search types would suffice. So the extension of the object is pretty simple and straight-forward.
