Tuesday, 30 March 2010

A Single Mistake Can Cost You $$$$$

IDOC, Mike Salvo, RBDMIDOC, SAP

Posted by ccampbell on July 9, 2009 · Leave a Comment

While working with a client on developing EDI-856 transactions with one of their trading partners, an error occurred that cost my client thousands of dollars in charge back fines.

In their SAP environment they produce a single DESADV IDoc per order/purchase order.  This could amount to several hundred DESADV IDocs being generated.  The initial development was a 1 to 1 translation in that each DESADV IDoc that was produced would be translated into a single EDI-856 document.

SAP EDI Idoc List Screen

Because of a single data error, due to department procedures not being followed in the warehouse in the closing of orders, the bad data element resulted and was repeated throughout all of the DESADV IDocs that were generated.  Translation of the IDocs was successful because this error was not conceived at the point of map development.  The hundreds of translated documents were sent to the trading partner and subsequently resulted in failed documents.

Because the trading partner generated a charge back for each document sent, my client was billed thousands of dollars in charge back fines.  This simple example shows how a single error repeated in each document can turn out to be a very costly problem.

I hope to show you in the next few postings how to bundle the IDocs together to:

  • Bundle and reduce the number of IDocs being translated
  • Reduce the number of EDI documents being sent to the trading partner
  • Minimize the charge back cost, should and error occur

Changing SAP IDOCs Status In Mass / Mass Deletion Of IDOCs

Posted by Tim Yates on Wednesday, October 7, 2009 · Leave a Comment

Mass Change of SAP IDOC Status

From time to time it becomes necessary to change the status of SAP IDOCs in SAP. The most common scenario is the requirement to mark SAP IDOCs for deletion. There is no good way to mass mark IDOCs for deletion via the standard IDOC processing transaction BD87. However there is a program that will let you change status.

RC1_IDOC_SET_STATUS

CAUTION: This program should be used with great care and consideration. Improper use of this program can result in data consistency issues. Make sure you know what you are deleting, why you are deleting it, and what is required to correctly update you system after deleting.

Example: Marking IDOCs for Deletion In Mass

It is pretty typical for support users to set the deletion flag on IDOCs that have been incorrectly created and have errored. When there are a small number of IDOCs this is possible via transaction BD87.

An inbound IDOC in error will have the status 51, when it is marked for deletion it has a status of 68.

A view of the IDOCs to be deleted in WE05.

200910051528.jpg

To mass delete IDOCs run the following program via SE38: RC1_IDOC_SET_STATUS via the SAP Transaction: SE38

200910051501.jpg

There are only a few parameters on the selection screen for this program. It is most important that you correctly restrict the IDOCs you select with this program. The program automatically defaults to marking inbound IDOCs in error for deletion.

To mass select IDOCs to be marked for deletion select: 200910051504.jpg

200910051522.jpg

There are many options for selecting and restricting the IDOCs to Mass process. Select by single value or range. Restrict by single value or range.

The 200910051506.jpg allows you to upload a list of IDOCs from a text file.

The 200910051514.jpg allows you to apply a list from your clipboard.

200910051531.jpg

Execute the program 200910051529.jpg

200910051529.jpg

Check the status of the 3 IDOCs in WE05

200910051534.jpg

Example: Changing IDOCs Status To Repost

It is also possible to use this program to reset an IDOC so that it can be reprocessed.

200910051549.jpg

With the following selection we are going to reset the IDOCs with status 68 marked for deletion back to status 64 to try and reprocess them.

Execute the program 200910051529.jpg

200910051529.jpg

200910051548.jpg

As you can see, program RC1_IDOC_SET_STATUS is very helpful, but please be careful when you use it!

About Tim:

Tim has over 20 years industry experience, with 15 years concentrated on SAP and related technologies. He has broad industry exposure working with companies such as Siemens Automotive, Mercury Marine, SAP America, Eli Lilly & Company, and Verizon. Tim’s deep understanding of SAP and the industry comes from a very hands on approach. His concentration in SAP has been in systems architecture and integration, helping companies develop their infrastructure and controls to successfully integrate SAP into their existing IT landscape.

Monday, 29 March 2010

Notes in MM-PUR

List of most important notes in MM-PUR

MM-PUR

30316 Problems with fields that are not ready for input in purch.



MM-PUR-GF-ACC

496082 FAQ: Account assignment in purchasing

627072 ME21N: incorrect account assignment on cost center

551863 ME21N: Accnt assignment not derived for required entry field



MM-PUR-GF-ADR

498153 FAQ: Addresses in the purchasing

821981 Change in Vendor Address in PO updates Vendor Master address

422641 ME21N, ME22N:



MM-PUR-GF-ARC

456129 FAQ: Archiving in purchasing

401318 Archiving: Additional information

335800 SARA: Deletion indicator not set, but why?



MM-PUR-GF-REL

365604 FAQ: Release strategies in purchasing

493900 FAQ: Release Strategy

86900 Transport of Release strategies (OMGQ,OMGS)



MM-PUR-GF-ARL

499625 FAQ: Optical archiving in purchasing

732278 Display of Originals does not work for archived documents

Wednesday, 24 March 2010

Christopher Stoll: Local SAP Printing

 

Local SAP Printing

With our SAP installation we have many printers defined all over the world, but sometimes we don't want to print to a real printer. Especially in IT, we can do a lot of prints to test things, and it is much more environmentally friendly (and cheaper) to print to an electronic file. For our installation there is only one way to do this, using the local SAP print daemon.

We have a specially configured printer named LOCL that will print to the default printer on the local computer using the local SAPLPD. And this is great until you need to print barcodes, there is a problem rendering them correctly probably due to the fonts. To get around this problem we also have a local post script printing option, but it is not very well known.

Instead of using the printer LOCL, we use the printer LOCO (LOCL_PS in the test systems). There is a catch to using this printer, which is probably why it isn't used more often. You must have a local printer set up with the name SAP_POST (SAP_PS for the test systems) that is configured to print to file. When you request a print on LOCO the local SAP line printer daemon searches for the SAP_POST printer and then sends postscript output to it. The system asks you for a file name, and voila, you have a post script file.


Of course the next problem is what to do with the post script file. To view it I installed Ghostscript and GhostView. And that works well for me. But, when other people need to view these outputs I have to assume that they do not have any postscript viewer installed. So, from inside of GhostView I print the label to PDF.

And that is the simplest method I have found for generating PDF output of prints containing special items such as barcodes.

Christopher Stoll: Local SAP Printing

Tuesday, 23 March 2010

MIR7 Park Invoice Functionality

 

New processing functionality has been added to the MIR7 - Park Invoice Transaction. The new processes, listed below will be effective Thursday, September 9, 2004.
Paying invoices when the unit price of the invoice is less than the unit price listed in a Purchase Order (PO). An error situation will occur if one attempts to process an invoice that is $750 or 30% less than the unit price listed in a purchase order line item. This functionality is being instituted to aid in the prevention of exhausting the entire quantity of a PO line item when making partial invoice payments. The following error message will be displayed when the conditions of the tolerance are met: “Price too low (below tolerance limit of $750 or 30%”). If you encounter this error, please review and compare the quantity entered in the MIR7 transaction against the actual quantity of the invoice being paid. In most cases, changing the quantity in the MIR7 transaction to match the quantity being invoiced will resolve the error. If the invoice price is accurate and the unit price is $750 or 30% less than the unit price of the PO, please contact your local purchasing department to discuss a possible modification of the PO.
Paying invoices against expired framework orders (FOs). All invoices and credit memos for purchases made during the effective period of a framework order must take place within 60 days after the expiration date of a FO. This rule applies to all framework order types. Attempts to enter invoices or credit memos with a posting date greater than 60 days past the FO expiration date will result in the following error: “Blanket purchase order 6500000000: validity (01/01/2003 – 01/01/2004) not complied with”. If you encounter this error, please use transaction ZME_NEW_FO_NBR - Find New Purch Contract FO Nbr to determine if a new framework order has been issued for the requirements of the expired FO. This transaction is appropriate for FOs that are issued against purchasing contracts and is not applicable to department specific FOs. Input the old framework order number in the appropriate field of the displayed transaction and select the execute button. If a new FO has been issued the new FO number will be displayed. In most cases you may use the new FO number in making your invoice payment. (**A word of caution about using a new FO number – please compare the vendor in the new FO to the vendor in your invoice. If the vendor in the new FO is not the same as the vendor in the old FO – do not use the new FO number.) If an invoice is greater than 60 days past the expiration date of the FO and a new FO has not been issued, you will need to contact your local Purchasing Department to discuss your options in processing the invoice.
Determining when framework orders expire: Copies of department FOs are forwarded to the department of record and the FO document will contain the expiration date. You may also access transaction ZME_FO_EXP_DT - Framework Order Expiration Date. This transaction is applicable to all FO types. Enter the FO number or a vendor number in the selection screen that will be displayed and select the execute button. The expiration date of the FO will be displayed. Additionally, for FOs issued by the UTK Purchasing Department against purchasing contracts, you may access the UTK Purchasing web site and monitor the status of purchase contract/FO that is scheduled to expire. Once the UTK Purchasing web site is accessed - select the “Announcements link”.  Instructions have been attached that will aid in adding the UTK purchasing web address in the favorites section of your SAP main menu. Please note: Purchases should not be made against a framework order after it has expired. Any questions concerning framework order validity periods or the proper framework order to use in processing an invoice should be directed to your local purchasing department for additional clarifications.

MIR7 Park Invoice Functionality

Sunday, 21 March 2010

Logistics Simulation Conveyor Picking

The picking and packing process

Datalogic PowerScan RF Industrial Barcode Scanner

RF ORDERS: Orders/Receiving

Warehouse Operations

Warehouse Robots at Work

Warehouse Management System

IBM RFID Commercial - The Future Market

RFID - Technology Video

RFID system for warehouse management

Pallets identification and location with RFID on the forklifttruck by PHI DATA

Item Locator System

SAP Warehouse Project Case Study by CSI for Salton Europe Case Study

RFID Wizard for EASYLABEL labelling software - LogisticsIT.com

 

RFID Wizard for EASYLABEL labelling software

EASYLABEL's RFID Wizard allows you to easily create EPC (Electronic Product Code) and DoD (Department of Defence) smart labels.

The RFID Wizard will prompt you for the necessary information and EASYLABEL will do the rest. RFID projects that do not require the EPC or DoD RFID code can use EASYLABEL to directly program HF (High Frequency) or UHF (Ultra High Frequency) smart labels in a hexadecimal or ASCII format.

With EASYLABEL, you have the option to import parts or all of your RFID data from sources such as: databases, serial files, user input, existing bar code or text fields, and external text files.  You may also choose to print the RFID data, encoded in the RFID tags, on your smart labels as a text or bar code field.

An additional EASYLABEL RFID feature is the ability to write and print a report that includes the data used to program your printed smart labels. This report can then be used as part of an ASN (Advanced Shipping Notice) or to keep a record of labelled items.

Combining all of these RFID capabilities with EASYLABEL's other time-tested features, will allow you to easily design, report, program and print smart labels.

A complimentary trial edition is available for download from Tharo's web site at www.tharo.com.

RFID Wizard for EASYLABEL labelling software - LogisticsIT.com

Tuesday, 16 March 2010

SMARTFORM - Font Problem Arial 12 converting to courier 12 in print

 

how fonts in smartform works (as I guess).

A. Smartform has a smartform style
B. Smartform style use some fonts
C. In SE73 you must define font in Font families
D. In se73 you must define font as System Fonts
E. Every printer has its own Device type (LP01 has HPLJIIID I guess), so you must have in SE73 - Printer fonts - defined some of System fonts what do you want to use.
F. If the font used in smartform style is not defined in SE73 - Printer fonts - DT, SAP converts it with automatic generated table of "Font Conversion" (SE73 - Printer fonts - DT - Font Conversion Button above)
So if you dont have Arial in DT, SAP generate preview with conversion from table DT - "Font Conversion".
But beware ! It doesnt say what font will be used on printer. It says Print Controls in Device Type of Printer AND SE73 - Printer fonts - DT - Font x print control selection (or conversion table, if font doesnt exist).

Note 776507

 

Subscribe

Add to Favorites

Note 776507 - SAPscript/SmartForms: Which fonts for which languages?

Note Language:
Version: 4
Validity: valid since 22.08.2005

PDF
Download Corrections
Compare Versions
SSCR

Go to SAP Note: Display

Content: Summary  |  Header Data  |  Releases  |  Related Notes

Summary

Symptom

Documents printed via SAPscript or SmartForms do not print with correct special characters, e.g. ### prints instead of Japanese or Russian characters. What to do?

Other terms

SAPscript, SmartForms, printing, device types, OTF

Reason and Prerequisites

Help required to choose proper fonts in a SAPscript or SmartForm

Solution

When using SAPscript or SmartForms to print (or email or fax) a form from a business application, many factors influence the outcome of the actual text within the form. All these factors must be checked in order to ensure a correct printout:
1) The language version of the form used to produce the printout.
Example: If you want to print a French invoice, you need to have a FR version of your SAPscript or SmartForms invoice form RVINVOICE01. And the application program must specify the corresponding language key (FR) when calling the SAPscript or SmartForms API.
2) The font selections specified in the form (possibly also in a SAPscript style or SmartStyle used in a form).
Example: In a SAPscript form or a SmartStyle you need to specify HELVE if you want to print German text in Helvetica (or similar) font. If you want to print Japanese text, HELVE is not a valid choice but you need to specify a Japanese font like JPMINCHO in your Japanese form.
3) The output character set of the device type
Every printer in transaction SPAD has a "device type" assigned. Device types used by the spooler for printing support only one single specific output character set. All text from the form has to be converted (using SAP's built-in character conversion mechanism) to this output character set.
A character set can typically support either a single language (e.g. Shift-JIS which supports only Japanese) or a set of languages (e.g. ISO 8859-1, which supports Western-European languages). It is possible that a given language (such as German) can be supported by several output character sets, e.g. you may use either ISO 8895-1 (Latin-1) or ISO 8859-2 (Latin-2) to represent German text. This is so because both character sets contain the special characters used in German.
Example: HPLJ4000 is a HP LaserJet device type supporting the ISO 8859-1 (Latin-1) character set. ISO 8859-1 can be used to represent e.g. Dutch, English, French, German, Spanish, Swedish but NOT Russian or Japanese.
As a consequence, it is ok to use HPLJ4000 to print English, German French etc. but not for Japanese or Russian.
4) The set of available printer fonts for a given device type
When formatting a document, SAPscript and SmartForms perform an automatic mapping of the font definitions in the form (e.g. "HELVE 14 point bold") and the available printer fonts of the device type. A replacement printer font is chosen, should the specified font selection not be available in the device type. Now this replacement can be problematic if a language-specific font, such as Chinese CNSONG, is specified in a form and it gets replaced by a font which does not support this language, e.g. COURIER.
To solve this problem, font families in SE73 have language attribute assigned, e.g. some fonts are characterized as being suitable only for certain languages. And when a replacement has to be chosen because the original font from the form is not available in the device type, a replacement font is chosen which has the same language attributes.
If no fonts for the language in question exist in the device type, the resulting font will not be able to print the special characters and you will see "wrong" output characters in the printout.
Note on SAPscript/SmartForms Print Preview:
The OTF Print Preview available in Windows GUI (e.g. from transaction SP01) will sometimes not show the "wrong" characters which appear on the final printout. Here is the reason: since the Print Preview runs in Windows environment, it will use Windows fonts to represent the actual printer fonts. A Windows font typically has more available characters (i.e. covers more character sets) than are actually available in a printer's resident font.
A typical example where the Print Preview will differ from the printout is here: if you have a Chinese PCL5 printer such as CNHPLJ4 and use the Western Latin font COURIER in your document, the print preview will show you Chinese characters if you (by accident) tried to format Chinese characters in COURIER font. This is because Windows will automatically choose a font that can output Chinese characters (which is actually not Courier). But when you print the job on an actual PCL5 printer with resident Western and Chinese fonts, the Courier font will not print any Chinese characters but Western special characters instead, because the printer's resident Courier font does not include Chinese characters.
Rule of thumb: all Asian device types (e.g. CNHPLJ4, JPHPLJ4, JPPOST, KPHPLJ4) support not only Asian fonts but also COURIER, HELVE and TIMES fonts. But these Latin fonts can only be used to print English text, not Chinese/Japanese/Korean characters.

Which fonts are suitable for a given language?
Language(s):            Font family to use in a form:
************* Latin-1 (Western Europe/Americas) *******
DE,EN,FR,ES,NL,SV       COURIER, HELVE, TIMES
                        (LETGOTH, LNPRINT)
************* Latin-2 (Central Europe) ****************
PL, CZ                  COURIER, HELVE, TIMES
************* ISO 8859-4 (Baltic) *********************
ET, LT, LV              COURIER, HELVE, TIMES
************* ISO 8859-5 (Cyrillic) *******************
BG, RU, SR, UK          COURCYR, HELVCYR, TIMECYR
************* ISO 8859-7 (Greek) **********************
EL                      COUR_I7, HELV_I7, TIME_I7
************* ISO 8859-8 (Hebrew) *********************
HE                      COURIER, HELVE, TIMES
************* ISO 8859-9 (Turkish) ********************
TR                      COURIER, HELVE, TIMES
************* Simplified Chinese **********************
ZH                      CNHEI, CNKAI, CNSONG
************* Japanese ********************************
JA                      JPMINCHO, DBMINCHO, DBGOTHIC
************* Korean **********************************
KP                      KPBATANG, KPDODUM, KPGULIM
                        KPGUNGSE, KPSAMMUL
************* Traditional Chinese *********************
ZF                      TWDPHEI, TWMING, TWSONG
************* Thai ************************************
TH                      THANGSAN, THDRAFT, THVIJIT
************* Arabic (Unicode systems only) ***********
AR                      ANDALE_J

Verify your output by examining the OTF data
When analysing printing problems of this type, be sure to check the OTF data which gets produced by SAPscript or SmartForms. OTF or "Output Text Format" is the intermediate page-description format generated from SAPscript or SmartForms. OTF will contain the final printer font names and character set/language identifiers which help to solve the problem. OTF will even name the form and the language of the form used to create the output.
The easiest way to do this is to create a spool request from your application, run transaction SP01, use menu
Goto->Display Requests->Settings
and choose
Display Mode: Raw
Now display your spool request. If this is a SAPscript or SmartForms spool request, you will see OTF data. Each line represents one OTF command, every command starts with a 2-character cmd identifier and possibly some cmd parameters follow.
Here is an excerpt from a sample OTF file where we highlight the most interesting commands:
//XHPLJ8000    0700 00000+00000+1
IN04EALEXTEST_ZEBRA
IN05%PAGE1
OPDINA4  P 144  240 1683811906000010000100001
IN06%WINDOW2
MT0024401289
CP11000000E
FCHELVE  120  00109XSF100SF101110000067E X
UL +0000000000000
SW00067
CT00000000
ST0453037Dieses SF hat Stil ALEXTEST_ZEBRA mit
...
The 1st line with the // (Control) command reveals the device type used to print: HPLJ8000
//XHPLJ8000    0700 00000+00000+1
The 2nd line (IN = Info command) shows the name and (internal 1-char) language key of the form:
IN04EALEXTEST_ZEBRA
In this case it is the English (E = EN) SmartForm ALEXTEST_ZEBRA
The OP-line (OP = Open Page) gives the page format used in the form, it is DINA4 Portrait orientation:
OPDINA4  P 144  240 1683811906000010000100001
The CP (CodePage) cmd shows the SAP system codepage used to code the text and the active language. In our case it is codepage 1100 and language E = EN = English.
CP11000000E
Finally, the FC-cmd (Font Call) lists a printer font selected within SmartForms. Please note that every SmartForm has a designated default SmartStyle under "Form Attributes->Output Options". In addition, every text node can have a SmartStyle attached (which will override the definitions from the default style for the text). In our case the resulting printer font that was selected is HELVE 12.0 pt bold-off, italic-off.
FCHELVE   120  00109XSF100SF101110000067E X

Header Data

Release Status:
Released for Customer

Released on:
22.08.2005  09:57:20

Master Language:
English

Priority:
Recommendations/additional info

Category:
Customizing

Primary Component:
BC-CCM-PRN Print and Output Management

Secondary Components:
BC-SRV-SCR SAPscript

BC-SRV-SSF Smart Forms

Affected Releases

Release-Independent

Related Notes

1319517 - Unicode Collection Note

880490 - Russian Sapscript forms print with wrong characters

423003 - Printers and Asian/Eastern European fonts/languages

Print Selected Notes (PDF)

SAP Community Network Wiki - ABAP Development - Handling Idoc Acknowledgements

 My Home > ABAP Development > ...Data Transfers - BAPI, BDC, ALE, LSMW, DX-WB > ALE,IDOC > Handling Idoc Acknowledgements

Handling Idoc Acknowledgements 
Apr 13, 2009  (view change)

Labels:

idoc, ack, acknowledgement, status

Way of handling the acknowledgements forthe custom generated Idocs.

Note: I took an example custom Idoc which has already been developed to explain the concept of handling Acknowledgements. I am providing the necessary details here before proceeding to the actual concept

Sender System       : BANGSEND
Recieving System  : HYDRECIEVE
Message Type         : ZEMP84364_MNT_RPT
Basic Type                : ZEMP84364_MNT_RPT01
Functionality of the Idoc : Transfers the records created with the help of a report program and updates the database table of the target system.

For this scenaio, now we are going to see how we can handle the acknowledgement.

ALE Configuration for Idoc Acknowledgement:

Sender creates an Outbound Idoc and this particular Idoc is received by the receiver as an Inbound Idoc and receiver system processes the Idoc, it updates the database tables. Now, Sender system would never know what happened to the document that it has passed to the receiver. So, to make sure that the receiver had posted the application document in the necessary database tables, we would need an Acknowledgement.

ALEAUD is a standard message type through which we can achieve this functionality. Now, we need to update the settings for ALEAUD message type in both sender and receiver systems.

Add ALEAUD message type in the outbound parameters for the partner BANGSEND. Now, this particular Ack Idoc would behave as an outbound Idoc from the receiver system of the actual Idoc to the sender system of the actual Idoc.

The settings after adding the ALEAUD Idoc in the outbound parameters in the above screen is shown below.
This is the place where we are using the port that we have created in the receiver system.
Note: Select the Output mode as Transfer Idoc immediately (Though it is optional, you can collect all the Idocs and process them using a job). Save the screen.
Now, make similar settings in the sender system. As, HYDRECIEVE is the partner for the BANGSEND system, you would receive the Acknowledgement Idoc as inbound in the BANGSEND system. So, add the ALEAUD message type in the Inbound parameters of the partner HYDRECIEVE as shown below.
The actual process code settings that we need to do after adding the message type ALEAUD in the inbound parameters is shown below
Since you are using the standard message type, no need to write a function module to process these Ack Idocs. Even the process code that we are using is a standard one.
Now, you need to create Distribution model in the receiver system for these ALEAUD Idocs
Below screen shows that, HYDRECIEVE system is going send ALEAUD Idocs to the BANGSEND system with the distribution model name MODEL_ACKS which we have not yet created.

Save the screen now which is very important


To generate partner profiles, go to the menu Environment and click on Generate Partner Profiles and execute the below screen.

After executing the above screen you would see that the partner profiles created. Items marked in the green color are the ones which are created automatically.
A standard message type SYNCH always gets generated and you can check the same in the partner profiles.

Now, once you are done with the above you need to distribute the distribution model with the partner system by clicking on the menu Edit -> Model View -> Distribute
Click on Ok and the distribution model is shared with the partner system as shown in the next screen.

Click on OK.

Testing the Idoc by running the Application Program:

Go to the Sender system, execute the Application Program (ABAP Program) and enter the selection screen the details as shown below.

Now execute the above screen and you would see the output saying the Idoc number generated as shown below

Now, Go to WE05 transaction and see the above Idoc.
In the above screen the very last one is the Idoc that has been created now. Let us open the Idoc and verify the contents as shown below.

In the above screen, the final status of the Idoc is 03. It means that, the Idoc has gone to the destination system. But, we do not know whether the Idoc has been processed there or not. Now, let us go to the target system and check whether this particular Idoc has been converted in to an Inbound Idoc to get posted in the target database.
Execute WE05 transaction in the target system and see the Idoc. Based on the time, the last Idoc that has been processed should be the Idoc that has been created. The Idoc is selected for the reference.

Let us open the Idoc and see whether the contents of the Outbound Idoc of Sender are same as the contents of the Inbound Idoc in the target system.

You can see that content of the Idoc is same and as the status of the Idoc is in 53, we can confirm that the Idoc has been posted in the target database.
Let us verify that by opening the database table in the target system.

We can see that the record has been updated in the target database.

This ends the Idoc posting.

But, in the view of Sender as the Outbound Idoc is in 03 status, Sender would never know what happened to the Idoc in the target system.
So, in production environment generally a job is set to run periodically which has the program RBDSATATE with the variant SAP_AUDIT_SEND to send the audit data back to the Sender from the target system.

In our case, let us run the job manually to send the Audit data back to the sender system

The job has finished and the spool shows that there is an Idoc with the message type ALEAUD that has been generated as shown below.

Now, go to the Sender system and check the status of the Idoc it should have been changed to 41(Final Status of any Outbound Idoc) as the Idoc has been posted successfully here in the target system.Go to sender system and open WE05 transaction.


In the above screen, you can clearly see that all the Idocs have been changed to the status 41. You can see the same for our Idoc in the below screen.

This ends the way of handling Idoc Acknowledgements.

Contact Us Site Index Marketing Opportunities Legal Terms Privacy Impressum
Powered by SAP NetWeaver

SAP Community Network Wiki - ABAP Development - Handling Idoc Acknowledgements

SAP Community Network Wiki - ABAP Development - ALE,IDOC

 

ALE Technology : Application Link Enabling (ALE) is a technology to create and run distributed applications.  ALE Technology is proprietary of SAP.

ALE Objectives - ALE incorporates controlled exchange of data messages ensuring data consistency across loosely coupled applications. ALE comprises of three layers.  Application Services  Distribution Services  and Communication Services .Basic principle of ALE is to provide a distributed and fully integrated R/3 system. Each application is self-sufficient. The use of self-sufficient system implies a certain measure of data redundancy.Hence data has to be both distributed and synchronized.

Difference Between ALE and EDI :Normally we refer to EDI technology when a non SAP system is one of the communication channel. ALE communication occurs from the SAP side and EDI from the non-SAP side. IDOCs uses ALE and EDI to deliver the data to the receiving system. If the data needs to be exchanged between two SAP systems, then IDOC uses ALE technology . For the exchange of data between a SAP and Non SAP system, IDOC uses EDI subsystem to convert and deliver the data.

ALE Communication Diagram

1. What is the difference Between IDOC type and Message type? How to link the IDOC type with Message type?
Message type gives the meaning of the IDOC . IDOC type gives the structure of an IDOC.The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message and  the IDOC type.The IDoc type indicates the SAP format that is to be used to interpret the data of a business transaction.
In the OO(Object Oriented) approach, Message Type can be refferred to a Class and IDOC Type as an instance of the class Message Type
The linkage will happen in transaction WE82.

2. Where the IDOC information gets stored?

Table
Description

EDIDC
Stores the Control Record information an IDOC

EDID4
Stores the Data Records (version 4.6)

EDIDD
Data Seg (EDI Intermediate doc)

EDIDS
Stores the Status of an IDOC

3. What is process code? What  are type of process codes

Process code refers to an workflow or a function module which helps in reading or writing data from/to Idoc. Process Codes are used in both ALE and EDI framework to identify the function module or API (Application Programming Interface) to be invoked for subsequent processing. Inbound as well as outbound interfaces use process code but for different purposes. Outbound process codes are stored in table TEDE1, while inbound process codes are stored in TEDE2.

Following are types of process code

Process Code
Description

Outbound Process Code
This will read application data and place data in Idoc 

Inbound Process Code
This will Idoc and create corresponding application data

System Process Code
This will create  work item in case some error occurs in idoc / application document processing

Status Proces Code
This will handle error that occurs when a idoc is sent to some other system

4. How to reprocess an IDOC?

You can use the below Programs for IDocs Reprocessing:

  • RBDMANI2  : Reprocess Idocs manually
  • RBDMANIN  : Posting of IDocs with Status 51
  • RBDMOIND  : Outbound Idocs status 03->12
  • RSEOUT00  : For Processing 30 Status IDocs
  • RBDAPP01  : For Processing 64 Status IDocs
  • RBDAGAIN : Reprocess Incorrect Outbound IDocs
  • RBDAGAI2 : Reprocessing of IDocs after ALE Input Error

5. How to trace the IDocs of the Receiving system from the Sending system?

Steps:

  • Execute the transaction BD87
  • Give the Outbound IDocs in the IDoc Number field and execute or Just Note the Start time and End time when u execute the Master Data Transaction say for eg.BD10 and specify the same in the Time Created input field of BD87,also give the Message Type and the Receiving System Names and execute.
  • Select the Repective Message Type and Press the Trace IDoc Button.

6. How to trace IDocs based on the data .

Steps:

  •   Execute Transaction WE09
  •   Put in the message type name in the field labeled 'Logical Message'   Ex -  DEBMAS
  •   Now we will move to the section 'Criteria for Search in Data Records '
  •   In this section we will put the Segment name in which we want to search the existance of data in the field labeled 'Search in Segment'  EX - E1KNA1M
  •   In the field labeled 'Search in Field' we will put the field name of the segment in which we want to search the existance of data. Ex - KUNNR for searching IDOCs for certain customer number.
  •   Now in the field labeled 'For Value' we will put the search value. Ex - Customer number as 100 .
  •   We will now execute the transaction.
  •   The result can be a single Idoc or a list of multiple IDOCS depending upon the Search Criteria entered.

7. How to Send and Receive an IDoc in the same system.

Steps :

  • Create a Dummy Logical System.
    • Goto T-Code SALE-> sending and Receiving Systems -> Logical Systems -> New entries.Enter SYSID_CLNT, but this one is Dummy so use the first 2 characters of the SYSID and prefix 'D' then underscore and then the Client number.
    • E.g.: If ERP_100 is the logical system of the R/3 then create ERD_100 as the dummy system.
  • Create Port for the Original System, (ERP_100)
    • Goto WE21 and select Transactional Port and press the Create button. Name the Port as "SAP" contatenated with the SYSID in our example it would be SAPERP Select the appropriate version and enter the RFC dest of the system that you are working on in this case it will be 'ERP'.
  • Create Partner Profile in partner type LS:
    • Receiver Side ( Outbound to ) :  In Partner type LS name ERD_100create the Outbound Parameters, give the Message type, Receiver Port same as the port we created in step 2. Enter the Basic type.
    • Sender Side ( Inbound From ): In partner type LS name ERP_100 create the Inbound Parameters, give the appropriate message type and the process code.
  • Now create the stand alone program to send the IDoc:
    • The program will at some point calls the MASTER_IDOC_DISTRIBUTE function module. When you pass the EDIDC structure it will be populated as follows:
      i_edidc-mestyp = message type.
      i_edidc-idoctp = basic type.
      i_edidc-rcvprt = 'LS'.
      Concatenate 'SAP' sy-sysid into l_port.  
      i_edidc-RCVPOR = l_port.
      i_edidc-rcvprn = 'ERD_000'.
      CONCATENATE sy-sysid '_' sy-mandt
      INTO l_sndprn.
      i_edidc-SNDPRN = l_sndprn.
      i_edidc-sndprt = 'LS'.
      i_edidc-sndpor = l_port.
  • Observe that the Sender port and the receiver port is the same, this does the trick. The outbound Idoc is sent on the port SAPERP with the Sender as ERP_100 and receiver as ERD_100 and then the Inbound Idoc is also sent to the same port SAPERP with the Sender as ERP_100 and receiver as ERD_100.

8. What is message control and when do we use it?

Message control is a mechanism by which documents are output based on a selection criteria and requirements. This concept is applicable not only to EDI and ALE, but also to other output mediums (for example: print, fax). Message control determines the type of document, its timing, number, and the medium. NAST table stores output records. The conditions (selection criteria and requirements) for creating an output message are stored in condition tables. Search mechanisms are used through access sequences, output processes, and requirements to determine whether an application document qualifies for output.

Some of the tables for Message Control are :

Transaction Code
Description

NACE
Condition Record Maintenance

VOK2
SD Message Control Components

VOK3
Purchasing message Control Components

VOFM
View Message Requirements

V/86
Condition Table Field Catalog

WE15
IDOC test : outbound from Message Control

9. How do you reprocess the failed trfc entries?

  You can reprocess the failed trfc entries using the program RSARFCEX.

10. What is the transaction used to find the outbound and inbound process codes at one place?

WE64

Children Hide Children  |  View in Hierarchy

7 Steps For ALE Configuration
Administration of ALE Functions and Troubleshooting ALE
ALE- DDIC tables that are reflected with respect to Partner Profiles
Change Pointers
Creating an ABAP program from a BDC recording
Customer Master Record (Tax Groupings) in Customer ALE
EDI 997 - Functional acknowledgement
Handling Idoc Acknowledgements
IDOC Steps
Idocs
Interface Development using IDOC's
Managing Data in different Formats with IDOC
Message Control for ALE
Modify IDOC Status by Program
Outbound Idoc Through ALE
TO BE DELETED

SAP Community Network Wiki - ABAP Development - ALE,IDOC