|
Writing programs for a single mass data changes in SAP can be a fairly involved process involving several steps such as, requirements definition, design, coding, testing, and documentation. Since every mass change request may be different, the entire process has to be repeated for every such request. Moreover, IT's programming resources tend to be expensive and may not be always available. The SAP support teams are constantly struggling at prioritizing such mass change requests among their many other mission critical projects. Therefore, all-in-all the second option of requesting the IT support team to build programs also becomes a not so desirable proposition.
Many companies using SAP, however, have adopted some good practices and tools that are enabling them to make mass changes to SAP data in record time with minimal resources. These practices are affording these companies the following benefits:
They are saving on data entry resources by eliminating redundant manual data entry.
They are saving time by updating SAP data instantly.
They are able to reassign the valuable IT resources to more mission critical projects by reducing programming efforts for mass change projects. They are reducing data errors due to manual data entry or due to hastily put-together programs.
The next section of this article describes these best practices for mass changes to SAP data. This section will be followed by a specific mass data update example and how these practices are used, and finally some success stories will be presented.
This section describes the best practices in making mass changes to SAP data that we've discovered by interviewing SAP users at hundreds of companies. Using these practices, these companies were able to make mass changes to SAP data very efficiently and cost-effectively.
Mass changes to data are carried out most easily when the data to be updated is in a spreadsheet format, such as in Microsoft Excel files. The ease of use of spreadsheets and functionality such as bulk copy and paste, referential lookups, and formulas make spreadsheets an ideal format for making mass changes. Moreover, spreadsheets can be easily passed around for review and collaborative input.
Most SAP data can be easily imported into spreadsheet formats. The commonly used SAP reporting functions and data query functions, e.g., SE16, SQ01, ALV reports, job spools, etc., allow the easy export of data into spreadsheet formats. If the business users responsible for the mass data update do not have access to the SAP query transactions, such as SE16, they can use third-party tools such as TablePro from Winshuttle, Inc. to securely read data out of SAP and download it into Excel files.
Once the data to be changed has been brought into an Excel file and modified as needed, this data can be then uploaded back into SAP. However, the upload method must be carefully selected and the practices listed below illustrate the best ways to upload data from Excel files to SAP.
Excel files with the updated data should never be uploaded directly into SAP tables. While this point is very obvious, it cannot be overemphasized. Writing directly to SAP tables ignores all the data validation and checks and balances that happen when creating data through the normal SAP transactions. So, we should avoid using any such method that writes directly to SAP tables.
Data from Excel to SAP should always be uploaded via the pre-configured SAP transactions or via specific SAP provided business interfaces known as BAPIs. SAP-provided tools such as BDC, CATT, or LSMW, or third-party tools such as TxShuttle from Winshuttle, Inc. allow the upload of data via SAP transactions instead of writing directly to SAP tables.
With the several non-programming choices available to easily upload Excel data to SAP, custom programming in ABAP or VB should be the absolute last resort for ad-hoc uploading Excel data into SAP. Not only is programming expensive and time consuming, but also the fact that such a program may be used only once or even once a year is particularly wasteful. Further, creating robust programs require a fair bit of testing and if a program has not been well-tested, it could be dangerous and cause irreparable data damage.
|
