topic SE16N Support of Data mapping? in Application Development and Automation Discussions

SE16N Support of Data mapping?

Former Member — Fri, 07 Sep 2018 17:35:43 GMT

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

Re: SE16N Support of Data mapping?

Colleen — Sat, 08 Sep 2018 10:02:27 GMT

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?

Re: SE16N Support of Data mapping?

SimoneMilesi — Mon, 10 Sep 2018 12:50:19 GMT

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.

Re: SE16N Support of Data mapping?

Former Member — Tue, 11 Sep 2018 04:18:42 GMT

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.

Re: SE16N Support of Data mapping?

Colleen — Tue, 11 Sep 2018 05:25:02 GMT

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.

Re: SE16N Support of Data mapping?

Former Member — Tue, 11 Sep 2018 14:44:01 GMT

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.

Re: SE16N Support of Data mapping?

Former Member — Tue, 11 Sep 2018 14:45:44 GMT

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.

Re: SE16N Support of Data mapping?

pokrakam — Tue, 11 Sep 2018 16:36:35 GMT

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.

Re: SE16N Support of Data mapping?

Former Member — Tue, 11 Sep 2018 19:08:18 GMT

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

Re: SE16N Support of Data mapping?

Jelena_Perfiljeva — Wed, 12 Sep 2018 19:57:23 GMT

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.

Re: SE16N Support of Data mapping?

Former Member — Thu, 13 Sep 2018 09:23:20 GMT

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