Different values within "conversion rule" possible?

Hi,
in context of the HR-CRM-integration we are using a conversion rule for converting the private address (IT 0006) to a constant value by using trx bd62 -> bd79 -> bd55. This conversion rule works quite fine, but the disadvantage is that we can only define one address for all.
Is there a way using conversion rules for converting to several addresses? E.g. we have some employees in the USA, and others in Germany. Depending on the country maintained in the IT0006 we would like to convert the addresse for the colleagues in the USA to address1, for german employees to address2. At last we need something like a condition-express: "if... then". Is there anything possible achiving it, please?
Thank you
Maik

Found it by my own. In the transaction bd79 is it possible to use different rule types. With using "Convert/copy" we could define different search criteria for "sender fields". By setting some conditions we could filter, and set then the "Value receiver field" with proper fields.

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>

HT1918 is it possible to have two different password within one iTunes account? one to log in with and a different one to use when making a purchase?

Is is possible to have two different passwords within itunes? one to log in with and a different one to make purchases with?

The system is not setup to provide that kind of sservice. If making certain purchases it does ask for an answer to one of your security questions, so that provides a little more security for some purchases, just not all.

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

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

Dbms_lob.getlength() returns different values

Hi !
I am not a developer.. So, possibly cannot answer developer specific question.
We have two instances running on 10.2.0.4 but both giving different value for
declare
 xml varchar2(32676) :=
'SELECT XT_STRATEGY, ACCT_DESCRIPTION,sum(MON_PL) PL_MON ,sum(TUE_PL) PL_TUE,sum(WED_PL) PL_WED ,sum(THU_PL) PL_THU, sum(FRI_PL) PL_FRI, sum(WTD_PL) PL_WTDPL,sum(WTD_PREMIUM_PL) PL_WTDPRMPL, sum(MTD_PL) PL_MARKPL,sum(MTD_PREMIUM_PL) PL_MTDPRMPL,sum(YTD_PL) PL_YTDPL,sum(YTD_PREMIUM_PL) PL_YTDPRMPL,
 DLC_REGION,DLC_ENTITY FROM (SELECT xt_strategy, acct_description ,case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else MON_PL end as MON_PL, case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else tue_pl end as tue_pl,
case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else WED_PL end as WED_PL, case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else THU_PL end as THU_PL,
case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else FRI_PL end as FRI_PL, case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else WTD_PL end as WTD_PL,
case when blankout_date < to_char( to_date( fv[EOD] )+ (1 -to_char(to_date(to_date( fv[EOD] )),''D''))) then 0 else WTD_PREMIUM_PL end as WTD_PREMIUM_PL,
case when blankout_date < (select actual_date from tbl_date where date_type = ''PLMonthStart'' and to_char(actual_date, ''MMYYYY'') = to_char(to_date( fv[EOD] ),''MMYYYY'')) then 0 else mtd_pl end as mtd_pl,
case when blankout_date < (select actual_date from tbl_date where date_type = ''PLMonthStart'' and to_char(actual_date, ''MMYYYY'') = to_char(to_date( fv[EOD] ),''MMYYYY'')) then 0 else MTD_PREMIUM_PL end as MTD_PREMIUM_PL,
case when blankout_date < (select to_date(''01-JAN-''|| to_char(to_date((fv[EOD]),''DD-MON-YYYY''),''YYYY''),''DD-MON-YYYY'') from tbl_business_date) then 0 else ytd_PL end as ytd_PL,
case when blankout_date < (select to_date(''01-JAN-''|| to_char(to_date((fv[EOD]),''DD-MON-YYYY''),''YYYY''),''DD-MON-YYYY'') from tbl_business_date) then 0 else ytd_premium_PL end as ytd_premium_PL,
IN_STRIKECURR, IN_QUOTEDCUR, case dlc_region when ''LON'' then ''LN'' when ''NYC'' then ''NY'' when ''TOK'' then ''TK'' else dlc_region
end as DLC_REGION, DLC_ENTITY,DTL_REFERENCE,TRADE_STATE,blankout_date
FROM (select a.bo_book_id as xt_strategy, a.bo_book_id as acct_description , b.mon_pl, b.tue_pl, b.wed_pl,b.thu_pl,b.fri_pl,b.wtd_pl, b.wtd_premium_pl , b.mtd_pl , b.mtd_premium_pl, b.ytd_pl, b.ytd_premium_pl,
 a.BASE_CCY as IN_STRIKECURR, A.QUOTED_CCY AS IN_QUOTEDCUR, a.region_code as dlc_region, a.entity_acronym as dlc_entity, TP.EBI_TRADE_ID AS DTL_REFERENCE, a.trade_state,
 case when a.trade_state in (7,8,13) then a.amendment_date when a.maturity_date > nvl(a.premium_settlement_date, to_date(''01-JAN-1900'')) then
 Case when a.trade_state in (4,5 ) then trunc(a.updated_date) else a.maturity_date end else a.premium_settlement_date end as blankout_date FROM TBL_TRADE_HIST A
 join vw_feed_downstream_trade_id tp on a.trade_id = tp.trade_id and tp.mapping_source_name = ''ramfx''
 join tbl_pl b on a.trade_id = b.trade_id and a.version = b.trade_version and b.pl_date = (select max(pl_date) from tbl_pl d where a.trade_id = d.trade_id and pl_date <= fv[EOD] )
 join tbl_bo_book bk on a.bo_book_id = bk.bo_book_id and bk.business_Area = ''OPTIONS''
 where b.pl_date < fv[EOD]
 AND NOT EXISTS (SELECT 1 FROM TBL_EOD_TRADES D WHERE A.TRADE_ID = D.TRADE_ID AND D.BUSINESS_DATE = fv[EOD] )
UNION
 SELECT A.XT_STRATEGY, A.ACCT_DESCRIPTION, C.MON_PL,C.TUE_PL, C.WED_PL,C.THU_PL, C.FRI_PL,C.WTD_PL,C.WTD_PREMIUM_PL,C.MTD_PL,C.MTD_PREMIUM_PL,C.YTD_PL,C.YTD_PREMIUM_PL,
 A.IN_STRIKECURR, A.IN_QUOTEDCUR, A.DLC_REGION,A.DLC_ENTITY, A.DTL_REFERENCE , a.trade_state , case when a.trade_state in (7,8,13) then a.DLC_BUSDATEUPD when a.IN_EXPIRATION > nvl(a.XT_SETTLEDATE, to_date(''01-JAN-1900'')) then a.IN_EXPIRATION else a.XT_SETTLEDATE end as blankout_date
 FROM VW_EBI_FEED A , TBL_EOD_TRADES B , TBL_PL C
 WHERE A.TRADE_ID = B.TRADE_ID AND A.VERSION = B.TRADE_VERSION AND A.TRADE_ID = C.TRADE_ID
 AND A.ACCT_RISKFEED = ''D'' AND A.DLC_DEALSTATE in (''LIVE'',''PENDING'',''CANCELLED'',''REVERSED'') AND A.VERSION = C.TRADE_VERSION
 AND B.BUSINESS_DATE = to_date( fv[EOD] ,''DD-MON-YYYY'') AND C.PL_DATE = to_date( fv[EOD] ,''DD-MON-YYYY'')
UNION
 SELECT A.BO_BOOK_ID AS XT_STRATEGY , A.BO_BOOK_ID AS ACCT_DESCRIPTION, a.MON_PL , a.TUE_PL , a.WED_PL, a.THU_PL , a.FRI_PL, a.WTD_PL ,a.WTD_PREMIUM_PL , a.mtd_pl, a.MTD_PREMIUM_PL,a.ytd_PL , a.ytd_premium_PL,A.BASE_CCY AS IN_STRIKECURR,A.QUOTED_CCY AS IN_QUOTEDCUR,
 A.REGION_CODE as dlc_region ,A.ENTITY_ACRONYM AS DLC_ENTITY, A.MAPPING_SOURCE_ID AS DTL_REFERENCE, 12 as trade_state , a.PL_DATE as blankout_date
 FROM TBL_PL_ARCH A , tbl_bo_book b where a.bo_book_id = b.bo_book_id and b.business_area = ''OPTIONS''
union
select d.bo_book_id as xt_strategy, d.bo_book_id as acct_description, case when to_char(b.pl_date,''D'') = 6 then (b.inception_pl + b.inception_premium_pl ) else (b.mon_pl * -1) end as mon_pl ,
 case when to_char(b.pl_date,''D'') = 2 then (b.inception_pl + b.inception_premium_pl ) when to_char(b.pl_date,''D'') > 2 then (b.tue_PL * -1) else 0 end as tue_pl, case when to_char(b.pl_date,''D'') = 3 then (b.inception_pl + b.inception_premium_pl ) when to_char(b.pl_date,''D'') > 3 then (b.wed_pl * -1) else 0 end as wed_pl ,
 case when to_char(b.pl_date,''D'') = 4 then (b.inception_pl + b.inception_premium_pl) when to_char(b.pl_date,''D'') > 4 then (b.thu_pl * -1) else 0 end as thu_pl ,case when to_char(b.pl_date,''D'') = 5 then (b.inception_pl + b.inception_premium_pl) when to_char(b.pl_date,''D'') > 5 then (b.fri_pl * -1) else 0 end as fri_pl ,
 (b.mon_pl + b.tue_pl + b.wed_pl + b.thu_pl + b.fri_pl) * -1 + (b.inception_pl + b.inception_premium_pl) as wtd_pl, case when b.wtd_premium_pl <> 0 then b.wtd_premium_pl *-1 + (b.inception_premium_pl) else b.wtd_premium_pl end as wtd_premium_pl , case when b.mtd_pl <> 0 then b.mtd_pl * -1 + (b.inception_pl) else b.mtd_pl end as mtd_pl ,
 case when b.mtd_premium_pl <> 0 then b.mtd_premium_pl * -1 + (b.inception_premium_pl ) else b.mtd_premium_pl end as mtd_premium_pl, case when b.ytd_pl <> 0 then b.ytd_pl * -1 + (b.inception_pl) else b.ytd_pl end as ytd_pl,
 case when b.ytd_premium_pl <> 0 then b.ytd_premium_pl * -1 + (b.inception_premium_pl) else b.ytd_premium_pl end as ytd_premium_pl ,
 c.base_ccy as IN_STRIKECURR,c.quoted_ccy as IN_QUOTEDCUR,c.region_code as dlc_region,c.entity_acronym as dlc_entity, to_char(c.trade_id) as dtl_reference,
 8 as trade_state, case when to_char(b.pl_date,''D'') = 6 then b.pl_date + 2 else b.pl_date end as blankout_date
from tbl_trade_hist a
join tbl_pl b on a.trade_id = b.trade_id and a.version = b.trade_version
join tbl_trade_hist c on a.tradE_id = c.trade_id
join tbl_pl d on c.trade_id = d.trade_id and c.version = d.trade_version and d.pl_date = (select max(e.pl_date) from tbl_pl e where c.trade_id = e.trade_id and e.pl_date <= c.amendment_date)
join tbl_bo_book f on a.bo_book_id = f.bo_book_id and f.business_area = ''OPTIONS''
where (b.bo_book_id <> d.bo_book_id or a.region_code <> c.region_code or a.entity_acronym <> c.entity_acronym or a.base_ccy <> c.base_ccy or a.quoted_ccy <> c.quoted_ccy)
and d.pl_date - b.pl_date = case when to_char(d.pl_date,''DAY'') = ''MON'' then 3 else 1 end
and d.pl_date <= to_date( fv[EOD] ,''DD-MON-YYYY'')
union all
select b.bo_book_id as xt_strategy, b.bo_book_id as acct_description,case when to_char(b.pl_date,''D'') = 6 then (b.inception_pl * -1 + b.inception_premium_pl * -1) else (b.mon_pl ) end as mon_pl ,
 case when to_char(b.pl_date,''D'') = 2 then (b.inception_pl * -1 + b.inception_premium_pl * -1) when to_char(b.pl_date,''D'') > 2 then (b.tue_PL) else 0 end as tue_pl, case when to_char(b.pl_date,''D'') = 3 then (b.inception_pl * -1 + b.inception_premium_pl * -1 ) when to_char(b.pl_date,''D'') > 3 then (b.wed_pl) else 0 end as wed_pl ,
 case when to_char(b.pl_date,''D'') = 4 then (b.inception_pl * -1 + b.inception_premium_pl * -1 ) when to_char(b.pl_date,''D'') > 4 then (b.thu_pl ) else 0 end as thu_pl , case when to_char(b.pl_date,''D'') = 5 then (b.inception_pl *-1 + b.inception_premium_pl * -1) when to_char(b.pl_date,''D'') > 5 then (b.fri_pl) else 0 end as fri_pl ,
 (b.mon_pl + b.tue_pl + b.wed_pl + b.thu_pl + b.fri_pl) + (b.inception_pl* -1 + b.inception_premium_pl * -1) as wtd_pl, case when b.wtd_premium_pl <> 0 then b.wtd_premium_pl + (b.inception_premium_pl * -1) else b.wtd_premium_pl end as wtd_premium_pl , case when b.mtd_pl <> 0 then b.mtd_pl + (b.inception_pl * -1) else b.mtd_pl end as mtd_pl ,
 case when b.mtd_premium_pl <> 0 then b.mtd_premium_pl + (b.inception_premium_pl * -1) else b.mtd_premium_pl end as mtd_premium_pl, case when b.ytd_pl <> 0 then b.ytd_pl + (b.inception_pl * -1) else b.ytd_pl end as ytd_pl,
 case when b.ytd_premium_pl <> 0 then b.ytd_premium_pl + (b.inception_premium_pl * -1) else b.ytd_premium_pl end as ytd_premium_pl ,
 a.base_ccy as IN_STRIKECURR, a.quoted_ccy as IN_QUOTEDCUR, a.region_code as dlc_region,a.entity_acronym as dlc_entity, to_char(a.trade_id) as dtl_reference, 8 as trade_state,
 case when to_char(b.pl_date,''D'') = 6 then b.pl_date + 2 else b.pl_date end as blankout_date
from tbl_trade_hist a
join tbl_pl b on a.trade_id = b.trade_id and a.version = b.trade_version
join tbl_trade_hist c on a.tradE_id = c.trade_id join tbl_pl d on c.trade_id = d.trade_id and c.version = d.trade_version and d.pl_date = (select max(e.pl_date) from tbl_pl e where c.trade_id = e.trade_id and e.pl_date <= c.amendment_date)
join tbl_bo_book f on a.bo_book_id = f.bo_book_id and f.business_area = ''OPTIONS''
where (b.bo_book_id <> d.bo_book_id or a.region_code <> c.region_code or a.entity_acronym <> c.entity_acronym or a.base_ccy <> c.base_ccy or a.quoted_ccy <> c.quoted_ccy)
and d.pl_date - b.pl_date = case when to_char(d.pl_date,''DAY'') = ''MON'' then 3 else 1 end and d.pl_date <= to_date( fv[EOD] ,''DD-MON-YYYY'') ))
group by xt_strategy,ACCT_DESCRIPTION,DLC_REGION,DLC_ENTITY';
c clob;
s varchar2(25000);
i numeric := 424;
begin
 c := xml;
 dbms_output.put_line('length of clob: ' || dbms_lob.getlength(c));
 dbms_output.put_line('split clob at: ' || i);
 dbms_output.put_line('desired substring length: ' || to_char(dbms_lob.getlength(c) - i));
 s := dbms_lob.substr(c, dbms_lob.getlength(c) - i, i + 1);
 dbms_output.put_line('length of substring: ' || length(s));
end;I checked for the database characterset and they are same - AL32UTF8
The result we get is
Output from MD1 database
length of clob: 10616
split clob at: 424
desired substring length: 10192
length of substring: 10192
Output from MD2 database
length of clob: 10616
split clob at: 424
desired substring length: 10192
length of substring: 8191Any idea why there is this discrepancy ?
Edited by: USER101 on Feb 19, 2010 4:24 PM

The EOF and the LF versus CR/LF could influence the count difference, yes.
Another explain could possibly be character set conversions. The BFILE I believe counts bytes, a CLOB would count "characters" - so if the source happens to contain a few multibyte characters (UTF), then the byte count would be larger than the character count.
To help you find the cause for your exact file, then I can suggest a couple of things you might do to explore the issue:
<li>Load the file into a BLOB instead of a CLOB and see what getlength() returns for the BLOB. BLOBs would also do byte counts and not try to treat the source as text.
<li>Save the CLOB back into the filesystem and compare the original file with the exported CLOB and check the differences with some filecompare tool.

Error in global conversion rule for InfoObject 0INCOTERMS2

When I activate BI content 2LIS_12_VCITM with transfer rule, The transfer rule was error with the message " Error in global conversion rule for InfoObject 0INCOTERMS2" and Mgs No. 263.
The transfer rule cannot be activated.
I checked the 0INCOTERMS2 infoObject . The global conversion rule is no error.
The global conversion is in below.
============================================================
PROGRAM CONVERSION_ROUTINE.
Type pools used by conversion program
TYPE-POOLS: RSD, RSARC, RSARR.
TYPES: DE_0INCOTERMS2(000028) TYPE C.
Conversion rule for InfoObject 0INCOTERMS2
    Data type       = CHAR
    ABAP type       = C
    ABAP length     = 000028
FORM CONVERT_0INCOTERMS2
USING    RECORD_NO LIKE SY-TABIX
           SOURCE_SYSTEM TYPE RSA_LOGSYS
           IOBJ_NAME TYPE RSIOBJNM
CHANGING RESULT TYPE DE_0INCOTERMS2 " InfoObject value
           RETURNCODE LIKE SY-SUBRC.
$$ begin of routine - insert your code only below this line        -
TRANSLATE RESULT TO UPPER CASE.
$$ end of routine - insert your code only before this line         -
ENDFORM.
=================================================================
If you have any idea or face the similar problem, please suggest solution.
Thank you.

Good afternoon,
If you have not done so already can you apply the SAP note 1387854 in your system and it should prevent the problem from happening again. If you also reactivate the infoobject 0INCOTERMS2 in RSD1 then it should be possible to manually activate the transfer rule.
Best Regards,
Des

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

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 ?

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.

Trying to get multiple cell values within a geometry

I am provided with 3 tables:
1 - The GeoRaster
2 - The geoRasterData table
3 - A VAT table who's PK is the cell value from the above tables
Currently the user can select a point in our application and by using the getCellValue we get the cell value which is the PK on the 3rd table and this gives us the details to return to the user.
We now want to give the worst scenario within a given geometry or distance. So if I get back all the cell values within a given geometry/distance I can then call my other functions against the 3rd table to get the worst scores.
I had a conversation open for this before where JeffreyXie had some brilliant input, but it got archived while I was waiting on Oracle to resolve a bug (about 7 months)
See:
Trying to get multiple cell values within a geometry
If I am looking to get a list of cell values that interact with my geometry/distance and then loop through them, is there a better way?
BTW, if anybody wants to play with this functionality, it only seems to work in 11.2.0.4.
Below is the code I was using last, I think it is trying to get the cell values but the numbers coming back are not correct, I think I am converting the binary to integer wrong.
Any ideas?
CREATE OR REPLACE FUNCTION GEOSUK.getCellValuesInGeom_FNC RETURN VARCHAR2 AS
gr sdo_georaster;
lb blob;
win1 sdo_geometry;
win2 sdo_number_array;
status VARCHAR2(1000) := NULL;
CDP varchar2(80);
FLT number := 0;
cdl number;
vals varchar2(32000) := null;
VAL number;
amt0 integer;
amt integer;
off integer;
len integer;
buf raw(32767);
MAXV number := null;
r1 raw(1);
r2 raw(2);
r4 raw(200);
r8 raw(8);
MATCH varchar2(10) := '';
ROW_COUNT integer := 0;
COL_COUNT integer := 0;
ROW_CUR integer := 0;
COL_CUR integer := 0;
CUR_XOFFSET integer := 0;
CUR_YOFFSET integer := 0;
ORIGINY integer := 0;
ORIGINX integer := 0;
XOFF number(38,0) := 0;
YOFF number(38,0) := 0;
BEGIN
status := '1';
SELECT a.georaster INTO gr FROM JBA_MEGARASTER_1012 a WHERE id=1;
-- first figure out the celldepth from the metadata
cdp := gr.metadata.extract('/georasterMetadata/rasterInfo/cellDepth/text()',
'xmlns=http://xmlns.oracle.com/spatial/georaster').getStringVal();
if cdp = '32BIT_REAL' then
flt := 1;
end if;
cdl := sdo_geor.getCellDepth(gr);
if cdl < 8 then
-- if celldepth<8bit, get the cell values as 8bit integers
cdl := 8;
end if;
dbms_lob.createTemporary(lb, TRUE);
status := '2';
-- querying/clipping polygon
win1 := SDO_GEOM.SDO_BUFFER(SDO_GEOMETRY(2001,27700,MDSYS.SDO_POINT_TYPE(473517,173650.3, NULL),NULL,NULL), 10, .005);
status := '1.2';
sdo_geor.getRasterSubset(gr, 0, win1, '1',
lb, win2, NULL, NULL, 'TRUE');
-- Then work on the resulting subset stored in lb.
status := '2.3';
DBMS_OUTPUT.PUT_LINE ( 'cdl: '||cdl );
len := dbms_lob.getlength(lb);
cdl := cdl / 8;
-- make sure to read all the bytes of a cell value at one run
amt := floor(32767 / cdl) * cdl;
amt0 := amt;
status := '3';
ROW_COUNT := (WIN2(3) - WIN2(1))+1;
COL_COUNT := (WIN2(4) - WIN2(2))+1;
--NEED TO FETCH FROM RASTER
ORIGINY := 979405;
ORIGINX := 91685;
--CALCUALATE BLOB AREA
YOFF := ORIGINY - (WIN2(1) * 5); --177005;
XOFF := ORIGINX + (WIN2(2) * 5); --530505;
status := '4';
--LOOP CELLS
off := 1;
WHILE off <= LEN LOOP
dbms_lob.read(lb, amt, off, buf);
for I in 1..AMT/CDL LOOP
if cdl = 1 then
r1 := utl_raw.substr(buf, (i-1)*cdl+1, cdl);
VAL := UTL_RAW.CAST_TO_BINARY_INTEGER(R1);
elsif cdl = 2 then
r2 := utl_raw.substr(buf, (i-1)*cdl+1, cdl);
val := utl_raw.cast_to_binary_integer(r2);
ELSIF CDL = 4 then
IF (((i-1)*cdl+1) + cdl) > len THEN
r4 := utl_raw.substr(buf, (i-1)*cdl+1, (len - ((i-1)*cdl+1)));
ELSE
r4 := utl_raw.substr(buf, (i-1)*cdl+1, cdl+1);
END IF;
if flt = 0 then
val := utl_raw.cast_to_binary_integer(r4);
else
val := utl_raw.cast_to_binary_float(r4);
end if;
elsif cdl = 8 then
r8 := utl_raw.substr(buf, (i-1)*cdl+1, cdl);
val := utl_raw.cast_to_binary_double(r8);
end if;
if MAXV is null or MAXV < VAL then
MAXV := VAL;
end if;
IF i = 1 THEN
VALS := VALS || VAL;
ELSE
VALS := VALS ||'|'|| VAL;
END IF;
end loop;
off := off+amt;
amt := amt0;
end loop;
dbms_lob.freeTemporary(lb);
status := '5';
RETURN VALS;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001, 'GENERAL ERROR IN MY PROC, Status: '||status||', SQL ERROR: '||SQLERRM);
END;

Hey guys,
Zzhang,
That's a good spot and as it happens I spotted that and that is why I am sure I am querying that lob wrong. I always get the a logic going past the total length of the lob.
I think I am ok using 11.2.0.4, if I can get this working it is really important to us, so saying to roll up to 11.2.0.4 for this would be no problem.
The error in 11.2.0.3 was an internal error: [kghstack_underflow_internal_3].
Something that I think I need to find out more about, but am struggling to get more information on is, I am assuming that the lob that is returned is all cell values or at lest an array of 4 byte (32 bit) chunks, although, I don't know this.
Is that a correct assumption or is there more to it?
Have either of you seen any documentation on how to query this lob?
Thanks

Make field read only untill value within pciklist is choosen

Hello,
I am trying to establish if it is possible to make a field read-only until a value within a pick list is chosen. Basically we have a pick list called structure and if the field value called "Aligned" is selected then I want the text field called Aligned Name to be available for import all other times this field should not be available.
Has anyone done anything similar? I'm guessing that this could only be achieved through WF but I haven't been able to find any code to make fields read only.

For those of you unable to download the document from MetaLink3 here it is:
As an example to illustrate this requirement, let’s say that once there is a checkbox field called "My_Check_Box". When this field is checked, the "Account Type" field need to become a required for entry by the user. To do this follow these steps:
1. In the Admin> Application Customization, select the appropriate Object and go into the Object Field Setup.
2. Edit the field called "My_Check_Box" and enter a Field Validation expression so it uses the following expression:
=[<bMy_Check_Box_ITAG>] AND NOT([<AccountType>] IS NULL AND [<bMy_Check_Box_ITAG >]='Y')
3. Enter an explicit error message.
This expression means that when the checkbox field is checked, the Account Type becomes required. Your custom error message will be raised when checking the checkbox, leaving the account type unpopulated and trying to save the account record.
4. Edit the Account Type field and enter the following expression as Field Validation:
=[<AccountType>] AND NOT([<AccountType>] IS NULL AND [<bMy_Check_Box_ITAG >]='Y')
5. Enter an explicit error message.
That validation handles the user case where a user changes the Account Type value from a NOT NULL value to a NULL value. Your custom error message will be raised when emptying out the account type from a populated value to nothing while the checkbox is checked and trying to save the account record.
Note that the expression in both fields validations begins with the field variable on which the statement is being written.**

The priority of different data type conversion

Hi All,
I want to know the priority of data type conversion rule. if in an expression, I have several kind of data type( I, P, F,N..).
Then finaly, all the data object will convert to which data type?
I don't know the priority of data conversion.
E.g.   data a type i. data b type p. data c type f.
         a = b + c.
or    data d type p, data e type f.
      if ( d > f ).
Then who will convert to who's type?
Thanks and Regards.
Aaron

For expressions, the right term in SAP is "calculation type", it's explained here : [abap help - determining the calculation type|http://help.sap.com/abapdocu_70/en/ABENARITH_TYPE.htm]. SAP takes the "biggest" type of all variables in the expression. It can be I, P or F (smallest is I, biggest is F).
Conditions are handled differently, just using data type conversion (see link given above by Abhishek), SAP converts from smallest to biggest type (in your case, it converts P to F and compares the two F variables).

The sme variable in data selection of inpopackage and value in transfer rul

Hello
I would like to use the same variable in data selection of infopackage (1) and as a value in transfer rules (2).
Example :
If I pass 1 I want to see value1 in data selection of infopackage (1) and as a value in transfer rules (2).
If I pass 2 I want to see value2 in data selection of infopackage (1) and as a value in transfer rules (2).
How is possible?

Hi Aleks,
In the transfer routine your code would be something similar to this:
zvar is a variable
select LOW from RSLDPSEL into zvar where LOGDPID = '<Technical name of Infopackage>' and IOBJNM = '<The Info-object whose value you want to use>'.
*Now assign the value
RESULT = zvar.
Hope this helps.
Bye
Dinesh

Can we clear more line items with different currency within one Vendor

Dear All,
Please guide us the following issue is
Can we clear two line items with different currency within one Vendor (i.e., Down Payment entry passed in EUR and Invoice in JPY).
Thanks in advance.
Regards
Srinivas

Hi
I suppose this should be possible in F-44, for any difference in forex enter a new line item 'Charge off diff.' to Dr/Cr Forex gain/loss account
Thank You,

Different values within "conversion rule" possible?

Similar Messages

Maybe you are looking for