Naimesh Patel's blog about LSMW with RFBIBL00 inspired me to jot down some of my own LSMW comments and rules of thumb, in the hope that others may find them at least slightly useful. This time, I'm not focusing too much on the technical aspects, rather the administrative framework around data migrations in general and LSMW in particular.
Trying to stuff data from system A into system B can be both challenging and fun, with a sometimes fuzzy border between the two. What follows is my own, personal checklist for LSMW undertakings.
1. Before import
Check your upload files. In particular, pay close attention to the following:
Reformat dates to proper SAP date format (YYYYMMDD or whatever the valid company format is - see point 2 below). Do not rely on doing this by inserting unneccessary code in the LSMW conversion. Also see point 2 below.
Reformat amounts to correct decimal point. Ensure you know what the correct settings are (again, see point 2 below)
Reformat amounts to correct number of decimals. Ensure currencies have no more than 2 decimal points. If using Excel, format your columns to "currency, 2 decimals". Simultaneously, if you're dealing with FI data, make sure you remove the negative sign and replace it with the proper credit/debit indicator (and posting key).
Convert all source fields to SAP format before import. Avoid having to do this in the LSMW conversion program itself. It's much better to do it beforehand, using Excel or whatever tool you enlist to handle your source data. Converting in advance avoids errors, involuntary shortening of field contents, and minimizes surprises during the acceptance test after migration. Apply WYSIWYG.
Avoid using translation tables (except for large number of entries). It's always better to clean up the source files before obtaining the final validation from business - this also means business signs off something they can actually see, instead of two things; the un-converted source and a separate conversion table. Doing the translations directly on the source data reduces the risk of unforeseen errors (especially of the "hey, this is not what we expected..." kind).
Keep similar input file structures as identical as possible. When importing similar data, such as various kinds of FI transactions, make sure the input files contain the same sequence of identical fields. This ensures users (data providers, extractors, surveyors, cleaners) will be familiar with the data and spot errors more easily. You do not necessarily have to sort the fields according to the corresponding SAP segment sequence (this is one of the virtues of LSMW); it may instead be better to arrange them in ways that the extractors find familiar, logical and easy to handle.
Export LSMW conversion logic, mappings and translation tables etc. to local files. Make sure business signs these off as part of the validation process, preferably before the production load.
2. During import
Check the executing user's date and decimal point settings. This is the famous point 2 I referred repeatedly to above. Ideally, the date format and decimal point settings (as seen in transaction SU3, tab "Defaults") should be company-wide and not modifiable for the individual user (the Security guys should tweak this setting with transaction SCUM, disallowing users to modify the date/decimal point format locally, at least during the data migration phase and for the user community executing the loads). Other than that, discrepancy between the source data and the user's settings will show up soon enough, during conversion...
Keep the team physically together. If you cannot post to a specific GL account because it's not open for postings, or no clearing account has been defined for a specific company, it's nice to have the functional FI consultant with authorizations to remedy this, close at hand. If that person is on another continent (or even in the next building) it may slow things down considerably. Keep the migration team together, preferably in the same room. Lock the door if needed.
Agree on how to handle erroneous sessions. Sessions with limited number of errors should be re-processed when the issue causing the error has been remedied. In more serious cases you should consider re-setting the system to its previous state (rolling back to a previously taken backup) and re-processing the data. Re-processing the session in online mode and applying changes manually on-screen should be avoided! You will be tampering with signed-off data and could ultimately be held responsible for whatever erroneous data is inserted into the system...
Download imported/converted data to PC files for auditing purposes. Store these in a secure place with limited and controlled access (and, no, your own personal laptop or USB drive does not qualify as such a location).
Backup your SAP system after each major import milestone. Successfully importing hundreds of thousands of documents, only to find that the next batch causes severe problems (system hang, errors, wrong postings), can really ruin your day. Instead of trying to cope by, say, reversing the documents or applying other cleanup tactics, you should consider reverting to your last backup. Of course, this is provided you have one...
3. After import
Take snapshots of session logs (SM35) for auditing purposes. This enables you to document when the data was loaded, number of transactions, number of errors and so on.
Have business sign off logs and mappings. Print the above documents, obtain signatures, and scan for archiving.
