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.
Status records are not sent to the EDI subsystem on outbound.
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.
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.
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
Purchasing info records (ME11) are unique to a vendor and an SAP material number
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
In the vendor master, the EDI group partially owns the Company Code / Correspondence tab; specifically, the “Account w/Vendor” field.
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.
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)
Message control is most common in MM and SD. Other modules (especially finance) may not make use of message control.
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”)
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.
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.
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).
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 need, so you'll need a custom solution.
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.
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.
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.
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.
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.
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.
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.
Inbound IDocs stuck in status 64? Go to t-code SE38 and run program RBDAPP01 to process these IDOCs.
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.
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.
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.
ORDERS: The KA1-STRS2 is not used by the standard system for logical message ORDERS. (OSS note 754333)
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
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.
To find which user has a workflow item held for a related IDoc.
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#*
Get the WI_ID value
Search in SE16, table SWWWIHEAD Enter the WI_ID value from the previous search into the WI_ID field
The user that has hold of the workflow item is in the field WI_AAGENT
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.
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.
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.
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.
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.