S/4HANA SD Special Sales Scenarios: Returns, Free Goods, Consignment, Third‑Party, MTO & Inter‑company – Complete Hands‑On Guide | Part 25 | FreeLearning365

 

Day 10 – SD Special Sales Scenarios: Returns, Free Goods, Consignment, Third‑Party, MTO & Inter‑company Sales

Functional Consultant Track – Part 25

Welcome to Day 10, the grand finale of the SD configuration deep dive. By now, you’ve built the entire standard order‑to‑cash machinery. But real businesses are never this simple. Customers return goods. Suppliers ship directly to your customers. You give away free cartons to boost sales. You hold consignment stock at a distributor’s site. And you sell across your own company codes. Today, we cover all these special sales processes in one intense, 20,000‑word hands‑on session. You’ll leave with the ability to configure, execute, and troubleshoot the scenarios that make up 30‑40% of any SD consultant’s project work.

Our client GlobalTech is expanding aggressively. They’re launching a trade promotion with free goods. They’re starting a consignment program with a major distributor. They’re sourcing a specialised motor from an Italian supplier and shipping it directly to a US customer (third‑party). A key turbine is built only after the customer orders it (make‑to‑order). And their US sales team frequently sells products that are physically shipped from the German plant, requiring inter‑company billing. You’ll configure every single one of these processes in your sandbox, following exact SPRO paths and posting real documents.

1. Returns Processing and Credit Notes – The Reverse Logistics Engine

Returns are inevitable. A customer receives a damaged product or simply changes their mind. SAP handles returns through a dedicated document flow: return order → returns delivery → credit memo. The goal is to receive the goods back into inventory (or blocked stock) and issue a credit to the customer.

1.1 Return Order Type and Item Category

The standard return order type is RO. Its item category is REN (Return Item). We verified copy control in Part 24: RO → returns delivery type LR. The billing type for returns is G2 (Credit Memo). All must be correctly linked.

In SPRO: Sales and Distribution → Sales → Sales Documents → Sales Document Header → Define Sales Document Types (VOV8). Check RO: delivery type LR, billing type G2, and that the “Order‑related billing” flag is set? Actually, returns billing is usually delivery‑related (from the returns delivery). So the delivery type LR must have billing relevance, and the copy control from LR to G2 must exist.

1.2 Returns Delivery and Movement Types

When you create a returns delivery (VL01N with document type LR), the system uses movement type 651 (Return delivery to vendor? No, customer return to own stock). Standard movement types for returns:

• 651 – Return from customer to unrestricted stock (if goods are perfect).
• 652 – Return from customer to blocked stock (if quality inspection needed).

The movement type is determined by the return order’s item category and the material’s inspection settings. In GlobalTech, all returns go to blocked stock initially (movement type 652) for inspection. The warehouse then transfers to unrestricted via 321 or scraps via 551.

SPRO: Logistics Execution → Shipping → Deliveries → Define Movement Types for Returns (not a standard separate node; movement types are configured in MM). Actually, the link between delivery type LR and movement type is in Logistics Execution → Shipping → Deliveries → Define Delivery Types (VOV9 for delivery types? Actually, in 0VLK for delivery types). In delivery type LR, you specify the “Return movement type” as 651 or 652. For GlobalTech, we set default to 652.

1.3 Credit Memo Request and Billing

After the returns delivery is posted, the billing due list (VF04) proposes a credit memo (billing type G2). The FI posting: credit customer AR, debit revenue (or a returns account). The condition type for credit memo is automatically negative. The billing document references the return order, ensuring the credit matches the original invoice if the same price is used. If the price has changed, a pricing re‑determination can be allowed or blocked based on copy control settings.

In copy control VTFA (delivery to billing): source LR, target G2. Item category REN → billing item category REN (or standard). The “Pricing” field can be set to “B” (re‑determine) or “D” (copy). GlobalTech uses “B” to re‑determine price based on the current condition records, but usually for returns, you want to copy the original invoice price. So they set it to “D” and link the return to the original billing document via the “Reference” field in the return order.

1.4 Hands‑On Returns Scenario

Customer CUST‑SOLD01 returns 5 units of FERT01. Sales rep creates RO (VA01). Reference original billing document. Item category REN. The system proposes the original price. Save. Warehouse creates returns delivery (VL01N) with movement type 652. Post goods receipt: material document debits blocked stock (20000095), credits COGS or a returns account. The returns delivery posts FI: debit blocked stock, credit GR/IR? Wait, standard accounting for customer returns: For standard priced material, the return from customer posts: debit inventory (blocked), credit a returns clearing account (not revenue). The credit memo later clears that clearing account and credits the customer. So the sequence: Delivery return: debit blocked stock, credit returns clearing account (e.g., 40000090). Credit memo (G2): debit returns clearing, credit customer. This avoids touching revenue directly. In OBYC, the account for movement 652 is configured under transaction key GBB and account grouping for returns (usually VAX? No, returns use a separate account grouping, often “RET”). We must set up GBB entry for movement type 652 with account grouping “RET” and the returns clearing account. We’ll configure this quickly.

In OBYC, for GBB, add entry: Valuation mod. 0001, Account grouping “RET”, Valuation class 3200 → account 40000090 (Returns Clearing). Then assign account grouping “RET” to movement type 652 in OMJJ. Now the delivery return postings hit the clearing account. Billing then debits 40000090 and credits customer. Perfect.

2. Free Goods – Enhancing Orders with Giveaways

Free goods are items given at no charge based on a purchasing condition (e.g., buy 10, get 2 free). SAP supports two types: inclusive (the free quantity is included in the ordered item, like “10+2”) and exclusive (the free goods are a separate item on the order, maybe a different material). The condition technique masterfully automates this.

2.1 Inclusive Free Goods

Inclusive free goods add extra quantity to the same sales order item. The system automatically increases the ordered quantity by the free quantity, but only the net quantity is priced. Configuration:

SPRO: Sales and Distribution → Basic Functions → Free Goods → Define Free Goods Condition Tables and Define Free Goods Condition Types.

Standard condition type: NR00 (Free Goods – Quantity). We’ll use NR00. The access sequence is pre‑delivered. Then maintain a condition record via V/BN1 (for inclusive free goods) or V/BN2 (exclusive). For inclusive, transaction code is V/BN1.

GlobalTech: “Buy 100 cartons of PACK01, get 10 cartons free.” In V/BN1, enter sales org US01, distribution channel 10, material PACK01, minimum quantity 100, free quantity 10, calculation rule “Proportional” (so for 200, free 20). Save. In a sales order, enter PACK01, ordered quantity 150. The system automatically adds a free goods line with quantity 15 (proportional) and sets its price to zero. The item category for the free goods sub‑item is TAN but with pricing ‘0’. The total quantity delivered is 165, but the billing is only for 150. This is inclusive because the free goods are part of the same main item.

2.2 Exclusive Free Goods

Exclusive free goods add a separate order item, often a different material. For example, buy FERT01 and get a free accessory “ACCESS01”. Condition type is the same NR00 but exclusive free goods use a separate condition type (maybe custom). Standard condition type NA00 is for exclusive free goods. We can copy NA00 and maintain a condition record in V/BN2.

Set up: For material FERT01, min qty 1, free material ACCESS01, free quantity 1. In the sales order, when FERT01 is entered, the system automatically adds a second item for ACCESS01 with quantity 1 and zero price, with a reason “Free goods”. This separate item can be delivered and billed as zero. Great for cross‑selling.

2.3 Free Goods Accounting

Since the free item has zero price, the revenue is zero. But the cost of goods sold still applies when the item is delivered (via movement type 601). The COGS is debited, and inventory is credited. This means the free goods impact the profit margin – a cost without revenue. Management must approve such promotions.

3. Consignment – The Complete Four‑Transaction Cycle

We touched on consignment fill‑up (KE) and issue (KA) earlier, but now we complete the entire lifecycle: fill‑up, issue, returns, and pick‑up. This represents the real‑world handling of consignment stock at a customer site.

3.1 The Four Document Types

• KE – Consignment Fill‑Up: sends goods to customer’s consignment warehouse. No billing, no revenue. Stock moves from own unrestricted to consignment stock at customer.
• KA – Consignment Issue: when the customer actually uses/consumes the stock. This creates a billing document (invoice). The consignment stock decreases, and the customer is billed.
• KR – Consignment Returns: the customer returns unused consignment stock back to own stock. Similar to a return, but no credit memo because ownership never transferred.
• KB – Consignment Pick‑Up: GlobalTech physically retrieves the stock from the customer (e.g., end of contract). The consignment stock returns to own unrestricted.

3.2 Configuration Recap and New Insights

Document types KE, KA, KR, KB are standard. Item categories: KEN (fill‑up), KAN (issue), KRN (return), KBN (pick‑up). Copy control must be set: KE → delivery LF (for fill‑up), KA → billing F2 (for issue), etc.

Movement types for consignment: 631 (fill‑up to consignment), 632 (return from consignment to own), 633 (issue from consignment to customer), 634 (pick‑up from consignment to own). The account determination for consignment is crucial: during fill‑up (631), stock is moved to special stock “W” (consignment at customer). No FI posting because ownership retained. During issue (633), the system posts a goods issue from consignment stock and automatically generates a billing document. The FI: credit inventory (consignment), debit COGS (or consumption), and then billing debits customer and credits revenue.

3.3 Real‑Life Consignment Cycle for GlobalTech

GlobalTech places 500 units of PACK01 on consignment at a large distributor, CUST‑DIST01.

1. Fill‑up: order KE, delivery LF with movement 631. Stock moves to special stock W at customer. No accounting entry.

2. Issue: Distributor reports consumption of 300 units. Sales rep creates KA order (consignment issue). Reference to the fill‑up? Not required. Deliver? No, the issue is directly a billing request. The KA order, upon save, creates an invoice (if configured) or a billing due list. Billing document F2 credits consignment stock (movement 633), debits COGS, and debits customer AR, credits revenue. The consignment stock at customer decreases by 300.

3. Returns: Distributor returns 50 unused units. Order KR, delivery LR with movement 632. Stock returns to own unrestricted. No billing.

4. End of contract: Pick‑up of remaining 150 units. Order KB, delivery with movement 634. Stock returns to own.

All tracked perfectly. The consignment info record (ME11) defines the price for the issue. The consignment settlement (MRKO) can be used to periodically bill multiple issues, or each KA can trigger billing immediately.

4. Third‑Party Order Processing – Never Touch the Product

Third‑party processing is drop‑shipping. You sell a product to your customer, but you don’t stock it. Instead, you send a purchase order to your vendor, who ships directly to your customer. You bill your customer, and you receive an invoice from your vendor. SAP automates this via the item category TAS (Third‑Party Item).

4.1 Master Data and Configuration Requirements

For a material to be processed third‑party, it must have a purchasing info record with a vendor. The material master item category group should be “NORM” or “BANS” (third‑party). Actually, the item category determination must map to TAS. Typically, the item category group “BANS” is used for third‑party materials. In VOV4, for sales document type OR and item category group BANS, default item category TAS.

GlobalTech uses material “MOTOR‑ITALY” (finished motor sourced from Italian vendor VEND‑IT). Create material master: item category group “BANS”, allow third‑party processing. In the purchasing info record (ME11) for VEND‑IT and MOTOR‑ITALY, maintain price. No plant/storage for this material (since you never stock it). In the Sales Org view, set delivering plant blank (delivery not needed).

4.2 The Third‑Party Order Flow (VA01 to Billing)

1. Sales order OR, item category TAS. Enter customer, material, quantity. The system does NOT check inventory. Instead, upon saving, it automatically creates a purchase requisition for the vendor and material. The purchase requisition contains the customer’s delivery address (from the ship‑to party) and the quantity.

2. The buyer converts the PR into a purchase order (ME21N) or the PR is automatically converted via background job. The PO is sent to the vendor VEND‑IT.

3. The vendor ships directly to the customer. The vendor sends an invoice. AP clerk posts the invoice in MIRO. This invoice is the cost of goods.

4. Back in SD, the goods receipt posting is irrelevant because the material is never in your inventory. When the vendor confirms delivery, the sales order can be “completed” manually or via the PO goods receipt posting (movement 101, but for third‑party, the GR doesn’t affect own stock – it simply acts as a trigger for billing). Actually, the standard third‑party process: the purchase order has item category “S” (third‑party). When you post goods receipt for the PO, the system automatically updates the third‑party sales order and enables billing. So the billing is triggered by the GR of the purchase order. The GR posts to a “GR non‑valuated” account (since inventory is never hit).

5. After GR, billing due list (VF04) picks up the third‑party item, and you create the billing document. The FI entry: debit customer, credit revenue. The cost is already posted via the vendor invoice. Gross margin is captured.

4.3 Key SPRO Settings for Third‑Party

• Item category TAS: in VOV7, ensure billing relevance “A” (delivery‑related billing? Actually, third‑party billing is order‑related, not delivery. For TAS, the billing relevance is “I” (order‑related billing). Check: standard TAS has billing relevance “I”. So billing type must be order‑related, and copy control from OR to F2 must exist.
• Copy control VTFL: from OR/TAS to F2/TAS. Must be maintained.
• Purchase requisition creation: automatic or manual. In SPRO: Sales and Distribution → Sales → Sales Documents → Sales Document Item → Define Item Categories. For TAS, check field “Automatic PR creation” (A). This ensures the PR is generated on order save.
• Vendor assignment: in the sales order, the vendor must be determined. This can be set via a source list or info record. If a single source exists, it’s auto‑proposed. Otherwise, the user selects.

4.4 Hands‑On Scenario

Customer OEMCORP orders 10 MOTOR‑ITALY. Sales order OR created. Item category TAS. Vendor VEND‑IT proposed. Order saved → PR 10000001 generated. Buyer converts to PO 45000001. Vendor ships; MIRO later. When PO goods receipt is posted (MIGO 101, no stock), billing due list shows the OR item; create billing document. Revenue recognized. Perfect drop‑ship.

5. Make‑to‑Order (MTO) vs Make‑to‑Stock (MTS) – The Production‑Sales Link

MTO and MTS define how production and sales interact. In MTS, you produce to stock and sell from stock. In MTO, you produce only after receiving a customer order, and the finished product is linked to that specific order (sales order stock). Configuring MTO correctly is vital for engineer‑to‑order and capital equipment manufacturers.

5.1 Strategy Groups and Requirement Types

The link between sales and production is the requirement type. The requirement type is determined from the strategy group (material master MRP 3 view) and the item category. For MTS, strategy group 10 (make‑to‑stock) gives requirement type 001, which creates anonymous planned independent requirements or consumption from stock.

For MTO, strategy group 20 (make‑to‑order) gives requirement type 040 or KE (individual customer). The key: the requirement class behind the requirement type must have “Individual customer” indicator set, and the planning strategy must allocate the order specifically. The sales order item carries a special stock indicator “E” (sales order stock).

5.2 MTO Configuration in SD

In the material master for the turbine “TURB01”, we set MRP 3 view: Strategy Group 20 (MTO). Item category group: “NORM” (but the item category determination will map to a special item category, e.g., TAB or TAN depending on requirement type). Standard: For OR + NORM, if the material has strategy group 20, the system automatically uses item category TAN but the schedule line category becomes BV (individual customer), which creates a sales order stock segment. Wait, check: Standard determination: schedule line CP for MTS, BV for MTO. The item category stays TAN, but the schedule line category is BV. That’s the typical MTO setup. The BV schedule line category drives the creation of sales order stock and links production orders to the sales order.

5.3 Hands‑On MTO Process

Customer orders a custom turbine TURB01 (material master strategy group 20). In sales order (OR), item category TAN, schedule line category BV. The system creates a sales order requirement (demand) with account assignment category “E” (individual customer). MRP then generates a planned order or production order specifically for that sales order. The production order is settled to the sales order stock segment. When the turbine is completed, goods receipt into sales order stock (movement 101, special stock E). The delivery is created from sales order stock, goods issue 601 from special stock E. Billing as usual.

5.4 MTS Process

Standard product FERT01 uses strategy group 10. Sales order TAN, schedule line CP. MRP creates planned independent requirements and later production orders for anonymous stock. Delivery uses general unrestricted stock. No link to specific customer order.

5.5 Mixed Strategies and Configuration Tricks

Some materials can be both MTS and MTO (strategy group 40 – planning with final assembly). SAP supports this but requires careful configuration. For GlobalTech, TURB01 is pure MTO. The key settings: In VOV5 (Assign Schedule Line Categories), ensure item category TAN with MRP type PD (or special MTO MRP) yields schedule line category BV. In VOV6 (schedule line categories), BV must have “Transfer of requirements” active and “Availability check” using rule “KE” (individual). Also, in the requirement class, the “Individ. Customer” indicator must be set.

Test: Create sales order for TURB01. Check the schedule line: it shows “E” stock indicator and a requirement number linked to the sales order. Go to MRP (MD04) for TURB01, you’ll see the sales order demand as a separate segment. Run MRP, it creates a planned order for that demand. All good.

6. Inter‑company Sales – Selling Across Your Own Borders

GlobalTech’s US sales organisation (US01) sells a product to a US customer, but the delivery is made from the German plant (GT02). Legally, the US company must “buy” the product from the German company and then sell it to the customer. SAP handles this via an inter‑company billing process. An internal invoice flows between the two company codes.

6.1 Organisational Setup

Two company codes: GT01 (US) and GT02 (Germany). Two sales orgs: US01 (assigned to GT01) and DE01 (assigned to GT02). A US customer places an order with US01, but the delivering plant is GT02 (since the material is produced in Germany). This plant is in company code GT02. The system automatically recognises that the delivering plant belongs to a different company code than the sales organisation’s company code, and triggers inter‑company processing.

6.2 Master Data for Inter‑company

You need an internal customer and vendor. In company code GT02, a customer master (sold‑to/bill‑to) representing GT01. In company code GT01, a vendor master representing GT02. The inter‑company pricing must be defined – usually a transfer price. In the sales order, the condition type for inter‑company price is PI01 (Inter‑company Price) or similar. The pricing procedure must include condition type PI01 and be assigned to the inter‑company billing type.

6.3 Document Flow

1. Sales order: OR in US01/10/P1, delivering plant GT02. The system determines the inter‑company billing type (standard IV). The order saves normally. The item category is TAN, but the delivering plant triggers inter‑company.

2. Delivery: created in plant GT02. The delivery is standard LF. When goods issue is posted (movement 601), inventory in GT02 is credited, and COGS is debited in GT02 (as if sold externally). But wait, legally GT02 has sold to GT01. So the COGS posting in GT02 should be cleared by an inter‑company revenue. How does this work? Upon goods issue, the system also automatically posts an inter‑company invoice request. Actually, the standard flow: The delivery in GT02 does not generate COGS directly? No, movement 601 from unrestricted stock debits COGS in GT02. But that COGS will be offset by the inter‑company revenue when the inter‑company billing is created. The inter‑company billing is a separate billing document (type IV) that bills the internal customer (GT01) in company code GT02. So GT02 gets revenue (inter‑company), GT01 gets cost of goods purchased.

3. Billing: The end‑customer billing (F2) is created in US01. The inter‑company billing (IV) is automatically created when the end‑customer billing is saved (or via the billing due list). The IV billing posts: debit inter‑company AR (GT01) in GT02, credit inter‑company revenue (GT02). In GT01, the corresponding entry is debit inter‑company COGS, credit inter‑company AP (GT02). This is handled by the FI document splitting or by a separate clearing account.

6.4 Configuration Steps

SPRO: Sales and Distribution → Billing → Inter‑company Billing → Define Order Types for Inter‑company Billing (transaction OVR3). Assign billing type IV to sales document type OR and delivery type LF.

SPRO: Sales and Distribution → Billing → Inter‑company Billing → Define Internal Customer/Vendor Assignment (transaction OVR2). For sales org US01, delivering plant GT02, assign internal customer number (e.g., CUST‑INT‑GT01) and internal vendor number (e.g., VEND‑INT‑GT02). The system uses these to post the IV billing.

SPRO: Sales and Distribution → Billing → Inter‑company Billing → Automatic Determination of Pricing Procedure (transaction OVR1). Ensure the pricing procedure for inter‑company billing (e.g., ICAA01) is assigned to the inter‑company billing type IV. This procedure contains condition type PI01 for the inter‑company price, which can be maintained in a condition record (VK11).

6.5 Hands‑On Inter‑company Scenario

US customer CUSTUS01 orders 10 units of FERT01, which is stocked in plant GT02. Sales order OR, US01/10/P1, delivering plant GT02. System determines inter‑company type IV. Save. Delivery VL01N from plant GT02. Post goods issue: FI entry in GT02: debit COGS (40000080), credit inventory (20000030). Billing F2 for end‑customer: created in US01, posts debit customer AR (GT01), credit revenue (GT01). Simultaneously, system creates billing document IV in GT02: debit internal customer CUST‑INT‑GT01 (inter‑company AR), credit inter‑company revenue (50000090). In GT01, the FI entry from IV billing is: debit inter‑company cost (40000095), credit internal vendor VEND‑INT‑GT02 (inter‑company AP). The inter‑company AP/AR between the company codes are later cleared via F110 or manual payment.

This complex flow is completely automated once the SPRO settings and master data are correct. It’s a thing of beauty when you first see it work.

7. Full Scenario – A Week of Special Sales at GlobalTech

Monday: Returns processing. Customer returns a defective motor. RO created, returns delivery (LR) with movement 652 to blocked stock. After inspection, warehouse transfers 2 units to scrap, 3 to unrestricted. Credit memo G2 issued for the 5 returned units.

Tuesday: Free goods promotion. A wholesaler orders 200 PACK01 cartons. Inclusive free goods adds 20 cartons at zero price. Delivery includes 220 cartons; billing is for 200 only.

Wednesday: Consignment cycle. Fill‑up KE for distributor with 500 units. Issue KA for 200 consumed units, invoice created. Returns KR for 10 damaged. Pick‑up KB for remaining stock at month‑end.

Thursday: Third‑party. Customer orders 5 MOTOR‑ITALY. Sales order TAS, auto‑PR, PO sent to VEND‑IT. Vendor ships, PO GR posted, billing F2 generated. No stock touched.

Friday: MTO and inter‑company. A custom turbine TURB01 ordered via MTO (BV schedule line). Production creates sales order stock. Inter‑company sales: US01 sells from GT02 plant. Delivery, end‑customer billing and IV billing all post smoothly.

8. Best Practices, Pitfalls, and Alternatives

Best Practices:

• Returns: always receive into blocked stock and inspect before moving to unrestricted. Configure movement type 652 as default.
• Free goods: use inclusive free goods for same material; exclusive for different materials. Keep the free goods condition records specific to avoid unintended giveaways.
• Consignment: regularly reconcile consignment stock at customer (MMBE special stock W) with customer reports. Run MRKO for consignment issue settlement to ensure accurate liability.
• Third‑party: always test the entire PR→PO→GR→Billing chain, including vendor invoice posting. A missing copy control or PR creation setting will break the process silently.
• MTO: use strategy group 20 and verify that the requirement class has “Individual customer” indicator. Incorrect setting leads to mixed stocks.
• Inter‑company: define a clear internal pricing strategy (cost plus transfer, market price) and maintain PI01 condition records. Test the IV billing thoroughly, including the FI clearing accounts.

Common Pitfalls:

• Returns billing fails because the returns clearing account (GBB RET) is not maintained.
• Free goods not triggered: check that the free goods condition record is valid for the exact combination and that the calculation rule is not “Condition record without value”.
• Consignment issues: if the consignment info record is missing or invalid, the KA order cannot determine the price.
• Third‑party: if the automatic PR creation fails (TAS item category field “Automatic PR” not set), the process stalls.
• MTO: the sales order stock is not visible if the schedule line is CP instead of BV. Always check the schedule line category in the sales order.
• Inter‑company: a missing internal customer/vendor assignment leads to error “Internal customer not defined” at IV billing.

Alternatives and When to Use Them:

• Instead of classic free goods, you can use a discount in kind (condition type R100 with a free goods indicator), but the classic NR00 is more straightforward.
• For consignment, if you use SAP EWM, you can track consignment stock at bins more precisely.
• Third‑party can also be done via inter‑company STO followed by a direct delivery, but TAS is cleaner for pure drop‑ship.
• Inter‑company sales can be handled via stock transport order (STO) with billing, but the direct inter‑company billing flow is preferred for sales‑driven scenarios.

9. Conclusion – You Have Conquered Special Sales Scenarios

Day 10 has equipped you with the complete toolkit to handle every non‑standard sales process SAP can throw at you. You can now configure returns and credit notes, set up free goods promotions, manage consignment lifecycles, execute third‑party drop‑ships, distinguish and implement MTO vs MTS, and orchestrate inter‑company sales across company codes. These are the skills that make you the “go‑to” person on any SD implementation team. Open your sandbox and run through each scenario – the muscle memory will be invaluable.

Tomorrow, we shift gears into Production Planning (Part 26) – MRP types, scheduling, capacity, and shop floor configuration. It’s time to connect the sales orders to the factory floor. Don’t miss it.

@FreeLearning365 – Tech Partner @techbook24