If you’re a curious reader involved in studying extra about SAP knowledge fashions, you’ve come to the suitable place!
Hiya Medium readers! I’m excited to share some learnings from a current challenge the place I dived into the complexity of SAP’s knowledge fashions.
For confidentiality causes, I’m unable to share all of the challenge particulars 🤫. Nevertheless, I’ll talk about a problem I confronted relating to the complexity of SAP knowledge fashions: what does the SAP knowledge structure seems like and the way does the whole lot match right into a coherent knowledge mannequin that is smart for enterprise customers?
On this challenge, my main focus was to combine knowledge into an analytics/mining platform utilizing SAP enterprise knowledge on procurement processes. As I progressed, a number of questions come up relating to knowledge modeling and discovering my approach via the assorted tables of SAP’s database.
My aim was to create a coherent knowledge mannequin able to effectively powering future dashboards, experiences, and different analytical outputs deliberate within the subsequent steps. To attain this, I needed to totally perceive SAP knowledge structure fundamentals, tables mapping and so forth. It was not a simple activity however I managed to understand this new data 🚀
1) SAP, a software program chief in Entreprise Ressource Planning
As a lot of you realize, SAP is among the many main suppliers of ERP software program, alongside others resembling Oracle and Infor. At present, two generations of SAP ERP software program exist: SAP ECC and its successor, SAP S/4 HANA.
The parts of each softwares cowl all firm features, which aren’t solely inward-looking, but additionally outward-looking, as an example on the shopper aspect (CRM) and the provider aspect (SCM). It’s made up of various modules overlaying all of the wants of an organization: Gross sales, Manufacturing, Logistics, Finance, Human Assets, After Gross sales Service.
It’s a software program bundle that consolidates all enterprise processes right into a single database. It additionally mechanically considers the interdependencies between completely different processes. In different phrases, SAP or ERP softwares generally, function the center of enterprise processes, powered by an enormous quantity of information and transactions.
For knowledge analytics and course of optimization initiatives, we are able to solely say that it’s useful to combine knowledge from SAP and mannequin it for front-end use to supply an end-to-end view of enterprise processes and determine inefficiencies. Nevertheless, it may be difficult with out first understanding how the information is organized in SAP.
2) SAP’s Knowledge and Tables Sorts
How is SAP’s knowledge organized? In short, a number of tables in SAP Database retailer all the information generated by SAP transactions, resembling making a vendor or a purchase order order within the case of procurement features. It’s additionally essential to notice that whereas some tables stay steady over time, others retailer knowledge capturing particular enterprise occasions essential for each day operations. The instance of making a vendor or a purchase order order in SAP illustrates this level nicely.
Let’s contemplate as an example an organization within the automotive sector. This firm would have a vendor desk itemizing these they steadily work with to buy the supplies wanted to fabricate vehicles and different objects. The creation of a brand new vendor on this desk is a uncommon occasion that will solely happen a number of occasions per yr. This desk is known as a Grasp Desk, which solely shops Grasp Knowledge.
In the meantime, creating a purchase order order is an operational activity. Buying groups throughout the identical firm steadily use MM (Materials Administration) transactions to create buy orders (e.g. hundreds of thousands of buy orders). Consequently, the desk storing all these buy orders is known as a Transaction Desk, and any such knowledge is called Transaction Knowledge.
Each tables in SAP ECC and S/4 HANA have particular names. The Vendor Grasp Desk is called the LFA1 desk, whereas Buy Orders are discovered within the EKKO Desk. For somebody working with SAP tables for the primary time, it might not be instantly clear what every desk represents based mostly on its title. As an example, if I point out the names MCHA, MSEG, BSEG, and many others., you’ll know these are SAP tables, however wouldn’t essentially know what info they retailer. Do they comprise manufacturing orders, monetary accounts, or invoices?
That’s exactly why it was essential for me to conduct analysis, take notes, and memorize the tables inside my challenge’s scope. Extra importantly, I wanted to grasp the relationships and fields utilized in every desk. At this stage, it’s additionally essential to map this knowledge for fast comprehension.
3) Knowledge Mapping of SAP Procurement Tables
A further problem that you can face in any such challenge is knowing each the information structure of SAP and the way procurement enterprise processes are outlined. Fortunately, my earlier expertise engaged on course of enchancment initiatives with procurement groups was useful when it got here to procurement processes. Earlier than getting into the SAP Knowledge Mannequin or Mapping of procurement tables, let’s briefly overview the primary objects dealt with in a procurement course of.
To simplify, procurement is the method of buying one thing, which may very well be uncooked supplies, providers, instruments, and many others., from a vendor. This course of entails receiving the bought objects, verifying their situation, after which initiating the cost course of, sometimes called the Accounting Payable course of. Nevertheless, we won’t cowl this course of in our scope.
All through this course of, procurement groups undertake varied duties: they validate buy requisitions, create buy orders, and ship these orders to distributors. Most of those duties are carried out utilizing ERP software program, particularly the MM (Materials Administration) module in SAP. Throughout this circulation of actions, key objects or parts transition from one step to the following:
- Buy Requisitions: These are created internally, usually by manufacturing groups, to tell procurement groups {that a} particular merchandise must be bought for manufacturing functions.
- Buy Orders: These are created by procurement groups and embrace detailed details about the objects to be purchased, the amount, the seller who ought to obtain the PO, and different related knowledge.
- Items Receipt: Upon receiving the products talked about within the PO, a items receipt is supplied by the seller. This receipt is essential for verifying that the products obtained within the warehouse match what was requested within the buy order.
- Bill Receipt: This doc confirms that the obtained items and providers are right and as per the acquisition order. It’s steadily used to provoke the cost course of to the seller.
Every object in SAP has its related Transaction Desk that shops all of the created objects. For instance, as beforehand talked about, Buy Orders are saved within the EKKO Desk. Nevertheless, there may be one other layer of complexity to contemplate in SAP Tables: the idea of header and merchandise paperwork.
In SAP, an object or doc resembling a purchase order order has two ranges of illustration: the header stage and the merchandise stage. It is because, conceptually, a doc is at all times created with two ranges of data. The header incorporates basic and aggregated knowledge, whereas the objects correspond to particular strains throughout the identical doc.
As an example, think about you might be shopping for a PS5, The Final of Us 2, and a headset.
Your ultimate order will embrace a header along with your deal with and order quantity. The objects you’re buying, together with their amount (on this case, one in all every merchandise) and value, might be listed individually in line objects
Then, a standard query is: does the EKKO desk characterize the header knowledge or the merchandise knowledge? The proper reply is the header knowledge. The merchandise knowledge is saved in a separate desk referred to as EKPO.
This core idea is crucial because it applies to nearly all of SAP objects/paperwork. Invoices could have one desk for header knowledge and one other for objects, as will items receipts. Nevertheless, buy requisitions are an exception, having solely an objects desk.
To combine and analyze SAP procurement’s knowledge, I wanted to determine the suitable tables to extract and perceive their relationships to construct a corresponding knowledge mannequin. The mapping I did to visualise how these knowledge components interconnect is detailed beneath:
Clearly, the mapping I’ve completed primarily focuses on the elemental transaction tables of the procurement course of. Extra tables, resembling grasp tables and different transaction tables — for instance, these storing modifications to buy orders — may very well be included within the mapping.
This mapping additionally highlights the relationships between tables, whether or not they’re one-to-one, one-to-many, or many-to-many. Moreover, it consists of the fields that kind the first key of every object.
Understanding the function of every desk and the potential relationships might be time-consuming. Nevertheless, quite a few assets can be found to help, resembling people who helped me create this high-level procurement knowledge mapping. If you happen to’re involved in studying extra about SAP tables, contemplate visiting this web site. It gives an in depth overview of every SAP desk, together with main keys, fields, potential values, and many others. You solely have to kind the title of the desk you’re searching for, for e.g. MSEG and you’ll get extra particulars in regards to the desk’s construction and kind of saved info:
Lastly, if this text acquired you extra interested in SAP knowledge fashions for different enterprise features, don’t hesitate to examine SAP Group web site. You will see that some attention-grabbing content material, as an example the identical high-level knowledge mapping for finance features: