How to Set Up SAP IDocs for PO to SO Conversion

Hey there, SAP explorers and business problem-solvers! It’s your go-to guide for all things SAP here, ready to unravel one of those clever tricks SAP uses to make businesses run smoother. Today, we’re tackling something super common in the business world: how one company’s order (a Purchase Order, or PO) magically becomes another company’s incoming sale (a Sales Order, or SO) inside SAP. And the secret sauce? It’s all about IDocs.

We’re going to walk through this step-by-step, just like I’d explain it on a whiteboard, complete with real-world examples. My goal isn’t just to show you what buttons to click, but to help you really get why each step matters. Let’s jump in!

The Big Picture: Why Do We Need IDocs to Turn a PO into an SO?

Imagine you’re running a big company with a few different branches, or maybe you’re a supplier receiving orders from a major customer. When one part of your business (or your customer) sends out a Purchase Order, the other side – the one selling the stuff – needs to receive it as a Sales Order.

Now, you could have someone manually re-type all that order info from the PO into a new SO. But let’s be honest, that’s slow, boring, and a magnet for mistakes. That’s where EDI (Electronic Data Interchange) comes in, powered by SAP’s IDocs (Intermediate Documents). They’re like special digital envelopes that carry business documents back and forth, making sure everything is exactly right.

So, for our PO-to-SO trick, here’s what happens:

1. The system that’s buying (the “Purchasing System”) sends out an outbound IDoc – basically, it’s packing up the PO details.
2. The system that’s selling (the “Selling System”) then receives this as an inbound IDoc. It then unpacks the details and automatically creates the Sales Order.

The cool part? We mostly use one main IDoc type for this: ORDERS. It’s super flexible and can represent both an outgoing PO and an incoming SO, thanks to how SAP is set up to handle it. Think of it like a versatile messenger service.

Getting Down to Business: Your Step-by-Step Configuration Playbook

For this setup, picture two different SAP systems (or even two separate parts of the same huge SAP system). Let’s call them the “Purchasing System” (where the PO starts) and the “Selling System” (where the SO ends up). Each one needs a bit of friendly configuration.

Part 1: Laying the Groundwork – The Basics of Connecting Systems

Before we get to the PO-SO magic, let’s make sure our basic connections are solid.

Step 1: Giving Each System an ID (Transaction: SALE)

Every SAP system or even a specific client within an SAP system needs a unique name to talk to others. We call this a Logical System. It’s like giving each computer a unique address on a network.

• Where to go: SPRO > SAP NetWeaver > Application Server > IDoc Interface / Application Link Enabling (ALE) > Basic Settings > Logical Systems > Define Logical System
• What to do:
  • For your Purchasing System, give it a name like PURCHASING_SYS.
  • For your Selling System, give it a name like SELLING_SYS.
• Quick Check: Just make sure these names are assigned to the correct system “clients” using transaction SCC4.

Step 2: Building the Communication Roads (Transaction: SM59)

These are like the actual phone lines or internet cables connecting your two SAP systems. We call them RFC (Remote Function Call) Destinations. They tell one system how to find and talk to another.

• Where to go: SM59
• What to do:
  • In the Purchasing System, create a connection that points to SELLING_SYS. Let’s name it TO_SELLING_SYS.
    • You’ll need the other system’s address (host, system number) and, importantly, a username and password that has permission to do things in the SELLING_SYS system.
  • In the Selling System, do the reverse: create a connection pointing to PURCHASING_SYS. Name it TO_PURCHASING_SYS.
    • Same deal here: you need login details for PURCHASING_SYS.
• Quick Check: After you set them up, click “Connection Test” and “Authorization Test.” You want to see nice green lights!

Step 3: Setting Up the Mailboxes (Transaction: WE21)

Think of these as the specific mailboxes where the IDocs will be dropped off or picked up. For direct SAP-to-SAP talks, we typically use tRFC (Transactional RFC) Ports.

• Where to go: WE21
• What to do:
  • In the Purchasing System (for sending out):
    • Under “Ports > tRFC,” create a new port. Let’s call it MAILBOX_TO_SELLING.
    • Link it to the TO_SELLING_SYS connection you made in Step 2.
  • In the Selling System (for receiving):
    • Under “Ports > tRFC,” create a new port. Let’s name it MAILBOX_FROM_PURCHASING.
    • While it’s for inbound, it’s good practice to link it to TO_PURCHASING_SYS if you ever need to send messages back.
• Quick Check: Make sure the port shows as active.

Part 2: The PO Leaves the House (In the Purchasing System)

Now, let’s get the Purchasing System ready to fire off that PO as an IDoc.

Step 4: Your Vendor is Also a Customer (Transaction: XK01/MK01/BP)

This is a small but critical detail! The vendor you’re buying from in your Purchasing System needs to be known as a customer in the Selling System.

• What to do: Open up the Vendor Master record for the company you’re buying from (e.g., VENDOR_ABC).
• The Crucial Link: Find the “Correspondence” section in the Vendor Master. There’s a field called “Account with Vendor.” In this field, you must enter the Customer Number that this vendor uses for themselves in the Selling System. This is how SAP knows who to send the Sales Order to.

Step 5: Telling SAP How to Send the PO (Transaction: WE20)

This is like giving SAP instructions on how to package and send the PO IDoc to the other system. We do this in a “Partner Profile.”

• Where to go: WE20 > Partner Type LI (Vendor)
• What to do:
  • Find or create a Partner Profile for VENDOR_ABC.
  • Look for Outbound Parameters and click “Create.”
  • Partner Role: This should usually be LI (Vendor).
  • Message Type: This is key: select ORDERS.
  • Receiver Port: Choose MAILBOX_TO_SELLING (from Step 3).
  • Basic Type: Pick ORDERS05 (or whatever the latest version is).
  • Send Mode: For testing, choose “Transfer IDoc Immediately.” In real life, you might “Collect IDocs” to send them in batches.
  • Message Control Tab: This part connects the IDoc creation to the PO printing/sending process.
    • Application: EF (for Purchasing).
    • Message Type: This is the “output type” used for your POs (like NEU for new orders, or a special one you’ve set up).
    • Process Code: Use ME10 (the standard one for sending out POs).
• Quick Check: After saving, just do a quick look-over to make sure all your selections are right.

Step 6: Setting Up the PO to “Print” an IDoc (Transaction: NACE)

This is where you tell SAP that when you save a PO, it should trigger the creation of an IDoc, just like it might trigger a printout or an email.

• Where to go: NACE > Application EF (Purchasing) > Output Types
• What to do:
  • Select your PO’s output type (e.g., NEU).
  • Go to “Processing Routines”: Make sure there’s a line for “Medium 6 (EDI)” with the standard program RSNASTED and routine EDI_PROCESSING. This tells SAP how to make the IDoc.
  • Go to “Partner Functions”: Make sure “VN (Vendor)” is listed.
  • Most Important: Condition Records (T-Code: MN04 for Purchasing): This is the rule that says “when this vendor, for this output type, send an IDoc.” Create a record for your output type (NEU), specifying your vendor (VENDOR_ABC), the medium (6 for EDI), and “send immediately” (4).
• Quick Check: Create a pretend PO (in ME21N). Go to the “Messages” tab. Your output type (NEU) with “Medium 6” should pop up. If not, double-check your condition records!

Part 3: The SO Gets Created (In the Selling System)

Now, let’s get the Selling System ready to catch that IDoc and turn it into a Sales Order.

Step 7: Your Customer is Also a Vendor (Transaction: XD01/VD01/BP)

Similar to before, the customer receiving the goods in your Selling System needs to correspond to the purchasing company (the vendor) from the other system.

• What to do: Open up the Customer Master record for the company that made the purchase (e.g., CUSTOMER_XYZ).
• The Crucial Link: In their “Sales Area Data > Sales Tab,” make sure there’s a way to identify them back to the Vendor Number from the Purchasing System. Sometimes a special “Customer Group” or a custom field helps with this.

Step 8: Telling SAP How to Receive the PO (Transaction: WE20)

This is the Partner Profile for the inbound side. It tells SAP how to receive the PO IDoc and process it into a Sales Order.

• Where to go: WE20 > Partner Type KU (Customer) or more commonly LS (Logical System) – using the Logical System type LS_PURCHASING is often cleaner for system-to-system chats.
• What to do:
  • Find or create a Partner Profile for CUSTOMER_XYZ or PURCHASING_SYS.
  • Under Inbound Parameters, click “Create.”
  • Message Type: Again, ORDERS.
  • Process Code: This is the magic button: ORDE. This code tells SAP to use the standard function to create a Sales Order.
  • Processing Mode: For testing, “Trigger immediately” (meaning the SO is created right away) is handy. In real life, “Trigger by background program” (meaning the IDoc sits waiting for a scheduled job to process it) is more common.
  • Permitted Agent: Assign someone or a team here. If the IDoc runs into trouble, they’ll get a message in their SAP inbox.
• Quick Check: Double-check all these settings.

Step 9: The Brains Behind the Inbound Process (Transactions: WE42 / BD51)

The process code ORDE isn’t just a random name; it’s linked to the specific piece of SAP code (a “function module”) that does the actual work of turning IDoc data into a Sales Order.

• Where to go:
  • BD51 (to see the function module details).
  • WE42 (to see which process code links to which function module).
• What to do:
  • In BD51, just confirm that IDOC_INPUT_ORDERS is listed as an inbound function module.
  • In WE42, make sure that for Process Code ORDE, it points directly to Function Module IDOC_INPUT_ORDERS. This is absolutely essential!
• Quick Check: Verify this connection.

Step 10: Making Sure Materials Match (Transaction: VOE2 – Customer Material Info Record)

This is a super common stumbling block! The item numbers (materials) on the incoming PO have to be recognized as valid item numbers in your Selling System.

• Where to go: VOE2
• What to do: For your CUSTOMER_XYZ, you need to set up a mapping. This tells SAP: “When CUSTOMER_XYZ sends me a PO with their material number XYZ-123, I know that means my internal material number MY_PROD_001.”
• Quick Check: If you skip this, your Sales Order will likely have problems with the line items.

Part 4: The Moment of Truth – Testing and Fixing Things

Alright, all the plumbing is in place. Time to see if the water flows!

Step 11: Create a Test Purchase Order (In the Purchasing System: ME21N)

Go ahead and create a simple PO, using your special vendor and material.

• What to do: Save the PO.
• Quick Check (Outbound):
  • Look at the PO’s messages (ME23N > Messages). That output type (NEU) with “Medium 6” should have a nice green light.
  • Go to WE02 (IDoc Display) in the Purchasing System. You should see an outbound ORDERS IDoc (look for Direction ‘1’). Its status should be 03 (meaning it’s been sent) or 30 (ready to be sent).
  • If it’s 03, it means it successfully zoomed over the network to the Selling System.

Step 12: Catching the IDoc and Making the SO (In the Selling System: WE02 / WE05 / BD87)

Now, jump over to the Selling System to see if the IDoc arrived and transformed.

• What to do:
  • Go to WE02 or WE05. You should see an inbound ORDERS IDoc (look for Direction ‘2’).
  • What to Expect:
    • It will first show up as status 50 (IDoc received).
    • If you chose “Trigger immediately” in WE20, it should quickly turn into 53 (meaning a business document was created successfully!).
    • If you chose to “Collect IDocs,” you’ll need to run a special program called RBDAPP01 to process it.
  • If you see status 53, high five yourself! A Sales Order should now exist. Go to VA03 and check for recent Sales Orders.
• What If It Fails? (If you see status 51 – “Application Document Not Posted”):
  • Check the IDoc Status Records: In WE02, click into the IDoc. Those little “traffic light” icons and messages are your best friends. They’ll tell you exactly what went wrong (e.g., “Customer not found,” “Material not maintained,” “Sales area data missing”).
  • Application Log (SLG1): For more detail, use transaction SLG1. Put “IDOC” in the object field and “ORDERS” in the sub-object field. This often gives super precise error messages from the Sales Order creation process.
  • Debugging (BD87): If it’s a tricky error, use BD87 to reprocess the IDoc. You can even set a “breakpoint” in the IDOC_INPUT_ORDERS program and watch what happens step by step.
  • Common Culprits:
    • Missing Setup Data: Customer info, material info, price lists, sales area details – if any of these are missing for the customer, the SO won’t create.
    • Wrong Mapping: The data coming in from the PO isn’t lining up correctly with what the SO expects.
    • Permission Problems: The user linked to the RFC connection, or the background user processing the IDoc, might not have the right permissions to create a sales order.
    • Custom Code: If your system has special customizations, they might be getting in the way.

Final Words of Wisdom

Getting IDoc communication just right, especially for something like turning a PO into an SO, needs a bit of patience and attention. It’s like conducting an orchestra of master data, communication lines, and specific rules. Don’t get discouraged if it doesn’t work perfectly the first time! That’s totally normal. Just configure a bit, test a bit, fix a bit, and try again.

The ORDERS IDoc, even though it’s standard, can carry tons of details (like different sections for the order header, individual items, who the partners are, dates, etc.). Understanding these sections is super helpful for more complex setups or if you ever need to add custom information.

Ultimately, this isn’t just about moving data around. It’s about making businesses talk to each other effortlessly, cutting down on manual work, and speeding up vital processes. Master this “digital handshake,” and you’ll be a true SAP integration wizard!

Stay curious, keep learning, and here’s to your IDocs flowing smoothly and without a hitch!