09-22-2014 2:08 AM
How to make custom duplicate checks to be carried out in posdm pipe engine checkings.In my posdm system,i couldn find some custom duplicate checks performed.I want to know the fields involved
09-22-2014 12:52 PM
Hi Kalai selvi,
In standard SAP, if a rule is created to check the successful completion of a task in POSDM that is configured as a precondition for another task execution, then system will not allow you to process the task unless the linked task is processed successfully e.g. 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.
Required Functionality
A new BADI implementation is required linked to a rule which checks that task maintained in the rule is either ‘complete’ or ‘rejected’ then the task status will be passed as ‘success.
The task status change will only be allowed for authorized users.
Technical Approach :
A new BADI implementation is required to check the linked task status and pass the status to follow on tasks (e.g. create sales aggregate) to process successfully.
The BADI details are:
Badi definition: /POSDW/CONDITION
Interface: /POSDW/IF_EX_CONDITION
Enhancement implementation: /POSDW/CONDITION
Badi Implementation: ZTASK_CHECK (Example)
A new filter should be created which will be linked to a rule.
Thanks and Regards,
Ramesh D
09-22-2014 11:40 AM
You can create Z* implementation of BAdi to carry duplicate check.
Standard implementation checks duplicate considering store id/posid/receipt no.
Thanks,
Vikrant.
09-22-2014 12:52 PM
Hi Kalai selvi,
In standard SAP, if a rule is created to check the successful completion of a task in POSDM that is configured as a precondition for another task execution, then system will not allow you to process the task unless the linked task is processed successfully e.g. 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.
Required Functionality
A new BADI implementation is required linked to a rule which checks that task maintained in the rule is either ‘complete’ or ‘rejected’ then the task status will be passed as ‘success.
The task status change will only be allowed for authorized users.
Technical Approach :
A new BADI implementation is required to check the linked task status and pass the status to follow on tasks (e.g. create sales aggregate) to process successfully.
The BADI details are:
Badi definition: /POSDW/CONDITION
Interface: /POSDW/IF_EX_CONDITION
Enhancement implementation: /POSDW/CONDITION
Badi Implementation: ZTASK_CHECK (Example)
A new filter should be created which will be linked to a rule.
Thanks and Regards,
Ramesh D
09-23-2014 12:35 AM
09-23-2014 12:38 AM
How to check what are all the functions of POSDM are implemented in my current system?Is by default all the standard tasks are implemented in system?
09-23-2014 5:17 AM
Check what profile has been used in General settings for your implementation.
Then check the linking of tasks with that profile.
Thanks,
Vikrant.
09-23-2014 5:33 AM
Hi Vikrant,I am new to POS DM.When I check Profiles in POS DM,i can see
0001 standard
z0001 customer profile
I can see some task s are assigned with standard and some are with customer profile.I just wanted to know whether all the task under both profile are implemented in current system
For example ,
0001 duplicate check & gaps in receipt numbers both are there
z0001 only duplicated check is there.
Can you please explain in detail
09-23-2014 6:01 AM
By default SAP will provide General Profile 0001 and by default all tasks are associated to it.
Z001 is your custom profile so you need to check if the tasks you want are linked to Z001.
All tasks (in short BAdis) are implemented in system but what you want to use needs to be assigned to your custom profile.
Thanks,
Vikrant.
09-23-2014 7:43 AM
This s custom code for duplicate check.can anyone explain whats difference between standard and this one in detail.
METHOD 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.
ENDIF.
ENDLOOP.
ENDMETHOD.
09-23-2014 12:23 PM
Hi KalaiSelvi,
Coming to your PROFILE question,
You can create number of profile based upon the requirement and stores,
0001 SAP Standard profile
you can create Z001,Z002,Z003 based upon the currency,Exch Type in PIPE,check profile etc/
Thanks and Regards,
Ramesh D
09-23-2014 4:33 PM
Hi Kalaselvi,
Mark correct or assumed answers to all my post, so that i can grab points
Thanks and Regards,
Ramesh D