Having a mirrored copy of a production SAP server (or a legacy SAP server) can prove immensely useful during an SAP implementation and works wonders for producing extracts with complex joins that can be used to produce load files and to validate loads afterwards. Sadly, not every organization will justify an SLT server or have the willingness to share access to it with key data migration resources.
SAP Replicator is opensource VBA code designed to be run on Microsoft Access to populate a Microsoft SQL Server with the data from an SAP server using RFCs. It initially uses a series of calls to the RFC_READ_TABLE function to take, in small nibbles, a snapshot of SAP tables. The example below was written over a weekend to handle a Material Master data migration project, but code changes can be easily intuited to include other Master Data objects or transactional data where required.
In rare cases, access to transactions to perform mass loads or to affect changes to data with any significant volume are restricted for users--even for users who are responsible for maintaining Master Data. One option is to use Excel to create an OLE connection to the SAPGUI interface to run scripts, but that option requires scripting to be turned on in the SAP system and each record takes several seconds to call a transaction and run it to completion in foreground.
Another option is to use run BAPIs from Excel using Remote Function Calls (RFCs) to perform the updates. This option is more cumbersome than transactions designed by SAP to perform mass updates and it requires that the user performing the updates have RFC access, but it is faster than using Excel for scripting and more accurate than manually keying data.
Loading data into SAP is a niche that many vendors try to fill with tools that are confusing, cumbersome and absurdly expensive. Some vendors, instead of including all features together, license their products for thousands or tens of thousands of dollars per user based on what features are included and then charge thousands more in recurring annual fees on top of the initial licensing fee.
The promise made by many of these vendors is to eliminate the need for expensive technical resources, but that promise is seldom kept; the customer is inevitably forced to find technical resources to support the new product. If it were the case that their products made data migration easy for non-technical resources then job search boards would not be flooded with job requisitions for "Expert in ________" or data migration roles for people that have "at least n years of experience using ________".
SAP provides the capacity to use various Units of Measure in pre-defined ratios in batches where the proportion of one component cannot be fixed, but will be different in every batch. Industry sectors like pharmaceutical, chemical, steel and paper utilize these Proportional Units of Measure throughout the logistics chain when creating product in Batches.
In a long enough career implementing SAP, despite one's best efforts, an encounter with IDOCs is inevitable. Knowing how to handle IDOCs--especially in any implementation that uses MDG--will make short work of any problems one encounters as the result of using IDOCs.
In this example, a handful of Material Masters are MASS updated in an MDG system. The MM17 transaction successfully updates each of the Material Masters and the Material Masters are all already assigned to the Classification that triggers the ALE connector to update the Material Masters in the downstream system.
There was a time when the best development platform produced by Microsoft was Notepad. IIS was relatively new and dynamic pages were served by Active Server Pages or "ASP".
As older servers are mothballed, newer servers come online, but custom applications remain the same when they work. Porting a classic ASP application to a modern .Net system requires esoteric skills in both and those don't come cheap.
Proficiency and confidence in the use of Business Objects Data Services (or "BODS") can be achieved in a single day by an experienced programmer. BODS does most of what Access does and comes with some exceptional features right out of the box.
After 20 years of success in the realm of R/3 and ECC, LSMW finally has a viable competitor called LTMC or Legacy Transfer Migration Cockpit. LTMC is native to S/4 and enjoys a small advantage over LSMW in most cases, but only when implementing S/4; it isn't available for R/3 or ECC.
In SAP, there is a way to make a popup specific to a Master Data record appear during the posting of many documents. It isn't perfect, but it can be useful as a reminder to customer service representatives when posting new Sales Orders, Shipping Orders or Billing documents.
A great way to gracefully sunset Master Data that is a duplicate of another record is by creating a message that appears as a popup while posting new documents. If the message explains that the Master Data record is a duplicate and requests that the user transact through a Master Data record that has been identified as the survivor then any open transactional documents will eventually settle and the Master Data record can be sunset.
Because of the cumbersome way that SAP stores long texts, it is not possible to access them with a custom query, with nested select statements or even with complex joins. The only way to access the long texts for the purpose of a report is through the READ_TEXT function.
Most data migration specialists take great pains to ensure that duplicate Vendor Masters, Customer Masters and Material Masters are not created during SAP implementations, but are instead extended to the Sales Orgs, Plants and Company Codes as a firm rolls up acquisitions and expands. Sadly, many fly-by-night organizations and even Big 6 firms will take shortcuts which result in duplicate records created and immediately used in a production system.
This is the sort of thing that is easily identified and resolved after the first System Integration Test, but during a recent project, it was discovered that tens of thousands of duplicate Master Data records slipped by the system test, and, if there were any, the UAT. Naturally, this leads to great consternation as managing interactions with customers and vendors through multiple Customer Masters and Vendor Masters causes undue confusion and renders downstream reporting near useless.
Little documentation exists on the internet explaining how to populate Long Texts in Master Data objects and the little that does is very specific and covers only standard SAP values like Material Basic Data Texts and Sales Texts. This whitepaper explains how to find the values used to populate the parameters of the SAVE_TEXT function in order to populate any Long Text value.
When Customer Master records are maintained correctly in a mission-critical SAP production system, transacting with customers is easier, faster and less frustrating for the internal resource and the customer. Like the view from a mountain top on a clear day, downstream reporting used for granular overview of single customers all the way to overview of the entire enterprise is accurate and therefore actionable.
The following are simple best practices that have been adopted by successful CRM and ERP implementations enabling them to control Customer Master data and prevent issues from cascading as more organizations are rolled up into a single ERP system. Best practices prevent data stewards and data migration specialists from filling a production system with Customer Masters that are not suitable for transacting with customers and from causing downstream reporting to be unsuitable for running any organization.
In any SAP implementation, the need to use a transaction to which nobody on the team has permission will arise. That is when two little-known tables can be very useful to the data migration professional.
The AGR_1251 table
Approaching the security team doling out permissions to a TCODE in a production SAP server can be a bureaucratic nightmare as the first question is always "What role do you need?" The people doing this job understand perfectly that users have no idea what roles have access to the transaction they need, but they're going to ask the question as though it is perfectly natural for users to have this esoteric knowledge.
When simple LSMW best practices are not followed, a system can be overwhelmed with uncontrolled redundant growth. When this happens, there is a chance that a consultant can walk into a situation that has many LSMW Objects spread over several LSMW Projects with disparate naming conventions and no rhyme or reason.
Knowledge transfer and training can take weeks, but that does not reduce a client's expectation that esoteric data can be loaded by a Data Migration consultant the day that he arrives on a project. After all, "The program is already written!"
Loading long texts can be a daunting task, but using a recording can make the task very easy. There are plenty of other solutions (Saplicity and SAVE_TEXT), but a recording is a simple and clean solution to an otherwise cumbersome mess.
In order to load the Long Texts using a recording, it is necessary to break the text into multiple 72-character chunks and then load each line one after the other. The first chunk will go into an empty editor screen and then each subsequent chunk will be appended to the end by simply running the recording again.
The PPOCE and PPOME transaction are notoriously slow and, because of the design of the interface, impossible to automate with a recording. PPOC and PPOM aren't much better as there is no way to drill down into the organizational hierarchy in order to create objects at lower levels.
The HRP1000 and HRP1001 tables are straightforward enough and easily understood, but there is little documentation on how to manage the data in these tables available on the internet. Fortunately, there are solutions for managing HR data in these tables.
Failing to validate data and report issues has caused catastrophic results for many SAP implementations. Simply checking to see if source data matches internal SAP tables allows migration specialists to report issues prior to loading and provides a great way to affect necessary customizations and changes to source data.
Generic Object Services or GOS is a commonly-used technology from SAP that creates a uniform way to add functionality across various business objects in SAP. One of the functions is a feature that allows attaching a file to a business object such as a document.
As one might expect, the GOS button vanishes when the program used to create a business object is run in batch mode making it useless for a recording. Additionally, the ABAP debugger is useless as the system stops debugging as soon as the GOS button is clicked, so chasing the code rabbit down the programming hole becomes much harder.
Loading long texts to objects can be a daunting task because of the way that SAP breaks up the texts to be stored in blocks. When the object with the long texts is opened in SAP, the system knits the blocks back together into the long text to be displayed to the user.
For this example, long texts for Service Notifications will be loaded using the IW51 transaction in batch mode. The long text is passed in as a series of lines populating the individual fields of the long text editor screen.
SharePoint has been experiencing a growing market share in the field of cloud-based data management and is a fine solution for many distributed applications. SharePoint allows content to be distributed to people outside the corporate network, but when it comes to handling source data, network shares on the corporate network are the optimal solution because there is no need for manual steps between extracting, transformation and loading.
Transactions with ALV grids and other Windows-based GUI plugins are out of reach for the traditional batch processing tools provided by SAP. If the transaction has been customized then there is a good chance that the data cannot be loaded with BAPIs or IDOCs provided by SAP.
Getting a developer to update or create tools to load legacy data into these transactions is often harder than getting developer access and permission to change or create the necessary tools. Here is where customized mouse and keyboard macros come into play as a solution of last resort.
Macro software for Windows simulates mouse movements, mouse clicks and keyboard strokes for the purpose of automating tasks and for testing automation. Creating custom macros as text files and launching them from SAP simulates an intern sitting at a computer entering the data, but without the whining or errors.
SAP's Master Data Governance software is an incredibly complex system that contains countless new tables and new transactions. Remembering enough to make regular ECC work is hard enough, so now this website does a lot of remembering for our developers.
Few things can be more annoying than leaving work with a coffee cup on the keyboard and returning to find that the report had crashed during the night. The prospect of starting the report over is one that nobody looks forward to.
Starting a report where it left off is still pretty bad, but not nearly as bad as starting over from scratch and losing all of the work that had already completed. Creating a delta report and appending it to the existing report is made easy with a few short snippets of code.
It might sound like a trivial task, but until the necessity arrives, one may not ever learn how to populate the fields in a query with default values. In one case, a client wanted a query to have the same 10 customers populated automatically when the query was run by any user.
SAP's CT04 transaction has grid controls that cannot be accessed using a recording in LSMW. A CT04-based recording would make quick work of populating the allowed values--even hierarchical values--available to users of the Characteristic, but that isn't an option.
That doesn't mean that the allowed values cannot be populated using LSMW, but it does make it a little more cumbersome. Previously, the task of using LSMW as a wrapper for BAPIs was explained as a demonstration of creating Classifications in a system where a customization had rendered CL02 unusable and it will serve well here to call the BAPI_CHARACT_CHANGE function.
Coaxing SAP into presenting useful information using SQ00 can be a daunting task if the complexity of the data is spread over more than two tables. It is not uncommon for clients to request disparate data sources be knit together in order to make sense of it for a particular scenario.
Writing a report for the same requested information can be a snap because of the way that ABAP allows one to manipulate tables, call functions and filter data based on complex requirements. Basic SQ00 queries don't offer such enhanced manipulation capabilities.
Fiscal year-end closing can be a very stressful time for any firm's accounting department. Having access to data in its most useful form can mean the difference between successfully performing procedures vital to the success and organization of a company and frustrating missed timelines.
Some firms have an army of dedicated data entry personnel. For those who don't, LSMW can provide a solution that is fast and accurate, albeit somewhat complicated.
SAP's Customer Relationship Management (CRM) software is written in the same language as ECC and, in addition to the web-based interface, uses the same GUI interface as ECC for most operations.
Because of the cumbersome way that SAP stores long texts, it is not possible to access them with a custom query, with nested select statements or even with complex joins. The only way to access the long texts for the purpose of a report is through the READ_TEXT function.
Determining what master data objects are no longer used is a great start to an SAP implementation. Obsolescence determination is a very important part of data cleansing. To reduce the amount of cleansing required, this should be performed before any other part of cleansing.
Groups are a cumbersome object to load as there is no program to be called from LSMW for direct input or for creating BDCs. The program itself relies on objects that fall outside the normal access of BDCs and the hierarchical format of the data makes loading them with a batch all but impossible even if there were an easy way.
Snapshots of the data stored in a central location for a project have proven invaluable in too many situations to count. It is an important part of a Data Conversion Team Lead's best practices and should be performed early each day when network traffic is low.
A catastrophic hardware failure or accident can set a project back months if due care is not taken. Even when the internal IT department is performing backups it may be difficult to reach them and have a single file or folder restored. A lost or corrupted file can disrupt a project while the IT professional finds the right tape, finds the right file on the tape and then restores it to the project folder. In some larger organizations the IT department may be inaccessible behind tiers of apathetic helpdesk employees or online forms that go unseen for days.
Some junior developers might be a little overwhelmed the first time they are tasked with using a Business Application Programming Interface or BAPI. It is important to understand that a BAPI is just a regular function and not some mystical tool the inner workings of which can only be comprehended by the man behind the curtain.
Some SAP objects don't come with a convenient way to load their information into SAP or if they do it doesn't always work. For many objects there is one or more BAPIs that can be used to load the data without having to rely on cumbersome recordings or even more cumbersome IDOCs.
Often during a career migrating legacy data it becomes a requirement to use more than the LSMW, SE16 and SM35 transactions. This is a list of useful transactions and the effects that make them useful. Where appropriate, an example of when to use the transaction is included.
LSMW is a very powerful tool and many SAP Security specialists are reluctant to grant LSMW permission--rightly so! LSMW access should never be granted without a legitimate business need and it should only be used by professionals trained in its use. This whitepaper does not address that issue, but instead is written for junior Security specialist who have never been faced with the need to grant LSMW access.
Sets are a great way to group objects together for accounting purposes and for custom reporting. Understanding sets can seem daunting at first, but it is important to understand that a set is nothing more than a list of individual values that point to objects within SAP.
At first glance it would seem that the easiest way to populate a set is by manually entering in countless records one after another. While it is possible to trick a recording into loading screens full of records into a Set, the simplest way by far is by creating a recording that shifts the contents of the set down and inserts one record at the top. This recording can be called once for each record in the source data such that all records are eventually loaded in reverse order into the Set. The order of the Set contents probably doesn't matter, but if it does then the source data should be reversed so that is loaded in reverse of the desired order; this will make more sense once the operation of the recording is understood.
Manipulating the details of individual operations with a recording can be very simple when one knows how to navigate through the routing using a recording. Selecting the appropriate operation from a specific sequence can be very difficult when there are more than 15 of either on a screen because the selection block for sequences and operations after the first 15 do not appear on the screen without a page-down.
The workflow of a project is marked by the path through which data flows from team to team. Each time data is touched it must also be validated against itself for relational integrity and against other source data for dependencies. These validation steps must occur before the data is passed downstream to the next team and, as the project progresses from early testing phases toward go-live the validation must occur faster and with more accuracy.
In many implementation projects for SAP it is necessary to break down the most complicated objects into manageable pieces for the purposes of time and energy. Routing data pulled from a legacy SAP system tends to load quite easily into a new system using the standard Direct Input or BAPI method, but this client wasn't using routings before.
An SAP implementation tends to be a fluid concept with surprising challenges, changing deadlines and moving targets. Many businesses rush through the various steps of an SAP implementation or skip steps in order to cut costs or to meet unreasonable deadlines. The process behind a traditional implementation has been designed, tested and then ratified by SAP as a best practice.
Many times it becomes necessary to rely on SAP's functions to validate source data. The optimal place to validate source data tends to be in the target system that the data will be loaded.
Some examples of source data that can be validated using ABAP functions written by SAP include dates, postal codes and tax jurisdictions. A little bit of know-how and the right function can save hours of effort and reporting by ensuring that source data is correct before attempting to load in SAP.
LSMW access isn't given out very often and few SAP security professionals know what is required for access to LSMW. An easy way to expedite a request for access to LSMW is to include the specific authorization objects required to successfully utilize LSMW.
It is always preferable to identify invalid data during the conversion step rather than during the load, but it isn't always obvious when a database table is being used by SAP to perform validation; SAP will reject data to be loaded in a transaction if it does not exist in the check table for domain from which the field comes.
A quick and easy transformation that can be applied to legacy data automatically (and therefore consistently) is a Translation. Translations are most often used in while migrating transactional data from legacy systems into a new production system.
A lack of any access to SAP's ABAP development environment is too often a hurdle for aspiring developers. SAP provides a free, scaled-down versions of it's flagship product for use as a teaching tool. The easiest way to obtain a copy is by purchasing a copy of The Official ABAP Reference, a book from SAP. The development system is included on CDs for training purposes. Additionally, it can be obtained by downloading it from the internet in a variety of places. It is hosted on SAP's website and on many other websites. It may be available from peer-to-peer sharing networks.
Starting off as a developer in ABAP can be a daunting task due to the complexity of the system. In addition to the countless programs written and buried within SAP there are tens of thousands of native tables--many of them abandoned and empty. This makes it difficult to find where a single piece of information resides in a system nearly too complex to use, much less develop software for.
Knowing where a specific value occurs in the SAP database structure can greatly ease the development of software to validate and change these values. By checking the values in tables it is possible to know if the value needs to be changed or is already correct as it is. This saves time and effort, reduces the strain on a busy server and simplifies management of the system.
Transactional data is some of the trickiest to load. Many documents have dozens of dependencies which, in turn, are stacked on top of other dependencies. It's not always possible to catch every problem and a partial load might make for a failed project.
Planting a discreet key in each source record allows for the ability to link the records from the source file to documents created in SAP. This link allows for delta loads to be performed as obstacles to loading are removed and dependencies are provided and reduces the risk of duplicate records when performing delta loads. Additionally, editing (or reversing and re-creating) documents becomes a much simpler matter when errors are discovered after the data has been loaded.
This isn't necessarily a new trick, but it can save a lot of time and energy when repetitively working on the same transaction or working with a transaction with a cumbersome transaction code like accessing Firefighter accounts. Go to the SAP Easy Access screen. It might very well be the first screen to come up after logging into SAP or there may be a button that leads to Easy Access. Also, typing /n in the Command Field and pressing the Enter key will most likely pull up the Easy Access screen.
Too often a team member will use Excel to open a source file for the purpose of changing some content. While manual manipulation of source data is taboo and should be avoided at all costs, it is sometimes unavoidable.
Some objects call for two or more recordings because the screen flow is different based on the source data. In many cases a single recording will do when used with the coffee cup method because SAP raises a warning over a missing screen field instead of stopping the transaction, but the transaction can still be run.
The whole point of validating data prior to loading is to give functional team members a chance to fix the data by preparing it again in a way that can be loaded into SAP or by configuring SAP to allow for the data. A meaningful report comes with all of the relevant source data along with a detailed explanation of why the record cannot be loaded to SAP.
Many conversion specialists prefer a method of error correction that calls for the data to be loaded to SAP followed by a complex process of combing through the batch log for error messages. Seldom are these error messages meaningful enough to tell why the record failed--especially when the batch is run in the background or as IDOCs. By validating the data against check tables or by calling validating functions provided by SAP, a report that documents each and every potential problem with the data can be produced for use by the functional team. This data is invaluable when coupled with instructions on how to fix the problems.
Part of almost any pre-validation of data in LSMW calls for a query against tables in SAP. Some of these tables are enormous with thousands or even millions of records in older systems. Comparing data to be loaded against documents already in the system using discreet external keys is a great way to avoid creating duplicate documents and is the best way to facilitate delta loads as obstacles to loading are exposed and removed. This often entails checking the key against fields that are not indexed and that can take seconds per document and make an otherwise well-developed LSMW object run for hours or even time out.
Recordings are an easy way to load data into SAP without a lot of effort or programming and they provide great way to make one-time modifications to existing data--especially to proprietary Z-fields. Producing a recording may be harder when the underlying program changes its interface by showing different fields on the screens or by changing the flow of the screens.
The MM02 transaction is a tough one to produce recordings for because the layout of the checkboxes (field KZSEL) on the Select View(s) screen shifts to accommodate additional views. This inconsistency makes a simple recording almost impossible to use for any large number of materials or for a small number of materials of different types. There is a way to predict the layout of the views on the Select View(s) screen and it is relatively simple.
LSMW stores conversion objects in a hierarchical format within projects and sub projects. Limiting the storage of objects used for a single SAP implementation to a single LSMW project enables team leads to easily find objects distributed over team resources, oversee progress and contribute to the development process.
There are a handful of things that fall outside of the realms of common sense and the obvious. Managing the Extract, Transform and Load (ETL) aspect of an SAP implementation can be a daunting task were it not that there are ways to make the project run more smoothly.
Financial documents are easy enough to transport when the data has been cleansed and formatted properly. We talk about that elsewhere on the site. Once the documents are loaded, the next step is to reconcile the documents. This report makes it easy to see how each document got into SAP by giving the SAP document number that relates to the legacy document.
Because of the cumbersome way that SAP stores long texts, it is not possible to access them 
Failing to 
vanishes when the program used to create a business object is run in batch mode making it useless for a recording. Additionally, the ABAP debugger is useless as the system stops debugging as soon as the GOS button is clicked, so chasing the code rabbit down the programming hole becomes much harder. 
Transactions with ALV grids and other Windows-based GUI plugins are out of reach for the traditional batch processing tools provided by SAP. If the transaction has been customized then there is a good chance that the data cannot be loaded with BAPIs or IDOCs provided by SAP. 
Determining what master data objects are no longer used is a great start to an SAP implementation. Obsolescence determination is a very important part of data cleansing. To reduce the amount of cleansing required, this should be performed before any other part of cleansing. 
Some SAP objects don't come with a convenient way to load their information into SAP or if they do it doesn't always work. For many objects there is one or more BAPIs that can be used to load the data without having to rely on cumbersome recordings or even more cumbersome IDOCs.
The workflow of a project is marked by the path through which data flows from team to team. Each time data is touched it must also be validated against itself for relational integrity and against other source data for dependencies. These validation steps must occur before the data is passed downstream to the next team and, as the project progresses from early testing phases toward go-live the validation must occur faster and with more accuracy. 
Transactional data is some of the trickiest to load. Many documents have dozens of dependencies which, in turn, are stacked on top of other dependencies. It's not always possible to catch every problem and a partial load might make for a failed project.
This isn't necessarily a new trick, but it can save a lot of time and energy when repetitively working on the same transaction or working with a transaction with a cumbersome transaction code like accessing Firefighter accounts. Go to the SAP Easy Access screen. It might very well be the first screen to come up after logging into SAP or there may be a button that leads to Easy Access. Also, typing /n in the Command Field and pressing the Enter key will most likely pull up the Easy Access screen.
