SAP EDI Tips

Written by anon
Wednesday, 09 July 2008 16:55 - Last Updated Tuesday, 08 July 2008 16:55

1. If an IDoc is edited prior to application processing (i.e., due to an error that prevents the
application from accepting it), then SAP saves a copy of the original IDoc and uses the
revised/corrected copy for processing.
2. Status records are not sent to the EDI subsystem on outbound.
3. If you’re having problems with an inbound transaction not matching to a partner profile,
then look at the transaction’s control record and check to see if the 7-key match is really a
match. Also be sure to inspect the correct partner fields in the control record since outbound
and inbound partners are stored in different fields.
4. A process code is an alias for a workflow item or for a function module. This layer of
abstraction exists so that SAP may change the technical names without impacting existing EDI
installations.
5. To see a “live” transaction, use WE05 to search by message type (i.e., INVOIC), find one
of a complete status (53 or 03) and open it. To see the corresponding business document, click
the drop-down beside “SAP R/3”), then click Relationships, then click
6. Purchasing
7. Purchasing info records (ME11) are unique to a vendor and an SAP material number
8. In purchasing, confirmation control code 0001 specifies that an order confirmation is
required, then an ASN, then an invoice. Configured here: IMG / MM / Purchasing /
Confirmations
9. In the vendor master, the EDI group partially owns the Company Code / Correspondence
tab; specifically, the “Account w/Vendor” field.
10. Doing goods issue during pick (adopt quantity, do goods issue) will not generate an ASN
in R/3 4.6. Apparently there is some bug in the function module. Generally, this wouldn’t make
sense to do as part of a meaningful business process anyway.
11. The requirement setting on the message control procedure can help orchestrate output
based on more complex requirements (i.e., whether other required steps have been completed)
12. Message control is most common in MM and SD. Other modules (especially finance)
may not make use of message control.
13. To re-send an outbound IDoc within SAP, use WE19 to copy the IDoc and make the
necessary changes. This (should) effectively re-queue the new IDoc. (Note: SAP won’t let you
re-send an IDoc you previously sent “successfully”)
14. Various connectors for SAP can be found: http://service.sap.com/connectors (including
a Java connector)
15. For inbound sales texts on the ORDERS message, the text types specified on the IDoc
override the texts for those types on the customer master.
1. This is consistent with how the inbound ORDERS message generally works: values are
copied from the customer master, these values may be copied by a referenced document (i.e.,
contract, quote), but the data provided on the IDoc overrules them all.

2. What is the difference between the outbound SHPMNT message and the DESADV
message? DESADV is associated with transactions VL01 and VL02 (Delivery); SHPMNT is
associated with transactions VT01 and VT02 (Shipment).
3. How do I populate the outbound 855's PO3 segment or provide the original PO
information on the PO1 segment? Good question -- SAP's not going to output the data you

1/3
SAP EDI Tips

Written by anon
Wednesday, 09 July 2008 16:55 - Last Updated Tuesday, 08 July 2008 16:55

need, so you'll need a custom solution.

4. You'll need to (a) write a program to capture the data from the inbound PO, (b) write a
program to re-populate it on the outbound IDoc prior to mapping.
5. On the inbound capture program, you'll want to capture partner & partner type, po#, po
line# (for matching on outbound), quantity, uom, price, and price basis. One option is to write a
custom segment to the outbound IDoc with the original values from the PO plus flags to indicate
what changed.
6. In the outbound 855 map, create the PO3 according to the flags you set in the custom
segment above. If the partner requires it, map the original PO information in the PO1 segment.
7. For inbound EDI sales orders, you can expect the order to bypass any warnings you set
within the application and stop on any errors. Example: if the duplicate sales order check only
raises a warning, then duplicate EDI orders will not be stopped; rather, the warning will be
overridden and the order will post successfully. Be sure to think through the ramifications of
your error-handling strategy.
8. For inbound sales orders (ORDERS01, 04, etc), the KA1-PARTN field must be left blank
if you want to use the EDPAR table to translate external partner numbers successfully. R/3 will
only execute the cross reference step if (a) PARTN is empty, (b) LIFNR is populated, and (c) a
match for sold-to and LIFNR can be found in EDPAR.
9. In the DELVRY02 IDoc and subsequent versions, the pack hierarchy is conveyed on the
L37/L44 structure. The segments contain values that describe the hierarchy in full.
10. If your IDocs are getting stuck in status 30 on outbound, try calling
MASTER_IDOC_UPDATE as an update task so that the IDoc is created asynchronously.
11. Inbound IDocs stuck in status 64? Go to t-code SE38 and run program RBDAPP01 to
process these IDOCs.
12. If a user gets a "5W 141" error when opening a workflow item after you've
recently added them to a workflow OU, position, etc, then their runtime buffer needs to be
refreshed. Have them go to transaction SWU_OBUF and click Runtime Buffer->Synchronize.
This refreshes their local copy of the groups.
13. An order-specific partner address record (i.e., sold-to, ship-to, etc) is only created if the
KA1-NAME field is filled on the IDoc.
14. In your pricing procedure, ensure only EDI1 is loaded and with formula 8 as the
alternative calculation type. Ignore the descriptions on the condition and the formula. EDI1
actually calculates item value in the standard
system rather than price. Formula 9 and EDI2 should not be used due to currency conversion
issues in formula 9. This inconsistency is all documented in OSS.
15. ORDERS: The KA1-STRS2 is not used by the standard system for logical message
ORDERS. (OSS note 754333)
16. ORDERS: The partner address on the sales order is proposed from the customer
master. Only non-blank KA1/PA1 fields from the IDoc are then copied over the proposal. This
means the resulting sales order address in the standard system could be a mixture of master
data and IDoc data. See OSS notes 350904 and 609421
17. For inbound sales orders with VC characteristics (E1CUREF, E1CUCFG, etc), it is
essential that the external item number either be alphanumeric (one character that is not either
a space or a number) or the value must be six digits. Otherwise, R/3 will attempt to re-format
the POSEX during processing and subsequently be unable to match it to the characteristics
loaded in the IDoc. In this situation your sales order will lack characteristics.

2/3
SAP EDI Tips

Written by anon
Wednesday, 09 July 2008 16:55 - Last Updated Tuesday, 08 July 2008 16:55

18. To find which user has a workflow item held for a related IDoc.
19. Search in SE16, table SWWLOGHIST
Enter the date that the IDoc was put into the system in METH_EDATE
Enter the IDoc# in the field PARA_VAL_1 surrounded by * - such as *IDOC#*
20. Get the WI_ID value
21. Search in SE16, table SWWWIHEAD
Enter the WI_ID value from the previous search into the WI_ID field
22. The user that has hold of the workflow item is in the field WI_AAGENT
23. If there is no agent listed (field is blank), use the WI_ID to search table SWWUSERWI,
and you can find the list of users that have the workflow item. If all but one user is checked in
the NO_EXECUTE field, then the user without that field marked has the workflow.
24. In an ORDERS message processed by IDOC_INPUT_ORDERS, the E1EDP01-POSEX
value should be unique within the document and be in ascending order. If the POSEX is not
unique, then you will have some interesting results.
25. For example, texts from all lines with the same POSEX will be accumulated and then
duplicated on each line sharing the POSEX. If you have line 1, 2, and 3 each with text A, B, and
C, then each line would have text AAA, BBB, CCC.
26. There is no standard workaround for this design limitation. IDOC_INPUT_ORDERS
does not process the E1EDP02-001, so it is not possible to map a sequential P01-POSEX and
then override it using the P02(001)-ZEILE.
27. If you need a way to re-process IDocs without re-issuing the output within the business
document, it's possible to programatically manipulate the status. For example, if you need to
re-send a batch of IDocs to a remote system, you could write a report that selects IDocs based
on desired criteria and then call FM IDOC_STATUS_WRITE_TO_DATABASE for each IDoc to
reset the status to 30. Then you could call RSEOUT00 to re-send the newly-restatused IDocs.

3/3