SE16N Support of Data mapping?

[Former Member]

I am working to prepare a system for transition to SAP. I was wondering if SE16N would be the correct transaction in support of mapping data elements from our current legacy system to the SAP system?

Thanks in advance

[Colleen]

SE11/SE12 is the data dictionary whilst SE16/SE16N is the data browser to look at the contents

mapping data elements directly may not be as easy without understanding what the design is. Do you have an SAP Consulting team who is going to guide you with the data migration strategy?

[Former Member]

We will have an SAP consultant working with us as the transition gets closer. I am actually certified in SAP and parts of my team have trained in different functional areas. What we are trying to do is build internal knowledge to support the transition when it becomes reality. So the data dictionary would afford definitions of the data elements? Most data elements I would think will be self explanatory but having definitions to ensure clarity might be the best path forward.

[Colleen]

The data dictionary will give you the information for primary key, referential integrity, field sizes, etc, which would be the starting point

It might be that you and the Functional team need to start at the top layer (i.e. the business object or transaction) and then work down to the database. I've done this by switching on ST05 SQL trace whilst replicating a transaction to see which tables are hit.

I'm not a data migration person but I could see that helping as the starting point. But as Simone already mentioned, there will need to be a data mapping exercise to figure out what will be migrated and if any transformation is required.

Self-explanatory probably depends on your module/area and your expertise. If you are providing this information to a business user who has never experienced SAP-speak before then it may not make much sense and a lot more scene setting is going to be required. But I guess, showing the SAP transaction (or Fiori, etc) to give the visual and the showing the data underneath might help.

[Former Member]

Colleen thank you. What I am trying to do is get ahead of the transition effort and have a good idea of what data elements will need to be added, where others will be already represented in the solution, and obviously I would imagine we will have some we need help working through.

We have a consultant that is a little better versed in our business application that will come on when we move closer to the formal transition but I would like to get a leg up. Think I will start with SE16N and see where that leads us, but I definitely appreciate your advice I think based on my team's level of expertise I need to keep this more focused on the business voice and less on the SAP voice. (Make sense?) Again thank you.

[SimoneMilesi]

Apart remarking c.hebbert 's note, my suggestion, having done the same job at least 3 different times with 3 different legacy systems, is to identify the data you want/need to move (i.e. Materials ), find out which informations you need in SAP and which one you want also to add.
And the start to follow the breadcrumbs of the complex relations (i.e Sales Orders, Purchase Orders) and all the related object, repeating the process.

You'll discover some data cannot be moved by standard and you'll have to add some custom fields or change place for them due different design as well as you need some data you do not handle at the moment.

You surely need a good consulting team with some experience to guide you.

[Former Member]

Simone

Thank you for your advice. I am sure you are correct. At this point I just want to get us moving forward. At some point I am sure our system knowledge will limit progress but if we can define as much as we can on our own I believe it will represent value in several different aspects of transition.

[pokrakam]

OK now that I understand the background a little better, I would suggest looking at transaction BAPI.

The BAPIs (= Business API) contain your more business-y view of data, thankfully also with more English-y names. Think of it as the logical data model whereas tables also contain a plethora of technical information and represent the physical data model.

BAPIs enforce business rules and will validate and translate your input into the correct table-level data and are therefore usually your preferred method of interacting with business documents programatically.

So for most objects you will see some form of update methods, usually CreateFromData or whatever, and the parameters for these represent the fields you're after. Of course I can't say whether your loads will be performed via these APIs or other mechanisms, but if you can give someone a mapping using BAPI fieldnames, the real filenames can usually be inferred.

[Former Member]

Thanks Mike. I will explore that as an option. It actually sounds like what we might need.

[Jelena_Perfiljeva]

Which SAP version are you migrating to?

In addition to what others have already said, the best thing you can do in preparation is to find if the fields to be mapped are actually used and to find their business definition. The way these mapping exercises usually go is some team creates a list of table fields and then an SAP team is called to find a suitable placement for all that data in SAP.

While most fields are obvious and can be mapped with the eyes closed (every system has a material / part number or a customer name), a lot of time ends up being spent with just a few fields that are not well defined. Both teams then are stalled while someone embarks on a search mission with the business folks on what exactly field A or B means.

Typical example: partners in SAP. Too many times I'd get a request "where do we store customer number for a sales order". Well, there is not just a single "customer number". There is a "partner" concept in SAP and there could be sold-to, ship-to, bill-to, etc. partners. A week gets spent on running around asking multiple managers for a decision on what exactly is this mystery "customer".

Also I find it very helpful when there are data examples available from the legacy/partner system. Sometimes if the field's meaning is not very clear you can tell more by looking at the data in it. It also offers an early insight into possible data inconsistencies.

[Former Member]

well i guess u know that u dont map 1:1 based on SE16.

if ur question is, if it's a good tool to help: Yes it is!

mostly key-users get access to se16 during Migration. Later, users access normaly gets more restricted, because of security issues.

regards

Stefan