Manage operations for sap pos

BP_MO_for_SAP_POS_V30.doc – 11.05.2009

Best Practice

Manage Operations for SAP POS

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUScustomer published

DATE VERSION

Apr-01 2009 3.0

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Operations & Continuous Improvement Best Practices for Solution Operations

TOPIC AREA SOLUTION MANAGER AREA

Application & Integration Management Business Process Operation

Best PracticeManage Operations for SAP POS

© 2009 SAP AG - BP_MO_for_SAP_POS_V30.doc page 2/84

Table of Contents1 Management Summary 3

1.1 Goal of Using This Best Practice 31.2 Alternative Practices 31.3 Staff and Skills Requirements 31.4 Duration and Timing 41.5 How to Use This Best Practice 41.6 Best Practice Procedure 4

1.6.1 Preliminary Tasks 41.6.2 Monitoring Concepts 5

2 Business Process Monitoring for POS Integration Using SAP POS and SAP for Retail 62.1 Business Process: POS Outbound 6

2.1.1 Business process P01: ECC generates the master data IDocs and sends them to PI 62.1.2 Business process P02: PI receives ingoing messages for transmission to the FTS 72.1.3 Business process P03: FTS receives data and transfers to the store server at a scheduled

delivery time 82.1.4 Business process P04: Data is received at the Xpress Server from the FTS and processed for

distribution to the POS terminals 112.1.5 Business process P05: The POS receives configuration information from the server 15

2.2 Business Processes within SAP POS 252.2.1 Store level processes 252.2.2 Monitoring objects for SAP POS within the store 30

2.3 Business Process: POS Inbound 302.3.1 Business Process P01: Transaction completes, POS writes locally and moves data to Xpress

Server 302.3.2 Business process P02: Send data from Xpress Server to CEFT server 302.3.3 Business process P03: Send data from CEFT message server to PI and RA 302.3.4 Business process P04: Send data from FTS to PI and RA via nightly batch 302.3.5 Business process P05: Monitoring returns authorization and SAP POS 302.3.6 Restarting returns authorization 302.3.7 Returns authorization logs 302.3.8 Troubleshooting returns authorization: Understanding POS error messages 302.3.9 System monitoring 302.3.10 Disaster recovery 302.3.11 Monitoring objects for returns authorization 302.3.12 Business process P06: Processing messages in PI and transferring the data to POS DM 302.3.13 Business process P07-P08: Processing POS data with POS DM and SAP for Retail 30

2.4 Appendix A – SAP POS Parameter Files 302.5 Appendix B – SAP POS Apply Files 302.6 Related Best Practice Documents 302.7 Other Related Documents 30

2.7.1 SAP POS 2.1 302.7.2 SAP POS 2.2 30

Index of Figures 30Index of Tables 30



1 Management Summary

1.1 Goal of Using This Best Practice

This Best Practice contains the recommended approach from SAP which uses, whenever possible, the SAPSolution Manager for the Monitoring functionalities. Even if you do not use the SAP Solution Manager, werecommend following the procedures described in this document as much as possible. This will ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.

1.2 Alternative Practices

You can have SAP experts deliver this Best Practice on-site by ordering an SAP Solution ManagementOptimization (SMO) service for SAP Business Process Management (BPM). This service is exclusivelyavailable within SAP’s support engagements, SAP MaxAttention and SAP Safeguarding. If your companycurrently does not have any support engagement with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. If this case, please contact your local SAP Consulting representative.

1.3 Staff and Skills Requirements

To implement this Best Practice, you require the following teams:

Application Management Team

This team creates the ERP Business Process Monitoring concept and consists of experts from several areasof your company: Business department Solution support organization (for example the Basis Support or the Application Support) Implementation project team

Business Process Operations Team

The Business Process Operations team will be responsible for applying the resulting procedures derived fromimplementing this best practice. They include the following groups: Persons designated to perform business process oriented monitoring and ensure that the process runs

smoothly (e.g. the Business Process Champion for each business process) All parties in your Solution Support Organization and IT department involved in monitoring focused on the

application aspects (Application Support, Development Support, Job Scheduling Management)

SAP Technology Operations Team

All parties in your Solution Support Organization and IT department involved in monitoring focused on thesystem administration side (Program Scheduling Management, Software Monitoring Team, SystemAdministration Team including the System Administrator)

Business Process Champion

The Business Process Champion is the person in the business department that is responsible for thesuccessful execution of the business process. He coordinates all activities necessary for the businessprocess. Therefore, he is usually responsible for the escalation paths in case of problems. Often he is asecond level in the escalation procedure, if the application monitoring team needs to escalate an issue.



More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe SAP Service Marketplace, quick link /BPM.

Necessary or Useful Trainings

SM300 Business Process Management and Monitoring E2E300 End-to-end Business Process Integration and Automation Management

1.4 Duration and Timing

DurationCreating a Business Process Monitoring concept could take around one week per business process.

Implementing the Business Process Monitoring concept might take approximately an additional week.

Timing

The best time to apply this Best Practice is during the planning phase or during the implementation phase ofyour SAP solution.

1.5 How to Use This Best Practice

Here you find a brief description of how you should proceed in using this document:

Read through the General Business Process Management Best Practice, available on the SAP ServiceMarketplace. This document explains the procedures you should use to create a general Business ProcessManagement concept. This includes the definition and documentation of the core business processes,definition of monitoring objects, definition of monitoring activities including error handling procedures,monitoring tools and monitoring frequencies, the definition of communication and escalation procedures andthe assignment of responsibilities.

At the beginning of chapter 2 you will find a typical flow chart of the core business process explained in thisBest Practice. It is intended to be used as a guideline for writing down your company specific processdocumentation.

1.6 Best Practice Procedure

1.6.1 Preliminary Tasks

Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in thesystem: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations resulting

from customer problem messages Implement all current SAP Support Packages upon availability



1.6.2 Monitoring Concepts

The monitoring procedures proposed for each business process step are the core of this Best Practice. Themonitoring procedures help you to ensure that the technical processes meet the requirements for stability,performance and completeness. These procedures cover monitoring for the five areas: Error monitoring Performance monitoring Throughput monitoring Backlog monitoring Data Consistency Monitoring

For each of the business process steps you will find the following information: A detailed functional description of the process step Identified monitoring requirements for the process step Defined monitoring objects, alerts and selection criteria Description of error handling procedures and restartability



2 Business Process Monitoring for POS Integration Using SAP POSand SAP for Retail

This document describes the process flows and monitoring requirements and possibilities for SAP POS 2.1and SAP POS 2.2. Deviations in these versions are indicated in the corresponding chapters.

2.1 Business Process: POS Outbound

Figure 1: Outbound process flow

Files sent from ECC such as item files, price changes, promotions, employee files, configuration changes,etc. flow into PI where they are transformed before sending to the File Transfer Server (FTS). Once at theFTS the files are scheduled and sent to the Store Server. The Store Server in turn applies the files to thedatabase and these files then become available to the POS suite of applications. If there are problems withthe outbound flow of information, some symptoms that become apparent in the store may include inability toscan items, incorrect prices or promotions on items, or improper configuration. Monitoring of a variety ofareas is very important to ensuring a smooth flow of data.

2.1.1 Business process P01: ECC generates the master data IDocs and sends them to PI

2.1.1.1 Description

The monitoring processes for ECC is documented in a separate publication “Manage Operations for SAP forRetail – POS Download” available under http://service.sap.com/solutionmanagerbp

http://service.sap.com/solutionmanagerbp



2.1.2 Business process P02: PI receives ingoing messages for transmission to the FTS

2.1.2.1 Description

Once PI has received the ingoing messages, the messages are mapped and transferred to the receivercommunication channel. The following message types (interface names) can be used in this scenario: Assortment lists: Material data (Rel. 99A): (WBBDLD.WBBDLD03, 05) POS interface: Download material group master (WPDWGR.WPDWGR01) POS outbound: bonus buy conditions (WPDBBY.WPDBBY01) Physical inventory (WVINVE.WVINVE03) Download special offer discounts (WPDREB.WPDREB01)

The interface names can be used to restrict to relevant messages in the PI monitors

2.1.2.2 Monitoring requirements

Error monitoring

The status of the PI messages can be can be monitored in transaction SXMB_MONI in the ABAP stack or theRuntime Workbench on Java. Additionally, the file adapter placing the files should be monitored with theruntime workbench. The monitoring is critical as untreated messages or unsuccessful messages will result inmissing data at the registers. In order to automate monitoring of the messages, a message based alertingwith SAP Solution Manager can be set up. Also for the adapter framework alerts can be configured which canthen be integrated in a Solution Manager BPMon. Please see the Interface Monitoring Setup Guide availableunder http://service.sap.com/bpm for details.

Performance monitoring

All messages need to be processed usually in a timely manner in order to update the information in the POSsystem as soon as possible. The message processing runtime can be monitored using SAP SolutionManager.

2.1.2.3 Monitoring objects

MonitoringObject

Selection Criteria Alert Analysis Tool onSatellite System

MonitoringFrequency /DataCollection

Message status Interfaces:

WBBDLD.WBBDLD03, 05

WPDWGR.WPDWGR01

WPDBBY.WPDBBY01

WVINVE.WVINVE03

WPDREB.WPDREB01

Messages inerror

SXMB_MONI in PI orRuntime Workbench

Frequentlyduringprocessing

http://service.sap.com/bpm



MonitoringObject

Selection Criteria Alert Analysis Tool onSatellite System

MonitoringFrequency /DataCollection

File AdapterStatus

File Adapter Adaptershows error

Runtime Workbench -> ComponentMonitoring -> AdapterEngine ->CommunicationChannel Monitoring

Table 1: POS outbound process P02 – Monitoring objects

2.1.3 Business process P03: FTS receives data and transfers to the store server at ascheduled delivery time

2.1.3.1 Description

PI will place files on the FTS in a predefined folder (typically SAP\OUTBOUND). From this folder the FTS willdeploy files to all appropriate store servers (Xpress Server)


E-mail alerts

It is recommended that all nightly scheduled transfer activity be reviewed the following morning to ensuretransfer completeness. The FTS has built-in email alert functionality that allows for instant notification ofdelivery failure to a store.

File transfer (plan) review

On a daily basis the nightly file transfer plans should be reviewed for failures. Plans are scheduled lists oftasks that are executed locally on the FTS or remotely on the store server. Most plans are configured/setupwith failure email alerts so that appropriate support personnel can be notified.

At the file transfer console, the following screen shows recent plan activity and whether or not any errorsoccurred during the processing of a plan.



Figure 2: View recent plan activity



To view details of any plan, note the instance ID from the summary results screen and enter it as searchcriteria under History/Audit Trail.

Figure 3: View details of a plan

2.1.3.3 Monitoring objects for FTS receiving data and sending to store

Monitoring Object Selection Criteria Alert Analysis Toolon SatelliteSystem

Monitoring Frequency /Data Collection

FTS List of recipients aredefined

Emailmessage

Email Alert Automatic alerts whenproblem occurs

FTS Date/Time/PlanName/Status

Reported onconsole

Plan Activity At user’s discretion butrecommended daily

FTS Date/Time/Instanceid/Plan/FileSet/Node

Reported onconsole

Audit Trail forselected plans

At user’s discretion butrecommended daily




2.1.4 Business process P04: Data is received at the Xpress Server from the FTS andprocessed for distribution to the POS terminals

2.1.4.1 Description

The Xpress Server receives a variety of files from external sources via FTS. Information is sent, usually on ascheduled basis, regarding items, pricing and promotions, employees, and merchandise hierarchies.Configuration parameters for new POS functionality are also sent from head office. Responses for credit,debit, gift card and other online authorizations are passed through Transnet (CEFT) to the store server. Whilethe data has been sent from the CEFT server to the store, there are possibilities that the in-store XpressServer or the POS terminals never received it. There are several ways to determine whether or not the datawas received and distributed to the POS terminals.

If the POS has not received the files that it requires or if the files are of an incorrect format, then the POS willnotify the user with an error message that reports which file is wrong. The Xpress Server has the task ofapplying the files to the SQL database and the POS. The success or failure of the apply process on the POSis recorded in the TLOG as a Miscellaneous record as well as in the Server’s Apply log.


TLOG records for monitoring

Whenever files are applied on the server, the summary outcome of the apply is written into the TLOG. Thebinary TLOG files are stored on the rdata/sdata folders of the Xpress Server/POS directories. A utility calledCVTLOG can be used to decrypt the contents.

When an ASCII record fails to convert to binary successfully or when the binary record could not be loadedinto the binary file or into its corresponding SQL table, a TLOG record is added that appears like the samplesbelow. Miscellaneous record type=52 and type=53 (to SQL) are used to record the error. Errors of this typetypically only happen in the first few weeks to the fist few months of implementation or the implementation ofthis file.

Other fields to note in the TLOG for the apply records:

Field Description

MiscType (field 14) 52 (apply app file) or 53 (apply direct to SQL)

Amount Field (field 163) Apply record count

Additional Info (field 23) Apply file name

Start/Stop Flag (field 24) 1 = start

0 = stop

Table 3: Fields to note in the TLOG



Samples of TLOG records showing files that failed to apply (the format and content of a record can be foundin the Technical Reference Guide):

M 00001p5000000000000090210090711004600010002101

M 00001p5000000000000090210090711004600010002101530 00000004 00000000000 VENDOR.ASC00000

M 00001p5000000000000090210090711004700010002101530 00000000 00000000000 LANGUAGE.ASC10000

M 00001p5000000000000090210090711004800010002101530 00000004 00000000000 LANGUAGE.ASC00000

M 00001p5000000000000090210090711004900010002101530 00000000 00000000000 PARMVAL.ASC10000

M 00001p5000000000000090210090711005000010002101530 00000040 00000000000 PARMVAL.ASC00000

M 00001p5000000000000090210090711005100010002101530 00000000 00000000000 PARMFMT.ASC10000

M 00001p5000000000000090210090711005200010002101530 00000042 00000000000 PARMFMT.ASC00000

M 00001p5000000000000090210090711005300010002101520 00000000 00000000000 disctxn.asc10000

M 00001p5000000000000090210090713005400010002101520 00000073 00000000000 disctxn.asc00000

M 00001p5000000000000090210090713005500010002101520 00000000 00000000000 taxtable.asc10000

M 00001p5000000000000090210090713005600010002101520 00000016 00000000000 taxtable.asc00000

M 00001p5000000000000090210090713005700010002101520 00000000 00000000000 postxn.asc10000

M 00001p5000000000000090210090713005800010002101520 00000011 00000000000 postxn.asc00000

Figure 4: Samples of TLOG records

At http://help.sap.com/saphelp_pos21/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm,you can find the SAP POS 2.1 technical reference guide. Go to Technical Product Reference TLOG DataCapture Formats.

Go to http://help.sap.com/saphelp_pos22/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm,for SAP POS 2.2: Technical Product Reference TLOG Data Capture Formats.

Apply log monitoring

The outcome of apply process is also written the apply log (named apply.log) which is located the programfolder of the Xpress Server (…\Xpress Server\ ) and register (..\Point of Sale\ )

The format of the apply logs is as follows:

Field Name Position Description Values

Time Stamp 1 - 16 This field will indicate the date and time therecord has failed to apply.

Example:

Aug 18 15:18:48:

File Name 17 – 31 This field will contain the name of thedownload file that has generated an error.

plutxn.asc, xreftxn.asc,suppattr.asc, suppdata.asc

Key Word 33 – 42 This field will contain the word“FAULTLINE#”. This will indicate that thecurrent LOG line contains detailed logginginformation.

FAULTLINE#

http://help.sap.com/saphelp_pos21/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm




Field Name Position Description Values

Line Number 44 – 52 This field will contain the actual linenumber (within the apply file) that hasfailed to apply.

1 to 999999999

Action Code 54 – 55 This field will contain the Action Code“Add/Modify/Delete” that has failed.

1, 2, 3, 99

PLU Number 57 – 76 This field will contain the PLU number (ifpresent in the download file record andreadable by Xpress Server)

PLU Number – If Present (or)

Blank

Line Data 78 – 137 This field will contain the first 60 charactersof the download file line that has failed toapply

Table 4: Format of apply logs

A record is added to the apply logs when an ASCII record fails to convert to binary successfully or when thebinary record could not be loaded into the binary file or into SQL tables. The same limit used for logging theseerrors to the TLOG is used here.

Records are added when parameter files are copied to POS.

Summary:

Xpress Server’s apply (log) messages are written to the Server’s APPLY.LOG file Backup Server’s apply (log) messages are written to the Backup Server’s APPLY.LOG file. Backup server

applies will not show in the primary server’s log file Log messages generated at the registers are written to the Server’s APPLY.LOG

Example of an apply log with POS apply messages included:

Mar 24 09:58:21:plutxn.asc 27928 bytes 129 records applied on ServerMar 24 09:59:52:plutxn.asc 27961 bytes 129 records applied on ServerMar 24 10:45:54:plutxn.asc 27728 bytes 128 records applied on ServerMar 24 11:19:28:plutxn.asc 27728 bytes 128 records applied on ServerMar 24 11:36:00:plutxn.asc 27524 bytes 127 records applied on ServerMar 24 11:54:01:plutxn.asc 27525 bytes 127 records applied on ServerMar 24 14:50:37:plutxn.asc 370 bytes 5 records applied on Reg# 1Mar 24 14:50:37:plutxn.asc 370 bytes 5 records applied on Reg# 1Mar 24 14:50:37:plutxn.asc 69 bytes 2 records applied on Reg# 1Mar 24 14:50:37:postxn.asc 148 bytes 11 records applied on Reg# 1Mar 24 14:50:37:negtxn.asc 117 bytes 8 records applied on Reg# 1Mar 24 14:50:37:dept.asc 5363 bytes 33 records applied on Reg# 1Mar 24 14:50:37:group.asc 291 bytes 14 records applied on Reg# 1Mar 24 14:50:37:category.asc 110 bytes 6 records applied on Reg# 1Mar 24 14:50:37:mixmatch.asc 1770 bytes 11 records applied on Reg# 1Mar 24 14:50:37:taxtable.asc 2956 bytes 16 records applied on Reg# 1Mar 24 14:50:37:rcptlogo.asc 170 bytes 1 records applied on Reg# 1Mar 24 14:50:37:custdisp.asc 159 bytes 1 records applied on Reg# 1Mar 24 14:50:37:coupon.asc 4272 bytes 96 records applied on Reg# 1Mar 24 14:51:42:plutxn.asc 27933 bytes 129 records applied on Reg# 1Mar 24 14:51:42:plutxn.asc 208 bytes 1 records applied on Reg# 1Mar 24 14:51:42:plutxn.asc 207 bytes 1 records applied on Reg# 1Mar 24 14:51:42:promotxn.asc 97 bytes 1 records applied on Reg# 1



Mar 24 14:51:42:promotxn.asc 97 bytes 1 records applied on Reg# 1Mar 24 14:51:42:promotxn.asc 97 bytes 1 records applied on Reg# 1Mar 24 14:51:42:postxn.asc 148 bytes 11 records applied on Reg# 1Mar 24 14:51:42:negtxn.asc 117 bytes 8 records applied on Reg# 1Mar 24 14:51:43:dept.asc 5363 bytes 33 records applied on Reg# 1Mar 24 14:51:43:group.asc 291 bytes 14 records applied on Reg# 1Mar 24 14:51:43:category.asc 110 bytes 6 records applied on Reg# 1Mar 24 14:51:43:mixmatch.asc 1770 bytes 11 records applied on Reg# 1Mar 24 14:51:43:taxtable.asc 2956 bytes 16 records applied on Reg# 1Mar 24 14:51:43:rcptlogo.asc 170 bytes 1 records applied on Reg# 1Mar 24 14:51:43:custdisp.asc 159 bytes 1 records applied on Reg# 1Mar 25 13:31:44:plutxn.asc 27933 bytes 129 records applied on ServerMar 25 13:31:44:plutxn2.asc 1629 bytes 0 records applied on ServerMar 25 13:31:46:xreftxn.asc 2858 bytes 73 records applied on ServerMar 25 13:31:46:mixmatch.asc 1770 bytes 11 records applied on ServerMar 25 13:31:50:pricetxn.asc 695 bytes 11 records applied on ServerMar 25 13:31:51:linktxn.asc 253 bytes 4 records applied on ServerMar 25 13:31:52:category.asc 86 bytes 6 records applied on ServerMar 25 13:31:52:group.asc 235 bytes 14 records applied on ServerMar 26 15:27:16:plutxn.asc FAULTLINE# 3 2 06224012,0622401,,4445,GINGER ALE IS THE GREATEST, DRINK ON THE PMar 26 15:27:16:plutxn.asc 27994 bytes 128 records applied on Server

Figure 5: Example of an apply log

Note that the “RECORD:“ lines above will actually be on the same line as the “FAIL” line above it. They onlyappear here on a separate line to make the example more readable.

An apply file is and ASCII TEXT document that is comma delimited. Each line is a record. Each Record isterminated by a Carriage Return or a Carriage Return and line Feed. Either is acceptable.

Being a comma-delimited file, the most prevalent reasons that apply problems occur is that the files do notmatch the required format for that file. For example, commas in a description field or incorrect usage ofquotes meaning that a quote is opened but not closed. Once corrected and the file needs to be re-sent to thestore, the apply should work. All ASCII Fields should be protected with a double quote. For example a pludescription that contains a comma will be separated into two fields and throw all the remaining field in thatrecord off. Also because of this you cannot use the double quote to denote inches. If a double quote isopened and not closed the POS Suite cannot know where the description ends. Some choose to put indouble quotes. Others filter the text to only allow a-z and A-Z and 1-9.

To address this problem in the short term open the file in a text editor and examine the format closely. Findthe issue(s) and fix it. Long term solution involves fixing the system that generates the apply files in the firstplace.



2.1.4.3 Monitoring objects for Xpress Server receiving data and distributing to POS registers



Xpress Server /Backup Server

Store number,terminal number,date, time

Miscellaneous records oftype 52 and53

TLOG Daily

Xpress Server /Backup Server

Store number,terminal number,date, time

FAULTLINE# Apply.log Daily or as required byerror situation at POS

POS Registers File name andrecord length

Errormessage ondisplay

Call First LevelSupport

Situational


2.1.5 Business process P05: The POS receives configuration information from the server

2.1.5.1 Description

The Xpress Server sends information to the registers as they need it. For example, if new parameters havebeen sent from head office, they may need to be applied immediately at the registers to affect the POSfunctionality (menu options, screen display, receipt printer behavior). Once a “newparm.trg” file exists in the…\Parm folder, the parameters get applied.

The server also sends the business date for the store. The registers need to synch up with the server for thedate to be common across all registers.

The POS sends requests to the Server for example PLU lookups and EFT requests. The server receivesthese requests and either looks up the information locally (for requests like PLU) remotely for EFT.

Overall, if the back office database is not running, then the Store Manager applications will not work. ThePOS will continue to function but resort to Department Entry.


Determine if the Xpress Server application is running

The Xpress Server application and its activity are monitored via the Xpress Server Console. At the bottom ofthe Console there is a connection box that shows the number of registers currently connected.

The User can see if the server application is running or not using this Console. If not, the application can berestarted at the Console by pressing the <Start Server> button. If the server application does not start usingthis function, the User should contact the appropriate help desk support services to investigate the failure.

If the Server is not running properly, there are usually errors reported in the log window (xps.log). This logfile is a low level log file for the Xpress Server application. It is found in Xpress Server\xps.log. This is a



programming log file for activity at the Xpress Server. This log file is what is seen in the log window of theXpress Server Console. Any errors that occur at the Server would be reported here.

The <LSN REPORT> and <STATUS REPORT> buttons on the Console can be used to identify technicalproblems. LSN Report shows all underlying connections from application clients. Status Report shows therunning detail of store like Business Date, License Information, Database status, Store Status (Open/Closed),Registers connected.

Exception and event logs to assist in diagnosing problems in the POS application are found in the followinglocations: 1) Point of Sale\xcpt.log and event.log 2)Xpress Server\xcpt.log and event.log

Troubleshooting using SAP POS logs

Log File Name Log File Location Description of Contents

Xps.log C:\Program Files\SAP\RetailSystems\Xpress Server

Contains Xpress Server specific details. Informationsuch as EFT connectivity status/details, databaseconnectivity are written to this file.

Crsrv.log C:\Program Files\SAP\RetailSystems\Xpress Server

Contains EFT specific information.

Xcpt.log C:\Program Files\SAP\RetailSystems\Xpress Server

Contains software exceptions that are caught andlogged by Xpress Server.

Apply.log C:\Program Files\SAP\RetailSystems\Xpress Server

Contains information concerning ASCII download fileapplies.

Table 6: Troubleshooting using SAP POS logs

If the primary server is offline and the system is configured to use a backup server, that Backup Server isdesigned to perform these three mission critical functions only: Price Lookup Backup connection for Credit Authorization Data Redundancy of Tlogs and Journal file

The backup server is not a redundant backup system and the store cannot be Opened or Closed while theStore Server is offline. Registers concurrently trickle their completed transactions to the backup server andthe primary server. In the event of failure of the primary server and sales data is required by some hostsystem (before repairs to the primary server can be completed) the backup server can be polled to retrievethe required data.



Remote monitoring of Xpress Server

The Xpress Server can be remotely monitored through scripting of TELNET functionality. The Xpress Server,if running, will answer across port 2202 when accessed via TELNET. Commands available are: MONXPS [ON|OFF] SHOWTERM|TERMINAL-STATUS] [ALL|Term#] MONTERM|MONITOR-TERMINAL] [ALL|XPS|Term#] [START|STOP|ON|OFF] OPEN-TERMINAL [ALL|Term#]

OPEN-STORE [TODAY|NumberOfSecsSinceJan1-1970]CLOSE-TERMINAL [ALL|Term#] [FORCE|NO-FORCE|ABORT]

CREDIT-LOGGING [ON|OFF]

You can monitor the receipt window of the POS from Store Manager as well. Open the store Manager and login. Then Select the “Administration” Icon from the main menu. Then select the Store Administration iconfrom the Administration window. You will see the following window:

Figure 6: Store administration

Select the checkbox of the register that you would like to monitor then select the Monitor Terminals button.The following will appear:



Figure 7: Monitor terminals

As the cashier rings in items you will see what ever appears on the receipt window of the POS. Click exitwhen you are done monitoring.

For reasons of support or training it is recommended that some form of remote software be installed on theXpress Server and POS Terminals. Packages include Windows Remote Desktop, PC Anywhere, Net Viewer,VNC, Or whatever package your company deems fit.

Determine server problems from store manager application

The Store Manager application can identify potential problems with the Xpress Server.

Once launched, at the bottom of the application screen, there are two status flags: Database Connected andServer Connected. If the indicator light is green for both, the connections are fine; if one or both lights are red,connection(s) have failed. If the server connection indicator is red, it is possible that the Xpress Server has stopped

and been restarted. If the Xpress Server was restarted, then the Store Manager application has become detached

from the Server. The following screenshot illustrates a where to re-attach the connection between the Server andthe Store Manager:



Figure 8: Re-attach the connection between the server and the Store Manager

Once the Store Manager application is attached to the server, the Connected checkbox is selected and theversion information is displayed as seen in the screenshot below:



Figure 9: Server connection

Some log files are viewable from the Store Manager application. These include the Apply.log which is the logfile for base parameter applies, as well as the xcpt.log and the event.log. To access these go to Main Menu-> Administration Menu -> Log File.

Viewing log files from the Store Manager application

You can view and search through the contents of three log files. Log files allow stores to view and act upondownloaded files during the polling process. xcpt.log -This log file contains information on errors or general exceptions that have occurred within the

application. It is mainly intended for debugging purposes. event.log - This log file is also intended mainly for debugging purposes. It contains information on various

events occurring within the application or between the application and the server. apply.log -The apply file log contains operational information from files such as the PLU, xref, and promo

files. It also logs information which you can view on purchase orders, receiving documents, inventoryadjustments, physical inventory and store transfers. See Appendix B for a list of the apply files and theirdescriptions.

To view the contents of a log file: On the Main Menu, click Administration. Click Log Files. Click the Log File drop-down list. A list of the three log files appears. Click a file. The contents of the log file appear in the window. Once you have opened a log file, you can

search through its contents for a text string.



To search a log file: In the Search field, type a text string. Click <Go>. Store Manager searches through the log file for a match. When all the matching information is

found, the first piece of it is displayed in the window. If available, to display the next piece of matching information, click <Next>.

Store Manager includes two windows that provide you with information for troubleshooting your POS system.They are: Server State Information window Server Message Log window

Note: You cannot edit the information in these windows.

To open the Server State Information window: On the Main Menu, click Server State. The Server State Information window displays the Store Information and the Server Connection

information.

To open the Server Log window: On the Server State Information window, click Setup Log. You can view and/or save the log. Click the View Log check box to display the Server Log window. Click the Save Log check box to save the log file. Click OK.

Viewing Configurator parameters from the Store Manager application

Head office uses the Configurator to tailor the POS Xpress application to meet specific requirements and todownload changes to the server in the stores. The information that head office downloads to a store is storedas records in tables. It is used by both the Store Manager and the POS Xpress. The Store Managerapplication can be used to add information to tables at the store level.

Although the Store Manager is a store level management tool and the Configurator is a head office tool, theycan both add or modify the information in some common tables. Since there is no notice to Head Office ofchanges that were made to the common tables using the Store Manager, it is very important that Head Officeclearly define the areas for which the store is responsible. To avoid entering conflicting information, the storeor Head Office should update the information in each table. Access to various Store Manager functions canbe restricted through User Authority Levels.

Both, the Store Manager and the Configurator can update the following tables: Employee Category Group Department Tare weight ID/Code Vendor Store User flag PLU



PLU cross reference Quantity and level pricing Link items Promotion Taxes

Head Office must download three sets of parameters so that the Store Manager can function properly: Register parameters Tender parameters Layaway parameters

For information about downloading information from the Configurator, refer to the Store Configurator UserGuide.

Use http://help.sap.com/saphelp_pos21/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htmfor SAP POS 2.1 and go to Head Office Functions Store Configurator

Use http://help.sap.com/saphelp_pos22/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htmFor SAP POS 2.2.

You can view information about the status of the three mandatory sets of parameters in the ConfiguratorParameters window. This window also displays information about other parameters that are downloaded fromthe Configurator. You cannot edit the information in the window.

To access the Configurator Parameters window: On the Main Menu, click Parameters Setup. The Parameters Setup Menu window appears. Click Configurator Parameters. The Configurator Parameters window appears.

Additional tip

To help determine what files have been recently changed, check the date and time of the files within theParm directory on the Server or on the POS. Sort by date and the most recent files will appear at the top orbottom of the list.

Paths for the Parm folders, presuming a default installation: …\Program Files\SAP\Retail Systems\Xpress Server\Parm …\Program Files\SAP\Retail Systems\Point of Sale\Parm

PARMDUMP utility

This utility converts PARM files into ASCII so that the configuration settings can be viewed as they were set inthe Configurator application. This utility is handy when trying to determine if the correct parameter set wasdownloaded or applied. The PARMDUMP utility can be run from the Server and from the POS directories: C:\Program Files\SAP\Retail Systems\Xpress Server C:\Program Files\SAP\Retail Systems\Point of Sale

Usage: parmdump [flags] parmfile

Example: parmdump regparm.reg





Where parmfile is one or more of the following parameter files: license.lic regparm.reg ptdparm.lwp custparm.cdp

rcptlogo.rcp custdisp.cus ndc.ndc employee.emp chkdgt.cdv choice.lst coupon.cpn discount.dsc firstten.ftn license.srv menus.mnu mgrcode.mgr modem.mdm modemcfg.cmd nabanco.nab nonmerch.non policy.pol profile.inq prtlines.lpr regreprt.rrt remtecom.rcm tarewght.tar taxtable.tax tender.tdr udtxn.udt dept.dpt rndrules.rnd custmenu.cmn

See Appendix A – SAP POS Parameter Files for a list of parameter files and their descriptions.

Flags Explanation

-D directory Specifies a parameter directory other than \parm

-L LogFile Retains output in a log file

-A Dumps all parm files

-P[n] Pauses every ‘n’ lines

-U Suppress parm file header

Table 7: Flags



Once it is determined that incorrect parameters or incorrect files were sent, then corrections to the files mustbe made and then resent to the store or stores.

2.1.5.3 Monitoring objects for POS receiving data and applying it



POS Registers N/A Errormessage orunexpectedbehavior oftheapplication

Call First LevelSupport

Situational

Xpress Server -Xps.log

C:\ProgramFiles\SAP\RetailSystems\XpressServer - Mostrecent log

Store issueon POS

Store Supportcalls SAPSupport

Store Support shouldcapture log as soon asproblem is identified

Xpress Server / StoreManager Application:Crsrv.log


Store issueon POS



Xpress Server / StoreManager Application -Xcpt.log


Store issueon POS



Xpress Server / StoreManager Application -Apply.log


Store issueon POS






2.2 Business Processes within SAP POS

Figure 10: POS in-store process flow

This chart shows the flow of data from stores to The Head Office. From the registers Transaction logs andJournal files trickle as transactions are finalized. The Server will then post the tlogs in the database forreporting purposes. As well the tlogs are made available to CEFT to trickle them to the Head Office wherethey are in turn posted through RI to the SAP for Retail product suit. Files can also be pulled from the XpressServer for nightly processing as well.

Also EFT (Credit, Gift Card, etc) transactions flow from the POS to the Xpress Server then onto CEFT forprocessing.

2.2.1 Store level processes

After having imported the master data from SAP for Retail, the data can be used within the SAP POSsolution.

2.2.1.1 Description

While there are many issues related to the transmission of data in and out of the store, there are also issuesthat can occur during the day-to-day operations of the store that can affect the completeness or quality of thedata used and produced at POS.



At the in-store level, the following common processes can be carried out: Regular Sales Consumer Specific Sales Tendering Cash Management Reporting on in-store activities

It is vital that all these processes can be carried out at all times during the business day.

When problems occur in an environment that is running SAP POS, which has numerous interconnectedapplications, it is important to start looking at the issue in a holistic way. It helps to try to identify whetheranything has changed on the system. Have there been any parm (parameter file) changes? Are all of the services that should be running actually running? When the system booted, were any error

messages received? Has the operating system been changed in any way (system updates, antivirus updates, etc.)? Has the application’s installation been changed in any way (patches, etc.)?

Once the general area of the problem has been identified, for example no connectivity to a register, start withthe basics. Is the network cable connected to the register? Is the register correctly defined in Manager Code 6? Can the register be pinged from the Xpress Server system?

If able to be connected to the system that is experiencing the problem, operating system tools that may be ofuse include: Task Manager – Accessed by pressing Ctrl+Shift+Esc, or by right-clicking on the taskbar. Shows what

processes are running on the system, provides ability to monitor the current performance of the system. Event Viewer – Accessed by navigating to Start>Run>eventvwr. Provides view of the operating system

event logs. Services – Accessed by navigating to Start>Run>services.msc. Provides view of the services that are

currently installed on a system, and their current status. Usage of the command prompt can also be helpful to investigate issues. The ping command when used

with the –t flag (continuous) can be used to identify latency on the network: ping <IP Address> -t The netstat command can be used to identify the systems current TCP/IP connections. Running the

command: netstat –anp tcp 5 will display only the current TCP/IP connections and will refresh the listevery 5 seconds. This is helpful in working with issues involving network connectivity between twosystems.


There are a few critical areas within the store where specific troubleshooting techniques are applied toalleviate performance issues. These issues include: credit offline, problems with encryption, database issues,and synchronization of the applications. As well, there is a tool called AppSight that can assist in monitoringand troubleshooting problems with the POS applications



2.2.1.2.1 Credit offline issues

Assuming that the pinpads or signature capture devices are connected and functional, there are severalreasons why credit or debit may fail to authorize. The cashier is notified through the POS if the Credit Serviceis offline and may be asked to perform the authentication manually based on the Configuration. The store’s network may be failing. Follow normal procedures for checking the status of the store’s

network. Store may not be able to reach the CEFT Server. A required service may not be running or may need to be restarted due to an earlier communication issue.

See below for steps to restart the services. There may be a credit.saf preventing further credit or debit processing. See below for steps to

troubleshoot a credit.saf file.

Stopping and Restarting Credit Services:

If you are able to connect to a store that cannot process debit or credit transactions, try to ping the serviceprovider (e.g. CEFT Message Server) from a command prompt. If the service provider CEFT Server can bepinged, try stopping and restarting the following Services in the sequence below: Shutting down –

- Express Server application- Transnet- NTM Java Client- NFM Client Service

Restarting:- NFM Client Service- NTM Java Client- Xpress Server application- Transnet

Note: The TPS Java Command Service is not required to be running or even present at store level.

Credit.SAF

If a current credit.saf file is present in the “Xpress Server\sdata” folder, the contents should be viewed shortlyafter restarting credit services and the Xpress Server, to confirm that the records were processed.SAFUTIL.exe is the utility to view the contents of the file. The Xpress Server must be in a stopped statebefore using the SAFUTIL. In some cases, a Return with Receipt via Returns Authorization will fail to processif a credit.saf is present.

When running SAFUTIL, the following flags are available for use:

Usage safutil [flags] SAF Filename

FlagsV: To view the contents of SAF fileD YYMMDD: Process up to and including records with date ‘YYMMDD’L LogFile: To retain output in a log fileP[n]: To pause every ‘n’ linesR start end: Start processing from ‘start’ record to ‘end’ record



S OnOff: To set processed flag 1=On, 0=Off (-S 1 or – S 0)X ExportFile: To export SAF records to a comma delimited fileI ImportFile: To import comma delimited file to SAF fileC CreditService: Import SAF records for this Credit Service Number

Notes: The following special keys are available when the display is paused: q – quit program c – switch to continuous output

Returns error levels: =0 if no warnings >0 if any warning

Keep in mind the utility can be both Retailer and / or Software Build specific, so care must be taken to use thecorrect version of this utility.

When looking at the credit.saf, it can be seen which records failed to process, at what time and on whichregister. Until those records are processed, the transactions which follow will also fail to process as will anynew credit / debit transactions from this register. The data in the records may be corrupt or missinginformation such as the credit card number and will be marked as “Unprocessed”.

The records in question then need to be processed, albeit as “Declined.” Since declined is a valid message,these records will now be ignored by the system and any remaining records will be available to be processed.From the command prompt, type the following: Safutil –r x y – s1 credit saf

*where x = the first record and y = the last record.

This will mark records x and y as “Declined.” The credit.saf can then be placed back in the sdata folder andthe Xpress Server can be restarted.

Note: the timeliness of correcting the credit.saf is critical since the consumer may be double charged or notcharged at all for their transaction. Processing should typically occur within two days of the event.

If the export flag is used, the contents of credit.saf are put in a comma delimited file and a program such asExcel can be used to easily edit / repair it. The resulting file can be imported back into a new credit.saf file.

Troubleshooting Credit.saf issues

The flow chart below describes typical decision patterns for troubleshooting issues with credit connectivityand credit.saf..



Figure 11: Typical decision patterns for troubleshooting

Logs to help diagnose integrated credit issues

The suppport should check the credit log files at store and at CEFT server. These are low level log files thatlog credit transactions to an external service: 1) Point of Sale\crsrv.log (Register PC) 2) Xpress Server\crsrv.log (POS Server PC) 3) Transnet\Logs\log.txt (CEFT Server PC)

The purpose of these log files is to log credit, debit and some transnet messages for debug purposes. Creditor Transnet communication errors would be reported here.

2.2.1.2.2 Encryption issues

In SAP POS, any sensitive information such as customer information, passwords, credit card relatedinformation can be encrypted. Data inside the database, binary files, log files and receipts are eitherencrypted or masked. If a key or key container for encryption becomes corrupt, then the POS will not be ableto read encrypted data from the Xpress Server and the Xpress Server will not be able to read encrypted datafrom the database or binary files locally on its hard disk. Errors will appear in the xps.log on the XpressServer.

One of three error messages will be logged in the xps.log:



1) Encryption not enabled. IE: Encryption key is not defined in Configurator

“WARNING: ### ENCRYPTION IS DISABLED (EMPTY KEY TOKEN) ###”

Encryption is disabled as there is no configuration file to tell the application which key to use. To fix this senddown the correct configuration file.

2) Encryption token key configured through Configurator could not be found.

"ERROR: ### ENCRYPTION KEY TOKEN IS NOT FOUND (Key token: <encryption key token>)###”

This error is displayed when the configured key is not present in the Key container. Perhaps the key is corruptas well. To fix this either send down a different key from the configurator or add the correct key into the keycontainer.

3) Encryption token enabled as configured through Configurator

“Multi-Key Encryption Enabled (Key token: <encryption key token>)”

This is a confirmation that encryption is enabled and functioning.

On the POS register, the following message will be displayed if the configured encryption token is not found:

“ENCRYPTION KEY TOKEN IS NOT FOUND”

This is a signal to the cashier that he/she should reach out to their help desk. Encryption is not working on thatregister.

For a full overview of the security related processes see the “Security Guide - SAP Transactionware GM xx.x”.

The Security Guide (TGM 10.1) for SAP POS 2.1 is available at https://websmp107.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000401180 Industry Security Guides SAPTransactionware GM: Security Guide

For SAP POS 2.2, go to Components at https://websmp107.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000708894&_SCENARIO=01100035870000000202& andchoose SAP Transactionware GM

There are four areas for encryption issues Compromised Key, Compromised Container/keystore, CorruptKey, Corrupt Container/Keystore.

Compromised secret key

A secret key may be deemed compromised if the unencrypted key is displayed or exported by any operator,the encrypted secret key is accessed by an unauthorized operator, or personal information is known to havebeen used for unauthorized purposes. If a secret key is compromised, the sensitive data that has beenencrypted by the compromised key must be re-encrypted using a new key. Process for replacing acompromised key and re-encryption of existing data is described in detail in the “Security Guide – SAPTransactionware GM xx.x” located on the Support Portal. The POS suite has no way of knowing when a Keyhas been compromised. There is no Error Message possible. Example situations where a key may beconsidered to be compromised are: An entire register is stolen from a store. An image of a register is taken

https://websmp107.sap-/




One of the Trusted Key Password holders has left the company Any security related issue related to a store or that store

Compromised container/keystore

A container/keystore may be deemed compromised if the unencrypted keys are displayed or exported by anyoperator, the container/keystore is accessed by an unauthorized operator, or personal information is known tohave been used for unauthorized purposes. If a container/keystore is compromised, the sensitive data thathas been encrypted by the keys in the container/keystore must be re-encrypted using a new key. Process forreplacing a compromised container/keystore and re-encryption of existing data is described in detail in the“Security Guide – SAP Transactionware GM xx.x” located on the Support Portal. The POS suite has no wayof knowing when a Key Container has been compromised. There is no Error Message possible. Examplesituations where a key may be considered to be compromised are: An entire register is stolen from a store. An image of a register is taken One of the Trusted Key Password holders has left the company Any security related issue related to a store or that store

Corrupt key

It is possible that a secret key will become corrupt. If this occurs, then the secret key will not be accessible.This will prevent an application from encrypting new sensitive information or decrypting any data that haspreviously been encrypted. The offending key must be deleted and new key activated for use. Process forreplacing a corrupt secret key is described in detail in the “Security Guide – SAP Transactionware GM xx.x”located on the Support Portal.

Corrupt container/keystore

It is possible that a key store (or key container) will become corrupt. If this occurs, then the secret keys willnot be accessible. This will prevent an application from encrypting new sensitive information or decryptingany data that has previously been encrypted. The container/keystore must be deleted and new keys addedfor use. Process for replacing a corrupt container/keystore is described in detail in the “Security Guide – SAPTransactionware GM xx.x” located on the support portal.

2.2.1.2.3 Database problems

If the POS registers or Xpress Server has become slow at retrieving data, scanning an item does not retrievea price or reports that are run at Store Manager or POS are incorrect, the cause may be due to problemswithin the backoff.db. The backoff.db is the database that holds all of the data flow that occurs.

Error messages regarding database problems are reported at the Xpress Server console and in the xps.logare similar to the following:

“SQL ERROR in parameter @adt_datetime of statement BOSDB_INSERT_TXN_HEADER, Can't convert0xfe000003 to timestamp”

Such errors need to be usually need to be investigated by SAP Support.



Troubleshooting SAP POS using MS SQL Utilities (MS SQL 2005)

These are general MS SQL trouble shooting procedures. If a store database is having troubles follow thesesteps before calling SAP support. Scenario 1: Investigate the contents of a particular database. To view data within Xpress Server’s backoff

database:- Navigate to Start>Programs>Microsoft SQL Server 2005>SQL Server Management Studio- Log in using the administrator password- On the left-hand side pane, expand Databases- Expand the database name of the one to be viewed- Expand Tables- Right-click on the table name and select ‘Open Table’

Scenario 2: Bad data integrity of databases is sometimes the cause of incorrect reports, slow dataretrieval to the Xpress Server/POS terminals. Validate the database structure is correct using DBCC:- In SQL Server Management Studio, select ‘New Query’- In the Query Window, type ‘dbcc checkdb’, and click on Query>Execute- Once the query is complete, the bottom pane of the window will display the information as it relates to

the check- The eodproc process can be set up to run a database check, trap errors from the process and use the

FTS to send an email alert to appropriate support staff Scenario 3: Determine what is occurring to the database when certain actions are being performed.

- Navigate to Start>Programs>Microsoft SQL Server 2005>Performance Tools>SQL Server Profiler- Navigate to File>New Trace- Log into Profiler using the database’s ‘sa’ password- Click on Run- Perform the action that is to be traced- Once complete, stop or pause the trace, or save the trace as a file.

2.2.1.2.4 Stopping and starting the applications

Stopping and restarting a single application such as POS may resolve a problem such as slow performance.However, if stopping and restarting a single application that is experiencing problems does not resolve thatapplication’s issue, then stopping and restarting all applications can be tried to resolve the problem. Whenthis approach is selected, the sequence in which stopping and restarting occurs must be followed so thateach application in the suite reconnects correctly with other related applications. Note that it is rare that allPOS registers would need to be shut down at the same time.

Assuming all applications are running, following is the sequence in which they should be stopped. Therestarting of the applications would occur in the reverse order indicated below.

In-store applications

Sequence Application Description

1 SAP Store ManagerApplication

The Store Manager application runs after the back office databaseand Xpress Server application are running.

This application will not run if the database is not running. Several



functions will not run if the Xpress Server is not running. If the XpressServer is stopped while this application is still running, thisapplication can be re-connected using the Main Menu/ServerState/Attach function. Otherwise, this application needs to bestopped and restarted.

2 SAP POS Client POS can be stopped by running Manager Code 499 – Exit POS.

Each register can be restarted at any time.

The register uses the Xpress Server to provide information. The POScannot receive information from the Xpress Server unless the XpressServer is running. POS can be restarted using the desktop icon or byusing the Start menu.

3 SAP Xpress Server The server is normally configured as a Windows service and can bestopped or started automatically or by using administrative tools forWindows. The Xpress Server application can also be stopped byusing the Xpress Server Console application as well as subsequentlybe re-started in the same way. The Console application can be runfrom the desktop or from the Windows start menu. Closing theConsole application does not stop the Xpress Server from running.

Although this application is generally run before the registerapplication, it does not have to be.

4 Back Office Database The back office database can either be Sybase or Microsoft SQL.Standard database processes apply.

The back office database must be running for Xpress Server or StoreManager application to work.

Table 9: In-store applications

2.2.1.2.5 Monitoring and troubleshooting the applications via AppSight

Since version 2.2, SAP POS setup includes AppSight Service Black Box optional installation.

AppSight is a third party monitoring tool used to troubleshoot generic Windows applications.

How AppSight works

AppSight has two main parts. The first one monitors all or particular applications running on a PC, recordingall the details into a log file (*.asl), including screen shots, user input, program stack and other technicalinformation which usually helps to pin down a problem. You can install the recording part either as a regularapplication or as a service. To make the recording efficient and capture only required application(s) activity,special recording profiles are used (*.rpr).

The second part is a playback application which allows developers to playback the log file offline from the livesystem and see all the details, internal variables and state of the program right before the critical error. Inaddition to the log file debug files like *.pdb and *.map are usually required to obtain detailed information onan application’s internals. AppSight playback application requires additional license but is typically used onlyby SAP Support team.



AppSight installation along with SAP POS

SAP POS suite installs only AppSight Service Black Box – an AppSight Windows service which does notrequire additional license. Its installation can be found on the SAP POS setup CD. Once installed, the serviceis configured to be launched manually which ensures that it won't be running all the time degrading systemperformance or bringing unnecessary overhead that is not immediately required. SAP POS also installsrecording profiles and helper batch files used for starting and stopping the service.

For more information on AppSight Service Black Box installation along with SAP POS, seehttp://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000720437&_SCENARIO=01100035870000000202& for the SAP POS Installation Guide for SAP POS 2.1 and https://websmp107.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000708894&_SCENARIO=01100035870000000202& forSAP POS 2.2. Go to Components, choose SAP Transactionware GM.

AppSight Typical Use Case Scenario

The following scenario illustrates how AppSight may be used to troubleshoot a problem: The SAP POS application is installed on a target PC along with AppSight Service Black Box. The

application is used on a daily basis while the service is stopped by default. At some point a user notices a critical error in the application performing a particular operation, and

contacts the SAP support team. The support team uses the appropriate batch file to start the service with the corresponding recording

profile. The support team advises the user to reproduce the issue or to continue normal operation until the error

occurs again. When the problem occurs again, the user contacts the support team. The support team stops the service using the batch file SAP provides, and collects the recording log file

for further investigation along with additional binary and debug files of the application in question. The SAP customer representative uses the SAP SAPmats service to transfer any large log files.

Starting and Stopping of the AppSight service

Along with each SAP POS application installed, there is a shared component installed which includes SAPPOS specific recording profiles as well as start and stop batch files.

AppSight SAP POS specific files are installed to a fixed location: %ProgramFiles%\SAP\RetailSystems\AppSight.

There are subfolders:Bin – contains StartAppSight*** batch files and util subfolder.Logs – recording log files folder; where *.asl files are kept.RPR – AppSight profiles folder with *.rpr files

We do not recommend starting AppSight Service Black Box directly from Control Panel. Instead, use thebatch files from the Bin folder. This ensures that the service is started with the appropriate recording profileand the log file named appropriately is stored in the Log folder so it can be easily located. The Bin folderlocation is added to the PATH environment variable so the batch files can be called from any location(including Run... box and command line windows).

The SAP support representative may advise on what batch file to use for each particular case.

http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000720437&_SCENARIO=0110003587000




Use the StopAppSight batch file to stop the service and finalize the recording. (Batch files can be started byname with or without specifying the .bat extension).

The following table provides information on the batch files for AppSight.

Batch file name Profile used and Applicationsmonitored

Created Log file prefix

StartAppSight_POSGeneric POSGeneric.rpr

bkoff.exe journal.exe posw.exe xps.exe

POSGeneric

StartAppSight_POSStoreAdministration POSStoreAdministration.rpr

bkoff.exe journal.exe xpsctrl.exe

POSStoreAdministration

StartAppSight_POSStoreConfigurator POSStoreConfigurator.rpr

poscfgw.exe

POSStoreConfigurator

StartAppSight_POSStoreOperations POSStoreOperations.rpr

transnet.exe xps.exe

POSStoreOperations

StartAppSight_POSTerminal POSTerminal.rpr

alg.exe posw.exe TrvLPoints.exe

POSTerminal

StopAppSight - just stops the service

Table 10: Batch files for AppSight

Log files naming convention

Recording *.rpr log files are named as follows: <ProfilePrefix>_<computername>_<date>_<time>_SEQ<sequencenumber>.asl

where: <ProfilePrefix> - is a prefix defined by profile used (see table above) <computername> - PC name the service is running on <date> - service launch date in format DDMMYY <time> - service launch time in format HHMMSS <sequencenumber> - is a number of the log file in the rotation sequence.

Important: There is a mechanism to rotate log files. A maximum of 10 files are kept in a shared sequenceproduced from all profiles. A recording log file is overwritten once it becomes the 11th in the sequence of logfiles created on a given PC. If you need to keep previous version of the log files, please rename them beforestarting the service.



Starting the AppSight service remotely

To start the service remotely, use the sc utility. You need to specify the full path to a profile to be used, and toan output recording log file on the target PC as shown in the following example:

sc \\computername start bbxservice /rpr "C:\ProgramFiles\Appsight\Data\RPR\SAPPOS.rpr" /asl "C:\ProgramFiles\Appsight\Logs\POSRecording.asl"

where:bbxservice – AppSight Black Box service name in the system.\\computername - is target PC name/rpr <path> - a switch and path to a profile to be used by the service/asl <path> - a switch and path to a log file to be created

Use quotes for long path names as shown in the example.

Stopping the AppSight service remotely

sc \\computername stop bbxservice

Sending log files to SAP Support

Once an issue is reproduced, stop AppSight service using StopAppSight. Locate the appropriate recordinglog file in %ProgramFiles%\SAP\Retail Systems\AppSight\Logs folder. For information on how to useSAPmats to transfer large files to SAP support team, see SAP Note 1146680. In addition to .asl files, thesupport team may ask you to provide additional files like .map or .pdb for specific .dll and .exe files.

AppSight service best practices

When the service is running to monitor application crash, make sure users do not press RESET button on thePC once the issue encountered. The service has to be stopped first, that will allow dumping all recordedinformation into the log file safely.

Beware that if AppSight service is running to monitor an issue on a PC and a user reboots the PC, the servicehas to be started again manually.



2.2.2 Monitoring objects for SAP POS within the store



Credit Services Error message atPOS during EFTtransaction

Store usersnotice thatcredit anddebittransactionsare not gettingapproved atPOS

First LevelSupport willstop and startall services

Situational

Credit.saf Error message atPOS during EFTtransaction


First LevelSupport willinvestigate

Situational

Manual correction of acredit.saf should occur within2 days of the event or asmandated by the creditservice

Credit Logs:

\Point of Sale\crsrv.log

\Xpress Server\crsrv.log

\Transnet\Logs\log.txt

Error message atPOS during EFTtransaction


First LevelSupport willretrieve logs fromPOS Registers,

Xpress Server,and TransnetServer and passonto SAP Support

Situational

Encryption key and keycontainers

N/A Data has beenaccessed byanunauthorizeduser or keysare corrupt

Xps.log Situational

Backoff.db database Productionbackoff.db

Slow retrievalof data orincorrectreports andSQL errors inthe xps.log

Head OfficeDatabaseadministrator SQLServerManagementStudio and thexps.log

Situational

Xpress Server

Configurator

POS registers

Transnet Server

Generic profiles areavailable and can beconfigured forspecific needs

N/A AppSight utility onXpress Server,Configurator,

Transnet and onPOS registers

Situational – Support wouldcollect log files as required

Table 11: Store level processes – Monitoring objects



2.3 Business Process: POS Inbound

Figure 12: POS Inbound process flow

Real Time Trickle is the process used to pass, in near real-time, transactions occurring at the POS to thehead office system(s). Once the POS finalizes a Transaction the TLOG and Journal file are sent to theXpress Server. Then the TLOG files are converted on the Xpress Server to an ASCII / XML format. TheseXML TLOG files are picked up by the CEFT Client’s trickle service where they are transmitted to the HeadOffice systems for processing. The head office systems include POS DM via PI and Returns AuthorizationServer (RA) if available.

2.3.1 Business Process P01: Transaction completes, POS writes locally and moves data toXpress Server

2.3.1.1 DescriptionOnce a POS transaction has been completed the POS will write the details to local files (rdata\ld.txn andrdata\ld.jrn). Xpress Server will, during idle cycles, request completed transactions from POS terminals.




Most of the data generated in a store comes from the POS. The data flows from the POS register to theXpress Server. If the register is non functional, if the POS application is non functional or improperlyconfigured or if the connection between the server and the POS is severed then transactions may not bemoved to the Xpress Server. In addition, if POS cannot write a transaction, the system will stop and displayan error to the cashier.

Business date issues can lead to accounting problems and so these need to be minimized. Rebuilding localPOS files is needed when the TLOG at the register is corrupted or lost.

2.3.1.2.1 No DB at POS

When no DB appears at POS, this is an indication that the connection between POS and the Xpress Serverhas been severed. This could be due to POS or Server hardware problems, network or Windowsconfiguration, or to problems with the POS configuration. First it must be verified that the primary server is

online. Hardware, network and Windows problems need to be reported to First Level support for resolution.To troubleshoot POS configuration, run Manager Code 6 – Terminal Define at the POS and review theparameters defined based on the script for that particular implementation.

Throughout the day both the LD.TXN (Tlog) and the LD.JRN (Electronic Journal) are trickled to the server. This process is initiated by the server when it has idle processor cycles. The server pulls these files from

the …\Rdata directory on the registers. The trickle process only stops if the server is busy performinganother task. Credit requests, Report generation and terminal close procedures are some things that maystop the trickle process for brief periods of time. The Xpress Server window can be monitored for possibleerrors.

When the server receives TXN and JRN files, they are written to the server’s …\Sdata directory. The information in the Tlog is also posted to the SQL database on the server.

On the Point of Sale client application, there is a status window that normally appears blank. A short code “NoDB” will appear if there is an error. Since the POS’s user interface is highly customizable, the location of thestatus window may vary.

While the user may not notice the actual no DB status, the performance of the system will be indicative of noconnection to the database. The No DB error code shows in the status window if the register is offline to theXpress Server. The server or the network could be having problems. In the case of No DB, the LD.txn filesare not trickling to the backoff.db database and, along with LD.jrn, the files are not posting to the sdatadirectory. Therefore, the following symptoms may appear: PLU lookup is not possible (unless the Local PLU is configured) Online credit auth is not possible The terminal cannot be closed Store Manager reports for that terminal and consolidated store reports will be inaccurate The TLOG for that terminal as well as the consolidated store TLOG will be incorrect

Functions that may assist in diagnosing the problem: Manager code 6: Terminal Define - configures essential data for the setup and functionality of the POS

registers



Manager code 900: Runs peripheral diagnostics. The tests available include a scanner test, auto PLU testand disk size test.- Disk Size: Provide the current disk size settings contained in memory.- Diagnostic Report: Show the current peripheral settings for the POS.- Scanner Test: Test the scanner connected to the terminal.- Keyboard Test: Test the keyboard.- Auto PLU Test: Test the performance of Price Look Up.- Software Version: Provide the version of POS Xpress software that you are using.- MSR Test: Test the magnetic strip reader.- Printer Test: Test the printers.- Cash Drawer: Test the cash drawer.- Read Micr Test: Test the micr reader.

Manager code 999: Shows the current version and build#.

Manager Codes allow the user to quickly access a particular transaction without going through the menuoptions. Access Rights to Manager Codes can be configured through the Configurator. For exampleEmployees with a Security Level below 3 may not access certain Manager Codes.

Exception and event logs to assist in diagnosing problems in the POS application are found in the followinglocations: 1) Point of Sale\xcpt.log and event.log 2)Xpress Server\xcpt.log and event.log

2.3.1.2.2 Business date problems

The business date is unseen by Managers, Cashiers and Customers. This date only applies to reporting. It isthe system date that is visible on the screen, receipts, etc.

The most typical scenario of business date conflict is closing of the store and missing a register that is offline.When the store re-opens and the register connects, it will have the previous business date. The POS willwarn of the conflict and appropriate action for resolution will be required. The actions could be to close theregister or reset the business date. Action is dependant on host system data processing requirements.

The Manager Codes to run at POS to resolve business date issues are: Manager Code 426 - Change Business Date can be used to change the Business date on a terminal at

any time. Manager Code 424 - Needs to be run if a terminal did not close the evening before. Not closing a terminal

will result in a Business Date Conflict.

2.3.1.2.3 Rebuild local files

When running POS terminals configured to use local PLU, it is recommended to regularly rebuild the files,e.g. on a weekly basis. The frequency of the rebuild depends upon how often the pricing files are updated.This helps ensure the registers are as current as possible with pricing.

A file containing the exact content of each of the following tables is created by selecting them in the Local FileRebuild maintenance window: PLU PLU Cross Reference Qty Level Pricing



Link Items Promotions Departments

Regularly scheduled rebuilds are configured in the Configurator. Consult the Configurator User Guide formore information.

Note: A parameter download will not occur during a rebuild.

To perform a local file rebuild: On the Main Menu, click Administration. Click Local File Rebuild. On the Local File Rebuild window, click the check boxes beside the files that you want to rebuild. Click Start.

Note: The Abort button is active only when a rebuild is in progress. You must click the Abort button to stop theregularly scheduled rebuild in order to perform an immediate rebuild in the Store Manager.

To abort the rebuild process of each file, click the Abort button on the Rebuilding Local File pop-up windowthat shows the name of the file being rebuilt and the progress of the rebuild.To confirm the abort request, click Yes, or click No to cancel the request and continue the rebuild process.

When the local file rebuild is complete the files are saved in the xps\txnsave directory.

2.3.1.3 Monitoring objects for SAP POS writing data locally and sending information to theserver

Monitoring Object Selection Criteria Alert Analysis Tool onSatellite System

MonitoringFrequency / DataCollection

POS applicationfunctionality

Are PLU lookupsfunctional

No DB at POSterminal

POS applicationinvestigated by FirstLevel Support

Situational

Xpress serverservice started

N/A No DB at POSterminal

Xpress Serverinvestigated by FirstLevel Support

Situational

POS applicationconfiguration

Define Terminal -Manager Code 6

No DB at POSterminal

POS application Situational

Missing TLOGs atPOS

Local PLU rebuild POS may stopresponding

POS application andCVTLOG utility

Situational

Message at POSterminal

Reset Business Date –Manager Code 424

Messageappears atPOS terminal– Businessdata mismatch

POS application Situational

Table 12: POS inbound process P01 – Monitoring objects



2.3.2 Business process P02: Send data from Xpress Server to CEFT server

2.3.2.1 Description

The Xpress Server will receive and write the details to files locally (sdata\SSSSRR00.txn andsdata\SSSSRR00.jrn), post details to the local database and create the TLOG trickle files The Xpress Serverwill take the TLOG trickle files and push them (oldest first) as messages to the CEFT Message Server. Oncetransferred successfully, the trickle files are removed from system.


Xpress ServerXPS: ..\sdata\SSSSRRss.txn, where SSSS is store number, RR is the POS terminal numberand ss is a sequence number. Sequence number of 00 indicates current register file that will correspond withthe ld.txn file at the pos.

Additionally, we can examine the txn_POS_Transactions table in the backoff database and look up thehighest value of txnnum for a given storenum and regnum. This should be in very close agreement with themost recent transaction number actually executed at the given POS.

The typical staging directory for trickled TLOGs on the Xpress Server is in the TRICKLE on the root drive. Abuild-up of *.TRX files in this directory is indicative of an issue trickling to the CEFT Messaging Server. Thereshould typically be, at most, two or three. TRX files present in this directory. As they get handed off to theTransnet Messaging Server, Xpress ServerXPS deletes them from this directory.

Suggested troubleshooting process

If we have reason to believe that PI is not receiving a timely feed of transaction data (TLOGs) from one ormore POS terminals, then the direction of investigation is determined by how many POS terminals we believewe are not seeing timely data from:

Missing data from ALL POS terminals in the chain

The issue is most likely not at store-level, between all the POS terminals and their Xpress Servers. Make sureboth services (NTM Manager and Transnet) are running on the Transnet Messaging Server. Examine thelogs on the Transnet Messaging Server to see if there is anything out-of-place. The Transnet service logsmessages and errors to Transnet\stdout.txt, Transnet\stderr.txt and Transnet\logs\log.txt. Any errors relatedto the NTM Manager can be found by executing the ntmfmt command from within the Transnet\tpsntmdirectory.

Missing data from all the POS terminals at one store

The issue most likely resides with either the Xpress Server at that one store, or with store-to-corporatecommunications. If the Xpress Server service is running, check the XPS.LOG file on the in-store server forissues related to the TLOG trickle. If the Transnet Messaging Server can be pinged from the in-store server,then check the Transnet client logs (Transnet\stdout.txt, Transnet\stderr.txt and Transnet\logs\log.txt.) and theNTM Java Client logs (Transnet\jtmt\logs\NtmClientEvent.log). Make sure both the Transnet service and theNTM Java Client service are running.



On the Transnet Message Server console the Client Monitor will display the connectivity of the NTM JavaClients for the entire chain of stores by IP address. The indicators on the monitor represent the following: Green: connected store Blue: connected but idle store Red: store not connected

This is a screenshot of the Client Monitor:

Figure 13: Client Monitor

Missing data from one POS terminal at one store

When running reports at the server or when trying to balance cashiers at the end of day, data from oneterminal may not be included. As well, when trying to close the store, the system will report on any registerthat was opened but has not closed. In order to check differences, the LOG files on the missing POS terminalcan be verified and compared to the Xpress Server. The issue most likely resides with the communicationbetween the POS terminal and the Xpress Server at that store. There may be corruption in the TXN file in theXpress Server’s sdata directory on the in-store server. Check for connectivity between the POS and theXpress Server by trying to ping the POS from the Xpress Server. If that is successful, then delete the TXN filefrom the Xpress Server and the POS should try to re-trickle all that day’s transactions back to the XpressServer again. See section 2.3.1.2 regarding No DB and connectivity issues.

2.3.2.3 Monitoring objects for sending data from Xpress Server to CEFT

Monitoring Object SelectionCriteria

Alert Analysis Tool onSatellite System


Log files on TransnetMessaging Server

N/A N/A Transnet\stdout.txtTransnet\stderr.txtTransnet\logs\log.txt

Situational



Monitoring Object SelectionCriteria



C:\Trickle *.trx files N/A Client Monitor onTransnet MessageServer

Situational

Transnet clientconnectivity

None Color indicators Client Monitor Daily


2.3.3 Business process P03: Send data from CEFT message server to PI and RA

2.3.3.1 Description

The CEFT Message Server will receive the message, interpret, decrypt and pass to PI/XI through an httpadapter. PI/XI will transform the data and move it to POSDM. The CEFT Message Server will also pass datato RA through a Transnet adapter

2.3.3.2 Monitoring requirementsCPU Utilization: To receive optimal performance from the CEFT Server, ensure CPU utilization does notexceed 80% for sustained periods of time. Configuration is available to send an email alert message whena threshold level is met.Memory Utilization: To receive optimal performance from the CEFT Server, ensure memory utilizationdoes not exceed 60% for sustained periods of time. Configuration is available to send an email alertmessage when a threshold level is met.Disk Space Utilization: To receive optimal performance from CEFT Server, ensure disk space utilizationdoes not exceed 85%. This is not necessarily a CEFT Server requirement but is recommended on allWindows Servers.NTM Manager Service: This service controls the management interface for CEFT Server and should bemonitored to ensure it is always running.Note: A General Rule of thumb is two threads for every store connected to the CEFT Server systems andthat no more than 650 stores should be connected simultaneously to any single CEFT Server.*Applies to version 3.0.0.8 of NTM Server which is part of the CEFT Message Server software suite.(versions 1.5, 1.6, 1.7 and 1.8)Recent history of serious issues with client connectivity or other NTM Manager woes can be viewed byexecuting the “NTMFMT” and “NTMFMTD” commands from within the TPSNTM directory on the CEFTServer. The useful parameters for these commands are as follows:- -s... Severity code. Optional. Enter the lowest message severity code which will be displayed.

Messages which have a severity code lower than this value will not be displayed. Messages whichhave a severity code greater than or equal to this value will be displayed. The default value is zero, todisplay all severity codes. The severity codes are: 0=informational, 4=warning, 8=error

- -c Display prior copy of log file. Use this option when log files have been continued.- -a Display all copies of log files. Use this option when log files have been continued.- -p... Use to specify path to log file otherwise it will look in the NTM logs directory.- -b... Use to specify beginning date/time for log entries. Format: -bYYYYMMDDHHMMSS- -B... Use to specify beginning date/time for log entries in UTC format. Format: -B#



- -e... Use to specify ending date/time for log entries. Format: -eYYYYMMDDHHMMSS- -E... Use to specify ending date/time for log entries in UTC format. Format: -E#- -T... Use to specify (in seconds) amount of time of log entries to tail.- -t... = Program type code. Optional. The default is to display messages from all program types. Enter

one of the following values to only display messages from the specified program type:1=Transaction Processor2=Client Server3=Client4=Client API5=Broadcast Daemon6=Connection Server7=Program Manager8=GUI9=Log Daemon10=Director

- -n... = Program instance name. Optional. Enter a program instance name to only display messagesfrom the specified program instance. The name can end with an * to display messages from programinstance names which start with the specified name prefix. The default is to display messages from allprogram names.

- -v Display verbose information.Apache Service: This service controls the web interface for CEFT Server and should be monitored toensure it is always running.TPS Command Service: A server-side network service program use by multiple Components of the FileTransfer or Centralize EFT systems. Its main function is to handle requests for configuration, analysis, andsystem control from any JAVA-based screens on the network, forwarding them to the appropriateprograms. This daemon must be working to use the CEFT Server JAVA Graphical User Interface (GUI).NTM Log Daemon: Is responsible for buffering event and diagnostic log statements from all CentralizedEFT server-side programsTransnet Service: This service controls a portion of the CEFT Server messaging layer. It specificallyprocesses and routes messages to appropriate processors. Messages include EFT (Credit, Debit, StoredValue), Loyalty, Product Return validation and TLOG Trickle. No more than 1800 threads should berunning at any time in this service.TCP Port 8400: This is the port that Transnet Service listens on for incoming messages to route.CEFT Server Memory Usage: To receive optimal performance from the CEFT Server, ensure memoryutilization does not exceed 80% of its configured value established at startup.CEFT Server Thread Meter: To receive optimal performance from the CEFT Server, ensure thread countdoes not exceed 3 times the total number of store servers.SQL Service: This service controls the MS SQL database and should be monitored to ensure it is alwaysrunning.SQL Agent: This service controls the MS SQL job and scheduling engine and should be monitored toensure it is always running.SQL Port 1433: This is the port that MS SQL listens on and should be monitored as it is useful indetermining SQL availability. Default port is 1433 and this is configurable at time on SQL installation.SQL Maintenance: The database is set, in its configuration, as “Simple” by default. This means the logfile will remain relatively small and pose no growth issues on the hard drive. It is recommended thatperiodic backups be performed and these will need to be scheduled during periods of network inactivity.



The application requires manual intervention to periodically purge the “meter table”. Purge is documentedin the CEFT User Guide.- This guide is accessible in POS 2.1 under

http://help.sap.com/saphelp_pos21/helpdata/en/5a/70efcec69e4a67a1bfbdedc690a2a5/frameset.htm- F or SAP POS 2.2 under

http://help.sap.com/saphelp_pos22/helpdata/en/5a/70efcec69e4a67a1bfbdedc690a2a5/frameset.htm

2.3.3.3 Monitoring Objects for sending data from CEFT Message Server to PI and RA



CPU Utilization

Memory Utilization

Disk Space Utilization

CEFT Memory Usage

N/A SystemConfigurable

Windows Constant

NTM Manager Service

Apache Service

TPS CommandService

Transnet Service

NTM Log Daemon

SQL Service


Windows Constant

TCP Port 8400

SQL Port 1433


Windows Constant

CEFT Server ThreadMeter


Windows Constant


2.3.4 Business process P04: Send data from FTS to PI and RA via nightly batch

2.3.4.1 Description

Once the sales day has been completed at the store, a two-step process to close out the business day isexecute. First the registers are closed and then the store is closed. During the second step to close out thestore, the Xpress Server will create consolidated totals files (by store, by register and by cashier) for thestore. Subsequently, the files are picked up by the FTS.

2.3.4.2 Monitoring Points: Close Register

A close register process is initiated on the POS and it will push any remaining transactional data andconsolidated totals to the Xpress Server.





2.3.4.2.1 Posting totals

Background information

As transactions are completed at the POS, they are written in binary format to Point of Sale\rdata\ld.txn. Thisfile is known as the ‘tlog’ (transaction log). A second file, Point of Sale\rdata\ld.jrn, is also written to in ASCIIformat and this file is known as the ‘journal file’.

As transactions are completed, the information is updated in the register daily total files (rd.* files) that arelocated in the \Point of Sale\rdata folder.

Register Daily Filename Description

Rd.cto Cashier totals

Rd.dep Deposit summary

Rd.dit Discount totals

Rd.dsm Department summary

Rd.spd Salesperson Productivity

Rd.tms Timed Sales

Rd. tot Sales totals

Table 15: Register daily total files

Each register’s ld.txn and ld.jrn files are incrementally copied to the Xpress Server\sdata\ directory on theprimary Xpress Server. This process is performed throughout the sales day during a process called ‘trickling’.

Trickling is a low level file transfer mechanism that copies file packets at the transport layer. This process isscheduled by the Xpress Server to take place during idle periods.

Each register has its ld.txn and ld.jrn files trickled to the primary server.

Naming convention of the tlog and journal files on the server is as follows: SSSSttnn.txn SSSSttnn.jrn

- where SSSS is the 4 digit store number- where tt is the 2 digit register number- where nn is the 2 digit sequence number

The Xpress Server’s \xps\sdata directory contains sd.* files (store daily files) that are generated based on thedata from the rd.* files (registers daily files).



Store Daily Filename Description

Sd.cds Cashier by department

Sd.cto Cashier totals

Sd.dit Discount totals

Sd.dsm Department summary

Sd.rto Totals by register

Sd.smi SKU Movement – index

Sd.smv SKU Movement – data

Sd.spd Salesperson productivity

Sd.tms Timed sales

Sd.tot Store Daily totals

Table 16: Store daily files

Posting totals is the process of synchronizing the updating and finalization of register data to the server, andthe posting totals from finalized register data to the server’s total files.

Posting totals occurs upon Register Close and Register Exit (Manager Code 499).

A register is closed as a result of: Manager Code 249 – Close Terminal Manager Code 250 – Close Store POS Manager – Close Register

When the register is closed, the following events occur automatically: Register reports print. Totals are posted and cleared from the register. Polling files are prepared.

When the totals are posted, the server’s \Xpress Server\sdata\ .txn and .jrn files are updated. The registers rdtotal files, as well as the server’s sd total files are updated. Totals are posted to the database, and finally, newld.txn and ld.jrn files are generated.

What causes posting totals errors?

There are two main causes of posting totals errors: Network communications – problems that exist or existed during the operation. File corruption – result of network communication or HDD errors.

When a register receives a Posting Totals error, you are given the option to retry. During this period, you canattempt to resolve whether the issue is being caused by one of the issues above.



Network Communications: In POS Manager, does the register show up under Monitor Terminals? Can you ping the register with no packet loss with large packets?

Note: Let the ping test run for a few minutes to catch intermittent issues: From a command prompt, type ping<register’s IP> -l 1024 -t

Once the network issue has been resolved, the register should be able to post. Keep in mind that once anetwork issue has been resolved, a file corruption issue may have been created.

Data Corruption: Corruption will happen in 1 of 4 locations: At the register in \rdata\ld.* At the register in \rdata\rd.* At the server in \sdata\SSSSttnn.* At the server in \sdata\sd.*

How to resolve posting totals errors

Corruption most commonly occurs at the server in \sdata\sd*. In order to resolve ‘rd to sd consolidation’posting totals errors, do the following: Stop Xpress Server. From a command prompt, navigate to C:\Program Files\SAP\Retail Systems\Xpress Server\sdata Type ‘mkdir bkup’ <enter> Type ‘move sd.* bkup’ Start Xpress Server. Retry the terminal close.

When the file corruption involves \sdata\*.txn files, do the following: Stop Xpress Server. From a command prompt, navigate to C:\Program Files\SAP\Retail Systems\Xpress Server\sdata Type ‘mkdir bkup’ <enter> Type ‘move SSSSttnn.txn bkup’ <enter>, where SSSSttnn.txn is the problem registers txn. Start Xpress Server. Close the problem register.

Note: The first thing that a register will do upon close is to make sure that the txn file in Xpress Server\sdatais in sync and up to date with its Point of Sale\rdata\ld.txn. If not, it will recreate the entire sdata\*.txn file.

When the file corruption involves rdata\rd.* files, do the following: At the POS, run manager code 418 (delete files). Select Delete rdata files. Select All files. Run manager code 422 (rebuilt terminal totals) or reboot the register. This will cause the files in rdata to

be rebuilt from the *.txn files on the Server’s \sdata directory.

When the file corruption involves rdata\ld.txn, do the following: At the POS, run manager code 418 (delete files). Select ‘rdata files’. Select ‘Keep Files’ until you see ld.txn, and then select ‘delete’. Repeat for ld.jrn, then select done. Run manager code 422 to rebuild the totals.



Troubleshooting posting totals errors

Error Codes take the format (Exxx/yy/zz) and occur from within the POS interface.

For example: during close terminal, the error code (E100/0/6) indicates that the POS could not retrieverdata/rd*.* files on terminal because these files were not found. The “xxx” refers to Consolidation/Close Terminal/EOD Error Codes - These errors occur during report

consolidation, close terminal or end of day. They are usually reported with a communications error codeand file transfer error/status code.

The “yy” refers to Communications Error Codes - These are used by the communications API to indicateerrors that have occurred on the network.

The “zz” refers to File Transfer Error/Status Codes - These are error codes or status messages which canoccur during the file transfer process.

Consolidation/close terminal/end of day error codes (Exxx)

Error # Description

001 Not enough memory to for task for message status transmit

002 Error occurred when writing a miscellaneous transaction to TLOG.

100 Error retrieving all files matching rdata/rd*.* from terminal during terminal close process.

101 Could not fully trickle EJRN (electronic journal) from terminal during terminal closeprocess

102 Could not fully trickle TLOG (transaction log) from terminal during terminal closeprocess

103 One of rd.* (rd.tot, rd.cto, rd.spd, rd.tms, rd.dsm or rd.dit) from terminal not found insdata directory for posting.

110 A consolidation of terminal totals (rd.*) into store consolidated totals (sd.*) has failed; allconsolidated totals files have been rolled back to state before consolidation started.

111 Could not copy all of the current store consolidated totals files (sd.*) to sdata/rollbackbefore posting terminal totals to these files.

200 Error copying existing store data to work file for data consolidation.

201 Error consolidating totals from a terminal into store totals.

202 Error sending final consolidated file to requesting register for totals consolidationrequest

300 Could not fully trickle TLOG from each open terminal on current day SMV databaserequest

301 Could not generate SMV database extract for SMV database request.

302 Error sending final consolidated file to requesting register for SMV database request.



Error # Description

310 Could not fully trickle TLOG from each open terminal on current day CDSM(cashier/department-summary) database request

311 Could not generate CDSM database extract for CDSM database request.

312 Error sending final consolidated file to requesting register for CDSM database request.

Table 17: Consolidation/close terminal/end of day error codes

Communications error codes (yy)

Error # Description

0 No Error

1 Bad LSN (Logical Session Number)

2 LSN table is full

3 Session is closed

4 Invalid or missing phone number

5 Could not initialize port

6 Invalid Command

7 Session is busy

8 Message is too long

9 Port number is out of range

10 Port does not exist.

11 Port already open

12 Node segment error

13 Could not open the port

14 Could not initialize the modem

15 Could not build the send file list because the directory does not exist or out of memory

16 Error in packet transmission

17 File transmission error

18 Error in received file



Error # Description

19 Reserved for future use

20 Insufficient disk space

21 Negative acknowledgment from receiver

22 File not sent; Receiver is too busy

23 Timeout after no receiver response

24 Could not erase file

25 No mail in mailbox

26 Received packets out of sequence

27 Directory for receiving files could not be created

28 Directory for receiving files is locked

29 Error sending receiving mailbox message

30 Message is in the mailbox

31 Process has been aborted by the system

32 Process has been aborted by user

33 Files received

34 Files sent

35 Invalid directory

36 Out of memory

37 Incomplete datagram

38 Carrier lost

39 Receiver acknowledged a request

40 Network not available (NetBIOS or TCP/IP is not installed; no response from LANprotocol stack)

41 Could not reset network adapter (No response from adapter)

42 Could not create network name (Name is already used - i.e. Duplicate terminal number)

44 Could not close NCB (Network Control Block)

Table 18: Communications error codes



File transfer error/status codes (zz)

Error # Description

0 No error

1 Invalid command

2 Disk problem/file copy error

3 File being actively sent

4 Zero length file (File send not required)

5 Existing file has identical time/date/size (File send not required)

6 File not found (Not sending file)

7 Network busy (Not sending file)

8 Ready to receive file

9 Network busy (Cannot receive file)

10 Out of disk space (Cannot receive file)

11 File not found (Cannot receive file)

Table 19: File transfer error/status codes

General error/status codes (ZZ-2)

These are general error codes or statuses which can occur during the consolidation process.

Error # Description

Programming Errors

100 Programming fault

101 Invalid parameter

System Errors

102 Out of memory

103 Out of disk space

104 No floppy disk



Error # Description

105 No directory

106 No communications connection

File Oriented Errors

110 File not found

111 File not opened

112 File read error

113 File write error

114 File not writeable

115 File create error

116 File delete error

120 File not found

121 Record not found

122 Value out of range

123 Invalid data

124 Unrecognized type

125 Not configured

Table 20: General error/status codes

Scenario: Posting Totals Error E102/23/124 is generated Look up the ‘E102’ error (Exxx):

- E102 – Could not fully trickle the Tlog from the terminal during terminal close process. Trickling iswriting to the server, not reading from the register.

Look up the ‘23’ error (yy)- 23 – Timeout after no receiver response

Look up the ‘124’ error (zz)- 124 – Unrecognized file type

2.3.4.2.2 File corruption

Rebuilding the TLOG and journal

One of the key causes for End of Day difficulties is a corrupt TLOG or Journal on the server. To test forcorruption you would use the utility CVTLog. Once you discover the corrupted TLOG, you must rebuild it inthe following manner.



Click Stop Server on Xpress Server. Using Windows Explorer, navigate to the Xpress Server\sdata directory. Locate the current day’s .txn (TLOG) and .jrn files for the troubled terminal(s). Copy and rename each of the files located in step 2. You may leave them in the same directory (\sdata)

as long as they are renamed. Delete the original files that were located in step 2. Restart the Xpress Server by clicking Start Server.

Rebuilding the \sdata directory

Another possible cause of end of day problems is a corruption of files in the Xpress Server\sdata directoryon the server. Your power may have failed in the middle of the day causing the files to be of a different size ortime than the source files from the register(s). If all else fails, an attempt may be made to restore the situationby rebuilding the entire \sdata directory. Click Stop Server on Xpress Server. Using Windows Explorer, navigate to the Xpress Server\sdata directory and copy the state.srv file into a

temporary folder somewhere outside of the \sdata directory. Delete all contents of the \sdata directory. Paste the state.srv file back into the \sdata directory.

Restart the Xpress Server by clicking Start Server. Note that this procedure is relatively extreme measure.

2.3.4.3 Monitoring Points: Close Store

A close store process is initiated to Store Server. Any registers still in an open state will be closed. All totalsfrom transactions performed on the registers will be consolidated for the business day. Consolidated files(and others depending on configuration) are created in the “Xpress Server\Upload” folder

2.3.4.3.1 End of day (EOD) issues

Troubleshooting end of day data problems

This section describes some common difficulties encountered during the EOD process, and instructions forcorrecting the difficulties.

Most often, issues encountered when closing the store are issues that prevent a register or registers fromclosing.

The issues that prevent a register from closing are primarily: Inability to post totals, due to hardware issues, or file corruption. Business Day conflicts Balancing the terminal if client has configured it as mandatory.

The issues that can cause the store close to fail are primarily: Database corruption State.srv corruption Hardware failure



The EOD script is conventionally called “eodproc.bat”, but can be called anything. Whatever the file is calledthat executes the EOD batch script, it is specified in the Xpress Server controller property tab. This is alsowhere the log file is specified. Many EOD issues occur during the execution of client eodproc.bat scripts.

When troubleshooting EOD issues, or verifying if EOD was completed successfully, there is only onemethodology that can be relied upon. This is to walk through the script and verify that each action wassuccessful. Once it’s been concluded that a step has failed, the problem can more easily be determined.Often the eodproc.log is helpful but cannot be relied upon by itself.

2.3.4.4 Monitoring Points: FTS

A job/plan to move data on the FTS is initiated to pull back the files from the “Xpress Server\Upload” folder.The data is then transformed into expected standard content output and presented for PI/XI pickup. Seesection

NFM Server Service: This service controls the File Transfer process to/from stores and should bemonitored to ensure it is always running.NFM Client Service: This service runs on the FTS at each store. It receives and transfers files betweendestinations and should be monitored to ensure it is always running.TCP Port 8008: This is the port that NFM Client listens on to process transfers and should be monitoredas it is useful in determining system availabilityDaily Polling plan execution: At the CEFT Console at head office, review plan activity from previousnight. Review summary results of plan execution by selecting Scheduling/Plan Activity from the FTS pulldown menu.

Figure 14: Select scheduling/plan activity



To view details of any plan, note the instance ID from the summary results screen and enter is as searchcriteria under History/Audit Trail.

Figure 15: View details of any plan

2.3.4.5 Monitoring objects for sending data from FTS to PI and RA via nightly batchMonitoring Object Selection Criteria Alert Analysis Tool onMonitoring Object Selection Criteria Alert Analysis Tool

on SatelliteSystem


POS register N/A ErrorExxx/yy/zz

Dependant ontype of error

Situational

TLOG Terminal ID ErrorExxx/yy/zz

CVTLog.exe Situational

Xpress Server\sdatadirectory

N/A N/A N/A Situational

Eodproc.bat andeodproc.log

N/A Data notreceived atH.O.

N/A Situational

FTS List of recipientsare defined

Emailmessage

Email Alert Automatic alerts whenproblem occurs





FTS Date/Time/PlanName/Status

Reported onconsole

Plan Activity At user’s discretion butrecommended daily

FTS Date/Time/Instanceid/Plan/FileSet/Node

Reported onconsole

Audit Trail forselected plans

At user’s discretion butrecommended daily


2.3.5 Business process P05: Monitoring returns authorization and SAP POS

2.3.5.1 System landscape

SAP Returns Authorization (SAP RA) is a centralized transactional service that authorizes item return andrefund transaction requested from the SAP Point of Sale (SAP POS). SAP RA is typically deployed at theretailer’s Head Office and provides service to SAP POS across all stores. SAP CEFT is required in order toconnect SAP RA and SAP POS. SAP RA is a Java EE application that is currently running on IBMWebSphere Application Server. The following diagram shows integration of all involved SAP components forreturns authorization.

Figure 16: Integration of all involved SAP components for returns authorization



2.3.5.2 Returns authorization system configuration Data mapping for application server to process POS trickled Tlogs CDL configuration to process end-of-day batch load Data mapping file for batch loading SKU descriptions (nice to have) Stores file (for RA reporting)

2.3.5.3 Where to find returns authorization configuration

Data mapping for application server trickleload.jar at following location

Trickle process receives POS Tlog message from SAP EMT server and process this message; Loads thetransaction to Returns Authorization data base as they happen, normally within very short amount of time (2-3seconds). If SAP RA JMS have any issue or is not listening SAP EMT server can queue these POS Tlogmessages on SAP EMT server. And can process these messages when SAP RA comes on line.

Data mapping for trickle can be found here:- “WAS_INSTALLED_DRIVE\Program

Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\w2003serverNode01Cell\ReturnsAuthorization.ear” as shown below

Figure 17: Data mapping for trickle (1/2)

Open trickle.jar with winzip or winrar and the file named as SAP_POS-trickle.xml is the data mapping fileused for trickle for your environment. As shown below.

Note: Sometimes the name of the file is changed that can be found out from ERTrickle.properties the tagparserConfig=/SAP_POS-trickle.xml will define the name of the mapping file being used.



Figure 18: Data mapping for trickle (2/2)

Data mapping for CDL

Common Data Loading is nightly batch loading process that runs in parallel to trickle process; It consolidatesthe Transaction Log.

By default this component is installed at following location: “C:\SAP\ReturnsAuthorization\Dataload\SAP_POS”

The default name of the data mapping file is “SAP_POS.xml” as shown below

Figure 19: Data mapping for CDL (1/2)



Occasionally, this file name may be configured differently. Double-check in cdl.properties for the file’sParseTlog task as shown below.

The detail of the tags for this configuration file can be found in Common Data Loading technical referenceguide. task.ParseTLog.class=com.triversity.cdl.tasks.ParseTask task.ParseTLog.sourcedir=C:/SAP/ReturnsAuthorization/Dataload/SAP_POS/tlog task.ParseTLog.sourceext=asc task.ParseTLog.targetdir=C:/SAP/ReturnsAuthorization/Dataload/SAP_POS/output task.ParseTLog.targetext=oh,oc,oi,ot,oti,oa,meta,rpt,op,ol,oid,oix task.ParseTLog.configfile=SAP_POS.xml

Figure 20: Data mapping for CDL (2/2)



2.3.6 Restarting returns authorization

2.3.6.1 Returns authorization application

Returns Authorization Application is hosted on IBM WebSphere application server. Starting IBMWAS6Serviceon your node (as shown below) will start Returns Authorization.

Figure 21: Start IBMWAS6Service

This service can also be stopped or started from link provided from: start\programs\IBMWebsphere\AppllicatonServerNetwork..\profiles\AppSrv01\Start the server start\programs\IBM Websphere\AppllicatonServerNetwork…\profiles\AppSrv01\Stop the server

OR

From a command line using one of the following batch files as shown below "D:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\bin\stopServer.bat" server1 "D:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\bin\startServer.bat" server1



2.3.6.2 Starting batch data load

TLOG data from the stores needs to be loaded into RA on a daily basis. This is achieved either by trickle orby common data loading (CDL.) CDL is configured on the database’s server. The batch process for loadingPOS Tlog data, item SKU description and stores files can be started by running following batch file: C:\SAP\ReturnsAuthorization\Dataload\SAP_POS\pipeline.bat

The encrypted POS Tlogs needs to be copied to following folder in clear text: “C:\SAP\ReturnsAuthorization\Dataload\SAP_POS\Tlog”

CDL concatenated individual store files to a file named as YYYYMMDD.asc and parses data to StandardTriversity Input File Format (STIFF)

Windows scheduler is used to create a scheduled task to run this process daily.

Figure 22: Start batch data load

2.3.6.3 Starting the SAP RA Web portal

Log on to a web browser and access the following URL: http://IP_ADRESS_OF_APPSERVER:9080/ExpressReturnsWeb/RefundLogin.jsp



2.3.6.4 Resetting Web portal password

In case a user forgets their password, there is no direct way to reset password. The user has to access thedatabase and update following table with the string provided below to reset the password: Table name:USERSECURITY Field name:PWD Update value: KZ+YsYQaZdceoa4rnkDPmxws7so=

The string defined above is hashed value for abcdef1. Any user whose password is reset to this value will beabcdef1.

2.3.7 Returns authorization logs

2.3.7.1 Returns authorization application logs

Returns authorization application logs: “C:\SAP\ReturnsAuthorization\logs\ engine.log.0”

The size and levels of logging can be changed based on following file and settings at WebSphere levellogging: “C:\SAP\ReturnsAuthorization\lib\ authloggingExt.properties”

- # Mapping JDK logging levels to log4j- # JDK level Log4j level- # ALL ALL- # FINE DEBUG- # INFO INFO- # WARNING WARN- # SEVERE ERROR

### main log file for TE- FileHandler.FH1.level=ALL- FileHandler.FH1.pattern=C:/SAP/ReturnsAuthorization/logs/engine.log- FileHandler.FH1.limit=10000000- FileHandler.FH1.count=10- FileHandler.FH1.formatter=com.triversity.tef.util.logging.formatters.TriversityFormat

Also the WebSphere logging will need to be changed accordingly as shown below:



Figure 23: Change WebSphere logging

These changes will take affect only after WebSphere restart.

Note: Level ALL will give the full details of Trickle including any mapping and Authorization.

Web Sphere Logs: WebSphere logs should also be checked in case there is any Application level Issues: “D:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1\”

- SystemErr.log- SystemOut.log

2.3.7.2 Returns authorization trickle logs

When using fail over application server for Returns Authorization; It is best practice to use the back upApplication server to trickle POS Tlogs.the The logging file “Engine.log.0” as defined above have the tricklelog.

Note: SAP EMT Trickle APM does not support failover configuration. But it is best practice to configure SAPRA Backup application server as Trickle server; so that in normal conditions RA Primary Application serverprocess’s Refunds while RA Backup Server process’s POS Tlog trickle.



2.3.7.3 Returns authorization CDL logs

Returns Authorization CDL Logs: Common data load can be found on database server at“C:\SAP\ReturnsAuthorization\logs\LoadLog.txt.0”. The configuration for this logging is at“C:\SAP\ReturnsAuthorization\logs\Logging.properties”. Full logging for data parser can be turned on bychanging Data mapping (SAP_POS.xml)’s following tag <Debug LogDebugInfo="yes"/>.

Figure 24: Returns authorization CDL logs

2.3.8 Troubleshooting returns authorization: Understanding POS error messages

Possible errors and what/where to look for more details.

2.3.8.1 Auto approved refund at POS

There may be a multiple reasons for this message: Communication Failure between POS-Transnet-Returns Authorization because of any of following;

- Physical connection problems between POS – TN - RA



- Any change in TCP IP communications, DNS, IP addresses etc.- SAP EMT or SAP RA Services on POS and Transnet are stopped- IBM WebSphere Application server hosting Returns Authorization is running- From SAP RA web interface try using Administration\POS Simulator

Encryption Key issues at Returns Authorization;- SAP POS sends a refund request for a manual refund by scanning or entering Items (the original

transaction was not found)- POS may have different Encryption Key than RA- RA does not respond to SAP EMT and the request times out at POS as well as SAP EMT

Look at the engine.log.x for following error message:

2009-04-08 15:36:55,547Z [ORB.thread.pool : 0] WARNING{com.triversity.expressReturns.authorization.AuthEngineBean} - RefundParseException occurredwhile parsing request: com.triversity.security.service.GeneralTWSecurityException: No valid keyfound: VR=2.5;KT=D2D3ADA1-7BA8-46C1-9C63-4FDF915A0601;TT=00;TS=0001;TR=0001;TN=1501;RD=090408;RH=125541;CN=5555;EF=0001010087;MT=00;MS=S;MN=cRxpEzAmSBk=;MQ=cRxpEzAmSBk=;OD=000000;OS=000;OR=00;ON=0000;OZ=S;FI=00000000000000000000;IT=00;IS=2;IQ=00001000;IP=00000200;IU=000:

- Look at the logs on Transnet Server at following location“C:\Program Files\SAP\Transnet\logs\ log.txt” and if the error looks like ;---“

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:java.rmi.RemoteException: ; nested exception is:java.lang.NullPointerExceptionatcom.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:64)at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)

atcom.triversity.expressReturns.authorization._AuthEngine_Stub.authorizeRequest(_AuthEngine_Stub.java:247)

at com.triversity.transnet.xtension.xreturn.DirectExpressReturnsAdapter.respond(Unknown Source)at com.triversity.transnet.core.tms.connection.TNMessage ………………………..“

Key used at POS is not imported in Returns Authorization Key container. Follow the process developedduring implementation to synchronize the Security Keys between POS and RA; Database Server not Running or Database is in suspect mode

2.3.8.2 Failed to retrieve transaction details from RA

This message may show up when cashier tries to pull original transaction for refund by either scanning thebar code or manually entering Original transaction information.



The reasons may be - Cashier inputs wrong original transaction information for Original Sales Transaction. The original transaction was not loaded to RA data base because of :

- Communication failure- Encryption issues- Data mapping is out of synch (POS configuration has changed)

Check the Returns Authorization Log “engine.log.0”. Load this store’s Tlog using the Batch process.

2.3.8.3 Transaction not found

This message may show up when cashier tries to perform manual refund by manually entering scanningitems instead of picking items from the original transaction. And Original transaction is not found in the database.

The reasons may be – Cashier inputs wrong original transaction information for Original Sales Transaction. The original transaction was not loaded due to:

- Communication failure- Encryption issues- Data mapping is out of synch (POS configuration is changed)

Check the Returns Authorization Log “engine.log.0” and load the Tlogs from this store.

2.3.8.4 Invalid data in RA response – Please retry

This message may show up for one of the following reasons Encryption Key container out of synch with POS keys POS is not able to decipher the TLOG information to create the original transaction for a refund



2.3.8.5 Refund declined LINE ITEM SKU MATCH FAILED

Reason for this Error message could be one of the following This Item has no sales history in the returns database, which means this item was never sold in the whole

chain in last XXX days. Therefore, this item cannot be returned. The POS message sent to Returns Authorization does not have required information (MT). To resolve this

refer to the returns Authorization Administration guide.

2.3.8.6 Refund declined original store day not POLLED

This message may appear because: Trickle from original store failed and hence data was not loaded by trickle Original store where the transaction was rung did not poll for that day and Batch process did not load any

data for this store

2.3.8.7 Refund declined same day return – Transaction number ERR

Reason for this type of behavior may be because of The transaction to be returned is not trickled\loaded to the database; while some transactions after this

transaction for this store was trickled; Same day return logic is kicked in.



2.3.9 System monitoring

Returns Authorization is a Transaction processing system and will need consistent monitoring. At the momentSAP Standard monitoring tools (mySAP or CCMS) are not integrated with system that can be used.

2.3.9.1 Database (server) monitoring

The database needs to be monitored every day. Some information that can be used to validate the data feedand appropriate steps in case there are any discrepancies: Data loaded to following tables should be compared to the information available from Stores as reported in

BI or other host application- original_tran group by Store_no, Sales_Date, Trans_Type- refund_tran group by refund_Store_no, Refund_Sales_Date

CDL Logs should be checked. Database health space available and database backups are up to date;

2.3.9.2 Application monitoring

Application Logs can be configured to different levels. For Production systems, these logs should be kept to awarning or Error level only. The log size should be appropriately configured so that the files do not getrecycled before weekly scheduled maintenance.

2.3.9.3 Weekly maintenance

IBM Websphere Server service should be recycled every preferably every week or biweekly. Engine.log.Xshould be moved away and backed up to a safe location.

Verify weekly database back up schedules.

CDL Logs should be moved and backed up to a safe place

2.3.9.4 Database growth monitoring

Database growth will need to be monitored. If the systems is tuned for 90 to 180 days data retention, thedatabase d size should stabilize after this time period. Make sure that database transaction logs are gettingtruncated with scheduled backups.

Note: One task of the everyday CDL batch load process is to purge data for rolling number of days as perconfiguration.

2.3.10 Disaster recovery

In case the system needs to be rebuilt from scratch use the following process: Rebuild Returns Authorization application server Rebuild Returns Authorization data base server Recreate the encryption key container Import the POS encryption keys Import Returns Authorization encryption keys Replace the RA database with the one from back up



2.3.11 Monitoring objects for returns authorizationMonitoring Object Selection Criteria Alert Analysis Tool onMonitoring Object Selection Criteria Alert Analysis Tool

on SatelliteSystem


POS register Depends on errormessage

Error message Troubleshoot asdescribed in2.3.8

Situational

Engine.log.0 Use most recentlog file

Application notresponding asexpected atPOS register ortrickle issuesoccurring

Text editor The log is recycled, makesure the file size and filenumber is enough tocapture everything formonitoring frequency (3days) in warning mode.

Loadlog.txt.0 Data Loading NA Text editor Daily

Returndb Database NA NA MS SQL server Weekly


2.3.12 Business process P06: Processing messages in PI and transferring the data to POSDM

2.3.12.1 Description

Once the FTS has placed the files in the directory defined in SAP PI in the communication channel, the filesare automatically picked up by PI and treated. The file is read, transformed into XML and a message mappingis carried out according to the target interface determined for the corresponding process flow. The relevantinterface names start either with GM* or TGM*. These interface names can be used to restrict the monitoringtransaction PI offers.


Error monitoring

The status of the PI messages can be can be monitored in transaction SXMB_MONI in the ABAP stack or theRuntime Workbench on Java. Additionally, the file adapter placing the files should be monitored with theruntime workbench. The monitoring is critical as untreated messages or unsuccessful messages will result inmissing data in POS DM. In order to automate monitoring of the messages, a message based alerting withSAP Solution Manager can be set up. Also for the adapter framework alerts can be configured which canthen be integrated in a Solution Manager BPMon. Please see the Interface Monitoring Setup Guide availableunder http://service.sap.com/bpm for details.

Performance monitoring

All messages need to be processed usually in a timely manner in order to update the information in POS DMas soon as possible. The message processing runtime can be monitored using SAP Solution Manager.

http://service.sap.com/bpm



2.3.12.3 Monitoring objects

MonitoringObject

SelectionCriteria


MonitoringFrequency /Data Collection

Message status Interfaces:GM* and TGM*

Messages in error SXMB_MONI in PI orRuntime Workbench

Frequently duringprocessing

File AdapterStatus

File Adapter Adapter showserror

Runtime Workbench ->Component Monitoring ->Adapter Engine ->Communication ChannelMonitoring


2.3.13 Business process P07-P08: Processing POS data with POS DM and SAP for Retail

2.3.13.1 Description

The monitoring processes for POS DM is documented in a separate publication “Manage Operations for SAPfor Retail – POS Inbound”available under http://service.sap.com/solutionmanagerbp

http://service.sap.com/solutionmanagerbp



2.4 Appendix A – SAP POS Parameter Files

Parm file extension Parm file name Description Type

.aky auxkey.aky PLU Cross Reference Database File D

auxkey.idx PLU Cross Reference Index File I

.clg cashier.clg Cashier File B

.cat category.cat Department Category B

.cdv chkdgt.cdv Checkdigit Configuration file B

.lst choice.lst Choice List Configuration file B

.cus custdisp.cus Customer Display Configuration B

.dpt dept.dpt Depar tment Configuration file B

.dsc discount.dsc Discount Configuration file B

.emp employee.emp Employee Configuration file B

.ftn firstten.ftn First Tennessee Credit file B

.aky auxkey.aky PLU Cross Reference Database D

auxkey.idx PLU Cross Reference Index File I

.clg cashier.clg Cashier File B

.cat category.cat Department Category B

.cdv chkdgt.cdv Checkdigit Configuration file B

.lst choice.lst Choice List Configuration file B

.cus custdisp.cus Customer Display Configuration B

.dpt dept.dpt Depar tment Configuration file B

.dsc discount.dsc Discount Configuration file B

.emp employee.emp Employee Configuration file B

.ftn firstten.ftn First Tennessee Credit file B

.fnp funcprot.fnp Back Office Protect file B

.grp group.grp Department Group B

0.101 keyboard.101 Standard PC 101 Key Enhanced B




.dec keyboard.dec DEC Alphanumeric Keyboard B

.dyn keyboard.dyn NCR Dynakey Keyboard B

.ib1 keyboard.ib1 IBM 50 Key Keyboard B

.ib2 keyboard.ib2 IBM Alpha Numeric Keyboard(ANPOS) B

.ib3 keyboard.ib3 IBM “New” Alpha Numeric B

.k52 keyboard.k52 NCR 7052 and 7450 Full Alpha B

.k54 keyboard.k54 NCR 7054 Alpha Numeric B

.kmp keyboard.kmp NCR 7058 and 7052 50 Key B

.omr keyboard.omr Omron 135 Key Keyboard B

.ppc keyboard.ppc Power PC POS Keyboard B

.uc1 keyboard.uc1 UCS Preh Keyboard B

.ull keyboard.ull Ultimate Keyboard B

.lvl levelqty.lvl Price Level/Quantity Cluster D

levelqty.idx Price Level/Quantity Cluster I

.lic license.lic Software License file B

.lnk link.lnk Linked SKU Database file D

link.idx Linked SKU index file I

linkidx2.idx Linked SKU index 2 file I

.blt literal.blt Back Office Literal File B

.lit literal.lit POS Literal file B

.lcm locom.lcm file for setup of RS-232 Server Only A

.xnn macro.xnn Macro file (from x.01 to .x99 are supported) B

.mnu menus.mnu Menu Definition file B

.mgr mgrcode.mgr Manager Codes for POS B

.mdm modem.mdm Supported Polling Modem list B

.cmd modemcfg.cmd Credit Modem Configuration file B

.nab nabanco.nab Nabanco Credit Service B




.ndc ndc.ndc National Data Corp. Credit B

.neg negative.neg Negative File Database file D

negative.idx Negative File Index File I

.cnw network.cnw Credit Network Configuration B

.non nonmerch.non Non Merchandise Configuration B

.pcf plucfg.pcf PLU Configuration file B

.plu pludata.plu PLU Database file D

.pi1 pluidx1.pi1 PLU index file indexed by PLU D

pluidx2.pi2 (Second PLU index no longer used) A

plupost.plt Post Dated PLU ASCII updates (system generated) A

.ini pos.ini POS configuration A

.rpv positive.rpv Positive File Database file D

positive.idx Positive File Index file I

.inq profile.inq Profile Prompts Configuration B

proidx.idx Promotion Index file I

.pro promo.pro Promotion Database file D

proxref.idx Promotion Cross Reference I

.lpr prtlines.lpr Print Lines Configuration File B

.lim qtylimit.lim Limited Quantity configuration B

.rcp rcptlogo.rcp Receipt Header and Footer B

.reg regparm.reg Register Parameters B

.rrt regrept.rrt Automatic Register Report Print B

.rcm remtecom.rcm Polling Modem configuration file B

.spt setport.spt Serial Port/Address/IRQ settings A

.tar tareght.tar Tare Weight configuration file B

.tax taxtable.tax Tax Table configuration file B

.tdr tender.tdr Tender Table Configuration file B




.udt udtxn.udt User defined Transaction B

D: Btree Database *

I: Btree Index file **

B: Binary file

A: ASCII file

* Btree database files are generally used by the POS only. The Server will use the SQL database.

** Index files may be deleted after the pos or server is shut down. The system will automatically regeneratethe file once it is resumed.



2.5 Appendix B – SAP POS Apply Files

File Name Description Comments

PRODUCT.ASC Full PLU file Deprecated in favor of PLUTXN.ASC

PLUTXN.ASC orNNNNRR00.PAT

PLU file update records

PROMOTXN.ASC orNNNNRR00.PAO

Promotional file update records

DEPT.ASC ORNNNNRR00.DTA

Department file records Deprecated in favor of Depttxn.asc

DEPTTXN.ASC Department file update records

GROUP. ASC ORNNNNRR00.GPA

Department group file records Deprecated in favor of Grouptxn.asc

GROUPTXN. ASC orNNNNRR00.GPA

Department group file updaterecords

CATEGORY. ASC orNNNNRR00.CTA

Category file records Deprecated in favor of Grouptxn.asc

CATTXN. ASC orNNNNRR00.CTA

Category file update records

TAREWT.ASC Tare weight

POSITIVE.ASC Full positive file Deprecated in favor of Postxn.asc

POSTXN.ASC orNNNNRR00.PSA

Transaction positive file

NEGATIVE.ASC Full negative file Deprecated in favor of Negtxn.asc

NEGTXN.ASC orNNNNRR00.NAT

Transaction negative file

PRICETXN. ASC orNNNNRR00.LVA

Price level/quantity transaction filerecords

XREFTXN. ASC orNNNNRR00.AAT

Cross reference file records

EMPLOYEE.ASC Full employee file Deprecated in favor of Empxtxn.asc

EMPXTXN.ASC orNNNNRR00.EMT

Transaction employee file

TAXTABLE.ASC orNNNNRR00.TXA

Tax tables




MIXMATCH.ASC orNNNNRR00.MXA

Mix match table

SSSSNNNN.ORR Inventory Purchase order file Placed in DNLOAD directory of XPS

SSSSNNNN.RCV Inventory Receiving file Placed in DNLOAD directory of XPS

SSSSNNNN.IVP Inventory count file format Placed in DNLOAD directory of XPS

SSSSNNNN.CTG Inventory Order book Placed in DNLOAD directory of XPS

SSSSNNNN.XFI Inventory Store transfers in Placed in DNLOAD directory of XPS

SSSSNNNN.XFO Inventory Store transfers out Placed in DNLOAD directory of XPS

VENDSKU.ASC Vendor/SKU file format

VENDOR.ASC Vendor file format

STORE.ASC Store file format

INVNCONT.ASC Inventory control file

BUCKET.ASC Inventory bucket definition

BUCKETMV.ASC Inventory bucket movement

CUSTTXN.ASC Customer file format

CUSTSTTY.ASC Customer status type

DENOM.ASC Tender denominations

TDRASC.TXT Tender

BINTXN.ASC Debit BIN

PLUTXN2.ASC PLU supplemental update

LOYALPRO.ASC Loyalty program

LOYALELG.ASC Loyalty Program Eligibility

CUSTPTS.ASC Customer Pints Update

DISCTXN.ASC Discount file update

DISCINEX.ASC Discount inclusion/exclusion

SAFE.ASC Safe ID records

JTDTXN.ASC Jurisdiction tax tables




JTIDTXN.ASC Jurisdiction ID table

JURTXN.ASC Jurisdiction table

LTYPRO.ASC Loyalty program table

LTYPROEL.ASC Loyalty program eligibility table

CUSTPTS.ASC Customer points for loyalty table

LTYCOM.ASC Loyalty component configurationtable

LTYALLEG.ASC Loyalty Allegiance configurationrecord

PARMDEF.ASC Backoffice parameter definition table

PARMFMT.ASC Backoffice parameter format table

PARMVAL.ASC Backoffice parameter value table

BATCHSET.ASC Price batch management setup fileformat

BATCHCHG.ASC Price batch file format

SUPPTYPE.ASC Supplemental code types file format

SUPPCODE.ASC Supplemental codes file format

SUPPCONT.ASC Supplemental codes contents fileformat

SUPPATTR.ASC Supplemental attributes definition fileformat

SUPPDATA.ASC Supplemental data file format

ATTSETUP.ASC Attribute setup file format

SUPPDATA.ASC Payroll periods file format

Table 24: SAP POS apply files



2.6 Related Best Practice Documents

There are several other Best Practice documents available on SAP Service Marketplace underhttps://service.sap.com/solutionmanagerbp that relate to this Best Practice document. These documents are:

General Business Process Management: This document explains the procedures you should use tocreate a general Business Process Management concept. This includes the definition and documentationof the core business processes, definition of monitoring objects, definition of monitoring activities includingerror handling procedures, monitoring tools, monitoring frequencies, the definition of communication andescalation procedures and the assignment of responsibilities.ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus onALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitorALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoringapproaches aim to detect any irregularities or deviations or to detect error situations at an early stage.Job Scheduling Management: This Best Practice provides a detailed description what SAP recommendsas a standardized formal process to support a job request process, including an end user job request formand an approval process. This integrated process will avoid error-prone and time intensive manualprocesses of copying redundant data from one data source to another (for example, MS excel to MS Excelor MS Excel to job scheduling tool).SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a BusinessProcess Monitoring concept for your SAP ERP solution. The concept aims to define procedures forbusiness process oriented monitoring and error handling and escalation procedures for your company’sERP core business processes. These procedures intend to ensure a smooth and reliable flow of the corebusiness processes so that your business requirements are met.Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set upbackground job monitoring properly in the framework of Business Process Monitoring in the SAP SolutionManager.

Please note that these documents are also available in the SAP Service Marketplace using alias “RunSAP” RunSAP Best Practices.Returns Authorization Install and Security Guide can be found in SAP Support Portal: Install and upgradeguides Industry solutions RetailReturn Authorization User Guide from SAP Help Portal http://help.sap.com: Documentation SAP forIndustries SAP for Retail SAP Returns Authorization 2.6

2.7 Other Related Documents

2.7.1 SAP POS 2.1

Technical Referencehttp://help.sap.com/saphelp_pos21/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm;Go to Technical Product Reference TLOG Data Capture Formats

Configuratorhttp://help.sap.com/saphelp_pos21/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm,Go to Head Office Functions Store Configurator

Security Guide (TGM 10.1)https://websmp107.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000401180 -> Industry SecurityGuides -> SAP Transactionware GM: Security Guide

https://service.sap.com/solutionmanagerbp

http://help.sap.com/

http://help.sap.com/saphelp_pos21/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm;


https://websmp107.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000401180



Installation Guide:http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000720437&_SCENARIO=01100035870000000202& (Go to Components, here you also find the Security Guide)

CEFT User Guidehttp://help.sap.com/saphelp_pos21/helpdata/en/5a/70efcec69e4a67a1bfbdedc690a2a5/frameset.htm

Returns Auth 2.6:http://help.sap.com/saphelp_pos21/helpdata/en/0e/9fed1ecc864a83bcbb8d007162e307/frameset.htm

2.7.2 SAP POS 2.2

Technical reference:http://help.sap.com/saphelp_pos22/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm:Go to Technical Product Reference TLOG Data Capture Formats

Configurator:http://help.sap.com/saphelp_pos22/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm

Installation/Security Guide:https://websmp107.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000708894&_SCENARIO=01100035870000000202&;Go to Components, choose SAP Transaction Ware GM

CEFT 1.9:http://help.sap.com/saphelp_pos22/helpdata/en/5a/70efcec69e4a67a1bfbdedc690a2a5/frameset.htm

http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000720437&_SCENARIO=0110003587


http://help.sap.com/saphelp_pos21/helpdata/en/0e/9fed1ecc864a83bcbb8d007162e307/frameset.htm

http://help.sap.com/saphelp_pos22/helpdata/en/be/5234a9eb44494ea0807925211e74c6/frameset.htm:






Index of FiguresFigure 1: Outbound process flow 6Figure 2: View recent plan activity 9Figure 3: View details of a plan 10Figure 4: Samples of TLOG records 12Figure 5: Example of an apply log 14Figure 6: Store administration 17Figure 7: Monitor terminals 18Figure 8: Re-attach the connection between the server and the Store Manager 19Figure 9: Server connection 20Figure 10: POS in-store process flow 25Figure 11: Typical decision patterns for troubleshooting 29Figure 12: POS Inbound process flow 30Figure 13: Client Monitor 30Figure 15: Select scheduling/plan activity 30Figure 16: View details of any plan 30Figure 17: Integration of all involved SAP components for returns authorization 30Figure 18: Data mapping for trickle (1/2) 30Figure 19: Data mapping for trickle (2/2) 30Figure 20: Data mapping for CDL (1/2) 30Figure 21: Data mapping for CDL (2/2) 30Figure 22: Start IBMWAS6Service 30Figure 23: Start batch data load 30Figure 24: Change WebSphere logging 30Figure 25: Returns authorization CDL logs 30

Index of TablesTable 1: POS outbound process P02 – Monitoring objects 8Table 2: POS outbound process P03 – Monitoring objects 10Table 3: Fields to note in the TLOG 11Table 4: Format of apply logs 13Table 5: POS outbound process P04 – Monitoring objects 15Table 6: Troubleshooting using SAP POS logs 16Table 7: Flags 23Table 8: POS outbound process P05 – Monitoring objects 24Table 9: In-store applications 30Table 10: Batch files for AppSight 30Table 11: Store level processes – Monitoring objects 30Table 12: POS inbound process P01 – Monitoring objects 30Table 13: POS inbound process P02 – Monitoring objects 30Table 14: POS inbound process P03 – Monitoring objects 30Table 15: Register daily total files 30Table 16: Store daily files 30



Table 17: Consolidation/close terminal/end of day error codes 30Table 18: Communications error codes 30Table 19: File transfer error/status codes 30Table 20: General error/status codes 30Table 21: POS inbound process P04 – Monitoring objects 30Table 22: POS inbound process P05 – Monitoring objects 30Table 23: POS inbound process P06 – Monitoring objects 30Table 24: SAP POS apply files 30



© Copyright 2009 SAP AG. All Rights ReservedNo part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.

Manage operations for sap pos

Documents

Transcript of Manage operations for sap pos