2LIS_06_INV

Filling Setup Tables : OLI6BW
Delete Setup Tables : LBWG - Application 06
Setup Table : MC06M_0ITMSETUP

When running setup tables, the selection screen parameters are mandatory, even  the screen doesn’t say so.

With out the selections the job would give the error

Enter Doc number, Year and Comp Code and run the setup tables. It ran fine few times, but twice I had duplicate error. So I deleted the setup tables (LBWG) and ran them again with only Doc Number and Year.

My Notes:

This datasource is used to get the invoiced data. The requirement is to replicate 'MB5S' tcode from ECC. Users wanted the data from EKBE table which shows Invoiced Quantities BEWTP = Q and 'E' delivered quantities.

The entries from EKBE with BEWTP = 'Q' can be extracted using this datasource, given that we extract records where EBELN, MENGE,MATNR are not inital (my assumption and it worked fine).

The BEWTP = 'E' is extracted from 2LIS_03_BF.

Issues:

• Difference in amounts of MSEG-DMBTR and EKBE-DMBTR
• EKBE table has Purchase Order History data and MSEG has Document Segment: Material data in it. When using a Join of 2LIS_03_BF ( for Good Movement (E) from MSEG data ) and 2LIS_06_INV ( for Invoice (Q) from EKBE data ) ; In general the DBMTR is same in MSEG and EKBE, but there are few scenarios when they are different. Below is the explanation.
• http://scn.sap.com/thread/1895345
• For the below example the $0 value in MSEG is due to the fact that the std price for that material in table MBEW is $0 - this is the value that would post to inventory.  The value that appears in EKBE for where value = "E" is the amount the vendor is invoicing us.  So it appears that EKBE is using the invoiced amount as the value for DMBTR.

SAP Link

http://help.sap.com/saphelp_nw70/helpdata/en/57/dad06449114814919000e27dfb255e/content.htm

APD

APD - Analysis Process Designer

TCode: RSANWB

Debugging APDs
https://blogs.sap.com/2014/03/04/steps-to-debug-apd-routine-code/

Duplicates in APD

• Go the step and do an intermediate result.
• This will generate a temporary table with results from that stage.
• The table is be visible in SE11/SE16 as regular table
• See if you can find the duplicates from the set
• Delete the intermediate result table again.

Some known issues

• APD connecting lines are missing
• If the connecting lines between the APDs are missing.
• This issue happened after SAP 7.4 GUI update/
• Check Note 2227956

• APD taking long time to run
• Uncheck 'Process Data in Memory' to improve the APD performance. It is checked by default.
• GoTo -> Performance Settings

Differences

Difference between REFRESH; FREE; CLEAR

REFRESH : If REFRESH is applied on an internal table  then the entries in the table will be deleted but the memory allocated to that table still exists.

FREE : If FREE is applied on an internal table then the memory allocated to that table will not exist and that memory can be used by some other variable/object.In this case both the entries and the memory do not exist anymore.

CLEAR : pplied on If CLEAR is generally used for workareas and also, if the internal table is defined with header line, clear can be applied to clear the header line. The memory allocated to it is not removed.

Difference between CHECK and IF

if the IF condition is not satisfied control will go to the next statements. Here when the IF condition is used, and the condition is not satisfied, control looks for remaining executable lines inside the loop.

in case of CHECK if the condition is not satisfied control will; not go further.Here when the CHECK condition is used, and the condition is not satisfied, control comes outside the loop.

Unwanted Characters

Method 1
*** Removing unwanted characters.
DATA: var_str(100) VALUE
‘QWERTYUIOPASDFGHJKLZXCVBNMqwertyuiopasdfghjklzxcvbnm1234567890-_’  ,
var_custpo TYPE /BIC/OIZCCUSTPO,
var_temp TYPE /BIC/OIZCCUSTPO,
var_len(3) TYPE c.
CLEAR: var_custpo,
var_len,
var_temp.
var_custpo = source_fields-/bic/zccustpo.
var_len = strlen( var_custpo ).
DO var_len TIMES.
SUBTRACT 1 FROM var_len.
IF var_str CS var_custpo+var_len(1).
CONCATENATE var_custpo+var_len(1) var_temp INTO var_temp.
ENDIF.
ENDDO.
RESULT = var_temp.

Method 2

CONSTANTS: c_allowed(100) TYPE C value
‘ #{}[]!”%&”()*+,-./:;<=>?_0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ abcd’ &
‘efghi’ &
‘jklmnopqrstuvwxyz ‘.
DATA : var_EANUPC TYPE /BI0/OIEANUPC,
var_len TYPE i,
var_error TYPE sy-subrc,
var_offset TYPE sy-index.
CLEAR: var_EANUPC.
var_EANUPC = SOURCE_FIELDS-EANUPC.
TRANSLATE var_EANUPC TO UPPER CASE.
CLEAR: var_error.
CALL FUNCTION ‘RSKC_CHAVL_CHECK’
EXPORTING
I_CHAVL                     = var_EANUPC
IMPORTING
E_ERR_SUBRC                 = var_error.
IF var_error NE 0.
CLEAR: var_len.
var_len = strlen( var_EANUPC ).
DO var_len TIMES.
CLEAR:var_offset.
var_offset = sy-index – 1.
IF var_EANUPC+var_offset(1) CO c_allowed.
ELSE.
var_EANUPC+var_offset(1) = ”.
ENDIF.
ENDDO.
ENDIF.
* result value of the routine
RESULT = var_EANUPC.

Reading Dynamic Table

Dynamic table fields declaration with Reference
Using For the parameters we use the dynamical reference to the data dictionary. This way we do not have to define texts  in the text pool, but the field name from the dictionary is used. Character fields to hold the dictionary names data:

* Logon data
t_gltgv(30) value 'BAPILOGOND-GLTGV',
t_gltgb(30) value 'BAPILOGOND-GLTGB',
t_ustyp(30) value 'BAPILOGOND-USTYP',

gltgv like  (t_gltgv),
gltgb like  (t_gltgb),
ustyp like  (t_ustyp),
class like  (t_class),
accnt like  (t_accnt),

Reference : IAM_USERCHANGE

-------------------------------------------------------------------------------------------------------------------------

REPORT z_dynamic_read.

DATA: gt_itab TYPE REF TO data,

      ge_key_field1 TYPE char30,

      ge_key_field2 TYPE char30,

      ge_key_field3 TYPE char30,

      go_descr_ref TYPE REF TO cl_abap_tabledescr.

FIELD-SYMBOLS: <gt_itab> TYPE STANDARD TABLE,

               <gs_key_comp> TYPE abap_keydescr,

               <gs_result> TYPE ANY.

PARAMETERS: pa_table TYPE tabname16 DEFAULT 'SPFLI',

            pa_cond1 TYPE string DEFAULT sy-mandt,

            pa_cond2 TYPE string DEFAULT 'LH',

            pa_cond3 TYPE string DEFAULT '0123'.

START-OF-SELECTION.

* Create and populate internal table

  CREATE DATA gt_itab TYPE STANDARD TABLE OF (pa_table).

  ASSIGN gt_itab->* TO <gt_itab>.

  SELECT * FROM (pa_table) INTO TABLE <gt_itab>.

* Get the key components into the fields ge_key_field1, ...

  go_descr_ref ?= cl_abap_typedescr=>describe_by_data_ref( gt_itab ).

  LOOP AT go_descr_ref->key ASSIGNING <gs_key_comp>.

    CASE sy-tabix.

      WHEN 1.

        ge_key_field1 = <gs_key_comp>-name.

      WHEN 2.

        ge_key_field2 = <gs_key_comp>-name.

      WHEN 3.

        ge_key_field3 = <gs_key_comp>-name.

    ENDCASE.

  ENDLOOP.

* Finally, perform the search

  READ TABLE <gt_itab> ASSIGNING <gs_result>

          WITH KEY (ge_key_field1) = pa_cond1

                   (ge_key_field2) = pa_cond2

                   (ge_key_field3) = pa_cond3.

  IF sy-subrc = 0.

    WRITE / 'Record found.'.

  ELSE.

    WRITE / 'No record found.'.

  ENDIF.

One note: When an internal table is created dynamically like in my program above, the table key isnot the key defined in the DDIC structure — instead, the default key for the standard table is used (i.e. all non-numeric fields).

Japanese Currency Issue

In SAP, amounts (data type CURR) are always stored with two decimals in the database.
It does not matter how many decimals are actually allowed for that currency.
Currencies like JPY, KRW, CLP, etc. do not have any decimals.

In those cases, SAP both on ECC and BW divides the amount for those currencies by the decimal factor maintained in TCURX table and multiplies by the same factor on the report.

For example, 30,000 will be stored as 30,000/100 (because the TCURX table has 0 decimal).

For zero decimals, 

SAP divides by 100. If we are loading the flat file data , we should make sure that this division occurs. After the division, 30,000 will be stored as 300.
In the BW report, 300 will be multiplied by 100 and shown as 30,000.
This division and multiplication occurs for all the exception currencies maintained in TCURX.

If the above division is not happening, the report will multiply by 100 by default and that will be an overstated amount by a factor of 100.

There are specific settings for flat file as stated in OSS Note 1176399 for special currency loads to work correctly.