ABAP log

June 16, 2008

Recoding document numbers

Filed under: ABAP, APO, SAP — abaplog @ 7:57 pm

For one of our external systems we collect the data from both R/3 and APO and last week I had an interesting problem of potential conflict between document numbers. The planned orders that are created in APO but not published to R/3 are (hopefully) guaranteed to have different document numbers than those existing in R/3. I guess you can configure the systems so that they will be using the same number range. So, if you are transferring R/3 and APO planned orders, there should not be any problems in mixing documents.

Now, imagine we have to transfer the material reservations of the planned order. If not all BOM components are known to APO, R/3 does the BOM explosion when the APO order gets published into R/3. If the order is not published, I have to make the BOM explosion in R/3 myself. How do I assign reservation numbers in a safe way? My first idea was to simply use the planned order number as reservation number abd the BOM position and the reservation position number. Wrong way. This does not ensure that the reservation numbers you “simulate” this way differ from real ones from the RESB table, because planned orders and reservations use different number ranges.

What saved me was that the reservation number for my external system doesn’t have to be purely numeric. Actually, even in R/3 itself it’s defined as “character” of length 10, and it’s only number range logic that results in numeric reservation numbers. How can we encode the numbers easily so that they will be distinct? I started looking at hexadecimal encoding. I needed to squeeze ten decimal positions into less, to save at least one position to use it as a prefix, something like “A” at the beginning, to make the resulting number (ok, not the number but “identifier”) 100% distinct. For if left just hexadecimal, we can easily have a hexadecimal number consisting just of digits, and we may end up with conflicting document numbers again.

If we split the maximum document number into two parts, i.e. two of 99999, each part can be represented with a hex number of 1869F. Same five positions! But the first one needs only one bit, it’s either zero or one! Thus, taking last four positions of both parts, and combining first two positions together into one hex digit, I can encode the whole thing into exactly nine positions, leaving one for my prefix. For example, 9999999999 will be coded like 03869F869F, and the external system will get something like A3869F869F.

The rest is the ABAP code that does the encoding:

form encode_via_hex
  using pf_char10
  changing pf_char10_out.
    lf_num51(5) type n,
    lf_hex4(4)  type x,
    lf_num1(1)   type n,
    lf_char8(8 ) type c.
  pf_char10_out = '0000000000'.
* first part
  lf_num51 = pf_char10(5).
  lf_hex4 = lf_num51.
  write lf_hex4 to lf_char8.
  lf_num1 = lf_char8+3(1) * 2.
  pf_char10_out+6(4) = lf_char8+4(4).
* second part
  lf_num51 = pf_char10+5(5).
  lf_hex4 = lf_num51.
  write lf_hex4 to lf_char8.
  lf_num1 = lf_num1 + lf_char8+3(1).
  pf_char10_out+2(4) = lf_char8+4(4).
  pf_char10_out+1(1) = lf_num1.

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: