...

...

1.  Select node “SCN events” to deactivate EPCIS events to be created with function module /K3T/RU_AIF_IN_SCN. By default commissioning, aggregation, receiving, shipping will be posted. Deactivate checkbox for specific event if posting is not needed.

2. Select node “Message field” to set possible values for reporting message field selection.

 4.6     Message approval

...

The approval user, group, and explicit waiting of user approval determined with following logic:

1. Get values from Rule parameters (transaction /K3T/RU_CONF under “Rule Configuration”)

2. Get values from GLN parameters (transaction /K3T/RU_CONF under “GLN assignment”)

3. Get values from Subject ID parameters (transaction /K3T/RU_CONF under “MDLP Subject ID”)

4. Get values from Configuration ID parameters (transaction /K3T/RU_CONF under “Configuration ID”)

Maintain the Approval Group and assign User to the Approval Group in the transaction /K3T/RU_CONF under “Approval group”, if approval shall be controlled by Approval Group assignment.

...

The logic of the sequence check:

1. No sequence check for messages 250-252, 10311, 10319

2. Check objects MDLP status, maintained in the transaction /K3T/RU_CONF under “Sequence Message sending”, allow for the MDLP document type. Aggregation messages 911-915 excluded from this check. The MDLP status tracked for every SGTIN in the table /K3T/RU_MDLP_STA. The SSCC MDLP status determined based on the first found SGTIN in the current hierarchy

3. Check the predecessor message exist for the same objects (messages currently in processing or confirmed with error from MDLP, messages with earlier operation data)

4. The message 915 checked to send parts in correct order. The parts of SGTIN-SSCC shall be send first and confirmed by MDLP before sending another SSCC-SSCC parts

The MDLP status will be updated with confirmation message from MDLP based on the values in the transaction /K3T/RU_CONF under “Sequence Status changing”

...

MDLP analytics reports functionality is available, including ability to request following reports: Remaining medicines, Medicine disposal, SSCC Hierarchy, Pricing report, General report Pricing report, General report on movement, General report on remaining item, General report on disposal.

To receive analytic reporting data from MDLP system the following steps are required:

• Schedule report run - create analytic reporting request and task (according to MDLP API requirements) using transactions /K3T/RU_MASMAR_SCD_* (For example, /K3T/RU_MAR_SCD_MD - Task scheduler Medicine disposal) or /K3T/RU_MAR_SCD_GEN_* (General reports, for example, /K3T/RU_MAR_SCD_GEN_MD - Task scheduler Medicine disposal)

• Run task processor (program /K3T/RU_MAR_TASK_PROC for tasks or /K3T/RU_MAR_REP_PROC for general reports) to create tasks at MDLP, receive task results and save as ZIP file into database table

• Run task execution (program /K3T/RU_MAR_TASK_EXEC) to extract data from ZIP file and save data to database or send data to external database

• Monitor task execution (transaction /K3T/RU_MAR_MONITOR)

...

The task execution results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_EXEC.

4.11.4     Report /K3T/RU_MAR_REP_PROC - Russia MDLP Analytics: Task processor (General Report)

The report /K3T/RU_MAR_REP_PROC shall be executed periodically as background job for sending requests to the MDLP and downloading results. The multiple background jobs can be planned for each MDLP Configuration ID to execute in parallel. The selection screen fields:

• MDLP Configuration ID

• Wait Time First Response: Default wait time in seconds between request and results download

• Max Wait Time After Crt: maximum processing time after request was registered by MDLP system and response is expected. If no response is received task status will be set to error

• Between Status Check (sec): wait time in seconds between task status check

• Create new Log after seconds: create new SLG1 log after specified interval from report run to monitor program execution

• Maximum runtime program (min): maximum program processing time before stop with error

• Max Server Errors: maximum server errors series before stop with error

Block “Available tasks operation retry option“

• Retry after failure times: not used, obsolete

• Delay after failure (sec): not used, obsolete

• Backoff: not used, obsolete

Block “MDLP queue operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Delete operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Result operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Block “Create operation retry option“

• Retry after failure times: how much tries needs to be done after each failure

• Delay after failure (sec): the initial delay in seconds after first negative response. Value must be greater than 0

• Backoff: the factor by which the delay should be increased after each failure. Value must be greater than 1

Report read tasks ID and process tasks according to MDLP API requirements. In correct scenario task status is changed:

• status 00-new to status 10-Sent to MDLP: task created at MDLP successfully

• status 10-Sent to MDLP to status 20-Ready (results downloaded from MDLP): task data retrieval is completed and task result deleted from MDLP

The task processing results stored as application log transaction SLG1, Object /STTP/, Sub object ANY, External ID /K3T/MR_TASK_PROCESSOR.

4.12     Manual signature

Manual signature functionality is available for sending outbound reports and receiving inbound reports via SAP GUI and Crypto Pro SSF software installed on the user local PC. Combined scenario with non-resident, resident MDLP cabinet with manual signature and without manual signature are supported.

4.12.1     Prerequisites

Prerequisite of manual signature are the following:

• Crypto Pro SSF software installed on the user local PC

• Crypto Pro setup refer to the configuration guide

• In case Java part use HTTPs the binding shall be created for new Web services

4.12.2     ATTP customizing

Maintain certificate ID assignment to the user and configuration ID via transaction /K3T/RU_SSF_C - “Russia MDLP Certificate assignment”.

Activate checkbox “Signature required” for Configuration ID via transaction /K3T/RU_CONF node Configuration ID.

Activate field “User approval” to stop message in status ‘01’ and wait for the user Approval in the transaction /K3T/RU_MONITOR.

4.12.3     Token update

In case of manual signature scenario token is stored at MDLP Connector Java part and updated from transaction /K3T/RU_MONITOR manually by user. MDLP system interaction works automatically if connector has active token and wait if token is expired until token renewed by the user.

To update token please execute the following steps:

• Run transaction /K3T/RU_MONITOR

• Execute report selection using manual signature configuration as a filter

• Select report line with using manual signature configuration

• Press menu button “Manual Signature” and choose option “Update Token”. System checks if token is still active and provide Popup window to confirm token need to be updated

• Popup window for Digital signature appears

• Enter your certificate password and press “Sign”

• Security settings window appears to confirm access to local PC

• Message token updated successfully appears

4.12.4     Report sending

In case of manual signature scenario report is always send to MDLP system manually and signing by the user before sending to MDLP Connector.

To update token please execute the following steps:

• Run transaction /K3T/RU_MONITOR

• Execute report selection using manual signature configuration as a filter

• Select report line with using manual signature configuration

• Press “Approval button”

• System checks if token is still active and provide Popup window to sign data and receive new token if token needs to be updated:

  • Popup window for Digital signature appears

  • Enter your certificate password and press “Sign”

  • Security settings window appears to confirm access to local PC

• System execute signature for report before sending to Connector:

  • Popup window for Digital signature appears

  • Enter your certificate password and press “Sign”

  • Security settings window appears to confirm access to local PC

• Report is sending to Connector and report status is changed to 20-Send

4.12.5     MDLP interaction

In case of manual signature scenario it is important to have active token before MDLP calls.

The check of the valid MDLP token added into transaction /K3T/RU_MONITOR to the MDLP Message menu buttons like “Display message XML” “Display Response XML” etc.

The check of the valid MDLP token added to the following transactions:

• /K3T/RU_MDLP_SN_INFO Russia MLDP serial number info

The following corrections implemented into program /K3T/RU_MDLP_DISPATCHER:

• report manual signature filter - reports with manual signature configurations will not be send to MDLP system by program (only using approval button via transaction /K3T/RU_MONITOR)

The following corrections implemented into program /K3T/RU_MDLP_IN (Inbound message processing):

• report manual signature filter - reports with manual signature configurations will be processed only in case active token exists for configuration

• API methods will be used to receive information for reports with manual signature from MDLP independently of system customizing (This correction works at inbound processing modules, for example, Function module /K3T/RU_AIF_IN_SCN will receive hierarchy information using API method not by using 210 / 220 XML message)

The following corrections implemented into transaction /K3T/RU_OMS_TOKEN - Russia OMS token:

• report manual signature filter - OMS token for manual signature configurations will not be updated by program if program is executed on background mode (only dialog mode)

• manual signature - If OMS token for manual signature configuration need to be updated additional popup window appears to execute manual signature to sign authorization data via SAP GUI and Crypto Pro SSF integration. After signature data is send to MDLP Connector Java part and token is updated at ATTP system

==

5.     Enhancements of the Solution

...