Question:
Hi
We were uploading PO data into BIW and the data load failed repeatedly due to the presence of a # character in the text liine of the PO item.
How can we prevent this happening in future - other than making sure there are no #'s in the line item descriptions that is
Thanx
Answer:
hi
you look into the rskc and add this # sign in thier and execute. delete previous loads and load again.
enjoy
Answer:
Hi
Thanks for your response. The character # was already in the permitted extra characters field although I cannot verify that this had been executed. It also gave me the option to save as a variant. what is the purpose of the variant, do you know?
Thanks
Clare
Answer:
REPLACE ALL OCCURRENCES OF '#' IN data_package-txtlg WITH ' '.
use above code in Routine
_________________
Sat
Answer:
Hi Microphoebus,
Tried the code sent by you, modifeid it as:
REPLACE ALL OCCURRENCES OF '#' IN W_INPUT WITH 'X '.
The problem is that the # can be anywhere in the charac string. Tried to use the REPLACE function, and CA CS as well.
I tried using *##* as advised in the function help as # is used for another purpose by the system.
I even tried to halt the data in PSA, then edit it and update it to the ODS. In the PSA maintenance, the # in the field were not visible, but they exist as I confirmed it from R/3.
Any suggestions are most welcome
Thanx,
Zubin
Answer:
you don't need to replace all # in a filed. BW only rejects fields with the exact entry "#". Entries like "123#abc", "#123", "abc#" are all permitted.
(read oss note 173241, it's very clear about this, it also explains that you cant have fields STARTING with "!")
We use the following routine for certain InfoObjects in the Update Rules (Transfer Rules would be even better):
DATA: temp_field(1).
IF COMM_STRUCTURE-<InfoObject>= '#'.
ELSE.
IF COMM_STRUCTURE-<InfoObject> CA '!'.
MOVE COMM_STRUCTURE-<InfoObject>+0(1) TO temp_field.
IF temp_field = '!'.
ELSE.
RESULT = COMM_STRUCTURE-<InfoObject>.
ENDIF.
ELSE.
RESULT = COMM_STRUCTURE-<InfoObject>.
ENDIF.
ENDIF.
But definitely read the OSS Note first
Answer:
Hi TRF,
Thank you for your reply. I had already seen note 172341 and it
mentioned that only # alone would cause a problem. I have observed
that a ## at the end of the field is causing this problem.
A # in the middle of the ch string is accepted.
I have tried to write a routine in the transfer rules, to convert
the # to X, but the problem is still the same.
I have tried using function replace, replace all occurrences also
According to help I tried to use '*##*' instead of '#' in the replace
routine, but the load still fails.
I also tried to write a routine in the update rules but ended up getting a blank data field. The upload went thru correctly though this wasn't the desired result.
Is there any way I can run the upload program or the transfer routine in DEBUG mode as in ABAP programs to check how exactly does the formula run in this case?
Thanx,
Zubin
Answer:
Depending on the release you're on you can debug:
BW 2.x: only update rules.
- change your routine in the UR and enter "beak-point." just before the code you want to analyse.
- Load data in PSA, go into the load monitor, Details > Processing > DataPAckage > right click : simulate update
- proceed with F8 till your break-point and see what he does
BW 3.x: tranfer rules and update rules.
- change your routine in the UR or TR and enter "beak-point." just before the code you want to analyse.
- Load data in PSA, go into the load monitor, Details > Processing > DataPAckage > right click : simulate update. Choose the rigth target (infoCube or ODS), click activate breakpoints in UR or TR depending on which you want to debug
- proceed with F8 till your break-point and see what he does
Answer:
hi,
did you get the solution?
please place it here. We are also facing the same problem.
kind regards
m
Answer:
Hi TRF,
Thanx for the debug procedure. It was extremely helpful to analyse what exactly was going on, although we haven't been able to solve it as yet.
We discovered that the "REPLACE" function was not working in the transfer rules with the particular Char string.
We tried the same function in a test program in R/3 to test our logic and the ABAP syntax, where it worked absolutely fine.
We traced it to the occurence of '$' in the char string. If this '$' was deleted during debug, the replace command would change the #.
So we wrote an additional routine to replace the '$' before replacing the #. However this did not work.
The string somehow was able to store the occurence of the $ even after deletion and did not change the #. We even tried a condense to remove the blank space created by the $ deletion. No luck either.....
This was pointed out by the OSS reply that it could be due to $ and in such a case they would access the system and check it.
We are now waiting for them to log in and give us a solution.
Will let u know if I get anything more on it.
Thanx and regards,
Zubin
Answer:
great..please keep in touch here. we would be grateful to you
regards
m
Answer:
you need to use the object code (since UNICODE changes mean stricter ABAP syntax checks ) as follows
data: text like TRAN_STRUCTURE-HDR_DESCR.
Data: int TYPE I.
DATA: buffer TYPE XSTRING,
hex_char type X value 'whatever the hex value for # is',
hex_sp type X value '20',
conv TYPE REF TO cl_abap_conv_out_ce,
conv2 TYPE REF TO cl_abap_conv_in_ce.
move TRAN_STRUCTURE-HDR_DESCR to text.
int = strlen( text ).
conv = cl_abap_conv_out_ce=>create(
encoding = 'UTF-8'
endian = 'L'
).
CALL METHOD conv->write( data = text n = int ).
buffer = conv->get_buffer( ).
replace all occurrences of hex_char in buffer with hex_sp in byte mode.
conv2 = cl_abap_conv_in_ce=>create(
encoding = 'UTF-8'
endian = 'L'
input = buffer
).
CALL METHOD conv2->read(
EXPORTING n = int
IMPORTING data = text
).
move text to RESULT.
* returncode <> 0 means skip this record
RETURNCODE = 0.
Answer:
try using this
REPLACE ALL OCCURRENCES OF '09' IN data_package-txtlg WITH ' '
in hexmode.
It should solve your issue.
Answer:
Hi Guest, Microphoebus,
Thanks for the routine, esp the hex routine was unknown to a few people here.
Tried out this routine too. Again the conv to hex and reconversion is ok, but the replace does not work.
SAP tells me to remove this problem from the R/3 side and then push data to BW. But this is not a complete solution.
I am still hopeful of some solution from one of us SAPFANs, rather than SAP.
Thanks a lot everyone and pl keep on helping us troubled souls.
Keep up the gr8 work.
Thanks and regards,
Zubin
Answer:
hi ,
we have the same problem.
we coded at the R/3 side itself.
not totally tested.It seems its working.will be back on monday.
regards
rao duttaluri