S/4HANA SD Enterprise Structure & Master Data: Sales Org, Distribution Channel, Division, Customer Master & Output Determination – Full Hands‑On Guide | Part 23 | FreeLearning365

 

Day 8 – SD Enterprise Structure & Master Data: Sales Org, Division, Distribution Channel & Output Determination

Functional Consultant Track – Part 23

Welcome to Day 8, the day we officially enter the world of Sales & Distribution. You’ve already built the financial accounting, controlling, and materials management backbone of GlobalTech. Now it’s time to configure the commercial arteries that bring revenue into the company. SD is unique because it’s the most customer‑facing part of SAP – every sales order, every delivery, every invoice originates here. A misstep in SD configuration doesn’t just cause a report error; it can literally stop orders from being entered, deliveries from being picked, and invoices from being sent.

Today, we start at the very foundation: the SD enterprise structure. We’ll define sales organisations, distribution channels, and divisions, and then link them together in the assignment chain that allows SAP to recognise a valid sales area. From there, we’ll create shipping points and set up route determination – so that when a sales order is created, the system automatically knows from where to ship and which route to take. Then we’ll build the complete customer master with all partner functions (sold‑to, ship‑to, bill‑to, payer). We’ll configure material master SD views and the customer‑material info record – a tiny but mighty object. Finally, we’ll make the system talk: output determination for delivery notes and billing documents, so that when goods leave the warehouse, the paperwork automatically generates.

By the end of this 20,000‑word hands‑on session, you’ll have built the entire SD master data foundation for GlobalTech’s global operations. You’ll see the config screens, the transaction codes, the pitfalls, and the best practices that only experienced SD consultants know.

1. The SD Enterprise Structure – Sales Org, Distribution Channel, Division

The SD enterprise structure is the framework that segments your market and defines how you sell. It’s a three‑level hierarchy: Sales Organisation (the highest) → Distribution Channel (the path to customer) → Division (the product line). Together, these three form a Sales Area, which is the master data and pricing key. Let’s build GlobalTech’s structure.

1.1 Sales Organisation

A sales organisation is the central organisational unit in SD, responsible for selling products and negotiating conditions. It’s assigned to exactly one company code for financial accounting purposes. GlobalTech needs:

• US01 – Sales Organisation US (company code GT01)
• DE01 – Sales Organisation Germany (company code GT02)
• IN01 – Sales Organisation India (company code GT03)

SPRO path: Enterprise Structure → Definition → Sales and Distribution → Define, copy, delete, check sales organization (transaction OVX5).

Create the three sales orgs. For each, maintain the address, currency (USD for US01, EUR for DE01, INR for IN01), and customer number range (internal/external). After creation, assign them to company codes via: Enterprise Structure → Assignment → Sales and Distribution → Assign sales organization to company code (transaction OVX3). Link US01 to GT01, DE01 to GT02, IN01 to GT03.

1.2 Distribution Channel

Distribution channels represent the ways goods reach the customer – e.g., wholesale, retail, direct. GlobalTech sells through:

• 10 – Wholesale (bulk, B2B)
• 20 – Direct (online sales directly to end‑user)
• 30 – OEM (original equipment manufacturer, components)

In SPRO: Enterprise Structure → Definition → Sales and Distribution → Define, copy, delete, check distribution channel (transaction OVXI). Create channels 10, 20, 30. No assignment to company code; distribution channels are cross‑company.

1.3 Division

Divisions represent product groups. GlobalTech’s divisions:

• P1 – Pumps & Valves
• P2 – Motors & Drives
• P3 – Services & Spare Parts

SPRO: Enterprise Structure → Definition → Sales and Distribution → Define, copy, delete, check division (transaction OVXB). Create divisions P1, P2, P3.

1.4 The Sales Area – The Assignment Chain

A sales area is a valid combination of sales organisation, distribution channel, and division. Not all combinations need to be valid; you must explicitly assign distribution channels and divisions to each sales organisation.

SPRO: Enterprise Structure → Assignment → Sales and Distribution → Set up sales areas (transaction OVXK). This is the assignment of:

• Sales org → allowed distribution channels
• Sales org → allowed divisions (if divisions are sales‑org‑specific)

For GlobalTech, US01 uses channels 10 and 20; DE01 uses 10 and 30; IN01 uses 10 only. Divisions P1, P2, P3 are allowed for all sales orgs. In OVXK, you’ll link:

• US01 with 10 and 20
• US01 with P1, P2, P3
• DE01 with 10, 30
• DE01 with P1, P2, P3
• IN01 with 10
• IN01 with P1, P2, P3

Now, the system knows that a sales order for sales area US01 / 10 / P1 (wholesale pumps) is valid, but US01 / 30 (OEM) is not allowed. This validation occurs at order entry, preventing configuration drift.

2. Shipping Points, Loading Points, and Route Determination

While sales organisation is about commercial responsibility, shipping is about physical execution. The shipping point is the highest‑level organisational unit in shipping. It’s assigned to a plant. Each delivery must be processed through exactly one shipping point.

2.1 Define Shipping Points

SPRO: Enterprise Structure → Definition → Logistics Execution → Define, copy, delete, check shipping point (transaction OVXD).

GlobalTech’s shipping points:

• SP01 – US Main Shipping (assigned to plant GT01)
• SP02 – US Spare Parts Shipping (plant GTSP)
• SP03 – Germany Shipping (plant GT02)
• SP04 – India Shipping (plant GT03)

For each shipping point, you set the factory calendar, working times, and the “Determination” times (pick/pack/load). The shipping point also has an address and can be assigned a loading point later, but loading points are not mandatory.

2.2 Loading Points (Optional)

Loading points are sub‑divisions of a shipping point, like a specific ramp or dock. If you don’t need them, you can skip. In OVXD, you can create loading points for a shipping point. For example, SP01 might have “DOCK1” and “DOCK2” as loading points. These can be manually entered in the delivery or determined via route. For simplicity, GlobalTech uses only shipping points.

2.3 Route Determination – Automatically Find the Path

Route determination is the automatic assignment of a route (and optionally, a shipping point) to a sales document or delivery based on several factors. The route is crucial for delivery scheduling and shipping cost calculation. It relies on two key master data fields:

• Shipping Condition – defined in the customer master or sales document header, e.g., “As soon as possible” (standard), “Road”, “Air”.
• Transportation Group – defined in the material master, e.g., “Pallet”, “Bulk”, “Dangerous Goods”.

Configuration steps:

Step 1: Define Modes of Transport.
SPRO: Logistics Execution → Transportation → Basic Transportation Functions → Route → Define Routes → sub‑step Define Modes of Transport. Already delivered: 01 Road, 02 Rail, 03 Sea, etc. We’ll use them.

Step 2: Define Shipping Types – e.g., “Standard”, “Express”. We can use standard 01.

Step 3: Define Routes.
SPRO: Logistics Execution → Transportation → Basic Transportation Functions → Route → Define Routes (transaction OVTC). Create routes:

• R1001 – Local US Truck (mode 01, transit time 2 days).
• R1002 – US to Germany Sea (mode 03, transit 14 days).
• R1003 – US to India Air (mode 05, transit 3 days).

Step 4: Define Route Determination.
SPRO: Logistics Execution → Transportation → Basic Transportation Functions → Route → Define Route Determination (transaction OVTC or O7E1). You create a condition table (e.g., based on Country/Shipping Condition/Transportation Group). Generate the determination. For each combination, you assign a route.

For GlobalTech:

• Departure country US, shipping condition “01” (Standard), transportation group “0001” (no restriction) → route R1001 (local truck).
• Departure country US, shipping condition “01”, destination country DE → route R1002 (sea).
• Departure country US, shipping condition “03” (Express), destination country IN → route R1003 (air).

In the customer master, you set the shipping condition (sold‑to view, “Shipping” tab). In the material master, you set the transportation group (“Sales: General/Plant” view). At sales order creation, the system determines the shipping point from the delivering plant (which comes from the customer‑material info record or customer master), and the route from the condition table. This is a beautiful piece of logistic automation.

2.4 Hands‑On Test

Create a customer CUSTUS01 (US), with shipping condition “01”. Create material FERT01 with transportation group “0001”. Enter a sales order in VA01 for sales area US01/10/P1. The system proposes plant GT01 (from customer master or manual entry), then determines route R1001 and shipping point SP01. If the order has a ship‑to party in Germany, the system can also determine the cross‑border route automatically. This saves order entry time and prevents errors.

3. Customer Master Data – Partner Functions (Sold‑To, Ship‑To, Bill‑To, Payer)

The customer master is the heart of SD. It contains all information needed for sales, shipping, and billing. In SAP, a customer can play different roles (partner functions) in a sales transaction. The four main partner functions are:

• Sold‑to (AG) – places the order, receives order confirmations.
• Ship‑to (WE) – receives the goods (physical delivery).
• Bill‑to (RE) – receives the invoice.
• Payer (RG) – pays the invoice (often same as bill‑to).

GlobalTech deals with complex customer hierarchies: a head office places the order (sold‑to), but deliveries go to multiple branches (ship‑to), invoices go to the head office (bill‑to), and a central parent company pays (payer). We must configure these as separate customer master records and link them via partner determination.

3.1 Customer Account Groups

Just like vendors, customer account groups control the number range, field status, and whether the customer is a one‑time account. SPRO: Financial Accounting → Accounts Receivable → Customer Master Data → Preparations → Define Account Groups with Screen Layout (Customers) (transaction OBD2). Already done in Part 17 (AR config). We’ll use:

• DOMC – Domestic customers (sold‑to, bill‑to, etc.)
• FORC – Foreign customers
• ONEC – One‑time customers (used for walk‑ins)

We also need a separate account group for pure ship‑to parties if we want to restrict them from being used as sold‑to. Many companies create a dedicated account group “SHIP” that only allows the general and company code views but not sales area data (since ship‑to itself may not have pricing). In OBD2, we’ll create “SHIP” with a separate number range and a screen layout that hides the sales area views. For simplicity, GlobalTech uses DOMC for all roles and relies on partner determination to link them.

3.2 Creating Partner Roles (XD01 / FD01)

Create customer master records using transaction XD01 (central creation) or FD01 (FI view). For SD, we use XD01 with all views.

Create sold‑to “CUST‑SOLD01” (account group DOMC) for US01/10/P1 sales area. Enter address, tax, and sales data: shipping condition 01, delivering plant GT01, etc. Then create ship‑to “CUST‑SHIP01” (account group DOMC, but as a separate customer number) with address. Create bill‑to “CUST‑BILL01” similarly. Set up the partner relationships in the customer master. In the sold‑to master, under the “Partner Functions” tab (transaction XD02 → Sales Area Data → Partner Functions), you can maintain default ship‑to, bill‑to, and payer for each sales area. For example, for CUST‑SOLD01 in sales area US01/10/P1, set ship‑to = CUST‑SHIP01, bill‑to = CUST‑BILL01, payer = CUST‑BILL01 (or a separate payer). When you create a sales order for CUST‑SOLD01, these partner functions are automatically copied to the sales document, and you can override if needed.

Partner Determination Procedure controls which partner functions are allowed and required. Standard procedure “AG” (sold‑to) already includes mandatory AG and optional WE, RE, RG. You can modify in SPRO: Sales and Distribution → Basic Functions → Partner Determination → Set Up Partner Determination (transaction VOPAN). For GlobalTech, we keep standard but ensure “WE” is mandatory for certain sales document types? Not yet; we’ll handle that later.

4. Material Master SD Views – Sales Org, MRP, Plant Data

A material must be extended to a sales organisation and distribution channel before you can sell it. This creates the SD‑specific views: Sales Org 1, Sales Org 2, and the sales‑relevant part of the Plant/Storage views.

4.1 Sales Org 1 View

Contains: base unit of measure (must match the material base UOM), delivering plant, delivery unit, taxation data (tax classification), and the material pricing group. Key fields:

• Delivering Plant – the plant from which the material is normally delivered. This plant must be connected to the sales org via the distribution chain. It’s the default for sales orders and can be overwritten.
• Tax Classification – determines the tax condition in pricing. For US, we set tax classification “1” (full tax) or “0” (exempt).
• Material Statistics Group – used for reporting.

4.2 Sales Org 2 View

Contains: account assignment group, which determines which revenue account is used (in OBYC via transaction key ERL). GlobalTech sets account assignment group “01” for standard products, “02” for services. This drives automatic postings during billing.

4.3 MRP Views (MRP 1‑4)

These are shared with production planning but highly relevant for SD because they control availability check and delivery scheduling. The MRP 3 view contains the Availability Check group. Standard groups:

• 01 – Daily requirement (summary).
• 02 – Individual requirements (for make‑to‑order).

GlobalTech uses 01 for finished goods. The availability check is triggered in the sales order based on this group plus the “Checking Rule” from the schedule line category. We’ll configure that in a later part.

MRP 1 view: MRP type (PD – MRP), lot size (FX – fixed lot, etc.). Not directly SD but impact delivery times.

MRP 2 view: scheduling margin key, which determines floats for production.

4.4 Plant/Storage Data (SD‑Relevant Fields)

In the Plant Data/Storage views, the “Shipping data” tab contains:

• Transportation Group – used in route determination.
• Loading Group – used in shipping point determination (e.g., crane, fork‑lift).
• Shipping Unit – default delivery unit.

We set transportation group “0001” for normal palletised goods, “0002” for bulk liquid (pumps). This is essential for automatic route determination.

4.5 Extending a Material to Sales Org (MM01/MM50)

Transaction MM01 – create material, choose views Basic Data, Sales Org 1, Sales Org 2, and optionally MRP 1‑3, Plant/Storage. For an existing material, use MM50 (Extend Material). Enter material FERT01, then choose the views, and enter the new sales org (US01) and distribution channel (10). Fill all fields. Save. Now the material can be sold.

5. Customer‑Material Info Record (VD51) – The Cross‑Reference Powerhouse

A customer‑material info record links a customer and a material for a specific sales area. It stores:

• The customer’s own material number (cross‑reference), which can be printed on delivery notes and invoices.
• Customer‑specific delivery tolerances (over/under‑delivery).
• Customer‑specific minimum order quantity.
• Default delivering plant (overriding the material master).

This object is often overlooked by novice consultants, but it’s a hidden gem for B2B operations. GlobalTech’s large OEM customer “OEMCORP” demands that their material number “OEM‑PUMP‑A” appears on all documents.

5.1 Create Info Record (VD51)

Transaction VD51. Enter customer “OEMCORP”, material “FERT01”, sales area US01/10/P1. Enter:

• Customer Material: OEM‑PUMP‑A
• Delivery Priority: 1 (high)
• Minimum Delivery Quantity: 10 pieces
• Planned Delivery Time: 3 days (overrides material master)

Save. Now create a sales order for OEMCORP. In the order line item, the system automatically pulls the customer material number, which is displayed in the “Customer Material” field. It can be printed on the order confirmation, delivery note, and invoice using output forms. This delights customers and reduces order entry errors.

5.2 How Customer‑Material Info Record Affects Delivery

If you set a minimum delivery quantity of 10, and the sales order has only 5, the system can issue a warning or block the order, depending on the configuration of the delivery item category (we’ll cover later). It’s a powerful control.

6. Output Determination – Let the System Talk Automatically

Output determination is the process of automatically generating documents (print, email, EDI, fax) when a specific business event occurs. In SD, the most important outputs are the order confirmation, delivery note, and billing document. Each uses a condition technique similar to pricing.

6.1 Billing Output (BA00) – Invoice / Invoice List

The standard output type for billing is RD00 (Invoice) or BA00 (Order Confirmation? Actually, BA00 is the output type for billing documents, often used for invoice). Let’s clarify: Standard SAP uses output type RD00 for billing documents, and LD00 for delivery notes. However, many projects rename or create copies. For GlobalTech, we’ll use standard RD00 for billing output and LD00 for delivery output. The configuration logic is identical.

Output determination procedure is assigned to the billing document type (e.g., F2 – Invoice). The procedure contains a list of allowed output types, with requirements and access sequences.

6.2 Configuring Output Determination – Step by Step

Step 1: Define Output Types.
SPRO: Sales and Distribution → Basic Functions → Output Control → Output Determination → Output Determination Using Condition Technique → Maintain Output Determination for Billing Documents → Define Output Types (transaction V/30 or NACE).

Output type RD00 already exists. Double‑click it to see settings:

• Access sequence: 0001 (standard).
• Transmission medium: 1 (Print) or 5 (EDI) or 7 (Simple Mail). We’ll use 7 (Email).
• Partner function: RE (Bill‑to).
• Processing routine: program RSNAST00, form routine ENTRY.

We can create a copy ZD00 for email invoices with transmission medium 7.

Step 2: Define Access Sequence.
Access sequence 0001 for billing output checks condition tables. You can maintain it in V/07. Standard is based on Customer + Sales Org + Billing Type. We can add a table for Customer + Sales Org + Output Type.

Step 3: Maintain Condition Records (VV11 / VV21).
Transaction VV11 (or VV21 for billing). Enter output type RD00, then specify the key combination: e.g., Sales Org US01, Customer CUST‑BILL01. Then define the medium (email), email address, language, and whether it’s automatically output (immediate). Set “Dispatch time” = 4 (Immediately when saving the application). Now, whenever a billing document for that customer and sales org is saved, the system generates an output, which can be sent via email using SMTP (configured in SCOT).

6.3 Delivery Output (LD00) – Delivery Note

Similar configuration. Output type LD00 is assigned to delivery document type (e.g., LF). Access sequence 0001. Condition record: VV21 (or VV11 for delivery), choose output type LD00, enter ship‑to party, etc. When a delivery is saved, the output is generated and can be printed or emailed.

GlobalTech wants delivery notes automatically printed at warehouse dispatch. We’ll set up output type LD00 with medium 1 (Print) and the printer’s name, or medium 7 (Email) to send a PDF to the warehouse team. Condition record based on shipping point SP01 and ship‑to CUST‑SHIP01 ensures the right output.

6.4 Output Determination Procedure Assignment

Ensure output determination procedure is assigned to the billing type (F2). SPRO: Sales and Distribution → Billing → Billing Documents → Define Billing Types. Find F2, check “Output Determination Procedure” = V10000 (standard). For delivery, assignment is in Logistics Execution → Shipping → Deliveries → Define Delivery Types. For LF, output procedure is V10000. So RD00 and LD00 are already included in the procedure. We just need to add our new output types if we created custom ones, or simply use the standards.

6.5 Testing Output

Create a billing document in VF01. Save. Check output in VF03 (display billing document, menu: Billing Document → Output). You’ll see a green light meaning output was processed. If email is configured, the customer receives the invoice PDF. Magic.

7. Full Scenario – From Sales Order to Delivery with Master Data in Action

Let’s simulate a real sales cycle for GlobalTech to see how the pieces connect.

Step 1 – Master Data Setup: Sold‑to CUST‑SOLD01 (US01/10/P1), ship‑to CUST‑SHIP01, bill‑to CUST‑BILL01, partner links set. Material FERT01 extended to US01/10/P1, delivering plant GT01, transportation group 0001. Customer‑material info record for OEMCORP (CUST‑SOLD01) with customer material “OEM‑PUMP‑A”. Output condition record: for billing type F2, customer CUST‑BILL01, output RD00, email immediate. For delivery LF, ship‑to CUST‑SHIP01, output LD00, print immediate.

Step 2 – Sales Order (VA01): Enter sold‑to CUST‑SOLD01, PO number “PO‑2025‑001”, material FERT01, quantity 50 units. The system automatically proposes:

• Ship‑to, bill‑to, payer from partner determination.
• Customer material number OEM‑PUMP‑A in the item overview.
• Plant GT01 (from customer info record or material), shipping point SP01, route R1001 (domestic).
• Availability check confirms stock, schedule lines calculated.

Save the order. No output is triggered for order confirmation (we can add later).

Step 3 – Delivery (VL01N): Create delivery for the sales order. Delivery document type LF. The system copies the shipping point SP01, route R1001. The ship‑to address is from CUST‑SHIP01. Pick/pack if configured. Post goods issue (movement type 601). At save, output LD00 is generated – a delivery note is printed in the warehouse. The material document posts: credit finished goods inventory 20000030, debit COGS 40000080.

Step 4 – Billing (VF01): Create billing document. The system copies partner functions, and output RD00 generates an invoice PDF and emails it to the bill‑to. The FI document posts: debit customer AR 31000010, credit revenue 50000010. The cycle is complete.

The smooth flow demonstrates the power of correctly configured SD master data and output determination. Every field that popped up automatically saved time and prevented error.

8. Best Practices, Pitfalls, and Alternatives

Best Practices:

• Design your sales areas to reflect how you actually sell, not how you report. Over‑complicating with too many distribution channels and divisions leads to master data explosion and reporting complexity.
• Set up partner determination carefully. The sold‑to partner should always have default ship‑to, bill‑to, and payer maintained. Use the “Partner Determination Procedure” to make ship‑to mandatory for certain order types if you always ship to a customer location.
• Use the customer‑material info record for every customer that provides their own material numbers or needs specific delivery tolerances. It’s a small effort with huge customer satisfaction return.
• Test route determination with all combinations of shipping conditions, transportation groups, and countries before go‑live. A missed route means manual entry and potential logistics errors.
• For output, always use the “condition record” approach rather than hard‑coding printers. This makes changes easy without transport requests.
• Keep output medium flexible – many customers now want email instead of print; condition records can be changed instantly.

Common Pitfalls:

• Forgetting to extend the material master to the sales org/channel results in error “Material not maintained for sales area” in sales orders.
• Missing shipping point determination: if the delivering plant doesn’t have a valid shipping point assigned, the delivery creation fails with “Shipping point cannot be determined”. The assignment of shipping point to plant is done in SPRO: Logistics Execution → Shipping → Basic Shipping Functions → Shipping Point Determination → Assign Shipping Points (transaction OVL2).
• Output not generating: check the condition record, the output determination procedure, and the processing time (immediate vs. batch). Often the output is set to “batch” and nobody runs RSNAST00.
• Partner functions not copying: the sold‑to master must have the default partner functions maintained in the sales area data. If missing, the order entry clerk must manually enter them, causing delays.

Alternatives and When to Use Them:

• Instead of a dedicated sales area per combination, you can use “Sales District” or “Customer Group” for segmentation and keep sales areas minimal. Choose what aligns with the business.
• For output, SAP now offers BRF+ output management in S/4HANA (using Output Management framework). This is more flexible, template‑based, and Fiori‑driven. Classic NACE output is still supported but for new implementations, BRF+ is recommended. However, for learning purposes, classic NACE is the foundation and still widely used.
• Shipping point determination can be automated via a user exit if complex plant/shipping point relationships exist.

9. Conclusion – The SD Foundation Is Built

Day 8 has given you the complete SD enterprise structure and master data configuration toolkit. You’ve created sales orgs, distribution channels, and divisions; assigned them into valid sales areas; built shipping points and route determination logic; mastered customer master partner functions; extended materials to sales orgs; set up customer‑material info records; and configured output determination for deliveries and invoices. These are the building blocks upon which every sales document, every delivery, and every invoice will rely.

Tomorrow, on Day 9 (Part 24), we dive into SD Document Flow Config – Order Types, Item Categories, Schedule Lines. You’ll learn how a sales order type controls the entire transaction flow, how item categories determine behaviour, and how schedule lines manage availability and MRP. It’s going to be intense and incredibly rewarding. See you then.

@FreeLearning365 – Tech Partner @techbook24