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

Similar Messages

ALE : conversion rule for field value to become null

Dear experts,
I need to pass a material from one system to another with ALE. The problem is that the field marc-prctr (profit center) of this material is populated in the first system, but it does not exist in the second, so I assume transaction bd79 should be used to convert somehow the value of prctr to initial.
How can I do that??? I have already tried defining a conversion rule and assigning it to message type MATMAS, segment E1MARCM, but it did not work.
Please help.

Did you check this?<a href="http://help.sap.com/saphelp_erp2005/helpdata/en/d3/06f6679aaf0e44b67ca6d6b58d91df/content.htm">http://help.sap.com/saphelp_erp2005/helpdata/en/d3/06f6679aaf0e44b67ca6d6b58d91df/content.htm</a>

Query about ALE conversion rule

Hi,
   I am trying to copy an ALE conversion rule from one system to another.
   In the rule, for one of the variables, the option 'Set Variable' is selected and a variable '&PRTMVxxxx' (Name changed)
   is set under 'Rule Type'.
   I was not aware of how this variable gets filled or what additional setting is required.
   Could someone help me out with this option under the conversion rules?
Regards,
Sudeep

Hi Gaurav,
I have exactly the same problem that you had back in late 2006, with the Conversion Rules somehow not passing the data to the IDOC segment.
The IDOC segment is cleared of all values with the Conversion Rule active.
I have managed to determine that the exit is working properly, at least to the point where it is finished in EXIT_SAPFKCIM_001, and SENDER_SET_NEW is filled correctly.
Did you manage to figure out what was wrong?
Does anyone else know how to get this working?
Thanks,
Bruno

ALE conversion rules - Using a Mapping table

Hi, I need to use ALE conversion rules to modify Objects IDs using a custom mapping table. I´m looking BD79 transaction but I didn't find a place to use a mapping table..does anyone know how to do it?
Thanks!

FYI
http://help.sap.com/saphelp_erp2005/helpdata/en/80/411a73382b44d0a1667816716f5b37/content.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/f9/c3075cac7d11d39460005004580996/content.htm
Hope thisll give you idea!!
Pl... award the points.
Good luck
Thanks
Saquib Khan
"Some are wise and some are otherwise"

ALE conversion rules

Hi All,
We are downloading HR master data into CRM through ALE.
I have a requirement where in the telephone numbers for employees should not come into CRM from HR.
I am trying to do this with the help of conversion rules where I am specifying that the particular field in the segment be overwritten by a constant. However, I cannot have a blank value as a constant, hence am having to put some character like a '.'
Can anyone please let me know if there is an option by which any particular field can be just blanked out?
Regards,
-Sweta

Hi;
n the ALE implementation guide (IMG) choose:
Transaction SALE ® IDoc Interface/Application Link Enabling (ALE) ® Model and Implement Business Processes ® Set-Up Conversion between Sender and Recipient
Proceed as follows:
       1.      Create rule: The rules are defined per segment.
       2.      Maintain rule: Rule maintenance specifies conversion rules at field level.
       3.      Assign rule to a message type: The assignment specifies when the rule is to be applied. This is sender/recipient and message type specific.
Regards
Shashi

ALE Conversion rules not processed

Hi all,
I defined some conversion rules for an inbound IDoc with trascation BD79 in my backend system.
If I send an IDoc from XI to the backend system the rules are ignored:
Status 64
No filters , No conversion , No version change .
If I try the SAME Idoc with WE19 using the standard inbound, it works:
Status 64
No filters , Fields converted , No version change.
Any idea? I guess it's a bug.
Thank you.
Stefano

FYI
http://help.sap.com/saphelp_erp2005/helpdata/en/80/411a73382b44d0a1667816716f5b37/content.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/f9/c3075cac7d11d39460005004580996/content.htm
Hope thisll give you idea!!
Pl... award the points.
Good luck
Thanks
Saquib Khan
"Some are wise and some are otherwise"

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.

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

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

ALE IDoc Conversion Rule or BADI

Hi,
I'm new to ALE IDoc. I have a requirement to hide some sensitive data field for the HR information when outbound the Idoc.
Example, I need to outbound the IT8 Basic Pay with payscale area etc but not with the basic pay amount. I can convert the basic pay amount to zero when the idoc is being created.
I've searched through some information and found out that there are several ways to achieve it. However, I'm not sure which one is a better way.
Is it using the Conversion Rule (BD62) or using Badi or Idoc Reduction method is better?
Kindly give me some hints as I'm very confuse of which one is the better solution.
Many thanks in advance.

No user exit is needed for conversion rule.
However, you should remember that conversion rules are applied segment fields for a particular message type. So wherever the IDoc message type is used the rule will be applied. If you want to associate the rule for any other condition in addition to message type better to go with a BADI
These are steps to create and apply a conversion rule to a message type:
1. Transaction BD62 - Create conversion rule and assign it to a IDoc segment
2. Transaction BD79 - Define the conversion rule by selecting your field and clicking display button. Once inside you can use various options like set constant to map 0 to the basic pay
3. Finally assign the conversion rule to your message type using BD55
As for BADIs, IDOC_DATA_MAPPER is also suited for your requirement, the method PROCESS, allows you to manipulate your IDoc fields whichever way you want. You get the control record, data records, using which you can restrict your manipulation to specific message type or other conditions
To above post, BADI IDOC_CREATION_CHECK should not be used for mappings/conversions as its specific purpose is to stop creation of an IDoc under required conditions

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

About conversion rule using 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

Are the two GSS devices clustered ? Set one up as the Master GSSM and the other as the Standby GSSM adding the source-lists you've specified. Either of the GSS devices can reply to DNS queries and these will provide an answer depending on where the request was sourced from. It also depends on your DNS Heirarchy and where the request are coming from. Is there a DNS server sitting above your GSS devices ? How are the clients configured ? Do they point directly to you GSS devices or some other DNS device ?

What are the conversion rules

what are the conversion rules?can anybody give information on that?points wil be rewarded?

hI..
From sap help....
Conversion Rules for Elementary Data Types
There are ten predefined ABAP data types. There are 100 possible type combinations between these elementary data types. ABAP supports automatic type conversion and length adjustment for all of them except type D (date) and type T (time) fields which cannot be converted into each other.
The following conversion tables define the rules for converting elementary data types for all possible combinations of source and target fields.
C D F I N P STRING T X XSTRING
Source Type Character

Conversion table for source type C
Target
Conversion
C
The target field is filled from left to right. If it is too long, it is filled with blanks from the right. If it is too short, the contents are truncated from the right.
D
The character field must contain an 8-character date in the format YYYYMMDD .
F
The contents of the source field must be a valid representation of a type F field as described in Literals.
N
Only the digits in the source field are copied. The field is right-justified and filled with trailing zeros.
I, P
The source field must contain the representation of a decimal number, that is, a sequence of digits with an optional sign and no more than one decimal point. The source field can contain blanks. If the target field is too short, an overflow may occur. This may cause the system to terminate the program.
STRING
The occupied length of the source field is copied. All trailing spaces are truncated.
T
The character field must contain a six-character time in HHMMSS format.
X
Since the character field must contain a hexadecimal string, the only valid characters are 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. This string is packed as a hexadecimal number, transported left-justified, and filled with zeros or truncated on the right.
XSTRING
As for fields of type X, except that the target field is not filled with zeros.
Source Type Date
Conversion table for source type D
Target
Conversion
C
The date is transported left-justified without conversion.
D
Transport without conversion.
F
The date is converted into a packed number. The packed number is then converted into a floating point number (see corresponding table).
N
The date is transported left-justified without conversion and, if necessary, filled with zeros on the right.
I, P
The date is converted to the number of days since 01.01.0001.
STRING
The date is converted to a character field, which is then converted to a character string.
T
Not supported. Results in an error message during the syntax check or in a runtime error.
X
The date is converted to the number of days since 01.01.0001 in hexadecimal format.
XSTRING
As for fields of type X, except that only significant bytes are copied.
Source Type Floating Point Number
Conversion table for source type F
Target
Conversion
C
The floating point number is converted to the <mantissa>E<exponent> format and transported to the character field. The value of the mantissa lies between 1 and 10 unless the number is zero. The exponent is always signed. If the target field is too short, the mantissa is rounded. The length of the character field must be at least 6 bytes.
D
The source field is converted into a packed number. The packed number is then converted into a date field (see corresponding table).
F
Transport without conversion.
N
The source field is converted into a packed number. The packed number is then converted into a numeric text field (see corresponding table).
I, P
The floating point number is converted to an integer or fixed point value and, if necessary, rounded.
STRING
As for fields of type C, except that the maximum number of places is used for the mantissa (maximum precision). Despite this, different signs or exponents can lead to different string lengths.
T
The source field is converted into a packed number. The packed number is then converted into a time field (see corresponding table).
X
The source field is converted into a packed number. The packed number is then converted into a hexadecimal number (see corresponding table).
XSTRING
As for fields of type X, except that leading zeros are not copied.
Source Type Integer
Type I is always treated in the same way as type P without decimal places. Wherever type P is mentioned, the same applies to type I fields.
Source Type Numeric Text
Conversion table for source type N
Target
Conversion
C
The numeric field is treated like a character field. Leading zeros are retained.
D
The numeric field is converted into a character field. The character field is then converted into a date field (see corresponding table).
F
The numeric field is converted into a packed number. The packed number is then converted into a floating point number (see corresponding table).
N
The numeric field is transported right-justified and filled with zeros or truncated on the left.
I, P
The numeric field is interpreted as a number, and transferred to the target field, where it is right-justified, and adopts a plus sign. If the target field is too short, the program may be terminated.
STRING
As for fields of type C. The length of the character string matches the length of the numeric text.
T
The numeric field is converted into a character field. The character field is then converted into a time field (see corresponding table).
X
The numeric field is converted into a packed number. The packed number is then converted into a hexadecimal number (see corresponding table).
XSTRING
As for fields of type X, except that leading zeros are not copied.
Source Type Packed Number
If the program attribute Fixed point arithmetic is set, the system rounds type P fields according to the number of decimal places or fills them out with zeros.
Conversion table for source type P
Target
Conversion

C
The packed field is transported right-justified to the character field, if required with a decimal point. The last position is reserved for the sign. Leading zeros appear as blanks. If the target field is too short, the sign is omitted for positive numbers. If this is still not sufficient, the field is truncated on the left. ABAP indicates the truncation with an asterisk (*). If you want the leading zeros to appear in the character field, use UNPACK instead of MOVE.
D
The packed field value represents the number of days since 01.01.0001 and is converted to a date in YYYYMMDD format.
F
The packed field is accepted and transported as a floating point number.
N
The packed field is rounded if necessary, unpacked, and then transported right-justified. The sign is omitted. If required, the target field is filled with zeros on the left.
I, P
A packed field is converted to type I. The resulting four bytes are placed into the target field right-justified. If the target field is too short, an overflow occurs. If the target field is longer, it is filled with zeros on the left.
STRING
As for fields of type C, except that leading zeros are not generated.
T
The packed field value represents the number of seconds since midnight and is converted to a time in HHMMSS format.
X
A packed field is converted to type I. The resulting four bytes are placed into the target field right-justified and in big-endian format. If the target field is too short, it is truncated from the left. If the target field is longer than 4, it is filled with zeros on the left. Negative numbers are represented by the two's complement (= bit complement +1).
XSTRING
As for fields of type X, except that leading zeros are not generated.
Source Type String
Conversion table for source type STRING
Target
Conversion
C
The target field is filled from left to right. If it is longer than the string, it is filled with trailing spaces. If it is too short, the contents are truncated from the right.
D
The string must contain an 8-character date in the format YYYYMMDD .
F
The contents of the string must be a valid representation of a type F field as described in Literals.
N
Only digits in the string are copied. The field is right-justified and filled with trailing zeros. If the target field is too short, it is truncated from the left.
I, P
The string must contain the representation of a decimal number, that is, a sequence of digits with an optional sign and no more than one decimal point. The source field can contain blanks. If the target field is too short, an overflow may occur. This may cause the system to terminate the program.
STRING
The source string is copied to the target string unconverted.
T
The string must contain a six-character time in HHMMSS format.
X
Since the character field must contain a hexadecimal-character string, the only valid characters are 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. This character string is packed as a hexadecimal number, transported left-justified, and filled with zeros or truncated on the right.
XSTRING
As for target fields of type X, except that the field is not filled with zeros.

Source Type Time
Conversion table for source type T
Target
Conversion
C
The source field is transported left-justified without conversion.
D
Not supported. Results in an error message during the syntax check or in a runtime error.
F
The source field is converted into a packed number. The packed number is then converted into a floating point number (see corresponding table).
N
The date is converted into a character field. The character field is then converted into a numeric text field (see corresponding table).
I, P
The date is converted to the number of seconds since midnight.
STRING
The time is converted to a character field, which is then converted to a character string.
T
The date is transported left-justified without conversion and, if necessary, filled with zeros on the right.
X
The date is converted to the number of seconds since midnight in hexadecimal format.
XSTRING
As for fields of type X, except that only significant bytes are copied.
Source Type Hexadecimal Field
Conversion table for source type X
Target
Conversion
C
The value in the hexadecimal field is converted to a hexadecimal character string, transported left-justified to the target field, and filled with zeros.
D
The source field value represents the number of days since 01.01.0001 and is converted to a date in YYYYMMDD format.
F
The source field is converted into a packed number. The packed number is then converted into a floating point number (see corresponding table).
N
The source field is converted into a packed number. The packed number is then converted into a numeric text field (see corresponding table).
I, P
The value of the source field is interpreted as a hexadecimal number. It is converted to a packed decimal number and transported right-justified to the target field. If the hexadecimal field is longer than 4 bytes, only the last four bytes are converted. If it is too short, a runtime error may occur.
STRING
As for target fields of type C, except that the field is not filled with zeros. The length of the string is twice the length of the hexadecimal field.
T
The source field value represents the number of seconds since midnight and is converted to a time in HHMMSS format.
X
The value is transported left-justified and filled with X'00' on the right, if necessary.
XSTRING
The hexadecimal field is copied completely that is, trailing zeros are not truncated.
Source Type Byte Sequence
Conversion table for source type XSTRING
Target
Conversion
C
The value in the byte sequence is converted to a hexadecimal character string, transported left-justified to the target field, and filled with zeros.
D
The byte sequence value represents the number of days since 01.01.0001 and is converted to a date in YYYYMMDD format.
F
The content of the byte sequence is converted into a packed number. The packed number is then converted into a floating point number (see corresponding table).
N
The content of the byte sequence is converted into a packed number. The packed number is then converted into a numeric text field (see corresponding table).
I, P
The content of the byte sequence is interpreted as a hexadecimal number. It is converted to a packed decimal number and transported right-justified to the target field. If the byte sequence is longer than 4 bytes, only the last four bytes are converted. If it is too short, a runtime error may occur.
STRING
As for target fields of type C, except that the field is not filled with zeros. The length of the string is twice the length of the byte sequence.
T
The byte sequence value represents the number of seconds since midnight and is converted to a time in HHMMSS format.
X
The byte sequence is transported left-justified and filled with X'00' on the right, if necessary.
XSTRING
The source byte sequence is copied to the target byte sequence unconverted.
Conversion Rules for Internal Tables
Internal tables can only be converted into other internal tables. You cannot convert them into structures or elementary fields.
Internal tables are convertible if their line types are convertible. The convertibility of internal tables does not depend on the number of lines.
Conversion rules for internal tables:
Internal tables which have internal tables as their line type are convertible if the internal tables which define the line types are convertible.
Internal tables which have line types that are structures with internal tables as components are convertible according to the conversion rules for structures if the structures are compatible.
Conversion Rules for Structures
ABAP has one rule for converting structures that do not contain internal tables as components. There are no conversion rules for structures that contain internal tables. You can only make assignments between structures that are compatible.
You can combine convertible structures in the following combinations:
Converting a structure into a non-compatible structure
Converting elementary fields into structures
Converting structures into elementary fields
In each case, the system first converts all the structures concerned to type C fields and then performs the conversion between the two resulting elementary fields. The length of the type C fields is the sum of the lengths of the structure components. This rule applies to all operations using structures that do not contain internal tables.
If a structure is aligned, the filler fields are also added to the length of the type C field.
A non-aligned structure without filler fields:
If you convert a structure into a shorter structure, the original structure is truncated. If you convert a structure into a longer one, the parts at the end are not initialized according to their type, but filled with blanks.
It can make sense to assign a structure to another, incompatible, structure if, for example, the target structure is shorter than the source, and both structures have the same construction over the length of the shorter structure. However, numeric components of structures that are filled in incompatible assignments may contain nonsensical or invalid values that may cause runtime errors.
DATA: BEGIN OF FS1,
INT TYPE I VALUE 5,
PACK TYPE P DECIMALS 2 VALUE 2.26,
TEXT(10) TYPE C VALUE Fine text,
FLOAT TYPE F VALUE 1.234e+05,
DATA TYPE D VALUE 19950916,
END OF FS1.
DATA: BEGIN OF FS2,
INT TYPE I VALUE 3,
PACK TYPE P DECIMALS 2 VALUE 72.34,
TEXT(5) TYPE C VALUE Hello,
END OF FS2.
WRITE: / FS1-INT, FS1-PACK; FS1-TEXT, FS1-FLOAT, FS1-DATE.
WRITE: / FS2-INT, FS2-PACK, FS2-TEXT.
MOVE FS1 TO FS2.
WRITE: / FS2-INT, FS2-PACK, FS2-TEXT.
Message was edited by:
Rammohan Nagam

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

CONVERSION RULE

hi,
plz suggest me anything(their types,significance etc.) about CONVERSION RULES in ABAP

Conversion Rules for Internal Tables
Internal tables can only be converted into other internal tables. You cannot convert them into structures or elementary fields.
Internal tables are convertible if their line types are convertible. The convertibility of internal tables does not depend on the number of lines.
Conversion rules for internal tables:
Internal tables which have internal tables as their line type are convertible if the internal tables which define the line types are convertible.
Internal tables which have line types that are structures with internal tables as components are convertible according to the conversion rules for structures if the structures are compatible.
Also check these links..
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb34d0358411d1829f0000e829fbfe/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/59/ae3cfe488f11d189490000e829fbbd/frameset.htm

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

Similar Messages

Maybe you are looking for