Electronic Data Interchange Tools are used in SAP ABAP are used to transfer data with in the SAP system and even outside the system.
Here we have previously discussed regarding EDI restating tools and here is the continuation for that discussion.
Manual Restart is useful when an error has occurred outside the SAP system or a strange error occurs in the SAP system. If the error occurs in the EDI subsystem, the SAP system can resend the IDoc only for status codes
04 (Error within Control Information of EDI Subsystem) ·
05 (Error during Translation) ·
In other cases, you have to fix the problem within the subsystem. For unexplained errors within the SAP system, it is best to restart from the application document.
For example, if you created an application document for which an output type is proposed with a timing of 1, the system would wait for the RSNAST00 program to execute and process the output type. However, in the meantime, someone could delete the application document, and the RSNAST00 program would be thoroughly confused then we have to restart the Electronic Data Interchange process from the beginning once again.
The steps to purge an IDoc from a work item are straightforward includes identifying the work item that was sent to you for the error situation you want to purge. Execute the work item and look for the Delete button. After you click the Delete button, the IDoc is marked for deletion and gets a status code of 31 (ErrorNo Further Processing). This step prevents the EDI or ALE tools from accidentally reprocessing the IDoc.
EDI Inbound Process Failures
The inbound process is a sequence of asynchronous processes, and failure can occur within any process. The points of failure on an inbound process are
When problems occur in the inbound process, the system uses the technique most suitable at that point to report the problem. The main technique used is the workflow component, but workflow is not started until an IDoc file is passed to the SAP system. After control is passed to the SAP system for processing, the SAP system logs the problems and reports them via workflow.
The EDI subsystem handles problems encountered in processing an inbound EDI document on the EDI subsystem. You will have to check with the subsystem vendor for a troubleshooting guide. However, you can design your EDI subsystem to send a TXTRAW message to the SAP system to report problems. This message can be directed to the EDI administrator.
The mechanism used here is
1.Purging the Outbound Process
2.Errors that occur in triggering the SAP system from the EDI subsystem are logged in the system log and are reported to the subsystem as RFC errors. No workflow is started until this point. Thus, errors up to this point have to be monitored at the EDI subsystem level.
3· From the point when an IDoc has been passed to the SAP system to the point when it is created in the database, errors are logged in the EDFI2 table (file log). A workflow message is also generated to inform the EDI administrator.
4· After an IDoc is created, errors are logged in the IDoc's status record, and problems are reported via workflow.
5· The system performs some basic integrity checks on the IDoc. After the basic checks, the control information is matched against a partner profile. If a partner profile is not found, the IDoc gets a status code of 56 (IDoc with Errors Added), and a workflow message is sent to the EDI administrator.
6· After an IDoc is created, a syntax check is done, the IDoc goes through version change, and conversion occurs. If an error is found, the IDoc gets a status code of 60 (Error during Syntax Check of IDoc Inbound). A workflow message is sent to the responsible person (as identified in the partner profile).
7· The IDoc is then passed to the posting module. If the posting module returns an error, the IDoc gets a status code of 51 (Application Document Not Posted). A workflow message is sent to the responsible person (as identified in the partner profile). There are several reasons for failure of an application document, but in most cases, the problem is with the data.
UPDATE
When an incoming IDoc is successfully posted, it gets a status code of 53 (Application Document Posted).
Troubleshooting for Inbound Errors of Electronic Data Interchange for Idoc is
The best approach for troubleshooting an inbound process is to check the SAP Inbox first. If there is no error message, check the IDoc list for any problems.
Resolving Application Errors of EDI:
Execute failed processes in foreground mode. If the posting program in SAP uses call transaction,
you can restart the process in foreground mode and step through each screen until you find the problem. To see whether your posting program uses call transaction, execute transaction BD51.
1.Entries with a value of 1 or 2 use call transaction.
2.Edit failed IDocs. Editing a failed IDoc is a quick fix for data−related problems. For example, if your vendor sends in a wrong material number, you can change the value in the IDoc. You can then restart the process, and the document should post.
SAP makes a backup copy of the original IDoc and assigns it a status of 70 (Original of an IDoc that was Edited). You should not use this technique as a permanent fix, however, because doing so addresses only the symptoms, not the cause of the problem.
Further posts will contiune discussing the Electronic Data Exchange for SAP ABAP .
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
Here we have previously discussed regarding EDI restating tools and here is the continuation for that discussion.
Manual Restart is useful when an error has occurred outside the SAP system or a strange error occurs in the SAP system. If the error occurs in the EDI subsystem, the SAP system can resend the IDoc only for status codes
04 (Error within Control Information of EDI Subsystem) ·
05 (Error during Translation) ·
In other cases, you have to fix the problem within the subsystem. For unexplained errors within the SAP system, it is best to restart from the application document.
For example, if you created an application document for which an output type is proposed with a timing of 1, the system would wait for the RSNAST00 program to execute and process the output type. However, in the meantime, someone could delete the application document, and the RSNAST00 program would be thoroughly confused then we have to restart the Electronic Data Interchange process from the beginning once again.
The steps to purge an IDoc from a work item are straightforward includes identifying the work item that was sent to you for the error situation you want to purge. Execute the work item and look for the Delete button. After you click the Delete button, the IDoc is marked for deletion and gets a status code of 31 (ErrorNo Further Processing). This step prevents the EDI or ALE tools from accidentally reprocessing the IDoc.
EDI Inbound Process Failures
The inbound process is a sequence of asynchronous processes, and failure can occur within any process. The points of failure on an inbound process are
- An error in triggering the SAP system from the EDI subsystem .
- An error in creating the IDoc ·
- An error in the ALE/EDI interface layer ·
- An error in the posting function module ·
- Unknown or mysterious errors.
When problems occur in the inbound process, the system uses the technique most suitable at that point to report the problem. The main technique used is the workflow component, but workflow is not started until an IDoc file is passed to the SAP system. After control is passed to the SAP system for processing, the SAP system logs the problems and reports them via workflow.
The EDI subsystem handles problems encountered in processing an inbound EDI document on the EDI subsystem. You will have to check with the subsystem vendor for a troubleshooting guide. However, you can design your EDI subsystem to send a TXTRAW message to the SAP system to report problems. This message can be directed to the EDI administrator.
The mechanism used here is
1.Purging the Outbound Process
2.Errors that occur in triggering the SAP system from the EDI subsystem are logged in the system log and are reported to the subsystem as RFC errors. No workflow is started until this point. Thus, errors up to this point have to be monitored at the EDI subsystem level.
3· From the point when an IDoc has been passed to the SAP system to the point when it is created in the database, errors are logged in the EDFI2 table (file log). A workflow message is also generated to inform the EDI administrator.
4· After an IDoc is created, errors are logged in the IDoc's status record, and problems are reported via workflow.
5· The system performs some basic integrity checks on the IDoc. After the basic checks, the control information is matched against a partner profile. If a partner profile is not found, the IDoc gets a status code of 56 (IDoc with Errors Added), and a workflow message is sent to the EDI administrator.
6· After an IDoc is created, a syntax check is done, the IDoc goes through version change, and conversion occurs. If an error is found, the IDoc gets a status code of 60 (Error during Syntax Check of IDoc Inbound). A workflow message is sent to the responsible person (as identified in the partner profile).
7· The IDoc is then passed to the posting module. If the posting module returns an error, the IDoc gets a status code of 51 (Application Document Not Posted). A workflow message is sent to the responsible person (as identified in the partner profile). There are several reasons for failure of an application document, but in most cases, the problem is with the data.
UPDATE
When an incoming IDoc is successfully posted, it gets a status code of 53 (Application Document Posted).
Troubleshooting for Inbound Errors of Electronic Data Interchange for Idoc is
The best approach for troubleshooting an inbound process is to check the SAP Inbox first. If there is no error message, check the IDoc list for any problems.
Resolving Application Errors of EDI:
Execute failed processes in foreground mode. If the posting program in SAP uses call transaction,
you can restart the process in foreground mode and step through each screen until you find the problem. To see whether your posting program uses call transaction, execute transaction BD51.
1.Entries with a value of 1 or 2 use call transaction.
2.Edit failed IDocs. Editing a failed IDoc is a quick fix for data−related problems. For example, if your vendor sends in a wrong material number, you can change the value in the IDoc. You can then restart the process, and the document should post.
SAP makes a backup copy of the original IDoc and assigns it a status of 70 (Original of an IDoc that was Edited). You should not use this technique as a permanent fix, however, because doing so addresses only the symptoms, not the cause of the problem.
Further posts will contiune discussing the Electronic Data Exchange for SAP ABAP .
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
No comments :
Post a Comment