Beware of RAW type screen fields

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:

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

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

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

One last test I did.

• I created ZRAW domain

• 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

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.