Limiting weight values to be transferred to target system

[ankit_30]

Hi All,

I have a requirement according to which I need to reduce the number of digits being passed to IDOC segmnet fields Z1BP_J_1BNFDOC-BRGEW and Z1BP_J_1BNFDOC-NTGEW. This IDOC will transfer data to a non-SAP target system. In the target system, the gross weight & net weight (BRGEW & NTGEW respectively having total length 13 with 3 decimal places in SAP) have mask: 9999999.99999 (7 digits before decimal and 5 digits after decimal). So the total digits that should be transferred to the target system should not be more than 12.

The method to achieve this, as suggested by functional, was to divide the weight values by 1000 instead of directly truncating the values so that there is no loss of data. For example, if the value in weight field is 123,234,432.000 KG, then on dividing it by 1000, it will result in 123,234.432 KG, which is correct. But using this method, if the number of digits in the weight field is less than 4 digits, for example, 123.000 KG, then on dividing this value by 1000, it will result in 0.123 KG, which is incorrect. And to avoid such a situation, if I apply a condition that the weight values should be divided by 1000 only when the number of digits before the decimal is more than 3, then I am facing the following issue:

Say, there is one value 123,4.000 KG, then in this case since the number of digits is more than 3 before the decimal, it will be divided by 1000, so we get: 1.234 KG. Now, there is another value say, 123.000 KG, then since in this case the number of digits before the decimal is 3, it will not be divided by 1000, so it will remain the same, that is, 123.000 KG. But comparing the two values, initially: 123,4.000 KG > 123.000 KG; and after applying the above logic: 1.234 KG < 123.000 KG, which is again incorrect.

Please suggest an appropriate solution.  

Thanks & Regards,

Ankit

[Former Member]

Reverse logic can figured out if boundary conditions are taken care of.

For input conversion, you are doing something like:

if input > 1000.

     output = input / 1000.

endif.

Reverse case can be:

if frac( output ) > 0.

     input = output * 1000.

endif.

FRAC function strips the integer part and gives only the fraction part.

Both logic would fail for specific cases.

Imagine 123KG becoming 123.000 KG as it is less than 1000.

On the other hand, 123,000 KG would also become 123.000 KG because input is greater than 1000.

When last 3 digits are anything other than 000, both input and output logic would work fine.

Tell your functional about above scenario.

Your requirement sounds really weird.

For exception cases, think about this.

Technically variable can store negative, but logically negative input weight may never come.

Whenever input ends with 000, can you apply negative sign and change 000 to 001, so that both logic work.

[ankit_30]

Thank for your input.

Could you please elaborate the last statement: "Whenever input ends with 000, can you apply negative sign and change 000 to 001, so that both logic work."

[Former Member]

Assuming input will never have negative value, to differentiate between inputs 123,000 and 123, logic can be modified as:

if input > 1000.

     output = input / 1000.

     if frac( output ) eq 0.

          output = -1 * ( output + 0.001 ).

     endif.         

endif.

Reverse case can be:

if frac( output ) > 0 OR output < 0.

     input = ( -1 * output - 0.001 ) * 1000.

endif.

[ankit_30]

Hi Manish,

Thanks for help. But, apparently, some ambiguities will still arise even if I use the above logic.

For example, what will be the result if the input value is 12345678 KG or 1234 KG.

Is there any other method using which these weight values can be made to match the target system mask: 9999999.99999 (total 12 digits with 5 decimal places).

Regards,

Ankit

[Former Member]

Why are you not dividing everything by 1000?

[ankit_30]

In that case values less than 1000 will become less than 1, that is 123 KG will become 0.123 KG, which is not accpetable.

[Former Member]

Why is the reasoning behind <1 being not acceptable?

After all, it is only your internal representation of quantity.

[Former Member]

About your scenario, 12345678 will become 12345.678 and 1234 will become 1.234.

What is the ambiguity here?

[ankit_30]

Since, in these cases, the fraction part is not 0, the latter part of the code logic will also be executed, right ?

if frac( output ) > 0 OR output < 0.

     input = ( -1 * output - 0.001 ) * 1000.

endif.

And if 1234 will become 1.234, then if the input value is 123.123 KG, it will remain unchanged, right ?

Then, in this case, intially the input value 1234 KG is greater than 123.123 KG but the resultant value 1.234 KG is less than 123.123 KG.

[Former Member]

Yes that logic won't work, but it is easy to correct now that you know the issue.

How about this:

if frac( output ) > 0.

     input = output * 1000.

elseif output < 0.

     input ( -1 * output - 0.001 ) * 1000.

endif.

[ankit_30]

In this case, if the value is say 12345678, then on dividing by 1000, it will become 12345.678,

but since in this case frac( 12345.678 ) > 0, then according to the above logic, input will again become:

input = output*1000

=> input = 12345.678 * 1000 = 12345678, thus resulting in no change. And since this value has more than 7 digits before the decimal, it will not be accepted by the target system.

[Former Member]

I don't have any further suggestions.