For those who are a curious reader inquisitive about learning more about SAP data models, you’ve come to the appropriate place!

Hello Medium readers! I’m excited to share some learnings from a recent project where I dived into the complexity of SAP’s data models.

For confidentiality reasons, I’m unable to share all of the project details 🤫. Nonetheless, I’ll discuss a challenge I faced regarding the complexity of SAP data models: what does the SAP data architecture looks like and the way does the whole lot fit right into a coherent data model that is smart for business users?

On this project, my primary focus was to integrate data into an analytics/mining platform using SAP business data on procurement processes. As I progressed, several questions arise regarding data modeling and finding my way through the varied tables of SAP’s database.

My goal was to create a coherent data model able to efficiently powering future dashboards, reports, and other analytical outputs planned in the subsequent steps. To realize this, I had to completely understand SAP data architecture basics, tables mapping and so forth. It was not a simple task but I managed to know this recent knowledge 🚀

1) SAP, a software leader in Entreprise Ressource Planning

As a lot of , SAP is among the many leading providers of ERP software, alongside others corresponding to Oracle and Infor. Currently, two generations of SAP ERP software exist: SAP ECC and its successor, SAP S/4 HANA.

The components of each softwares cover all company functions, which usually are not only inward-looking, but in addition outward-looking, as an illustration on the shopper side (CRM) and the supplier side (SCM). It’s made up of various modules covering all of the needs of an organization: Sales, Production, Logistics, Finance, Human Resources, After Sales Service.

It’s a software package that consolidates all business processes right into a single database. It also routinely considers the interdependencies between different processes. In other words, SAP or ERP softwares normally, function the center of business processes, powered by an unlimited amount of information and transactions.

For data analytics and process optimization projects, we will only say that it’s useful to integrate data from SAP and model it for front-end use to supply an end-to-end view of business processes and discover inefficiencies. Nonetheless, it will probably be difficult without first understanding how the info is organized in SAP.

2) SAP’s Data and Tables Types

How is SAP’s data organized? In short, multiple tables in SAP Database store all the info generated by SAP transactions, corresponding to making a vendor or a purchase order order within the case of procurement functions. It’s also essential to notice that while some tables remain stable over time, others store data capturing specific business events crucial for every day operations. The instance of making a vendor or a purchase order order in SAP illustrates this point well.

Let’s consider as an illustration an organization within the automotive sector. This company would have a vendor table listing those they incessantly work with to buy the materials needed to fabricate cars and other items. The creation of a brand new vendor on this table is a rare event that will only occur a number of times per yr. This table is known as a Master Table, which only stores Master Data.

Meanwhile, creating a purchase order order is an operational task. Purchasing teams throughout the same company incessantly use MM (Material Management) transactions to create purchase orders (e.g. hundreds of thousands of purchase orders). Consequently, the table storing all these purchase orders is known as a Transaction Table, and one of these data is often known as Transaction Data.

Each tables in SAP ECC and S/4 HANA have specific names. The Vendor Master Table is often known as the LFA1 table, while Purchase Orders are present in the EKKO Table. For somebody working with SAP tables for the primary time, it will not be immediately clear what each table represents based on its name. As an example, if I mention the names MCHA, MSEG, BSEG, etc., you’ll know these are SAP tables, but wouldn’t necessarily know what information they store. Do they contain production orders, financial accounts, or invoices?

That’s precisely why it was crucial for me to conduct research, take notes, and memorize the tables inside my project’s scope. More importantly, I needed to grasp the relationships and fields utilized in each table. At this stage, it’s also essential to map this data for quick comprehension.

3) Data Mapping of SAP Procurement Tables

A further challenge that you possibly can face in one of these project is knowing each the info architecture of SAP and the way procurement business processes are defined. Thankfully, my previous experience working on process improvement projects with procurement teams was useful when it got here to procurement processes. Before entering into the SAP Data Model or Mapping of procurement tables, let’s briefly review the fundamental objects handled in a procurement process.

To simplify, procurement is the technique of purchasing something, which might be raw materials, services, tools, etc., from a vendor. This process involves receiving the purchased items, verifying their condition, after which initiating the payment process, sometimes called the Accounting Payable process. Nonetheless, we is not going to cover this process in our scope.

Throughout this process, procurement teams undertake various tasks: they validate purchase requisitions, create purchase orders, and send these orders to vendors. Most of those tasks are performed using ERP software, specifically the MM (Material Management) module in SAP. During this flow of activities, key objects or components transition from one step to the subsequent:

• Purchase Requisitions: These are created internally, often by production teams, to tell procurement teams that a selected item must be purchased for production purposes.
• Purchase Orders: These are created by procurement teams and include detailed information in regards to the items to be bought, the amount, the seller who should receive the PO, and other relevant data.
• Goods Receipt: Upon receiving the products mentioned within the PO, a goods receipt is provided by the seller. This receipt is crucial for verifying that the products received within the warehouse match what was requested in the acquisition order.
• Invoice Receipt: This document confirms that the received goods and services are correct and as per the acquisition order. It’s incessantly used to initiate the payment process to the seller.

Each object in SAP has its associated Transaction Table that stores all of the created objects. For instance, as previously mentioned, Purchase Orders are stored within the EKKO Table. Nonetheless, there may be one other layer of complexity to think about in SAP Tables: the concept of header and item documents.

In SAP, an object or document corresponding to a purchase order order has two levels of representation: the header level and the item level. It’s because, conceptually, a document is all the time created with two levels of knowledge. The header incorporates general and aggregated data, while the items correspond to specific lines throughout the same document.

As an instance, imagine you’re buying a PS5, The Last of Us 2, and a headset.

Your final order will include a header along with your address and order number. The items you’re purchasing, together with their quantity (on this case, one among each item) and price, might be listed individually in line items

Then, a standard query is: does the EKKO table represent the header data or the item data? The proper answer is the header data. The item data is stored in a separate table called EKPO.

This core concept is crucial because it applies to nearly all of SAP objects/documents. Invoices can have one table for header data and one other for items, as will goods receipts. Nonetheless, purchase requisitions are an exception, having only an items table.

To integrate and analyze SAP procurement’s data, I needed to discover the suitable tables to extract and understand their relationships to construct a corresponding data model. The mapping I did to visualise how these data elements interconnect is detailed below:

Clearly, the mapping I even have done primarily focuses on the basic transaction tables of the procurement process. Additional tables, corresponding to master tables and other transaction tables — for instance, those storing changes to buy orders — might be included within the mapping.

This mapping also highlights the relationships between tables, whether or not they are one-to-one, one-to-many, or many-to-many. Moreover, it includes the fields that form the first key of every object.

Understanding the role of every table and the potential relationships will be time-consuming. Nonetheless, quite a few resources can be found to help, corresponding to those who helped me create this high-level procurement data mapping. For those who’re inquisitive about learning more about SAP tables, consider visiting this website. It provides an in depth overview of every SAP table, including primary keys, fields, possible values, etc. You simply have to type the name of the table you’re on the lookout for, for e.g. MSEG and you’re going to get more details in regards to the table’s structure and kind of stored information:

Search SAP tables | LeanX

Finally, if this text got you more interested in SAP data models for other business functions, don’t hesitate to ascertain SAP Community website. You will see some interesting content, as an illustration the identical high-level data mapping for finance functions:

A Relationship (basic) of MM and FI tables — SAP Community