Skip to Content

Few days ago we faced a strange issue which I decided to trace and get clarification at. I was preparing some files for LSMW upload. I was using standard procedure in this case: 

  • Record transaction input
  • Define intermediate structure field names      or any defaults (on post recording screen)
  • Create an object in LSMW for given      (sub)project
  • Create import file structure
  • Map fields b/w intermediate structure and      flat file’s
  • Run batch

 

Background

This was always more or less working for me. This time, however, we faced something that was the tip of the iceberg.

Together with my HR PY specialist colleague we were migrating Wage Type catalog (table T512W and all other tables crucial from HR PY perspective). After an analysis we did, we decided to generate our own maintenance view (Z_T512W2) and recorded data entry for it. So far so good.

During the batch load, we found strange error at field KUMUL which is of RAW 12data type.

 

It doesn’t fit my size

I did some trace and following technical details for that field I found:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screen field

 

 

Intermediate field

 

 

File field

 

 

Name

 

 

Type and Length

 

 

Name

 

 

Type and Length

 

 

Name

 

 

Type and Length

 

 

Z_T512W2-KUMUL

 

 

RAW 12

 

 

PLT512W2-KUMUL

 

 

RAW 12

 

 

IMP_T512W2-KUMUL

 

 

CHAR 24

 

 

At first sight nothing special happens here. We needed to fit 24 characters into 12 bytes. This is totally fine, as simple math tells us

1 bytes = 2 hex digit = 2 chars

So

12 bytes = 24 hex digit = 24 chars

 

OK, no big deal you think. Take a closer look on the above once again. I just said our screen field is 12 bytes long. But this doesn’t mean 24 chars. It turned out that system during screen generation of maintenance view doesn’t convert RAW 12 to CHAR 24. Ultimately we got RAW (acting as CHAR with 0-F value range) of 12 position long.

 

As a result of the above if we had such entry in file

IMP_T512W2-KUMUL = 112233445566778899AABBCC

The screen field would changed it to

Z_T512W2-KUMUL = 112233445566000000000000

 

System simply truncates last 6 bytes (12 chars) filling it up with trailing zero bytes.

 

Not for LSMW

I did a test. I changed screen field generated for maintenance view to be of type RAW 24. This way I could enter 24 characters. But there was another issue. The intermediate screen field generated during recording was of type C 12. So I had no choice. I couldn’t use LSMW to enter this 24 characters to screen field, as it would be truncated during data transport file field => intermediate field

image

 

How that happens?

I asked myself a question like that. Why the system doesn’t convert RAW data doubling its length for screen field. A simple test I expected to confirm that. But it didn’t as shown below

image

image

 

So I did another test. This time with normal screen instead of selection screen.

image

image

image

 

One last test I did.

  • I created ZRAW domain

image

  • I created a structure with field of data      element ZRAW which uses this domain
  • Now I referred both selection screen field      and my normal screen field to that ZSTRUCTURE field. The output was as      below

image

 

Conclusion

I know what you are thinking. No big deal. Everyone knows that domain controls elements technical specification. Yes, you are right. You can even redefine its length on screen field level if field length andoutput length on domain level are the same. This way you will overwrite this field technical specification.

The real purpose of this blog was to warn everyone who plays with RAW type fields. As shown above selection screen generator can evaluate RAW field’s length correctly, but it’s not the case for normal screen. Furthermore for LSMW this will not work even you tweak your screen field. This is due to the domain whose specification is used to generate intermediate field. As a result we can’t load data appropriately.

Hope you will consider that next time doing any migration activities or other RAW screen fields. You should no longer be surprised if some data are missing. 

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

    1. Marcin Pciak Post author
      Hi Suhas,

      I meant here 1 byte = 2 hex digits. In the upload file (and field) you will therefore have 2 chars (0-9, A-F).

      Regards
      Marcin

      (0) 

Leave a Reply