Solved: duplicate check in POS DM

Former Member · ‎09-23-2014

can anyone tell the difference between following custome BADI and standard BADI code and why they have gone for custome one and explain in detail?

ETHOD CHECK_DUP_TRANSNUMBERS .

DATA: lt_saved_keys TYPE ty_tt_transaction_key,

lt_proc_keys TYPE ty_tt_transaction_key,

* l_old_businessdaydate type /posdw/businessdaydate,

* l_old_transtypecode type /posdw/transtypecode,

l_retailstoreid TYPE /posdw/retailstoreid,

lr_field_order TYPE REF TO /posdw/cl_field_order,

lr_messagerange TYPE REF TO /posdw/cl_transindex_range,

lr_businessdaydate TYPE /posdw/rt_businessdaydate,

l_tabix TYPE sytabix,

l_transkey_old TYPE ty_transaction_key,

l_no_duplicate_found TYPE xfeld.

data: lv_lookbackdays type /POSDW/LOOKBACKDAYS,

lv_retention_period type /posdw/parameter_Value,

lv_chk_date type sy-datum.

FIELD-SYMBOLS: <fs_transkey> TYPE ty_transaction_key,

<fs_transkey_saved> TYPE ty_transaction_key.

CREATE OBJECT: lr_field_order, lr_messagerange.

* lr_field_order->append_field( 'TRANSTYPECODE' ). " Optionally (also see below!)

* lr_field_order->append_field( 'WORKSTATIONID' ).

lr_field_order->append_field( 'TRANSNUMBER' ).

lr_field_order->append_field( 'TRANSINDEX' ).

* lr_field_order->append_field( 'BUSINESSDAYDATE' ).

lv_retention_period = ir_task_parameters->get_value( i_parameter_name ='RETENTION_PERIOD' ).

if sy-tcode = '/POSDW/MON0' or

sy-tcode = 'SE37'.

* Retrieve the Retention period from the Task parameter

lv_lookbackdays = lv_retention_period.

elseif sy-tcode = '/POSDW/PDIS'.

lv_lookbackdays = i_lookbackdays.

endif.

lr_businessdaydate = /posdw/cl_range_service=>range_extend_lookback(

it_businessdaydate = ir_businessdaydate

i_lookbackdays = lv_lookbackdays ).

* i_lookbackdays = i_lookbackdays ).

*----------------------------------------------------------------------

* Split saved transactions and transactions to be processed

*----------------------------------------------------------------------

get_saved_and_processed_key(

EXPORTING

i_taskcode = i_task-taskcode

i_include_new_tasks = i_include_new_tasks

ir_field_order = lr_field_order

it_transaction = it_transaction

ir_businessdaydate = lr_businessdaydate

i_task_status_save = i_task_status_save

i_task_status_proc = i_task_status_proc

IMPORTING

et_saved_keys = lt_saved_keys

et_proc_keys = lt_proc_keys

e_retailstoreid = l_retailstoreid ).

* we get exactly one businessdaydate / retailstoreid,

* so only sort by workstationid and transnumber...

* or only sort by transnumber if workstationid not available.

* IF <fs_transaction_first>-workstationid IS NOT INITIAL.

* Search for duplicates

LOOP AT lt_proc_keys ASSIGNING <fs_transkey>.

* Check if the transaction date is older than the current period - retention period

* If yes, then issue a warning and continue

lv_chk_date = sy-datum - lv_retention_period.

if ( <fs_transkey>-BUSINESSDAYDATE < lv_chk_date ).

* Issue warning

APPEND_MESSAGE_OLD(

EXPORTING

i_retailstoreid = <fs_transkey>-retailstoreid

i_businessdaydate_proc = <fs_transkey>-businessdaydate

i_businessdaydate_sav = l_transkey_old-businessdaydate

i_workstationid = <fs_transkey>-workstationid

i_transtypecode = <fs_transkey>-transtypecode

i_transindex_proc = <fs_transkey>-transindex

i_transindex_sav = l_transkey_old-transindex

i_transnumber = <fs_transkey>-transnumber

i_retention_period = lv_retention_period

CHANGING

ct_message = ot_message

ct_actionresult = ot_actionresult ).

endif.

* IF l_transkey_old-workstationid EQ <fs_transkey>-workstationid AND

IF l_transkey_old-transnumber EQ <fs_transkey>-transnumber.

* Duplicate found

append_message_dup(

EXPORTING

i_retailstoreid = <fs_transkey>-retailstoreid

i_businessdaydate_proc = <fs_transkey>-businessdaydate

i_businessdaydate_sav = l_transkey_old-businessdaydate

i_workstationid = <fs_transkey>-workstationid

i_transtypecode = <fs_transkey>-transtypecode

i_transindex_proc = <fs_transkey>-transindex

i_transindex_sav = l_transkey_old-transindex

i_transnumber = <fs_transkey>-transnumber

CHANGING

ct_message = ot_message

ct_actionresult = ot_actionresult ).

ENDIF.

l_transkey_old = <fs_transkey>.

READ TABLE lt_saved_keys WITH KEY

* businessdaydate = <fs_transaction_proc>-businessdaydate

* transtypecode = <fs_transaction_proc>-transtypecode

* workstationid = <fs_transkey>-workstationid

transnumber = <fs_transkey>-transnumber

BINARY SEARCH TRANSPORTING NO FIELDS.

l_tabix = sy-tabix.

IF sy-subrc EQ 0.

lr_messagerange->clear( ).

LOOP AT lt_saved_keys FROM l_tabix ASSIGNING <fs_transkey_saved>.

IF

* <fs_transkey_saved>-businessdaydate NE <fs_transkey>-businessdaydate OR

* <fs_transkey_saved>-transtypecode NE <fs_transkey>-transtypecode OR

* <fs_transkey_saved>-workstationid NE <fs_transkey>-workstationid OR

<fs_transkey_saved>-transnumber NE <fs_transkey>-transnumber.

EXIT.

ENDIF.

if <fs_transkey_saved>-transindex ne <fs_transkey>-transindex or

<fs_transkey_saved>-businessdaydate ne <fs_transkey>-businessdaydate.

lr_messagerange->add_transaction_in_order(

i_transindex = <fs_transkey>-transindex

i_businessdaydate = <fs_transkey>-businessdaydate ).

EXIT.

endif.

ENDLOOP.

* Duplicate transaction found!

l_no_duplicate_found = lr_messagerange->is_initial( ).

IF l_no_duplicate_found IS INITIAL.

append_message_dup(

EXPORTING

i_retailstoreid = <fs_transkey_saved>-retailstoreid

i_businessdaydate_proc = <fs_transkey>-businessdaydate

i_businessdaydate_sav = <fs_transkey_saved>-businessdaydate

i_workstationid = <fs_transkey_saved>-workstationid

i_transtypecode = <fs_transkey_saved>-transtypecode

i_transindex_proc = <fs_transkey>-transindex

i_transindex_sav = <fs_transkey_saved>-transindex

i_transnumber = <fs_transkey_saved>-transnumber

CHANGING

ct_message = ot_message

ct_actionresult = ot_actionresult ).

ENDIF.

ENDLOOP.

ENDMETHOD.

ramesh_duraisamy · ‎09-23-2014

Hi Kalaiselvi,

The above custom BADI is used to check the duplicate check for a transaction number, As explained you in another post,

if Duplicate transaction check is a precondition for creating a sales aggregate then unless the duplicate task is in status ‘complete’ the system will not allow you to create sales aggregate for the relevant POS transaction.

Thanks and Regards,

Ramesh D

View solution in original post

ramesh_duraisamy · ‎09-23-2014

Hi Kalaiselvi,

The above custom BADI is used to check the duplicate check for a transaction number, As explained you in another post,

if Duplicate transaction check is a precondition for creating a sales aggregate then unless the duplicate task is in status ‘complete’ the system will not allow you to create sales aggregate for the relevant POS transaction.

Thanks and Regards,

Ramesh D

Former Member · ‎09-23-2014

I just need to find out why custom BADI is opted as standard also performs the same.if something additional is done please let me know as i couldnt find out through coding..

vikrant_mohite · ‎09-23-2014

It could be business requirements.

Business might be interested to check duplicate based on some other criteria (say timestamp of transaction).

You can check it with one who has implemented that.

Thanks,

Vikrant.