Create / change Conversion Rule 0BPARTNER

Hello,
I search for a customer conversion rule in BPARTNER.
We have log problems. There are Breakpoints in Generated Programms. At first we thought that the problem is a coding bug (handmade by programmer) but we didnt find the transfer rule. Furthermore we found out that the problem (Coding fragment) is in a "conversion rule".
The Questions:
Where can i find the place where the conversion rule can be added? (We allready have the programm name)
What is a conversion rule generally and how to define a customer conversion rule instead of a standard conversion rule from SAP?
Thanks alot!
BR Rene!

Hello ,
how exactly can I open the conversion rule in Update rule BW 3.5? (That is my problem?)
Sorry, I dont understand what you mean.
What means this code from function module?
FUNCTION CONVERSION_EXIT_ALPHA_OUTPUT.
*"Lokale Schnittstelle:
*"       IMPORTING
*"             INPUT
*"       EXPORTING
*"             OUTPUT
CALL 'CONVERSION_EXIT_ALPHA_OUTPUT' ID 'INPUT' FIELD INPUT
                                      ID 'OUTPUT' FIELD OUTPUT.
ENDFUNCTION.
BR Rene
Edited by: NW-DEV on Jun 2, 2009 5:20 PM

Similar Messages

IDOC inbound conversion Rules

Hi to all,
I'm Implementing an Inbound Interface for Cost Centers using idoc message COSMAS and IDOC type COSMAS01.
I want to modify IDOC data changing the cost center code by another one stored locally in a param table (Z*).
I think the best way to do this is by creating a conversion rule in BD72 than maintain and assign to Message type. The problem is that i have to select data from the Z* Table i need two parameters from the IDOC(LogicalSystem and cost center). How can I create a custom conversion routine or something to get this data from the Z table into the IDOC field (KOSTL).
The conversion exits only have one import parameter and one export parameter.
Do anyone had one problem like this?
Thanks in advance to all.

Hi,
Please check the documentation in WE60 tcode and see if the fields are required to be passed...
Regards,
Nagaraj

Can we write code using BD79(ALE IDoc Conversion Rule)

Hi -
I had created a conversion rule that specifies for the field account group (KTOKD) on KNA1: I need to include the following logic :
if the customer number (KNA1-KUNNR) is in the range 0010000000-0019999999 or 0140000000 to 0149999999, then change the account group value to u201CSKIPu201D.
So I had created a conversion rule using BD62.
In BD79, I had set the constant to SKIP.
But where to include the following logic :
if the customer number (KNA1-KUNNR) is in the range 0010000000-0019999999 or 0140000000 to 0149999999, then change the account group value to u201CSKIPu201D.
Thanks,
Gyanaraj

Hi Shital ,
Thank U very much for replying to my question.
But when I m trying to create the same , by clicking Use general rule & specifying special conversion routine ZBLNK , it is throwing the following error "Conversion exit ZBLNK does not exist".
Please can u help me out.
Thanks,
Gyanaraj

Conversion rule in ALE/IDocs

Hi,
   I have a requirement to make use of conversion rules in ALE/IDocs.
   For a particular field, I need to concatenate the values of two other fields in the IDOC segment
   and populate the value. The other direct options like setting a constant or changing a field's value
   work fine.
   But I was not able to figure out how to implement this option. Does anyone have an idea?
Regards,
Sudeep

Hi sudeep
Could you let me know the exact steps you did to create the conversion rule for idocs.
Thanks in Advance

About conversion rule in BD79

Dear experts,
I would like to fall back on your help on the conversion rule in BD79.
In our system, there is a HTTP connection used for sending IDoc to the website. The Unit of measurement need be converted when sending out to the receiver side. The problem is when I converted using BD79 with rule type 'Conver Sender fields', set conditon to convert unit '%' to 'wt%', but the value in recerive field always display in Upper letters('WT%').
Can anyone help me on this problem? if it can not be realized in this way, please show me another possible solution.
Besides, is it possbile to convert '%' to 'wt%' with some condition to make it just apply to some spectial characteristics?
Many thanks in advance.
Regards,
Benny

Hi sudeep
Could you let me know the exact steps you did to create the conversion rule for idocs.
Thanks in Advance

ALE Conversion Rules: Make recv'r dependant on different sender segment?

Hi Everyone,
I am putting in a conversion rule for MBEW-LIFO. I need this field to be checked on the receiving end ONLY for certain Material Types.
I know I can create a conversion rule to place in 'X' in MBEW-LIFO, but can I make that dependant upon Material Type, which is not in the E1MBEWM segment? I believe material type is in E1MARCM....
thanks!
Jen

hi Sudeep.
kindly look at this thread as reference ,inorder to get rid of your problem
aler&idocs
Regards
Saurabh Goel

Idoc Conversion rule, Change pointers and Filters

Hi Experts,
Please any one can help me out, i need material or clear picture about Idoc Conversion rule, Change pointers and Filters where we can use these concepts what is the befit for these concepts.
Thanks in advance,
Ramesh.

Hi,
Check this link. It has got some of the tutorials you are looking for.
http://www.****************/Tutorials/ALE/ALEMainPage.htm
Cheers
VJ

BD79 - conversion rule issue

Hi,
I am trying to send vendor master data between 2 client (on change
pointers) whenever there is change in vendor.
I have done full ale config and i can see the idoc coming in the
receiver system.
Now when i try using conversion as my requirement is to modify some
data, then i cant see the idoc data in sending or receiving system,idoc
gets created but there is no data in there.
I have attached the screenshot of my conversion steps. I am using
CREMAS with segment E1LFA1M
in BD79 i have used create proposal for rule just for testing purpose

Hi Ajay,
Try to 'Set constant' in BD79 under the section 'What happens with the non-assigned/non-converted field values?' too.
Regards,
Soumya.

IDOC reprocessing with new conversion rules

Hi All,
we've created IDOCs and after the creation the conversion rules are changed. Now we want to reprocess the IDOC's and in the reprocessing we want to use the new conversion rules.
I've tried just reprocessing, I also tried WE19, but with these 2 the conversion rules seem to left untouched.
Has anyone a solution were I can reprocess making use of the new rules?
kind regards,
Pieter

Hi,
I've debugged the reprocessing of the idoc and it seems indeed I had to change the status, however not all statusses result in reprocessing of the rules. Status '29' Error in ALE Service works. So my problem is solved.
Thank you.
kind regards,
Pieter

SAKNR and conversion rule

Hello!
It is possible that u201CG/L account numberu201D (Data element: SAKNR) could be stored without a conversion rule?
Now when we introduce a new account this is left aligned and zeros are introduced at right. There is any mechanism to deactivate this conversion?
Thanks a lot.

Are you sure of your description, SAKNR has the ALPHA rule, and is intend to receive numbers, so they are Right Justified and internally padded with leading zero (so the identification is sorted like the number), there is an Alphabetic field SKA1-SAKAN which contains the external format for search help purpose.
Nevertheless, there is a SMOD Enhancement to manage the general account number SAPMF02H. (Create a project under CMOD and attach the Enhancement)
Edit the ZXF03U01 include of function module EXIT_SAPMF02H_001.
Be aware that your Enhancement must not change the coding of an existing account, else your database will become inconsistent.
Regards

Idoc conversion rule

Hi,
What is idoc conversion rule? Why we need this?
While upgrading from 4.7 to ECC 6.0 what all precautions need to be taken for the existing standard idocs and custom idocs in the system.
Thanks & Regards,
Soumya.

Hi,
ALE allows the user to perform an SAP transaction in the sending system, after-which the following steps occur:
1 or more communication IDocs (intermediate documents: container for the application data) are created in the sending system database. An ALE distribution model, that needs to have been configured, determines which systems the IDocs are to be sent
These communication IDocs, that contain the relevant application data of the transaction that was performed, are then passed to the ALE communication layer
This layer performs an RFC call, using the port definition and an RFC destination determined through the customer model
The IDocs are then transferred to the respective receiving systems. These could be SAP R/3, R/2 or external systems
If the receiving system is an SAP system then:
In the case of master data distribution the same transaction that was performed on the sending system is again performed on the receiving system with the data contained in the IDoc. This allows the data to go through the SAP checks before posting occurs
In the case of transaction scenarios the relevant data is passed to the respective transactions in order to load the required application document. Eg. A PO is loaded on the sending side, yet a SO is created on the receiving system
Master data has another difference:
It can be set up in such a way that any changes made to specific fields in master data tables can automatically trigger off the ALE distribution process for that particular master data object
If a master data object is created or changed on a sending system and distributed to another system the respective transaction is used to either create or change that respective master data object on the receiving system
In general, if standard SAP can't perform the task required then neither can ALE. It doesn't add functionality, it merely decouples it and allows you to distribute it onto other remote systems.
The Detail as described by SAP
In the output processing one of the function modules of the application creates an IDoc, the so-called master IDoc. This IDoc is sent to the ALE layer where the following processing steps are applied:
Outbound processing
Receiver determination
An IDoc is similar to a normal letter in that it has a sender and a receiver. If the receiver has not been explicitly identified by the application, then the ALE layer uses the customer distribution model to help determine the receivers for the message.
The ALE layer can find out from the model whether any distributed systems should receive the message and, if so, then how many. The result may be that one, several or no receivers at all are found.
For each of the distributed systems that have been ascertained to be receiver systems, the data that is specified by the filter objects in the customer distribution model is selected from the master IDoc. This data is then used to fill an IDoc, and the appropriate system is entered as receiver.
Data selection
Segment filtering
Individual segments can be deleted from the IDoc before dispatch by selecting Functions for the IDoc processing -> Settings for filtering in ALE Customizing. The appropriate setting depends on the sending and receiving logical R/3 System.
Field conversion
Receiver-specific field conversions are defined under Functions for the IDoc processing -> Conversions.
General rules can be specified for field conversions; these are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field "plant" can be converted from a 2-character field to a 4-character field.
The conversion is done using general EIS conversion tools (Executive Information System).
Version change
SAP ensures that ALE functions between different R/3 System releases. By changing the IDoc format you can convert message types of different R/3 releases. SAP Development use the following rules when converting existing message types:
Fields may be appended to a segment type;
Segments can be added;
ALE Customizing keeps a record of which version of each message type is in use for each receiver. The correct version of the communication IDoc is created in the ALE output.
The resulting IDocs (it is possible that several IDocs could be created in the receiver determination) are referred to as communication IDocs and are stored in the database. The dispatch control then decides which of these IDocs should be sent immediately. These are passed to the communications layer and are sent either using the transactional Remote Function Call (RFC) or via file interfaces (e.g. for EDI).
If an error occurs in the ALE layer, the IDoc containing the error is stored and a workflow is created. The ALE administrator can use this workflow to process the error.
Inbound processing
After an IDoc has been successfully transmitted to another system, inbound processing is carried out in the receiver system, involving the following steps in the ALE layer:
Segment filtering
Segment filtering functions the same way in inbound processing as in outbound processing.
Field conversion
Specific field conversions are defined in ALE Customizing.
The conversion itself is performed using general conversion tools from the EIS area (Executive Information System).
Generalized rules can be defined. The ALE implementation guide describes how the conversion rules can be specified.
One set of rules is created for each IDoc segment and rules are defined for each segment field.
The rules for converting data fields from an R/2-specific format to an R/3 format can be defined in this way. An example of this R/2 - R/3 conversion is the conversion of the plant field from a 2 character field to a 4 character field.
Data transfer to the application
Input control
When the IDocs have been written to the database, they can be imported by the receiver application.
IDocs can be passed to the application either immediately on arrival or can follow in batch.
You can post an inbound IDoc in three ways:
by calling a function module directly: A function is called that imports the IDoc directly. An error workflow will be started only if an error occurs.
by starting a SAP Business Workflow. A workflow is the sequence of steps to post an IDoc.
by starting a work item A single step performs the IDoc posting.
The standard inbound processing setting is that ALE calls a function module directly. For information about SAP Business Workflow alternatives refer to the online help for ALE programming.

Alternate Unit of Measure Conversion Rule Error

We want to sell Cement by the Ton, the base unit of measure its kilograms.
But there its an error on the Material Master and the rule of conversion between Ton and Kilograms its 1 to 1.
First I try to change it then I tried to enter a new one with TNE (Metric Ton) and in both cases after I enter 1,000 on the kilogram box, SAP returns a 1 and in the bottom bar a green icon and the message: " units of measure have been verified and corrected" (translated)
Its there some menu where I can correct these conversion rules?
Thanks

Hi Carlos
We had lot of trouble with unit of measures in one of our projects.
The rule is you can't change base unit of measure untill all open objects are completed. The open objects typically are Sales Orders, production order, purchase orders, etc. If you try to chnage Base unit of measure, SAP gives you an error with list of open objects.
Second rule is it should be the smallest unit of measure if possible. For ex- you can't have base unit as Kilos and then alternate unit of measure as Grams. In this case Grams should be the smallest unit of measure.
But once all open objects are closed and Base Unit is chnaged, I have not seen any problems in the previous transactions. We have done it multiple times.
Another alternative to get out of this is, discard this material and create a new one with correct unit of measures.
Hope this helps.
Mankai

SCOT conversion rule

Hi,
What is the usage for the conversion rule under Tcode: SCOT. Since, i faced a problem that the outgoing email attachment always converted to TXT file( By my ABAP program with FM SO_NEW_DOCUMENT_ATT_SEND_API1). Could i do some changes in this area??
Regards,
Kit

Hi,
You can use printing using e-mail to send data as an attachment to an e-mail. The recipient can then display and/or print the data.
All device types can be used to print the e-mail. However, you must ensure that the relevant display program or printer is available for the device type. We recommend that you use device type pdf1, as with pdf1, a PDF file is generated from the document, and sent as an e-mail attachment. You can then display this with a PDF display program, such as Adobe Acrobat Reader, and print it as required.
Prerequisites
·        As of SAP Web Application Server 6.10, you must have activated and configured the interface to send e-mails from the SAP System in SAPconnect (transaction SCOT). For more information, see the Guidelines for SMTP Configuration. These guidelines explain, among other things, how to create an SMTP node in transaction SCOT, which can be used without special additional settings for e-mail printing.
Up to SAP Basis 4.6D, communication is performed using an additional external communication system and, accordingly, a SAPconnect node with the corresponding RFC connection must be set up until SAP Basis 4.6D (inclusive).
·        So that the recipient not only receives the mail, but can also reply using the REPLY button, you must maintain the e-mail addresses for all users in the user maintenance transaction SU01.
If you are using a default domain in transaction SCOT, the mail is sent, but the relevant user cannot reply using the reply button, as the generic sender address does not really exist.
·        You must have created a device definition for printing using e-mail in the SAP System.
·        To print using e-mail, the sender must, in addition to the usual authorization for the output device, also have authorization for the (pseudo) output device %MAI.
With this authorization, you can easily remove the right to use devices with access method M from individual users.
also check the below link
http://help.sap.com/saphelp_nw04/helpdata/en/39/4d3d3d9ba00645e10000000a114084/content.htm
Regards,
Nagaraj

Step-by step procedure for INBOUND IDOC (VENDOR CREATE / CHANGE)

Hi ,
Can any body provide me the step-by-step procedure for Inbound IDOCS.
As i'm new to this i need the the clarification between Inbound & outbound idocs.
How can we differentiate both?
where to define outbound & where to define Inbound?
( If possible Please explain me the procedure for Vendor Create through INBOUND IDOCS )
Thanks in advance..

Hi,
Ale Technology is SAPu2019s technology to support distributed yet integrated processes across several SAP systems.
Outbound Process:
ALE Outbound Process in SAP sends data to one or more SAP Systems. It involves four steps.
1. Identify the need of IDoc: This step starts upon creating a application document, can relate to a change to a master data object.
2. Generate the Master IDoc: The document or master data to be sent is read from the database and formatted into an IDoc format. This IDoc is called as a Master IDoc.
3. Generate the Communication IDoc: The ALE Service layer generates a separate IDoc from the Master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the Master IDoc. These recipient-specific IDocs are called Communication IDocs and are stored in the database.
4. Deliver the Communication IDoc: The IDoc is delivered to the recipients using an asynchronous communication method. This allows the sending system to continue its processing without having to wait for the destination system to receiver or process the IDoc.
Inbound Process:
The inbound process receives an IDoc and creates a document in the system.
1. Store the IDoc in the database: The IDoc is received from the sending system and stored in the database. Then the IDoc goes through a basic integrity check and syntax check.
2. Invoke the Posting Module: The control information in the IDoc and configuration tables are read to determine the posting program. The IDoc is then transferred to its posting program.
3. Create the Document: The posting program reads the IDoc data and then creates a document in the system. The results are logged in the IDoc.
Over view of IDocs:
IDoc is a container that is used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure SAP uses to store application data. This type of flexibility enables SAP to rearrange its internal structure without affecting the existing interface.
IDoc interface represents an IDoc Type or IDoc data. IDoc Type represents IDocu2019s definition and IDoc Data is an instance of the IDoc Type.
IDoc Types:
IDoc type structure can consist of several segments, and each segment can consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments and arrangement of the segments. Segments define a set of fields and their format.
An IDoc is an instance of an IDoc Type and consists of three types of records.
i. One Control record: each IDoc has only one control record. The control record contains all the control information about an IDoc, including the IDoc number, the sender and recipient information, and information such as the message type it represents and IDoc type. The control record structure is same for all IDocs.
ii. One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records, which store application data, such as purchase order header information and purchase order detail lines.
iii. One or Many Status records: An IDoc can have multiple status records. Status record helps to determine whether an IDoc has any error.
Message in IDoc Type:
A Message represents a specific type of document transmitted between two partners.
Outbound Process in IDocs:
Outbound process used the following components to generate an IDoc. A customer model, and IDoc structure, selection programs, filter objects, conversion rules, a port definition, an RFC destination, a partner profile, service programs, and configuration tables.
The Customer Model:
A customer model is used to model a distribution scenario. In a customer model, you identify the systems involved in a distribution scenario and the message exchanged between the systems.
Message control:
Message control is a cross application technology used in pricing, account determination, material determination, and output determination. The output determination technique of Message control triggers the ALE for a business document. Message control separates the logic of generating IDocs from the application logic.
Change Pointers:
The change pointers technique is based on the change document technique, which tracks changes made to key documents in SAP, such as the material master, customer master and sales order.
Changes made to a document are recorded in the change document header table CDHDR, and additional change pointers are written in the BDCP table for the changes relevant to ALE.
IDoc Structure:
A message is defined for data that is exchanged between two systems. The message type is based on one or more IDoc structures.
Selection Program:
Is typically implemented as function modules, are designed to extract application data and create a master IDoc. A selection program exists for each message type. A selection programu2019s design depends on the triggering mechanism used in the process.
Filter Objects;
Filter Objects remove unwanted data for each recipient of the data basing on the recipients requirement.
Port Definition:
A port is used in an outbound process to define the medium in which documents are transferred to the destination system. ALE used a Transactional RFC port, which transfers data in memory buffers.
RFC Destination:
The RFC destination is a logical name used to define the characteristics of a communication link to a remote system on which a function needs to be executed.
Partner Profile:
A partner profile specifies the components used in an outbound process(logical name of the remote SAP system, IDoc Type, message type, TRFC port), an IDocu2019s packet size, the mode in which the process sends an IDoc (batch versus immediate), and the person to be notified in case of error.
Service Programs and Configuration Tables:
The outbound process, being asynchronous, is essentially a sequence of several processes that work together. SAP provides service programs and configuration tables to link these programs and provide customizing options for an outbound process.
Process flow for Distributing Transactional Data:
Transactional data is distributed using two techniques: with Message control and without message control.
Process flow for Distributing Master Data:
Master data between SAP systems is distributed using two techniques: Stand alone Programs and Change Pointers.
Triggering the Outbound Process via Stand-Alone Programs:
Stand-Alone programs are started explicitly by a user to transmit data from one SAP system to another. Standard Programs for several master data objects exist in SAP. Ex. The material master data can be transferred using the RBDSEMAT program or transaction BD10.
The stand-alone programs provide a selection screen to specify the objects to be transferred and the receiving system. After the stand-alone program is executed, it calls the IDoc selection program with the specified parameters.
Triggering the Outbound Process via Change Pointers:
The change pointer technique is used to initiate the outbound process automatically when master data is created or changed.
A standard program, RBDMIDOC, is scheduled to run on a periodic basis to evaluate the change pointers for a message type and start the ALE process for distributing the master data to the appropriate destination. The RBDMIDOC program reads the table TBDME to determine the IDoc selection program for a message type.
Processing in the Application Layer:
The customer distribution model is consulted to make sure that a receiver has been defined for the message to be transmitted. If not, processing ends. If at least one receiver exists, the IDoc selection program reads the master data object from the database and creates a master IDoc from it. The master IDoc is stored in memory. The program then calls the ALE service layer by using the function module MASTER_IDOC_DISTRIBUTE, passing the master IDoc and the receiver information.
Processing in the ALE Interface Layer:
Processing in the ALE Layer consists of the following steps:
u2022 Receiver Determination: The determination of the receiver is done through Customer Distribution Model.
u2022 IDoc Filtering: if an IDoc filter is specified in the distribution model for a receiver, values in the filter are compared against the values in the IDoc data records. If a data record does not meet the filter criteria, it is dropped.
u2022 Segment Filtering: For each sender and receiver combination, a set of segments that are not required can be filtered out.
u2022 Field conversion: Field values in data records are converted by using the conversion rules specified for the segment.
u2022 Version change for segments: Segments are version-controlled. A new version of a segment always contains fields from the preceding version and fields added for the new version. Release in IDoc type field of the partner profile to determine the version of the segment to be generated.
u2022 Version change for IDocs: IDocs are also version controlled. The version is determined from the Basic Type field of the partner profile.
u2022 Communication IDocs generated: The final IDoc generated for a receiver after all the conversions and filtering operations is the communication IDoc. One master IDoc can have multiple communication IDocs depending on the number of receivers identified and the filter operations performed. IDoc gets the status record with a status code of 01 (IDoc Created).
u2022 Syntax check performed: IDoc goes through a syntax check and data integrity validation. If errors found the IDoc get the status of 26 (error during syntax check of IDoc u2013 Outbound). If no errors found the IDoc gets the status 30 (IDoc ready for dispatch u2013 ALE Service).
u2022 IDoc dispatched to the communication Layer: In the ALE process, IDocs are dispatched using the asynchronous RFC method, which means that the sending system does not await for data to be received or processed on the destination system. After IDocs have been transferred to the communication layer, they get a status code 01 (Data Passed to Port OK).
Processing in the Communication Layer:
To dispatch an IDoc to a destination system, the system reads the port definition specified in the partner profile to determine the destination system, which is then used to read the RFC destination. The RFC destination contains communication settings to log o to the remote SAP system. The sending system calls the INBOUND_IDOC_PROCESS function module asynchronously on the destination system and passes the IDoc data via the memory buffers.
Inbound Process in IDocs:
An inbound process used IDoc structure, posting programs, filter objects, conversion rules, a partner profile, service programs, and configuration tables to post an application document from an IDoc.
Posting Program:
Posting programs, which are implemented as function modules, read data from an IDoc and create an application document from it. A posting program exists for each message. Each posting program is assigned a process code. A process code can point to a function module or a work flow. In the standard program process codes always point to a function module.
Ex. The posting program for message type MATMAS is IDOC_INPUT_MATMAS which has a process code MATM.
Workflow:
A workflow represents a sequence of customized steps to be carried out for a process. The workflow management system is used to model the sequence, identify information required to carry out the steps and identify the person responsible for the dialog steps.
Partner Profile;
A partner profile specifies the components used in an inbound process (partner number, message type, and process code), the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.
Process flow for the Inbound process via a Function Module:
In this process, IDocs are received from another system and passed to the posting function module directly.
1. Processing in the communication Layer:
The IDOC_INBOUND_ASYCHRONOUS program, triggered as a result of an RFC from the sending system, acts as the entry point for all inbound ALE processes. The IDoc to be processed is passed as an input parameter. Control is transferred to the ALE/EDI layer.
2. Processing in the ALE/EDI Interface Layer:
u2022 Basic integrity check: A basic integrity check is performed on the control record.
u2022 Segment Filtering and conversion: Filtering out unwanted segments and carry out any required conversion of field values.
u2022 Creation of Application IDoc: The application IDoc is created and stored in the database and a syntax check is performed. If there are errors it gets status code of 60 (Error during Syntax check of IDoc u2013 Inbound). At this point a tangible IDoc, which can be monitored via one of the monitoring transactions, is created and the IDoc gets status code 50 (IDoc Added).
u2022 IDoc Marked ready for Dispatch: IDoc gets the status code 64 (IDoc ready to be passed to application).
u2022 IDoc is passed to the posting program: The partner profile table is read. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program immediately using the program RBDAPP01.
3. Processing in the Posting Module:
The process code in the partner profile points to a posting module for the specific message in the IDoc. The posting program implemented as a function module either calls a standard SAP transaction by using the Call Transaction command for posting the document or invokes a direct input function module.
The results of execution are passed back via the function moduleu2019s output parameters. If the posting is successful IDoc gets the status code 53 (Application Document Posted) or it gets status code 51 (Error: Application Document Not Posted).

Data records in an IDoc getting erased, when conversion rules are defined

Hello ,
We are sending IDocs of message type GLMAST & COELEM from a system(version 4.7) to another system (version 4.6B).
The segment data in the IDocs are changed using the user exit enhancement KKCD0001. The function exits used are EXIT_SAPFKCIM_001 and EXIT_SAPFKCIM_002.
If there is no conversion rule defined in the receiver system, for the segments, the IDocs are posted correctly in the receiving system. But if we define conversion rules , then the data records for all the segments for which conversion rule is defined are getting erased, and an error occurs during processing of IDocs
Please let me know what can be the the reason behind this issue..And how to solve this..
Thanks in advance,
Afsar

Issue solved

Create / change Conversion Rule 0BPARTNER

Similar Messages

Maybe you are looking for