SRS Technical and Functional Description en

Integrated Retail Store
Management System
A Technical and Functional Description
February 2013
SingularLogic Retail System Release 2 - A Technical and Functional Description
CONTENTS
INTRODUCING THE SINGULARLOGIC RETAIL SYSTEM ............................................................ 5
THE STRUCTURE OF THE PRODUCT................................................................................................. 6
MAIN SRS/FRONT-OFFICE SYSTEM ........................................................................................................... 7
ADDITIONAL SRS FRONT-OFFICE MODULES ............................................................................................. 8
MAIN SRS STORE BACK-OFFICE SYSTEM .................................................................................................. 9
ADDITIONAL SRS/BACK-OFFICE MODULES............................................................................................... 9
MAIN SRS HEADOFFICE SYSTEM ............................................................................................................... 9

SYSTEM TOPOLOGY AND ARCHITECTURE .................................................................................. 11
BUSINESS BENEFITS OFFERED BY SRS .......................................................................................... 15
INTRODUCTION TO SRS TECHNOLOGY ........................................................................................ 17
ARCHITECTURE, OPERATIONAL PLATFORMS AND DEVELOPMENT TOOLS ................... 18
SINGULARLOGIC APPLICATION SERVER (SAS) ........................................................................................ 19
SAS Identity ......................................................................................................................................... 19
SAS Implementation Methodology ....................................................................................................... 19
Main SAS benefits ................................................................................................................................ 20
SRS DEVELOPMENT TOOLS...................................................................................................................... 22
Embarcadero Delphi XE ..................................................................................................................... 22
Sencha Ext JS ...................................................................................................................................... 22
MAIN TECHNOLOGICAL AND OPERATIONAL CHARACTERISTICS .............................................................. 23

SRS/FO-POS MODULE ........................................................................................................................... 24
INTRODUCTION ......................................................................................................................................... 24
FUNCTIONALITY ....................................................................................................................................... 24
Selling .................................................................................................................................................. 24
Payment ............................................................................................................................................... 26
Other functions .................................................................................................................................... 27
Document Issuing ................................................................................................................................ 28

SRS/FO-COM MODULE ......................................................................................................................... 30
INTRODUCTION ......................................................................................................................................... 30
FUNCTIONALITY ....................................................................................................................................... 30
SRS/FO-KERNEL MODULE .................................................................................................................. 32
INTRODUCTION ......................................................................................................................................... 32
04/02/13 Rev. 7 2 © 1998-2013 SingularLogic SA. All Rights Reserved

FUNCTIONALITY ....................................................................................................................................... 32
ADDITIONAL SRS/FO MODULES ....................................................................................................... 41
SRS/FO-PLU DEVICES ............................................................................................................................ 41
General PLU Device Support Parameters .......................................................................................... 41
Electronic Scales Support .................................................................................................................... 42
ESL Support ......................................................................................................................................... 43
Price-Checker Support ........................................................................................................................ 44
SRS/FO-CUSTOMER LOYALTY ................................................................................................................ 45
General Characteristics ...................................................................................................................... 45
Loyalty Programme / Campaign Customisation ................................................................................. 46
PoS functions ....................................................................................................................................... 47
Other functions and system extensions ................................................................................................ 47
Reports and Printouts .......................................................................................................................... 48
Examples of Customer Loyalty Offers ................................................................................................. 49
SRS/FO-DUTY FREE SUPPORT ................................................................................................................. 52
SRS/FO-STORED CREDIT ......................................................................................................................... 52
General Characteristics ...................................................................................................................... 53
PoS Functions...................................................................................................................................... 53
SRS/BO-BASIS MODULE ....................................................................................................................... 55
INTRODUCTION ......................................................................................................................................... 55
WAREHOUSE AND ITEMS MANAGEMENT.................................................................................................. 55
Main functions ..................................................................................................................................... 55
Inventories package ............................................................................................................................. 57
PROCUREMENT MANAGEMENT ................................................................................................................ 58
Ordering .............................................................................................................................................. 59
Goods-receiving (purchases) - Invoice Control .................................................................................. 60
CASH-OFFICE MANAGEMENT ................................................................................................................... 62

ADDITIONAL SRS/BO MODULES ....................................................................................................... 64
SRS/BO-HANDHELD TERMINALS ............................................................................................................ 64
Introduction ......................................................................................................................................... 64
Main functions ..................................................................................................................................... 64
Additional functions............................................................................................................................. 65

SRS SYSTEM REQUIREMENTS ........................................................................................................... 66

SRS PRODUCT IDENTITY

INTRODUCING THE SINGULARLOGIC RETAIL SYSTEM
The SingularLogic Retail System (SRS) is an advanced functionality, state-of-the-art, fully
integrated software application that addresses the specialised management and
mission-critical operational needs of (chains of) sales stores and service providers, of
any size and line-of-business.
SRS was developed by the leading Greek business software manufacturer and is the outcome of
many man-years of effort incorporating the extensive experience of SingularLogic in designing
and building technologically advanced and operationally robust IT systems. In addition to the
"traditional" features of a state-of-the-art product (user-friendliness, rich functionality,
scalability etc.), SRS possesses all those special features required for the very demanding retail
environment, something that makes it one of the most advanced systems of its kind available
in the market today. Designed to provide the utmost reliability and information availability
combined with absolute deployment simplicity and unsurpassed flexibility and functionality,
SRS guarantees the quickest sales transaction turn-around, as well as the dependable handling
and automation of all the other in-store functions and operations of Front and Back Office
under the most adverse and intensive conditions.
In contrast to the majority of the systems in the market today, SRS is not a monolithic "shrink-
wrapped package". Furthermore, all current and future application functions are not
implemented as an "afterthought", but belong to a well-planned and consistent system
architecture that incorporates a future-proof basic design which encompasses virtually every
different vertical functionality front-end requirement in the retail business. The extensive
functionality of the main module (SRS/Front-Office) is supplemented by a series of
environment-specific extensions (e.g. for food supermarkets, cash & carry, convenience and
department stores etc.) or by "horizontal" sub-modules that provide, for example, full
automation of the store's warehouse tasks, special functionality of data keeping and
monitoring related to customer loyalty etc.
Despite the huge effort invested in designing and implementing the system, the nature of its
target environments demands constant functional enhancements, both in the standard system
(version and release), as well as in the customer specific modifications and enhancements.
Given the fact that SingularLogic is by itself a large corporation and a member of one of the
largest Group of companies in the country, it may not at first appear to be a dynamic and
responsive partner. On closer examination, it becomes evident that this in fact is one of the
strongest points of SRS. SingularLogic is one of the very few companies that consistently
displays a proven capability to bring its great flexibility and development capacity to bear when
addressing exactly these kinds of customer special demands and requirements.

GENERAL OVERVIEW OF SRS

THE STRUCTURE OF THE PRODUCT
The overall SRS product is divided into two main systems that cover the functional needs of
Front-Office (Sales) and of Back-Office (miscellaneous functionalities) respectively. These two
systems share the same database and collaborate between them, but they are also able to
operate totally independent from one another, exchanging data with other software products
available in the market. The core two systems are supplanted by a series of add-on modules
and sub-systems that target specific business/operational needs of retailers. Fully covering the
needs of the branches, SRS may be easily and effectively connected to any other central system
(ERP, Financial Management, Central Warehouse Management, Customer Relations
Management, Customer Loyalty Management etc.), covering the remaining needs of the
enterprise. The main structure of SRS is represented in the following figure.
Figure 1. SRS Application Architecture
One of the most important features of SRS is its capability to manage simultaneously numerous
stores with multiple warehouse locations (or «virtual» shop-in-shop stores) for each store, as
well as its fully multi-currency and multilingual operation features.

Finally, it should be stressed from the beginning that, the SRS mission is to provide full
operational and fiscal coverage for the needs of the stores (branches) exclusively, and not for
the needs of the enterprise as a whole. These are covered by the specialised for retail stores
Warehouse, Purchase, Sales and Central Counter modules. All other business needs (Financial
Management etc.) are covered by other central Information Systems (e.g. ERP), which
interchange data with the systems of the stores at regular intervals.
MAIN SRS/FRONT-OFFICE SYSTEM
The main SRS/FO system consists of the 3 following modules:
1. SRS/FO-PoS, the application software that runs on the PoS and

supports the entire range of cashier operations and functions. Its
main functionality is to ensure the quick and correct carrying-out
of the sales and to support the cashier-customer relation. It also
presents remarkable capabilities in managing all possible
difficulties that may arise during the sales procedure. This is
supported by the Graphical User Interface (GUI) which is fully
exploited by the SRS/FO-PoS module.
2. SRS/FO-Com middleware module, this module is the part of

SRS/FO-PoS which undertakes the fully fault-tolerant, two-way PoS
and Server communication and guarantees the dependability and
automatic synchronisation of all data exchanged over the network.
Also, it provides a number of management functions, making the
automatic software deployment for all connected PoS terminals a
simple and safe procedure. Due to its primary role in the system,
SRS/FO-Com can provide detailed status information and real-time
monitoring facilities of any PoS activity.
3. SRS/FO-Kernel, the basic store management application, takes on

the tasks of collecting and storing the transaction data coming
from the PoS terminals through the SRS/FO-Com module. At the
same time, it provides PoS clients with all information required for
the sales procedure. In addition, it also streamlines the cashier
reconciliation procedures and exports / imports all data to the
central database communicated to or from the central system at
the enterprise headquarters. Finally, it is supplemented by a
comprehensive assortment of financial and control reports on
sales, customer service and cashier productivity, with a wide
choice of different views (detailed or summary, statistical or
comparative with user-defined time periods etc.).
The three modules mentioned above constitute the minimum structural elements, necessary
for every installation of SRS. Licenses for SRS/FO-PoS and Com are combined and they are
charged per PoS, while those for SRS/FO-Kernel are charged per Front-Office PC.

ADDITIONAL SRS FRONT-OFFICE MODULES
Besides the basic and compulsory SRS/FO configuration, a series of modules are also available
which extend the functionality of the system, whenever required.
1. SRS/FO-PLU Devices provides the ability of connecting and on-line

updating price-checkers devices and electronic scales (networks),
as well as electronic shelf-labels systems. Thus, the PLU (Price
Look-Up) devices management is fully integrated and performed
by the system. Licenses are charged on the basis of the number of
the connected devices.
2. SRS/FO-Customer Loyalty supports the maintenance of additional

data regarding the existing customers profile and the sales made to
them, providing a wide range of identification and scoring methods
and mass or one-to-one marketing policy application, as well as
other sophisticated management tools. Customer loyalty data is an
integral part of the data-stream exchanged between the store and
the headquarters. Since this module extends the functionality of all
installed modules, licenses are charged on the basis of the total
number of Front-Office PC and PoS terminals.
3. SRS/FO-Duty Free Support adds all the system functions required

to cover the specialised needs of the duty-free and tax-free retail
environment. Licenses are charged as for the SRS/FO-Customer
Loyalty module.
4. SRS/FO-Stored Credit is the sub-system responsible for the

centralized management (creation, redemption, cancellation etc)
of any type of credit mediums on the system. These mediums can
take the form of a gift-voucher, a refund voucher etc. Licenses are
charged on the basis of the number of FO-PoS and FO-Kernel
terminals that need access to the module.
5. SRS/FO-Advanced Customer Loyalty is a next-generation complex

rules execution engine that takes the concept of Loyalty execution
on the next level. It provides the means to create highly
personalized loyalty experiences and awards and also doubles up
as a promotion and marketing communications “channel” for
consumers and customers. Licenses are charged as for the SRS/FO-
Customer Loyalty module.
6. SRS/FO-EFT Connect adds the capability to transparently and

efficiently manage EFTPoS transactions through SRS/FO-PoS
keeping the same level of control and operator accountability for
such transactions (credit card tenders, debit card tenders, bill
payments etc). Licenses are charged on the basis of the number of
FO-PoS and FO-Kernel terminals that are accessing EFTPoS
terminals.

MAIN SRS STORE BACK-OFFICE SYSTEM
SRS/BO integrates and extends the automation of all store procedures at the points located
«behind counters». The main functions of the basic SRS/BO-Basis module are the following:
 Warehouse and Storage location Management (inventories, stock control,

books and miscellaneous Warehouse reports, miscellaneous Warehouse
documents issuing etc.).
 Purchase Management (Orders, Receipts, Invoices, Purchase documents

issue).
 Store till management (miscellaneous receipts – expenses, cashier

reconciliations, deficits - surpluses as well as miscellaneous tax and information
reports, control and reconciliation reports).
Licenses are charged on the basis of the total number of PC's using the system.
ADDITIONAL SRS/BACK-OFFICE MODULES
The additional SRS/BO-Handheld Terminals module automates a wide range of store functions
regarding orders, receipts and warehouse (e.g. inventories) and in general the transfer of goods
using portable terminals1. It consists of the necessary communication functionalities with the
terminals (upload – download) and their respective software, developed entirely by
SingularLogic. Licenses are charged per portable terminal.
A series of other modules will be added in the future in order to cover specialised needs of
vertical markets back-office (e.g. fast-food restaurants, petrol stations etc.).
MAIN SRS HEADOFFICE SYSTEM
A typical SRS installation includes a number of SRS clients at the customer’s central offices.
These usually comprise PC’s with SRS/FO-Kernel used in a variety of reporting, controlling and
IT-related work. Apart from SRS/FO-Kernel itself, SingularLogic deploys the SRS/HQ product
that can be used for the following specialized tasks:
 PoS screen design and management. SRS/FO-PoS has the capability to work
as a Graphics-intensive terminal that can be touch-enabled (or not) and can also
employ a second customer-facing graphics screen. All screen elements are user-
defined and SRS can support different screen layouts for each PoS
 Advanced Customer Loyalty Offer management. SRS/FO-Customer Loyalty

has complex execution rules and can also be used as an efficient promotion
execution engine. From SRS/HQ, a user can create new campaigns or change
1
For portable terminal types that are supported, see System Requirements p.66. Contact SingularLogic for the last updated list of
models and types.

existing ones. He can mix and match existing campaign elements to speed-up
campaign creation
SRS/HQ is a native SRS client and all the above tasks are performed on the same database,
ensuring the same level of trouble-free, automatic communications with all stores as for the
SRS/FO-Kernel functions.

SYSTEM TOPOLOGY AND ARCHITECTURE

The unsurpassed flexibility of the system is immediately apparent from the great number of
site deployment variations that are possible. The basic configuration consists of an Ethernet
LAN, a server and a number of PoS terminals. Depending on the customer's needs this basic
set-up can be extended to include:
 Additional PC's in a variety of roles (Invoicing and miscellaneous documents

issue, miscellaneous Back-Office functionalities, store monitoring and
controlling, reporting etc.)
 Price-checkers, electronic scales and electronic shelf-label networks
 Hand-held terminals
 Connections to other local or remote systems.
Furthermore, all or a number of PC's and PoS terminals may be

configured with an additional electronic scale or a scanner / scale, a
printer, a security device deactivator etc.
The installed SRS computing power and availability features can be enhanced by using
commercially available RAID devices, or by separating the various modules to run on different
machines. It should be stressed that in case of server or LAN failure, the SRS/FO-Com
middleware module guarantees absolute fault-tolerant and uninterrupted operation of PoS,
since all the data required for the sales procedures are continuously and automatically copied
to every PoS terminal local hard disk. The only limitation in such an unfortunate situation is the
lack of continuous data synchronisation between Server and PoS clients, something that occurs
fully automatically and transparently to the end users when the breakdown or damage is
resolved. Of course, this feature can also be exploited in order to add extra and network-
independent PoS to the store to cope with, for example, Christmas period peaks or support
special outdoors promotions. In the figures that follow, three different SRS configurations are
presented.

In the first case, we see a very simple installation consisting of a server and a number of PoS
terminals and electronic scales. All the store management functions as well as invoice issuing
are performed at the server. The selling goods and payment procedures always take place at
the PoS terminals.
Figure 1: SRS Configuration (Example 1)
The second example presents a more complex installation with an additional PLU device fleet
(price-checkers), some wireless handheld terminals and two PC's. The first PC is installed in the
checkout area and is equipped with a printer and a scanner (a cash drawer is also possible).
This PC is a dedicated Invoicing station, justifiable in medium and large stores. With this
configuration, the invoices may be issued and paid for in three different ways:
1. Scan and pay at the PoS, print the invoice at any PC client
2. Scan, pay and print the invoice at the dedicated PC
3. Scan, pay and print the invoice at the PoS using an extra local
printer if needed.
The second PC (Manager’s Station) is used in this case as a reporting and monitoring /
controlling workstation (used by the store's chief cashiers and managers). In addition, it has the
task of printing shelf labels.

SRS clients are equivalent stations of the network and have the same
rights and capabilities. By utilising the various security levels and user
roles provided, the system administrator can assign only the authorised
functions to each user. This also means that the roles of "Invoicing",
"Monitoring" etc., are completely interchangeable and customisable to
reflect the needs of the store at any given time. SRS imposes no
practical limits on the number of connected PC clients or PoS terminals.
Figure2: SRS Configuration (Example 2)
The capability of the SRS/FO-Com middleware module to function in a distributed way (e.g.
over a WAN with various PoS terminals at different remote sites), allows for very flexible
system architectures. This provides the possibility of supporting many stores with only one
remote server. This implies minimum administrative and ownership costs.
These remote connections can either be permanent or on demand at the time when data
synchronisation is required to occur. Hence the costs of the two-way communication can be
controlled in an optimal way according to the varying needs of the enterprise and also can
cater for intermittent and low-quality internet-based connections. A number of different
configuration possibilities are available to meet these specific needs.

A fully distributed topology is displayed in the following figure.
Figure 3: SRS Configuration (Example 3)
SRS is installed to a remote server, not just from the PoS terminal it supports, but also from the
central Information system at the headquarters. Another possibility is a "hybrid" store where
the server has under its control a number of local and remote PoS terminals. The presence of
SRS server at the headquarters implies that PoS clients are connected remotely (SRS/FO-
PoS&Com), but the rest of the Front & Back Office software runs connected directly to this
server.
Finally, in the case of very large installations it is possible to utilise a completely separate
database server so that, besides the safe handling of large amounts of data, it becomes more
feasible to use sophisticated third party tools to support the reporting, analytical, data mining
and other OLAP technologies.

BUSINESS BENEFITS OFFERED BY SRS

Since its introduction to the market, SRS has a well-proven track record currently operating at
thousands of retail sites of all sizes and types and supporting a total of more than 20,000 PoS
and PC terminals under the most demanding environments and conditions. Despite its large
installed base, SingularLogic is fully committed to the continuous improvement of the system
so that it always remains state-of the-art, both technologically and functionally.
It is not coincidental that over the years, SRS has successfully followed the emerging customer
requirements and needs, establishing itself as one of the most successful systems in this
specialised and mission-critical market segment. In the table that follows the main
characteristics of SRS and the resulting business benefits are summarised.

Main characteristics Business Benefits
Based on open architecture platforms and Ability of two-way data interchanges with all types of
design principles corporate central system (ERP, SCM, CRM etc.)
Utilisation of the latest technological Interoperability with third party applications (e.g.
advances in software development tools and office automation)
techniques
Exploitation of all current and emerging e-business
Support of all widely accepted industry technologies (B2B and B2C), as well as EDI, Internet
standards etc.
Possibility to support advanced peripherals (e.g.

touch-screens, chip cards readers) and exploit point-
of-service technologies (e.g. multimedia information
kiosks).
Modular design– special vertical line of Unsurpassed flexibility

business modules
Full coverage of all the store needs
Rich functionality – possibility of
customisation to cover special needs Possibility of 100% coverage of customer's particular
needs
Full horizontal and vertical scalability Optimum total cost of acquisition and ownership
Hardware (e.g. PoS) and system software No loss of investment value over time – selection of
independence hardware suppliers on the basis of quality and cost
Innovative, fault tolerant, middleware Full, real-time store controlling and monitoring
module between the server and PoS
terminals Ultimate system availability
Easy-to-use, intuitive and foolproof sales Faster transaction turn-around

procedure
Increased customer satisfaction
Real-time data processing for all procedures Data security, integrity and accuracy
RDBMS-based data storage Quick and easy access to highly granular information
and high quality reports
Large, highly respected manufacturer Guaranteed roadmap and constant upgrade of the
product
Provision of high quality support services

SRS DETAILED DESCRIPTION

INTRODUCTION TO SRS TECHNOLOGY
For the development of SRS, SingularLogic employed modern but proven software design and
implementation tools and methodologies. Pursuing the dual objective of H/W independence
and total adaptability, SingularLogic implemented a concept that frees the customer from the
burden of system integration with legacy systems, totally protecting information technology
investments against depreciation over time. SRS customers will always be able to choose
between the best of breed H/W and system S/W, confident that SingularLogic will support
every major technological development as soon as it becomes available in the market.
The employment of advanced technological concepts and innovative ideas allows SRS to be
easily deployed in almost every type of retail environment or retail sale sector without practical
limits in the number of supported PoS terminals (from 1 to 100+), scaling and differentiating
the available functionality according to the customer's operating needs.
Finally, being a 3-tier resource driven system, means that SRS can be easily parameterised and
customised to particular, country-specific, functional, legal and language requirements.

ARCHITECTURE, OPERATIONAL PLATFORMS AND

DEVELOPMENT TOOLS
SRS is an open architecture client-server system designed using the Coad-Yourdon object
oriented methodology. The SRS/FO-PoS module follows model 5 according to Gartner Group
(distributed database) selected so that, in combination with the fault tolerance features of
SRS/FO-Com middleware, it ensures the autonomous and smooth operation of PoS terminals
even in the case of serious infrastructure failures or faults (server, LAN etc.). The SRS/FO and
SRS/BO modules follow model 2 (remote application) so as to minimise the data volume
interchanged between server and PC (clients) and to enable the operation in WAN, i.e. at
points remote from the server. The SingularLogic Application Server plays a major role in such
topologies (see «SingularLogic Application Server», Page.19)
Figure 5. Client Server Architectural Models
At any case, the end-users are presented with a well-designed, sharp and effective graphical
user interface (GUI) at all levels of operation. The SRS/FO-PoS software and all its modules run
on Windows XP, Windows Embedded versions or Linux, SRS/FO-Kernel client software and
SRS/HQ support all Windows flavours and basic functions can be furnished in a special browser-
based client.
The applications development tool used for the SRS development is Embarcadero Delphi XE
both at the server and the PC and PoS levels. The web-based clients are written on the Ext JS
JavaScript framework. The most well-known market products can be used as the system's
RDBMS, while their advanced security, recovery and high availability features are
complementary to those provided by the SRS/FO-Com software. In the case of a separate
database server, any operating system supported by the RDBMS of choice can be used. The
two-way, low-level communications middleware is developed and proprietary to SingularLogic
and fully exploits the broadly accepted, industry standard TCP/IP suite of protocols.

The totality of SRS software is based on the architecture and technology used for the
development of SingularLogic applications, SAS (SingularLogic Application Server).
SINGULARLOGIC APPLICATION SERVER (SAS)
SRS is one of the first products developed using the software applications architecture of the
SingularLogic. The corporate philosophy regarding the design of technologically advanced
solutions at all levels (even at the lowest one, whenever required) is also reflected on
SingularLogic Application Server (SAS). The reason leading to the SAS development (in contrast
to the market ready-made solutions) may not be obvious; therefore, it would be useful to
present a short analysis, in order to achieve a better understanding of the advantages offered
by the system.
SAS IDENTITY
As opposed to previous decades, contemporary IT companies are obliged to specialise in

specific domains and they have no longer the possibility to develop their own tools and
infrastructure products. SingularLogic was one of the first companies to realise that.
Unfortunately, there are still instances of this logic (also known as the "Not invented here"
syndrome), where commercial software developers rely on proprietary database systems and
support only “their own” communication protocols, while in some cases they may even use
their own programming languages! The SingularLogic Group never adopted such logic, and was
always in favour of the selection of the best of breed tool for each case. SingularLogic bases its
decisions on the accumulated knowledge of its engineers, which is utilised through the proper
exploitation and diffusion of information constituting the company's intellectual capital. The
corporate R&D Division stands at the top of these procedures, constituting the driving force of
the group both in tracing strategies and in ensuring the homogeneous implementation of
adopted standards throughout.
Since 2001, the R&D Division has initiated the design of the development platform that would
be used by the upcoming products of the Group. The requirements for this crucial system were
far-reaching and rigid and careful study revealed that a ready-made solution (such as
Microsoft’s DTC) could not be an option:
 Minimal hardware requirements
 High performance and speed
 Expedited deployment
 Portability to multiple operational environments
SAS IMPLEMENTATION METHODOLOGY
As mentioned above, the requirements for the new application development platform have
imposed its development within the Group. This decision makes SingularLogic one of few Greek
software developers that possess a proprietary infrastructure environment for the
development of 3-tier systems using distributed objects technology. As an additional benefit,

the need to obtain runtime licenses from third parties for the development and distribution of
any company product is eliminated, with evident advantages to the final customer.
Some regular features of commercial systems have been deliberately omitted, since SAS
focuses on supporting transparent representation, abstract network applications that make
extensive use of databases and / or other similar transactional environments. Put side by side
with other “distributed objects brokers”, SAS offers the same or more functionality regarding
these points, combining them with unsurpassed reliability. In this aspect, it is by far superior to
its “advanced”, “integrated”, “universal” competitors in the market.
The SAS implementation was based on the following two principles as far as portability is
concerned:
 Design specifications must be portable
 Implementation tools should be portable.
Obviously, the independence of the basic design paradigms was deemed more important than
the means used for their implementation.
For instance, the language (means) C++ is a widely popular tool with high portability
characteristics, but the possible use of COM+ technology in a system makes it fully dependent
to a single environment. The same would happen with a communication system based on the
"named pipes" protocol. Regardless of the programming language (means) used for its
implementation, the system cannot be ported to an operating system other than Windows.
The inherent SAS limitations are few since it was developed using the Delphi suite of RAD tools,
allowing its transparent use both in Windows and Linux environments. Certainly, business
objects that can be incorporated into SAS may be implemented in any language, provided that
this language supports communications via interfaces. SAS itself can be ported to any
programming language (syntactic translation) and operating system that supports object-
oriented development.
MAIN SAS BENEFITS
As mentioned above, SAS is a platform for the development of distributed objects applications
with special specifications. A comparison with DTC and CORBA or even with Enterprise
JavaBeans would reveal that none of the above systems cover the full spectrum of SAS main
features.
 Low bandwidth requirements. From all costs attached to implementing

WAN-based solutions or an ASP business model, the bandwidth capacity cost is
the most inflexible. This cost is not likely to decrease in the near future.
Furthermore, there are the additional reasons of medium availability, speed,
reliability and limited capability. No suitable infrastructure addressing all these
restrictions is going to be available, at least in the midterm.
 Low hardware requirements. The SAS structure is (especially in comparison

with other similar systems) very lightweight and requires limited system

resources from its host (which can be even a simple PC). The core SAS requires
only 4 MB of main memory to operate. Certainly, the objects it serves may have
their own (increased) requirements, but this is clearly an application and not to
an infrastructure issue.
 High performance. Due to the point above, SAS is also very fast. This is
achieved using «minimalist» solutions for protocols and user interfaces. In a
computer with a Pentium III/500MHz processor and 128MB of memory, SAS
achieves performance rates of 1,500 method invocations per second. This
implies that “real-life” system performance is limited only by the served object’s
optimisation level and RDBMS engine speed.
 Database independence. SAS is totally independent from the RDBMS used.

This is achieved by using abstract (and thus, portable) interfaces, which are not
related to specific technologies. In its first releases for Windows operating
systems, SAS internally utilises ADO objects, while direct access to most widely
known RDBMS engines (like Oracle and InnoDB) using native drivers support is
scheduled. In any case, the use of these technologies is fully transparent for the
application and direct access to them is possible but not recommended.
 Technology independence. SAS is an autonomous system. The only

requirement for its operation is a standard TCP/IP environment. SAS is not
based on ready-made solutions for method invocations and communication
(like ORB, DCOM, ADO, RMI etc).
 Support for a variety of object models. SAS supports objects of various

technologies. Internally, it supports one object form, native to Delphi, which is
both lightweight and efficient. In the Windows environment, it supports COM
and Java objects (Windows VM). The preferred object technology is certainly
that of Delphi, mainly because this guarantees object compilation and operation
in the Linux environment (and in any other environment supported by the tool)
without interventions to the code.
 Scalable performance in high-volume environments. SAS achieves high

performance in applications that require large data volume transfer, thanks to
its aggressive management of the available system resources (extended pooling,
dynamic allocation). A crucial factor in achieving and maintaining the speed and
the scalability of the system is the JIT (Just-in-time) possibility to activate objects
so that clients and server do not waste precious machine operation cycles and
communication resources to call / create and release their objects. SAS allows
the programmer to choose between stateful and stateless techniques for his
application. SAS also offers static load balancing and has also the possibility to
support dynamic scenarios. Contrary to other market solutions, SAS does not
require the use of additional front-end processors to achieve this, reducing
significantly the cost and the complexity of the solution.

SRS DEVELOPMENT TOOLS
EMBARCADERO DELPHI XE
As the first RAD (Rapid Application Development) environment to help developers easily use
and create emerging industry standard Web Services, Delphi enables the rapid development
and deployment of applications using XML- and SOAP-based Web Services technologies. Delphi
Web Services technologies speed e-business by enabling companies to automate the secure
sharing and exchange of business information over the Internet.
Embarcadero Delphi is the only RAD environment that supports emerging industry standards:
XML, SOAP, WSDL and XSL. Delphi also supports emerging Web Services-based vendor
platforms like Net and Biztalk from Microsoft, and ONE from Sun Microsystems, while
providing the scalability and reliability that enterprise and Web developers require.
Borland/Embarcadero designed the new Delphi framework, including BizSnap, WebSnap and
DataSnap, to enable faster time-to-market by simplifying business-to-business integration.
Delphi helps users build server-side and client-side applications that support Web Services
specifications through a fully integrated set of Web Service enabled visual tools, advanced
compiler technology and re-usable software components.
Embarcadero Delphi delivers performance rich graphical user interface (GUI) clients for
customers' CORBA or Enterprise JavaBean (EJB) server applications. Using the RAD Studio,
development teams can build rich GUI clients for VisiBroker for CORBA and AppServer
applications for EJB technology. Delphi extends customers' EJB applications as Web Services
enabling them to provide business-to-business integration to their customers, suppliers and
partners.
In addition, Delphi developers can build single-source applications for both Windows and Linux,
which opens new opportunities and increases the potential return on development
investments.
SENCHA EXT JS
Ext JS is a GUI framework for building complex and sophisticated JavaScript applications. It
features it’s own DOM and CSS manipulation libraries, as well as utility functions, and it's own
JavaScript-like language. The language, xjs, is essentially JavaScript with macros.
Ext JS includes a set of GUI-based form controls (or "widgets") for use within web applications:
 text field and textarea input controls

 date fields with a pop-up date-picker
 numeric fields
 list box and combo boxes
 radio and checkbox controls
 html editor control

 grid control (with both read-only and edit modes, sortable data, lockable and draggable
columns, and a variety of other features)
 tree control
 tab panels
 toolbars
 desktop application-style menus
 region panels to allow a form to be divided into multiple sub-sections
 sliders
 vector graphics charts
Many of these controls are able to communicate with a web server using Ajax.
Version 4.0 of the Ext framework was released on April 26th, 2011. It includes a completely
revised class structure, a revised data package, an animation and drawing package that uses
SVG and VML, and revised charting and theming. It also includes an optional architecture that
provides a model–view–controller (MVC) style of code organization.
MAIN TECHNOLOGICAL AND OPERATIONAL CHARACTERISTICS
The design of SRS and the technology on which it is based provide unique characteristics to the
application and offer to system administrators and to simple users very important advantages:
 On-line, Real-time operation of all modules.
 Data security and integrity.
 Interoperability with third party applications (e.g. office automation, report

generators etc.).
 Possibility of easy customisation for the full coverage of the current and
future customer needs.
 Possibility to exploit all the emerging and currently developed technologies

and especially e-business concepts, as well as EDI, Internet etc.
 Hardware independence and possibility to use advanced peripherals (e.g.

touch screens).
In conclusion, SingularLogic exploits advanced technology of every sector in order to offer to

the final user a state-of-the-art, easy to install and use, powerful and reliable information
system that covers all the operational and financial needs of the stores in the e-business era.


THE SRS/FRONT-OFFICE SYSTEM
SRS/FO-POS MODULE
INTRODUCTION
The SRS/FO-PoS software implements all the functions of the sales procedure and resides at
the PoS terminals. It is not required to be continuously on-line to operate properly. In fact, all
the data required for the sales procedure are copied to the PoS local hard disk. LAN or WAN are
used only for update / feeding of PoS clients with possible modifications of these data and for
the collection of sales transactions back to the server. In cases where flexibility matters most,
the SRS/FO-PoS software can be deployed in an off-line mode even for the entire trading day
(e.g. for outdoor sales) and be reconnected to the network after the store has closed, so that
data synchronisation is initiated. The appropriate data will then be exchanged with the server
automatically and in a completely transparent to the end-users manner, so that the PoS clients
continue operating normally without any operator intervention.
FUNCTIONALITY
SELLING
 Item posting can be performed through the scanner or the keyboard using
the item ID, barcode or generic Department code, or with a single-key "previous
item auto-repeat" feature. Unknown (not found) item barcodes are logged to a
special file for further processing.
 Data-entry of quantity / weight can be performed through an electronic

scale, the keyboard or by accepting the (user-defined) default value. Entry of
the quantity can be prohibited or compulsively required.
 It is possible to define various automatic and manual item discounts /

surcharges (percentage or fixed amount). Supervisor authorisation and / or
data-entry of a reason code may be compulsorily required (unlimited reason
codes can be set-up and selected from a drop-down list). Keyboard hot keys can
be programmed to perform percentage or fixed amount discounts (with
authorisation and reason-code options). Discounts can be given for specific
items in the transaction (full item navigation or barcode search) or at the
subtotal level.

 Coupon discounts (percentage or amount) can be given for any item in the
transaction (full item navigation or barcode search). Standard coupon barcodes
are automatically recognised. Option of manually entering the coupon quantity.
Coupon franking may be compulsorily required at data-entry time or at the end
of the sales procedure (en masse).
 A special "Gift" key gives discount equal to one unit of the last item entered
(provided the item has the appropriate parameterisation).
 Multi-buy discounts are automatically given on the basis of the quantity of

the items sold.
 Additional data-fields may be defined to be optionally or compulsorily

entered during the sales procedure (e.g. sales area code / salesman code,
personnel code, customer code, carnet code with possibility to apply special
discounts only to items belonging to a specific carnet). Data-entry can be
performed through keyboard, scanner, Magnetic Stripe Reader (MSR) or
searching from drop-down lists. Each additional data-field can be configured to
map to an alternative price list (See "Alternative price lists", page 37)
 Payment by instalments, with or without surcharges (interest, fees, etc).

Possibility of printing special pieces of text and comments on the receipt. Selling
prices are automatically adjusted. User-defined payment-specific rules can
prevent the acceptance of certain actions (e.g. discounts or other payment
types) or participation of certain items.
 Special transaction types with full "way of payment" functionality.

Additional (e.g. laser, dot-matrix) printers can be used in order to issue the
respective documents, for example:
 Item return2
 Down-payment2
 Sale of Gift Vouchers
 Other fiscal documents (invoices, delivery notes etc.)2
 Last line void, (corrective) operation for the whole line or for specific fields
(item, quantity, discount etc.). Also available for special lines (subtotal discount,
coupon, gift lines etc.). Supervisor authorisation and / or data-entry of a reason
code may be compulsorily required.
 Transaction void function, available at any stage of the sale procedure.

Supervisor authorisation and / or data-entry of a reason code may be
compulsorily required.
 Item exchange possibility. Supervisor authorisation and / or data-entry of a

reason code may be compulsorily required. Additional special rules can be
enforced (e.g. for country-specific tax requirements).
2
For more details see Page 2.

 Subtotal printout at any time during item posting in order to effect fixed
amount or percentage discounts / surcharges or to enter a discount coupon
whose value must be spread evenly across all items. The subtotal of the receipt
is always visible on the cashier's screen. Possibility to print and display subtotal
values in different currencies (e.g. in EURO).
 Total function at the end of item posting. Enters the tendering stage with
the option to backtrack and continue posting items, discounts etc. This total can
be printed and displayed in different currencies (e.g. in EURO).
PAYMENT
 Multiple ways of payment in each transaction. Self-excluding payment types

can be configured and overridden with (optional) authorisation. The amount-
due may be displayed in different currencies; while change amounts can be
restricted and / or configured to correspond to specific ways of payment (e.g. a
certain way of payment produces change of the same or different way of
payment).
 Cash payment, may or may not be allowed to exceed the total amount-due.
 Foreign currencies are treated in the same way as the base (national)
currency. Change can be given in either the base currency or in any other
currency available.
 Bank cheques behave in the same way as normal cash. Issuer code can be
logged by selecting from a drop-down list. Option to enter additional data.
 Credit card payments through MSR (no keying necessary) or the keyboard.
Payments can be less than or equal in value to the final total of the receipt. The
Credit card type and issuer are automatically recognised and validated and the
expiry date is checked. The Credit card number and the holder name are logged
for further processing. Connection with EFT terminals is optional (via SRS/FO-
EFT Connect, not supported in all countries).
 Club vouchers can be less than or equal in value to the final total of the
receipt. Voucher data is compulsorily entered. The Issuing authority code can be
selected from a drop-down list. Optionally, vouchers must / must not be
franked at the end of the transaction.
 Payment with "item-return" vouchers whose total value should be less

than or equal to the final total of the receipt. Voucher identification data is
compulsorily entered. Vouchers are automatically crosschecked for validity.
Voucher franking at the end of the transaction may be compulsorily required.
 Payment with "down-payment" vouchers, whose total value should be less

than or equal to the final total of the receipt. Voucher data is compulsorily
entered. Voucher identification data is compulsorily entered. Vouchers are
automatically crosschecked for validity. Voucher franking at the end of the
transaction may be compulsorily required.

 Up to 999 user-defined ways of payment can be configured, with

mandatory or optional extra data-entry fields and the respective specification of
the possible data-entry method(s) for each field (e.g. keyboard, scanner, MSR
etc.). Less-frequently used ways of payment are accessed through a special hot
key and the subsequent selection from a drop-down list.
OTHER FUNCTIONS
 Item price enquiries can be performed searching through the item ID or

barcode. Option of searching using only a part of the item search key. The item
price can be displayed in any of the available currencies.
 A special "no-sale" key opens the cash drawer and logs (optionally) the
event in the PoS journal.
 A "break" key puts the PoS in stand-by mode. The right operator password
should be (optionally) keyed-in in order to return to normal selling mode. This
operation can also be performed through a server-originated command.
 Sales and way of payment reports can be printed for the current sales
period and / or the current cashier shift. Option of special foreign currency
reconciliation report.
 Specially designed help-screen for all the main cashier functions may appear
at the touch of a single button.
 Request help option, by sending messages (selected from a drop-down list

or using special hot keys) to the server operator.
 "Χ-Read" and "Z-Read" functions. If a fiscal printer is present, these

commands issue the respective firmware-generated report. The report can be
supplanted by one generated by SRS/FO-PoS that may contain additional
information.
 "Cash-in" (deposit) and "Cash-out" (withdrawal) functions are available for

all currencies.
 Tender count function, which helps the cashier to easily reconcile the
drawer contents through a tender-specific counting method (e.g. denomination-
based, quantity-based or value-based).
 Training mode possibility. Can be also initiated through a server-originated

command. All transactions are performed in the normal way, but without
affecting the fiscal memory contents (with the condition that the fiscal firmware
requirements of the country are met). A special message is printed on each
receipt3.
 Lay-away function. A transaction can be interrupted and stored at any time

and stage to give priority to one or more others. It can then be recalled and
3
The exact behavior of this function depends on country-specific requirements.

continued by pressing only one special hot key. The PoS can store many lay-
away transactions.
 The "Shift-end" function indicates the end of the operator’s working session
and can be combined with the Tender count procedure (see above) and / or a
report printout.
 Macro keys. Unused PoS keyboard keys can be programmed to perform

various preset functions, like payment in a certain foreign currency, posting of a
specific item, entering a standard payment amount, sending a message to the
server etc.
 Customisable TEXT receipt elements, which include ticket headers and

footers, messages at the subtotal and / or total level and Euro-related
information. Also, counters for the total number of items purchased or the
number of items belonging to specific groups (e.g. promotional, seasonal etc.)
can be defined and printed. The SRS/FO-Customer Loyalty module offers a host
of additional features and possibilities (See page 45).
The SRS/FO-PoS software strictly adheres to the country-specific fiscal

requirements and is, of course, additionally constrained by the
capabilities of the hardware it runs on. For these reasons, some of the
printing and parameterisation features may not be available in some
countries or under certain H/W platforms.
 Full multi-lingual support. PoS terminals can be individually configured to

use different language screen and message sets. The language utilised may also
be selected automatically according to the profile of the current cashier.
DOCUMENT ISSUING
SRS fully supports the issuing of any fiscal or non-fiscal document required by the store, giving
the maximum possible configuration flexibility to the sales area (see also page 13). The
contents and the behaviour of these documents are parametrically defined and they can have
common or different user-defined form layouts (see "Document parameterisation ", page 36
for details). The printing of such documents can take place at any LAN-attached PoS or PC (SRS
Client), including the server.
All documents characterised as Sales documents are also included in all of the store's sales
reports, in the same way that PoS transactions are. All extra data fields contained in these
documents (e.g. Customer VAT code), are stored and transferred to the central system for
further processing.
 Document creation and issuing at the PoS. The system fully exploits the
user-friendliness of the GUI, the query capabilities of the RDBMS and the
functionality of the attached peripherals to make the creation and issuing of
(fiscal and non-fiscal) documents as easy and as rapid as possible. The
transaction procedures and the system functionality at the PoS are the same as
those already described (see «Selling», page 24 and «Payment", page 26).

 Document creation and issuing at SRS PC clients. This procedure includes a

number of additional functionalities and facilities:
 Running display of totals for net amount, VAT amount,

discounts, taxes etc.
 Documents that have been entered can be saved and recalled

(with a full query search) at a later stage for editing and / or
final issuing. This is the equivalent of the "find transaction"
function for PoS transactions (see page 37).
 Documents can be automatically transformed to create other,

new documents (stage sequence and transformation
constraints are defined through special parameters) or may be
reprinted (e.g. in case of a printer problem).
 In addition, all SRS clients have the capability to run all or user-defined
subsets of the SRS/FO-Kernel module, including the management of all
document-related information and parameters (see «Document
parameterisation », page 36) and customer files (see «Business partners master
file data», page 35).
If required, any SRS PC client can be equipped with a full range or a

subset of input and output peripherals normally connected to PoS (e.g.
scanner, MSR, electronic scale, printer etc.).

SRS/FO-COM MODULE
INTRODUCTION
The core functionality of the SRS/FO-Com software is to collect and store in the server the
transactions coming from the different points of sale, to manage and control all the PoS
terminals and other connected devices, as well as to send from the server (irrespective of its
location) to the PoS terminals all the global and/or specific parameters and data-sets (e.g.
items) of the system that are relevant to the sales procedure. These parameters and data can
be modified at any point, according to the then-current store operation policies. All
modifications made are sent automatically and transparently to the appropriate recipient - PoS,
where they are duplicated at the local hard disk. This ensures the fault-tolerant operation of
the system in case of a server or LAN failure. PoS clients, that for some reason (e.g. breakdown)
are off-line when these changes are made, will be updated the next time they connect to the
LAN, through the special fully automatic and fault-tolerant data synchronisation mechanism of
SRS/FO-Com. In this way, master file or parameter changes (e.g. price modifications) can be
part of the everyday routine of the store and since human intervention is minimal, the smooth
operation of the system is ensured at all times.
FUNCTIONALITY
Authorised users of the system can fully monitor and control the PoS operations in real-time.
Through the central control panel the current connection status of every PoS is displayed and a
repertoire of remote commands may be issued.
 Data exchange control and fully automatic and transparent to the operator
synchronisation between server and PoS data (send parameters and master file
modifications - receive completed transactions)
 Stand-alone operation (see also page 66). SRS/FO-Com has the capability to
operate remotely over a WAN, making SRS ideal for enterprises possessing
many sites with a small number of PoS per site. The server running the central
SRS software can be at an independent, remote location or even at
headquarters controlling all or groups of stores simultaneously. The
functionality of the system remains completely unaffected. The fact that the
PoS are served by a remote server is totally transparent to the cashiers. This
ensures:
 Connection of PoS and PC clients through a dial-up or ISDN line

(as opposed to the standard DSL-type connectivity).
 Continuous or on-demand (with user-defined polling time

intervals) connection for data exchange according to the
operating requirements and other cost factors of the company.
 Fully transparent and foolproof operation.

 An analytical «PoS status» display monitors all the PoS connection states
and activities, as well as other useful information (e.g. day / shift / cashier sales
totals etc.) in real-time, using special colour-codes.
 The «Current transaction» screen is displayed by double-clicking a PoS

screen line in the «PoS status» display. It is a special window through which the
server operator can remotely monitor the transactions progress on a PoS. Can
be used in conjunction with cameras for ultimate cashier control.
 Detailed system event log (audit trail), is kept, with user-defined level of
detail for the information to be stored (depending also upon the RDBMS
capabilities). This journal contains plain-language messages that help system
administrators and support personnel to diagnose system faults, greatly
reducing error resolution times.
 PoS message handling. Messages coming from PoS terminals are displayed
and acknowledged here. Also, messages to a particular or all the PoS clients can
be sent.
 Issuing remote commands to the PoS either en masse or selectively:
 Z-Read and X-Read
 Disconnect cashier
 Prohibit usage
 Re-boot
 Manage hard disk
 Request all transactions for a particular time period to be sent

to the server again
 Selectively reload from the server the master and parameter

files and tables
 Install and configure new software versions.

SRS/FO-KERNEL MODULE
INTRODUCTION
SRS/FO-Kernel’s main functionality refers to the management of store data and parameters.
The store manager or authorised personnel have the possibility to maintain all master and
auxiliary system files (e.g. item, customer file, etc.) and list-of-values tables (e.g. VAT rates or
categorisations) as well as general and special system parameters that correspond to current
store operation policy. SRS/FO-Kernel provides a wide range of lists and statistical reports
regarding sales and productivity rate of store operation procedures (e.g. cashiers productivity
etc.), providing the store managers with substantial statistical and other data that contribute
substantially in decision making.
FUNCTIONALITY
With its intuitive user interface, functional richness, robustness and comprehensive
adaptability characteristics, SRS/FO-Kernel software stands out as one of the most well
designed and implemented retail management systems.
In addition to the functionality provided at the local work stations (PC) for maintenance and
process of all master and auxiliary files, tables and parameters, almost all system data can be
set / updated automatically from a central point (e.g. headquarters) through standard two-way
data interchange routines between the store SRS/FO-Kernel and the central system. This is also
the case for all transaction data which should be sent to the headquarters for further
processing.
For store managers or other authorised personnel, working with the system is both easy and
effective. Everyday store procedures are only one mouse-click away whereas other, not
frequently used functions can be selected from drop-down lists. Each user interface can be
configured so that the user sees only the functions that are relevant to his/her work and
responsibilities.
In addition, SRS/FO-Kernel contains a veritable "armada" of financial, statistical and other

reports. These reports are fully parametric as far as the presentation, sorting, subtotalling
methods and filtering criteria are concerned, satisfying even the most demanding store
manager. Sales statistical data (comparative or not) can be obtained by using user-defined
methods regarding the relevant range of dates or time periods, whereas performance rates for
the entire store or for individual operators/cashiers help to reach to useful conclusions about
overall efficiency of procedures and they substantially help to control the operation of the
store.
 Usually configured during set-up time, the System parameters are global
attributes that affect specialised system functions such as:
 Payment types and categories
 Discount and coupon categories

 Shelf-label types and parameters4
 System operator groups
 Sales control parameters, constraints and options (e.g. highest

and lowest levels of sales, discounts, cancellations, etc.)
 Hierarchical item categories
 Input and output ASCII file formats, names and directories
 Historical, analytical and summarised (item level and item-

group level) transaction data retention periods (number of
days), for hourly, daily, weekly, monthly and yearly
transactions.
 The SRS/FO-Kernel architecture allows the definition of multiple "logical"

stores (e.g. for stores-in-store cases), which are all supported by the same
physical system. Each "logical" store is a unique entity and has its own basic
store data set which consists of:
 Static store data (description, name, address, VAT code etc.)
 Store configuration data (connected PoS terminals and PC's,

groupings of PoS terminals per sales location, VAT and foreign
currency exchange rates etc.).
Items, operators, customers (part of the "business partner" master file)

and sales parameters can belong to all or specific logical stores (see
respective paragraphs).
 Item categorisation. SRS gives the possibility to define unlimited levels of

hierarchical item groups. Apart from the normal item attributes (item ID,
description, barcode, price etc.), a number of additional data can be stored at
the item-group level, e.g. the price-computing algorithm for sales by
instalments.
 Item master file data. SRS holds a comprehensive set of attributes and files
for each stock item. Since only a small part of them is compulsory for the basic
sales and reporting / logging requirements, the user can adopt the "grow-as-
you-go" approach and enrich the system with the additional information only
when extra functionality is required. Due to the volume, the complexity and the
sensitivity of this data, maintenance is usually carried out at the enterprise
central system. In some cases, local maintenance is also possible. SRS has
extensive functionality to support any batch- mode, semiautomatic or purely on
line data exchange. If an off-line method is selected, authorised system
operators can also directly modify the database. Such events (e.g. price
changes) can be optionally logged for controlling purposes (See «Detailed
system event log », page31).
4
For types of labels printers supported see page 2.

It is important to stress that SRS fully supports the Efficient Consumer Response (ECR),
packaging conventions, as shown in the following diagram.
Pallet
S.K.U.
Consumer Unit
Item Multi-Pack
Figure 6. ECR packaging hierarchy
 Main stock item attributes
 Basic (compulsory) stock item attributes (ID, short & long

descriptions, item group, shelf-label type, connected
multimedia file, promo banner etc.).
 Item type indicators used to recognise and properly process

special items, such as weighted or refundable items. A special
indicator allows for the definition of virtual items so as to sell,
for example, a set of actual items with a unique virtual item ID.
 Multiple barcodes can be attached to the same item. Each

barcode may correspond to a different item quantity and
description and/or a unit of measure (e.g. multi-pack) or even
to a different price.
 Suppliers are supported in a two-level hierarchy (main supplier

– local reseller / own warehouse - warehouse area). Multiple
suppliers can be defined for the same item with preference
options. Every supplier has his own ID, and the logistics
parameters for each item (e.g. receipt packaging, minimum re-
order quantity etc.) are stored and properly exploited.
 Support of multiple prices. Apart from the standard selling

prices (retail, wholesale etc.) and the agreed and last cost
prices, an extra special price can also be entered. This special
price can be automatically activated for a specific time period
(from - to date and time) for promotional purposes. The
previous value and the modification timestamp are logged for
all selling prices. Selling prices can be further differentiated

according to the customer category, transaction type, way of

payment, item group and selling area (See "Alternative price
lists", page 37). The additional SRS/FO-Duty Free Support
module provides further options for tax and duty-free selling
(See page 52).
 Discounts can be given to specific items:
1. By defining pre-set amounts or percentages.
2. By setting a gift threshold (see Selling - "Gift" key ,

page25).
3. Through a special discount code (see "System

parameters", page 32).
4. By specifying a multi-buy scheme (see "Selling -

Multi-buy discounts ", page 25).
5. By defining that the item belongs to a certain

group (or groups) for which an extra "indirect"
discount is given.
 An item can be set to obey specific selling constraints, rules

and procedures by defining its "sales control" category
accordingly (See "System parameters", page 32).
 Various item flags and indicators allow for special statistical reporting and /
or logging schemes into transaction files. These indicators can be used for
promotional, seasonal or other "horizontal" categorisations (See "System
parameters", page 32).
 "Business Partner" master file data. SRS stores all the data that pertain to
transaction making entities (customers, suppliers, company personnel etc.) in a
single "business partner" master file. In this way, data duplication is avoided and
a consolidated view for each entity is possible, irrespectively of the multiple
roles it may play simultaneously (e.g. customer and supplier). Except for the
normal static data kept (addresses, VAT codes, names, linked multimedia file
etc.), the system also supports the following:
 To implement the different pricing policies of the company,

special discount / surcharge categories and types can be set for
specific "business partners". Additionally, a "business partner"
can be included in a certain selling group that automatically
maps to an alternative price list (See «Alternative price lists»,
page37).
 User-defined business partner categories allow for special

reporting schemes, while the SRS/FO-Customer Loyalty module
adds even more options and includes extensive buyer profiling
information (See page 45).

 Extra statistical information is automatically kept and can be

viewed directly from the business partner master file
maintenance screen. This includes current year turnover
figures, information about the customer's last visit, card usage,
detailed transaction display etc.
 The super-user or authorised personnel maintain the system's operator's

master file. SRS provides an easy way to define sets of authorisation grants
(called "user profiles") and directly assign them to users. Further fine-tuning of a
specific operator's role is also possible.
 Document parameterisation enables the super-user to define exactly how a

specific document type (e.g. invoice, delivery note etc.) will behave as part of
the company's procedures and the business flow.
 Document issuing authorisation for specific users / profiles at

specific PC / PoS terminals respectively.
 Definition of content and layout for the document's header, of

other standard information, detailed and total sections.
 If the document is to be printed in a non-impact printer, the

user has the option to employ the system’s Document
Designer where he can insert all kinds of graphical elements in
a document of any size supported by the printer. The
Document Designer has full access to the database schema and
can insert any database field (as-is or computed)
 Document creation parameters definition to specify the

document's mandatory or optional fields and their respective
default values (if applicable).
 Document calculation parameters definition to specify the way

the amounts and/or quantities of the document affect the
sales - financial figures and/or stock levels respectively.
 Indicator whether the document will be included in the

exchange file with the central system.
 For each type of a sales document a specific pricing scheme

can be set (See "Alternative price lists", page 37) and the
reporting consolidation category to which it belongs can be
selected (e.g. wholesale, retail etc.).
 If required, multiple document series each with its own

numbering scheme can be defined, each with additional
parameters as to the type of printer and the form layout it
utilises. Special “cancellation” series can be defined in order to
proceed to the necessary corrective actions and to correct
errors with a full audit trail of each action. The system
automatically numbers issued documents and resets the

numbering schemes at the beginning of each fiscal year (if

required).
For a more detailed discussion of the document issuing functionality,

see page 29.
 The "find transaction" function enables the user to search, locate and
display any transaction performed, by means of comprehensive query / filtering
criteria.
 The system possesses a large number of list of values tables in order to

constraint the contents of data-entry fields to specific codes or predefined
values and hence to minimise data-entry errors. Examples of such tables are:
 Delivery and shipment addresses
 Methods and reasons of shipment
 Professions
 VAT, tax and surcharge descriptions and percentages
 Tax authorities
 Banks and other credit institutions
 Credit card number recognition patterns
 Alternative price lists. SRS provides additional means to exercise

sophisticated special pricing policies in a consistent, easy-to-use and very
powerful manner. For each user-defined price list the following can be
specified:
 Retail and wholesale price adjustment methods and values.

These can be fixed amount or percentage discounts /
surcharges or special fixed prices.
 Specific time periods (from - to date & time) during which the
alternative prices are automatically activated and deactivated.
 Various applicability criteria e.g. according to sales areas (e.g.

PoS terminals at cafeteria or bar), customer categories
("selling-group") and item categories / groups.
 One of the key factors of the system's deployment versatility is its sales
parameter maintenance sub-system, which allows the total control of the
functionality and the complete personalised parameterisation of each
connected PoS in an easy and effective way. Setting of these parameters is
performed through the usual user-friendly interface and may be also activated
remotely. For each PoS the super-user may specify:

 Peripheral types and configurations (for devices like the cashier

and customer displays etc.). Keyboard set-up and key
assignments.
 Specialised processing options for certain barcode types

(weighted items, coupons etc.).
 Security / authorisation parameters through the use of

passwords or keyboard key-lock for sensitive operations like
special discounts, void receipt, cash-in or cash-out, X-Read and
Z-Read functions. Start and end-of-shift procedures can also be
similarly protected. All the above actions can be logged for
further control in «Detailed system event log » (see page 31).
 Value and quantity upper limits may be set for the whole
transaction and / or individual line fields (e.g. total-due, line
and total values and discounts, change amount, number of
items purchased etc.). These are automatically enforced during
the selling procedure. Authorised personnel using keys or
passwords may override these limits. All the above actions can
be logged for further control in «Detailed system event log »
(see page 31).
 Cash-drawer content (value) upper limit and cash-out warning

levels.
 Document franking and receipt printing parameters.
 Required decimal places for values, prices and quantities.
 PoS customer display parameters.
 Required mode of operation (e.g. training mode) for each PoS.
 Printing of shelf-labels can be done automatically (en masse) through the

price modification utility or manually. Label printers can be attached to any
available communications port (multiple printers are possible). Additional label
printing methods are available in the SRS/BO-Basis module (see page 55). If
printing on a laser/inkjet printer, the user has the option to employ the system’s
Label Designer where he can insert all kinds of graphical elements in a label of
any size. The Label Designer has full access to the database schema and can
insert any database field (as-is or computed). To conserve paper, the SRS shelf-
label printing facility can change the starting point (specific label) of a printing
job.
 The detailed store control reports that are available enable the store
manager and the chief cashiers to continuously monitor and assess the
performance of the operators and the store in general. Unless otherwise stated,
the following reports relate to a specific day of operation.
 Cashier reports (detailed sales performed, active / idle PoS

time statistics, activity summaries for user-defined periods,

surplus / deficit amounts, daily reports for individual or groups

of cashiers etc.).
 PoS level reports (activity summaries for user-defined time

periods, customer service statistics etc.).
 “Documents issued” reports.
 “Price modifications” reports for user-defined time periods

with department filtering criteria.
 Comprehensive sales reports are available for any hierarchical level of the
item groups as well as for all horizontal and / or user-defined categorisations.
Special reports exist for sales exceptions like discounts, item returns etc. All the
above reports can be issued for user-defined time periods, using various data
filtering criteria and optional intermediate totals.
 Summary and detailed item and item group sales reports.

Output data can further be narrowed-down by specifying an
item group range and / or a bestseller (or worst seller) item
threshold.
 Summary sales turnover reports per PoS, item group or sales

area.
 Summary item category sales report for specific item group

ranges.
 Various discount reports for user-defined discount categories.

Optionally these can be presented at the detail (transaction
line) level and grouped by PoS or item ID.
 Sales per discount category report.
 Salesman turnover report (daily totals, summary etc.).
 Item returns report.
 Detailed or summary comparative sales reports with variable,

user-defined comparison time periods (number of customers,
store turnovers, turnovers per customer, items sold, average
items per customer etc.).
 The wide variety of payment reports provided is designed to help the chief
cashiers easily reconcile their tenders (by pinpointing any mistakes), as well as
assist managers understand how turnover is analysed. All the following reports
can be produced for user defined time periods.
 Detailed and summary "way of payment" reports per cashier

or PoS.

 Coupons redeemed reports for specific item-groups and / or

coupon category ranges.
 Receipts (tickets) analysis reports per cashier and payment

type or per payment type and PoS terminal.

ADDITIONAL SRS/FO MODULES

Designed to exploit the latest advancements in peripheral technologies and to incorporate the
best business practices, these extra horizontal and vertical modules greatly extend the SRS
capabilities, keeping the same levels of rich functionality, user-friendliness and
uncompromising reliability. Forming an integral part of the whole system, any additional
module can be installed and configured from the very beginning, or can be added at a later
stage according to specific customer needs and requirements.
SRS/FO-PLU DEVICES
The integration of sales-area peripheral devices like electronic weighing scales, price-checkers
and electronic shelf-labels (ESL) can be a daunting experience. Usually these systems require
specialised technical expertise, elaborate planning of their functionality and (if "ready-made"
solutions are chosen), a great deal of care in designing a reliable updating mechanism. While
every modern food-related store currently has electronic weighing scales, only a few sites can
claim that their management is satisfactory. For price checkers and ESL's, the situation is even
worse and their inherent set-up and operational difficulties have kept them away of all but the
largest retail enterprises.
The SRS/FO-PLU Devices module addresses just these needs and provides the basis of an easily
deployable solution for all store types and sizes. Irrespectively of the number and type of
connected device(s), their management and control becomes an integral part of SRS/FO-Com
functionality. In addition, device-specific capabilities are fully exploited (provided they are part
of a widely used or industry standard).
GENERAL PLU DEVICE SUPPORT PARAMETERS
 Remote commands. The SRS/FO-Com remote commands repertoire (see

page 31) is extended to include the following functions:
 Reload PLU file (for devices with local storage capability).
 Reload the programming code set (full or partial).
 Fetch device status (for devices controlled by another system)
 Synchronise external management system parameters 5.
 The sales parameter maintenance sub-system provides the usual

customisation facilities (which are of course applicable to each device, see page
37 for details). It also supports additional device-specific settings by means of
the programming code set for:
 Idle mode messages.
5
Currently used for the PRICER system, will also be used for other (e.g. personnel attendance monitoring system).

 Promotional messages.
 Description, quantity, price and amount display format.
 Special visual effects.
 Connection settings (serial port, communication parameters

and polling frequency).
For small installations, the SRS/FO-PLU Devices module is able to

handle the direct connection of devices to the server (provided that
enough serial ports are available).
 Store configuration data. The SRS/FO-Kernel basic store data set includes a
list of "connected devices" (which contains information on various models or
types6) and allows device groupings per sales area in much the same way as for
PoS terminals (see page 33).
 Up to 99 lookup tables can be configured either automatically (based on the

Main stock item attributes ) or dynamically by defining item-group ranges.
These can be further edited through special screens in order, for example, to
include specific items or to further constrain the contents due to limited device
capacity. Lookup tables can be set to map to one or more devices or sales areas.
Look-up tables are currently used only for the network of weigh-scales,
but they will become the basis for future the SRS/FO-PLU Devices7
module extensions.
ELECTRONIC SCALES SUPPORT
The SRS customer portfolio includes a wide variety of food-market sites of all sizes and
specialities. The extensive experience gained from this large installed base is reflected in the
way the system manages the store's weighing scales.
 The additional extended attributes of the connected device (scale) models

are specified in the sales parameter maintenance sub-system:
 Label printer type and label layout.
 Customer and operator display options for EURO currency,

visual attributes and messages for promotional items etc.
 Number of device-supported ID's.
 Main stock item attributes for scales support include:
 Days to sell-by date.
6
For types of scales and price checkers supported, see page 66.
7
These will include PoS self-checkout systems, self-scanning systems and information kiosks.

 Weight information: tare, weight-type etc.
 Pricing information: price basis (1kg, 100g, 10g, 1g), price

scaling algorithm and rounding method.
 Lookup table code that the item belongs to.
ESL SUPPORT
To offer a high-functionality electronic shelf-label solution, SingularLogic has chosen one of the
leading products in the market today. The PRICER ESL (Electronic Shelf-Label) system and
accompanying infrastructure products have exceptional flexibility and remarkable deployment
characteristics. The SRS/FO-PLU Devices module is closely integrated with the PRICER Server
software and fully exploits all its characteristics.
Figure 7. PRICER ESL system overview
 A variety of methods can be used to produce and maintain the ESL match-
list. The actual data of this list are mirrored in the Main stock item attributes
where the actual label ID's are stored (up to three ID's can be defined per item).
 Direct list maintenance (it is recommended to use a scanner).
 Utilisation of PRICER Server’s own maintenance facilities.
 Batch-mode maintenance by means of an ASCII file. This can be

created from a portable terminal equipped with a scanner.

Based on the ESL-type indicator of each item, an "empty" match-list

can be created as a basis for this procedure. Irrespective of the method
used, the ESL match-list is always exchanged between SRS and the
PRICER system.
 Sales area information. By using the PRICER label's "switch page" function
together with the special infrared key, merchandising information can be placed
in the label's secondary memory page, making tasks like the verification of shelf
compliance and the reduction of out-of-stock items simple and effective.
 The extended attributes of the labels in use are specified in the sales
parameter maintenance sub-system:
 Label type: Standard, Large Display, Fruit & Vegetable, Peg-

hook / Miniature.
 Euro display option.
 Third price display option.
 Visual signal for promotional items (LED, blinking price etc.).
 Sticker label layout (stickers are produced by the PRICER

Server).
PRICE-CHECKER SUPPORT
In conjunction with the SRS/FO-PLU Devices module, the Price-Checker becomes more than a
simple price verification terminal. It is an eye-catching “scrolling billboard” with enhanced text
display and graphics capabilities for promoting custom sales messages at the point these have
the greatest impact:
 Merchandise clearance bins
 Aisle displays
 Free-standing kiosks
 Sales shelves and counters
 Check-stands and other high-visibility locations
Positioned at strategic locations around the store, Price-Checker devices bring new ways for
boosting sales and profits.
When Windows-based Price-Checkers are employed, SRS can provide a host of item
information like original and promo price and price per kilo or other measuring unit. The
SRS/FO-Customer Loyalty and SRS/FO-Stored Credit modules provide even more possibilities.

SRS/FO-CUSTOMER LOYALTY 8
The recognition of Customer Loyalty schemes as powerful marketing tools has already spurred
their widespread adoption by retail businesses around the world. The main targets addressed
by Customer Loyalty are the following:
 Identify and retain customers.
 Record customer habits and profiles so that mass or one-to-one marketing

policies can be adopted.
 Increase customer share by augmenting their "sense of profit".
 Optimise expenses by more focused marketing efforts.
 Create leverage for multi-tiered reward programs, cross selling and "e-
loyalty" schemes.
As often happens with every new idea, the first users of Customer Loyalty systems have faced
many technical and business process re-engineering (BPR) problems and obstacles. So they
ended up using complex and rigid systems that could not keep up with the constantly changing
policies and fast-moving new technologies (a fine example for the latter is the increasing use of
data-mining tools for everyday operations).
As a modern system, SRS was by definition detached from "legacy" concepts (the well-known
"perpetual compatibility" issue) and was perfectly positioned to benefit from the accumulated
market experience. Except avoiding the respective pitfalls, this means that it was able to take
full advantage of time-proven practices. The SRS/FO-Customer Loyalty module is a very good
example of versatility and innovative design practices. Whichever the company strategy is
today and irrespectively of how often it will change, the system will always be able to support
the management decisions down to the checkout lane in a consistent and efficient manner.
SRS/FO-Customer Loyalty module is not marketed like any other

“ready-made” module, but it is combined with a consulting services
package so as to ensure its efficiency towards the company's
management goals and the infrastructure that will support it.
GENERAL CHARACTERISTICS
 Multiple platforms supported. The system can work with all types of
Customer Loyalty cards, ranging from the simplest to the most hi-tech.
SingularLogic can undertake customisation and application development to
cover the needs of more advanced technologies.
 Barcode cards for on-line systems.
8
The description pertains to both SRS/FO-Customer Loyalty and SRS/FO-Advanced Customer Loyalty modules

 Magnetic cards for on-line systems, offering limited off-line

functionality.
 Chip cards for «hybrid" systems, offering the entire range of

functions.
 "Smart" cards. The advanced functionality of this platform

enables cross selling between diversified partners and the
adoption of ultimate acquisition and complex scoring
scenarios.
 Interfacing functions. The SRS/FO-Customer Loyalty module includes

extensive data storing options to support Customer Loyalty data exchange
mechanisms with the rest of the systems that are involved in the scheme.
 Card Issuer's systems.
 Supply Chain Management (SCM) software.
 Customer Relationship Management (CRM) or other Customer

Service systems.
 Financial, Accounting, Sales & Distribution and Enterprise

Resource Planning (ERP) systems.
 Multiple active programs available simultaneously. The main Customer

Loyalty programme can "run" in parallel with other programs (e.g. Ad-hoc or
time-limited). These can be initiated by the company's central system or by the
store staff itself.
 Integration with other SRS modules. The SRS/FO-Customer Loyalty provides

all the required extra information (at the item level) to the SRS/FO-PLU Devices
module in order to display information regarding customer loyalty programs
and gifts, offers, special discounts etc. at various store devices.
LOYALTY PROGRAMME / CAMPAIGN CUSTOMISATION
 Item-based criteria. Available throughout the Item categorisation trees (see

page 37). Different hierarchy levels can be defined as cumulative or self-
exclusive.
 Customer based criteria. For personalised privilege or offers award.
 Time duration criteria. (Monthly, weekly or daily periods, day and time-of-
day from- to criteria etc.)
 Additional item filtering for horizontal or user-defined item-groups. More

options (e.g. customer or sales-area related) are available by the system’s
Alternative price lists (see page 37).

 Award methods. Points (positive / negative). Point multipliers and

thresholds. Discounts as a fixed % or absolute value or as % of the targeted
offering. Special transaction level logic for "one-off" awards.
 Redemption methods. Vouchers, coupons, gifts, immediate discounts etc.
POS FUNCTIONS
Depending on the CL scheme used, SRS/FO-PoS can handle on-line "business partner" master
file data modifications and / or chip-card updates. Of course, all relevant data are always
logged and can be fed to the headquarters or other external systems.
 Customer account information. By simply entering his CL code, the

customer can be informed about his account status9 and get personalised
messages (as defined in the sales parameter maintenance sub-system).
 The same information can be printed at the end of each receipt involving a
certain CL code.
 Campaign-specific text and graphics can appear on the receipt, on the

cashier VGA screen or on the customer-facing VGA screen
OTHER FUNCTIONS AND SYSTEM EXTENSIONS
 System parameters support special payment discounts and coupons

categories, additional label data and additional sales control logic and
constraints.
 Item categorisation allows item-group level filtering, special item points and
point multipliers for group items.
 Additional Main stock item attributes for points, item types ("CL gift" item
etc.)
 "Business Partners" master file data are extended so as to include a wide

range of customer profiling data and fields:
 Categorisation range (upper and lower limit) values or sets for

income level, profession codes, educational level and other
user-defined customers profile information.
 Additional personal data (selling group, spouse, pets, notes,

cards owned etc.).
 Customer statistical data. Frequency of CL card usage, last

customer visit, current year turnover etc.
9
In on-line systems this is true only for local customers (home –store)

 Account information. Membership information, card numbers

(up to three), total points awarded, total points redeemed,
value and type of rewards etc.
In addition to the above, a number of additional data-fields, coming

from other systems (e.g. mass-mailing information or additional
account status information) can be stored in the system. If these are
properly categorised, SRS can automatically communicate specific
marketing messages to the customer by either displaying or printing
the relevant information (see below for details).
 The SRS list of values tables ensure the consistency of CL related data for
logging and reporting purposes. Utilisation and maintenance of these tables is
not compulsory, but enhance the quality of the information provided.
 Income and education level classifications.
 Profession tables.
 Domicile and other area categorisations.
 The Alternative price lists sub-system also contains additional options and
methods for point awards and point multipliers.
 All hardware-specific parameters and / or PoS-level logic controls are, as

expected, controlled through the sales parameter maintenance sub-system.
 Customer Loyalty card reading device parameters (card

readers, PIN-pads, etc.) and / or code recognition patterns for
generic reading devices.
 Customer-related messages for point scoring issues, reward

exchange procedures, mass-mail feedback information and
cross-selling information.
 Additional franking options.
REPORTS AND PRINTOUTS
Although SRS was not meant to compete with full-fledged Customer Loyalty Operator systems
of specialised companies, it has features that can be exploited to achieve adequate store-level
statistical reporting. To this end, the CL reports were designed for the store managers and the
operations support personnel. Unless otherwise stated, the following reports relate to a
specific day of operation.
 Points awarded per hour per cashier or PoS (in comparison with achieved
sales figures).
 Detailed awards given report per cashier or PoS.

 Analytical or summary comparative sales reports (Customer Loyalty versus

non-Customer Loyalty), with user-defined comparison time periods (number of
customers, store turnover, turnover per customer, items sold, average items
per customer etc.).
EXAMPLES OF CUSTOMER LOYALTY OFFERS
The nature of the SRS Advanced Customer Loyalty offer execution engine precludes a complete
reference of possibilities. The following are some indicative scenarios.
POINTS AWARDS
Scenario 1
All cardholders will be awarded points on every ticket based on the following scheme: 80
points for every €100 spent
Scenario 2
All cardholders will be awarded points on every ticket based on the following scheme: 2 points
for every €5 spent for transactions up to €100, 3 points for every €5 spent for transactions of
€101 or more
Scenario 3
All cardholders will be awarded points on every ticket based on the following scheme: 2 points
for every €5 spent up to €100, 3 points for every €5 spent for the rest of the amount plus 20
points if the transaction’s value is more then €100
Scenario 4
All cardholders will be awarded 10 points on every ticket
Scenario 5
Specific customers gain 10 points for specific items they purchase
Scenario 6
Specific customers buying specific items will gain 1 point for every €2 they spend
Scenario 7
Specific customers buying specific items that total at least €10 will gain 1 point for every €2
they spend
Scenario 8
Specific customers buying three different items from a specific item group gain 30 points
Scenario 9

Specific customers buying one item from item group A and one item from item group B gain 30
points
Scenario 10
All cardholders gain 10 points when buying one piece of a specific item, 25 points when buying
two pieces and 13 points for every piece above that
ITEM DISCOUNT AWARDS
Scenario 1
All cardholders gain a 3% discount on every item with a list price of at least €50
Scenario 2
Specific customers buying from a specific item group gain a 10% discount on every such item
Scenario 3
Specific customers gain a €1 discount on every item they purchase from a specific item group
with a list price of at least €10
Scenario 4
Specific customers buying three different items from a specific item group gain a 10% discount
on every such item
Scenario 5
All customers buying two items from item group A get one item from item group B free (100%
discount)
Scenario 6
Specific customers gain a €2 discount when buying one piece of a specific item group, €5 when
buying two pieces and €2,75 for every piece above that
Scenario 7
All customers buying three same or different items from a specific item group will pay €15 for
all three of them (the exact discount amount will be computed by the system and will be
spread proportionately on each one)
TICKET-LEVEL DISCOUNTS
Scenario 1
All cardholders gain a 3% discount on every transaction with a value of €300 or more
Scenario 2

All customers gain a €20 discount on every transaction with a value of €300 or more
Scenario 3
All customers gain discounts on every transaction with the following scheme: 1% for
transactions up to €99, 2% for transactions up to €199 and 3% for transactions of at least €200
Scenario 4
Specific customers gain a €2 ticket-level discount for every item they purchase that belongs to
a specific item group
CUSTOMER MESSAGES
Scenario 1
For every customer that has accrued 1000 points and upwards a “teaser” message reminds him
of the great savings awaiting him. The cashier also sees the same message on the screen and
can inform the customer to the fact.
Scenario 2
Customers that bought a partial promotional offer are reminded by the cashier of the
additional savings they would get if they brought the extra item to the counter. (e.g. Scenario 5
of Item Discounts).
Scenario 3
Customers that belong to a specific list get a relevant message (e.g. CRM lists for birthdays,
bounced mailings, inactive accounts)
Scenario 4
Non-cardholders are reminded of the points / discounts they could gain if they were already
members (“This transaction would cost €5,75 less if you were a VIP member”). Since the
transaction has not ended when the message pops up, the customer can fill out his form and
the cashier can scan his card and he will get the rewards.
COUNTER UPDATES (HISTORICAL DATA)
Scenario 1
During December, all cardholders that buy specific items have their “December Promo”
counter incremented by the value of each such item. During the first half of January, every
customer will get a voucher equal to 25% of his “December Promo” purchases.
Scenario 2
Cardholders that have accrued €500 in purchases can either gain a €40 gift voucher or go for
the €100 voucher that will be given to them once they reach €1000 in purchases

Scenario 3
Cardholders that have made purchases of €200 inside the previous week get an automatic 10%
discount on the purchases of the current week
Scenario 4
Every cardholder is eligible for a 10% ticket-level discount once per month
Scenario 5
Every cardholder is eligible for a 20% ticket-level discount upon enrollment to the VIP club
SRS/FO-DUTY FREE SUPPORT
Designed for tax and duty-free item retail sales, the SRS/FO-Duty Free Support module extends
some of the basic system functionalities to cover the specialised needs of this sector.
 Additional data fields, (e.g. flight number or ship destination, passenger

passport number etc.) can be recorded and printed on the receipts. The system
supports Boarding Pass reading.
 User-defined duty-free transaction types can be initiated either manually

or automatically (based on data-entry field criteria).
 Additional item classifications for tobacco, wine and spirits imported goods
etc. can automatically trigger different selling schemes and procedures (e.g.
different pricing) and logging logic, according to the selected transaction type.
 Special reports with multiple time period and filtering criteria:
 Foreign currency reconciliation reports (per cashier or PoS).
 Sales per customs authority reports.
 Sales per flight/itinerary or flight/itinerary type reports.
SRS/FO-STORED CREDIT
With SRS/FO-Stored Credit, SRS gains the capability to monitor the full life-cycle of credit
documents (tokens, vouchers etc) issued by a modern retailer. The scope of this capability
includes, but is not limited to, the following:
 Returns vouchers. Usually, when a customer returns an item, instead of a

refund in cash, the retailer issues a document that then can be accepted
as tender in a subsequent transaction.
 Down-payment voucher. In certain sales scenarios, the customer must

pay in advance against an item to be delivered to him/her at a later date.
In such a case, the retailer issues a document that then can be accepted
as tender in a subsequent transaction containing the item in question

 Gift Voucher. Many retailers issue gift vouchers for their customers as a
convenience. The vouchers are denominated in certain € values and they
are sold inside a normal sales transaction. The bearer of the voucher can
use it as tender in a subsequent transaction
 Gift Cards. These are the same as Gift Vouchers but they give the
possibility for incremental tendering and also reloads
 Employee benefits. Some retailers provide a monthly € allotment to their

employees that they can spend in the stores. These benefits can be
connected to the already existing employee ID’s or a physical card
(presumably with extra security features).
 Promo Coupons. During special occasions (e.g. new store openings,

seasonal events) a retailer can create stored value promotional coupons
that can be disseminated by various means to end-customers. These
coupons are usually of small value and, more often than not, have expiry
dates.
With SRS/FO-Stored Credit, a retailer can easily integrate any of the above business procedures
without incurring the attendant administrative and fraud-related costs.
GENERAL CHARACTERISTICS
 In the centralized credit note (token) store, all stored value mediums are
entered and their status can be interrogated and updated by SRS/FO-PoS but
also external systems via Web Services. Status can be:
 The SRS database holds a secure full log of all transactions for every token.
 Tokens can be created without value, with a pre-set value or with an ad-hoc
value.
 Tokens can have an expiry date set upon creation.
 Tokens can be attached to CL cards and can accrue € from SRS/FO-Advanced

Customer Loyalty awards
 Tokens can be personalized (for security purposes)
 Especially for Gift Vouchers, SRS/FO-Advanced Loyalty can be set to give a

bonus for every sale (for example, sale of a €50 Voucher for €45, 10%
increase of the Voucher’s value etc.)
POS FUNCTIONS
 At the SRS/FO-PoS or at any device running under the SRS/FO-PLU

Devices module, a customer can have his/her token checked for €
remaining and expiry information.

 The PoS accepts tokens as normal tenders (see also “Payment” at Page
26) and performs online checks against the SRS database to ensure the
validity of the requested operation.
 On every ticket involving a token, the current remaining balance can also
be printed.
 The sale of a Gift Voucher (or similar) can be logged via the PoS either as
a normal sale (i.e. together with other merchandise) or as a special
transaction type.


THE SRS/BACK-OFFICE SYSTEM
SRS/BO-BASIS MODULE
INTRODUCTION
For the companies seeking to decentralise procedures and conduct as many controls as
possible at the primary points of input (stores) and not at a central level (along with the
economies of scale this implies), SRS/Back-Office is the reasonable choice. Completely
harmonised with SRS/Front-Office, this system provides a comprehensive coverage for the
automation needs of a branch belonging to a goods-selling chain. Its main features are:
 Warehouse and inventories management and controlling.
 Full procurement package (orders to suppliers / central warehouse, goods-

receiving, invoice control, etc.).
 Consolidation and control of all cash-office and store transactions, with the
possibility of creating ready Accounting / General Ledger records.
 Full on-line interoperability with SRS/Front-Office (real-time stock status,

reporting etc.).
The extensive experience of SingularLogic in the area of commercial applications and especially
in the retail sales environment is reflected in the SRS/Back-Office operational capabilities. The
ease of use/deployment and the exploitation of the most advanced techniques and
technologies really make it stand out. SRS/Back-Office adds new important capabilities to
SRS/Front-Office and extends many of those already available. Like the other SRS add-on
modules, it can be installed and configured from the very beginning, or can be added at a later
stage according to specific customer needs and requirements.
WAREHOUSE AND ITEMS MANAGEMENT
MAIN FUNCTIONS
The SRS/BO-Basis Module adds some important features to the item and warehouse
management functions.
 Warehouse multiplicity. This possibility extends the basic store data set and
except from defining many "logical" stores, each with a possibly different

operation mode, it introduces the same concept for stock-areas as well. In

combination with the additional information integrated in Main stock item
attributes (see below), the items can also be transferred between warehouses,
maintaining (if required) different attributes.
 Each level in Item categorisation can take the following parameters:
 Indicator whether goods belonging to a certain category can be

ordered along with items from other categories or not.
 Indicator for consignment category and commission rate

(when activated it replaces the relevant indicator in Main stock
item attributes ).
 SRS Main stock item attributes are extended in order to include a wide
range of information and indices for data required by SRS/BO functionality.
 Supplier item code.
 Item type indicator for consignment items and the respective

commission rate.
 Item indicator for Serial Number-controlled items. When this

indicator is set, the system can be set-up to accept and control
Serial Numbers during all the stock procedures and
transaction, including sales
 Average and latest wholesale cost prices. They are calculated

automatically by the procurement package and are held
together with their timestamps.
 Warehouse data: Safety limit, optimum stock level and

sufficiency days, order limit.
 Additional data for the orders package: Order date, number of

days from the last sale for automatic item return
recommendation, “blocked for orders” indicator, “blocked for
returns” indicator, “central warehouse order” indicator
(supersedes the respective indicator from the "business
partners" master file data).
 Geographical (area) codes for the store and the warehouse

location and respective capacities.
 Volume and weight data for the order unit.
 Cyclic counting (stock-taking) data. Day of month or day of

week the item must be counted. Timestamps and recent data
for any inventories performed.

 Document parameterisation offers the possibility to define restrictions for

finalisation (e.g. for partial receiving) and to include the document type to the
file exchange with the headquarters.
 The SRS/BO-Basis Module adds a large variety of warehouse reports to

cover store information requirements, as well as those deriving from the
standing legislation. All the following reports can be produced for user- defined
time periods.
 Monthly and annual stock balance sheets.
 Movements by Item (Warehouse book). Detailed or

consolidated item transactions printout with user-defined
display range from-to item ID, Item group (Level), supplier.
Sorted by: Item Description, Horizontal group, VAT category,
Supplier Item Code. With intermediate totals per document
type.
 Transaction control report. Detailed or consolidated item

transaction printout per document category. This report can
also be taken in comparison to another time period.
 Sales report (clearing) for consignment items. Consolidated

item transaction printout with user defined display range (from
- to supplier). Turnover and commission totals per VAT
category.
 Not-sold item report for goods with a non-zero balance. User-

defined display range from - to creation date.
INVENTORIES PACKAGE
Following the system's philosophy, inventories (fiscal year and cyclic/extraordinary ones) can
be conducted in several ways and the information present in the master item file can be
exploited. The company can choose the method most suitable to its operational requirements
and (at a later stage) feed the system with the necessary data in order to exploit the most
advanced abilities.
The inventory parameterisation consists of the creation of the appropriate Documents in the
same way to the one described in «Document parameterisation » (see page 36).
The inventory document parameterisation also defines whether the

inventory will take into account only quantities, only values or both.
Using the Inventories package, the user may define the various counting methods he intends to
use, whether these are year-start inventories (with balance relocation), or cyclic/ extraordinary
inventories done purely for “internal” reasons. In the latter case, each stock item can have a
certain cyclic counting date (even a day of a week or a month), which can be centrally
maintained.

Independently of the inventory type, SRS/BO-Basis Module has a series of powerful tools that
facilitate such operations.
 Definition of stock balance valuation method. Using the cost prices present
in the item file (see «Main stock item attributes », page 34).
 No valuation
 Standard cost price
 Based on average cost price
 Based on last cost price
 Printing of Inventory sheets or statements. Items are selected based on

their item group or on their Geographical criteria (store/warehouse area).
Sheets are grouped in batches and can be assigned to counting groups.
 Inventory data input from file or manually. The file can be created either
from the PoS (see below), or from portable terminals.
 Inventory at PoS terminal. A special function has been added to the

software running on the PoS, so that inventory item and quantities can be
entered at the PoS terminal, also using its scanner. The file created with this
procedure can be imported to any of the defined inventories.
 Production of inventory control statements. Items are selected based on

their item group, their Geographical criteria (store/warehouse area), the batch
code of the inventory sheets or the code of the counting group carrying out the
inventory.
 Inventory corrections input. The differences between accounting

(theoretical) and actual balance can be corrected through special warehouse
transaction Documents (e.g. Balance posting from one item ID to another,
balance depreciation etc.).
Year-end inventories are transferred to the new fiscal year by finalising (issuing) the relevant
Document. All inventories can create an output file to be sent to the headquarters.
PROCUREMENT MANAGEMENT
The procurement management package provides new important information at the store level
and fully supports the hierarchical relation of the main supplier with its local representatives
(or the central warehouses), who receive and execute orders for each store depending on its
geographical location.
 The "Business Partners" master file data include further fields and indicators
for the basic suppliers and their representatives.
 Default values for the order Document’s fields (order recipient,

goods dispatch means, delivery lead-time, order dispatch
means).

 General information: Names of contact persons, fax /

telephone numbers, e-mail.
ORDERING
Operators can use any of the following methods to post their orders. The system numbers
automatically each order, while it maintains the creating operator's information and the
creation time.
 Automatic order creation (recommendation) based on re-stocking criteria

for each item and taking into account the relevant supplier’s logistics
parameters. Automatic item return recommendation is also possible.
 Possibility to recall / edit an order received from the central system (e.g. for
promotions). The orders “travel” both ways, as they are part of the daily data
exchange with the headquarters.
 Manual ordering. For cases where the system has not been supplied with
re-stocking parameters or for extraordinary orders.
The use of the Graphical User Interface (GUI) offers new capabilities to display a complex
document, such as an order document, on screen. The user has instant access (at a glance) to
data such as item quantity and value, current stock level, quantities to be ordered, package
units for each item etc. The user can also easily add his own notes and fill in the data of the
document as well as give instructions to the recipient and/or the person who will accept the
goods once they arrive.
Each order has an “order status” (Under revision, Pending, Partially

fulfilled, Executed, Deleted). The system automatically updates this
field each time there is a change in the content of the order.
Regardless of the way used to create an order, the system offers the possibility for further
processing.
 Save (store) order to continue working on it at a later stage and/or by a

different operator. Possibility to delete non-finalised orders.
 Order printouts. Summary or detailed ones, using filters based on the

calendar period and/or “order status.
 There are many possibilities for the selection of items to be ordered. The
following filters can be cumulative, whereas (where mentioned) there is the
option to use them also as exclusive filters.
 Supplier / Representative
 Warehouse
 Item group (with the option to use an exclusive filter)

 Geographical code or horizontal category (with the option to

use an exclusive filter)
Except for the above automatic, “en masse” item entry options, the user can independently
enter specific items either by using the item barcode (it is advisable to use scanner10), or the
item ID.
When finalising the order, it is possible to export it in a file (to send it to headquarters or for an
EDI connection) and/or print it. Once the order is finalised (and transmitted), it cannot be
modified.
GOODS-RECEIVING (PURCHASES) - INVOICE CONTROL
Apart from sales and stocktaking (inventories), the procurements management package covers
all the other the needs of a branch regarding stock movements. The package’s direct access to
orders data (see «Ordering», page 59), combined with the capability of SRS master files to
maintain data at item and supplier level, provide the enterprise with the ability to enforce
control on entries at the required level (value or quantity, detailed or not). Even in the case
where no local control is required, the storage (and dispatch to headquarters) of goods-
receiving data simplifies and accelerates the centralised procedures.
The purchase documents can be parameterised as described in the «Document

parameterisation » section (see page36). All Documents needed for the store operations can be
configured using this common approach (irrespective of the fact they are used in
Accounting/General Ledger or not).
Operators can use any of the following methods to post their documents orders. The system
numbers automatically each document, while it maintains the creating operator's information
and the creation time.
 Semiautomatic Document creation by transforming an order document (in

total or partially). Selection of orders based on calendar period, supplier code,
warehouse code and “order status. In that way, a document can contain items
from various orders. In combination with the possibility to merge many physical
Documents into one, all combinations are possible. Close cooperation of the
purchasing package with the orders package offers the possibility of partial
deliveries and can (at the user’s discretion) monitor back-orders.
 Possibility to recall / edit a Purchase document received from the central

system (e.g. for promotions). The purchase documents (as all system
Documents) are part of the daily data exchange with the headquarters.
 Manual document creation. In cases when the system is not updated with
the relevant order (which, of course, can be created from a goods-receiving
procedure and transformed afterwards) or for Documents regarding internal
movements, destroyed goods, declassification etc.
10
Any scanner with a keyboard wedge connector can be used.

 Additional transformations and controls. If receipt and control procedures

for the incoming documents are required locally (different behaviour can be set
foe each document type), the system can automatically suggest the creation of
credit documents for items (or item quantities) that do not meet certain
requirements. The user can choose not to issue these documents and to accept
the goods “as is”. The automatic control options cover:
 Difference between ordered and received quantity
 Difference between printed and received quantity
 Difference between agreed and printed final item unit value
 Items not ordered
 Computational discrepancy of document’s totals
For each of the above cases, it is possible to define separate

corrective/credit documents with the possibility to add comments etc.
The use of the Graphical User Interface (GUI) offers new capabilities to display a complex
document, such as a purchase document, on screen. The user has instant access (at a glance) to
data such as item quantity and value (anticipated/actual), current stock level, quantities on
order and to which orders they belong, package units for each item etc. Furthermore, the user
can easily add notes and fill in the data of the documents pertaining to the items he receives.
Each document has a «Document status» (Under revision, Pending,

Closed, Deleted). The system automatically updates this field each time
its content changes.
Regardless the way a document has been created, the system offers multiple options to further
process it.
 Save (store) document to continue working on it at a later stage. This option

is very useful in cases where different operators register data of the same
Document (e.g. when one person is responsible for physical receiving and
another for the control of accompanying paperwork).
 Document printouts. Summary or detailed ones, with the following filters:

calendar period, document type, supplier / warehouse and Document status.
 In order to facilitate the Receipt of goods included in a Document, the

operator has a number of ways to enter items (by typing the item ID, the
supplier item code, or the barcode (it is advisable to use scanner)). Any incurred
surcharges can be entered on the item lines or at the total-level, where an
additional option can spread these to all items. There is also the possibility to
print directly shelf-labels for the received items.
The documents entered can be exported (parametrically per type) into a file in order to be sent
to the headquarters. Which documents will be included in this file can be additionally

constrained based on the Document status criteria. Once the document is finalised and/or sent
to the headquarters, it cannot be changed.
CASH-OFFICE MANAGEMENT
Having direct access to transaction data from the PoS and sales workstations of the store, the
SRS/BO-Basis Module provides, through the special Cash-office Management package, a set of
tools and procedures that help chief cashiers manage all data concerning moneys. The main
benefits thus gained are:
 Unified overview of the incoming and outgoing moneys to the central cash-
office, even regarding actions that do not have to do with sales.
 Detecting human errors (when counting or entering data) and correcting

them. Provision of a complete track record of deficits and surpluses (cashier
outlook), as well as any corrective actions taken (in Detailed system event log ,
see page 31).
 Issuing an aggregate daily cashier balance sheet as well as a “certified

Transactions Sheet in Multipart” (and other such fiscal documents as required
by country).
 Production of other fiscal statements (printed or on diskette).
 Automatic creation of General Ledger records.
The Cash-office Management module can handle the following:
 Corrections in till counting. If utilised, the Tender count function in the PoS
terminal (see page 27) offers the possibility to compare it with the system
accumulators (whether they concern a particular PoS or a particular cashier)
through the store control reports (see page 38). If the resulting discrepancy is
due to an operator mistake, the chief cashier can correct it. It is also possible to
fully count the drawers' content from this point.
 Likewise, Withdrawals and Deposits in the store's counters can be

performed centrally, without requiring the cashier to execute the relevant PoS
function.
 Through the unified environment, the chief cashier can register other cash-
office transactions, like miscellaneous payments (e.g. expenses) and collections
(e.g. against open balance), withdrawals and deposits.
 The parameters for creating Accounting records define how system

transactions create records in the files that can be used to generate trial entries
for the headquarters’ system General Ledger.
 Certified transaction sheet in multipart issue parameters define the

contents of the specific printout (except for the mandatory legal data). If the
Main stock item attributes regarding the consignment items and/or the options
regarding other cash-office transactions are used, then the user can enter

strings and numbers pertaining to the actual trial entries regarding these
transactions so as to be included in the printout. Especially for consignment
items, the item group code must be entered.
All cash-office transactions can create corresponding Documents and

can be included in the files sent to the central system.

ADDITIONAL SRS/BO MODULES
SRS/BO-HANDHELD TERMINALS
INTRODUCTION
SingularLogic was quick to acknowledge the usefulness of portable terminals in the retail
environment and developed special software for these devices, so as to exploit their
possibilities at the maximum and create a fully integrated solution. As explained below, the use
of a portable terminal in conjunction with SRS/BO-Basis can be a valuable aid to the everyday
tasks of the store's personnel.
The use of wireless networks (WLAN) both in warehouses and in the sales areas is constantly
growing. This broad acceptance has been boosted by the fact that several infrastructure
hardware manufacturers adopted common standards for such topologies. Connecting portable
terminals is only one part of the capabilities and usefulness of such an architecture (like
Symbol’s Spectrum24) in which customer point-of-service, self-scanning terminals, PoS
terminals as well as all devices supported by the SRS/FO-PLU Devices module (see page 41) can
be integrated.
MAIN FUNCTIONS
Irrespectively of the connection method (batch or on-line), the application running on the
portable terminals provides the following:
 Ordering
 Create an order for further processing within the orders

package.
 Create an order for direct transmission to a remote

computer11.
 Enter received item quantities.
 Enter stock-taking data
 Select items for Printing of shelf-labels.
 Enter and update certain Main stock item attributes
 Geographical (store/warehouse) codes
 Shelf capacity (store/warehouse)
 Safety stock level
11
Through PDTpal. An internal modem as well as a suitably configured computer–host are required.

 Price change
 Barcode – item ID matching (with the possibility to enter

different quantity for each code)
 Miscellaneous functions.
 Shelf-label price verification. Comparison between label and

file price.
 Shelf verification. Actual shelf space control.
 Competition variety. Simple barcode entry.
 Competition prices. Barcode and price entry.
 Simple list. Barcode and optional value entry for a simple list
printout.
ADDITIONAL FUNCTIONS
 Load Terminal. A terminal can be loaded with a part of the items file, so that
the operator may work on specific data. This function is especially useful during
inventories, price check on shelves and barcode- item ID matching. Loading
criteria depend on the function selected.
 Unload Terminal. Depending on the function activated, there can be

automatic display / printout of terminal memory data or copying of the data in a
special file to store them or send them to headquarters.
 Orders, goods-receiving and inventories function in similar ways with those

described at the relevant paragraphs.
 Printing of shelf-labels runs as it is described in the respective paragraph of

the relevant chapter (see page 38). It can also be automatically activated by the
portable terminal functions that affect label contents (e.g. Label price
verification).
 All the changes in Main stock item attributes , can be printed before they
are finalised (by comparing old and new data). The user can choose to finalise
only part of the changes. Especially in the case of price changing, the specific
item should have the appropriate flag that allows such an action.
 The Miscellaneous functions of the portable terminals can produce

printouts and/or files. The simple list has user-defined header and columns
descriptions and can be used for a variety of auditing/informational tasks.

SRS SYSTEM REQUIREMENTS
Hardware
12
Server Intel i3 (or equivalent), 4GB RAM, 70GB HDD
13
PoS Wincor Nixdorf Beetle (all models),
IBM 4694 (models 104 and later),
IBM SurePOS (all models),
IBM APK (all models),
NCR RealPOS (all models),
Bizerba KH series,
Any UPOS-compliant PoS system
Fiscal Printers Wincor Nixdorf BJB, ND77, MF-EJ210, MF-EJ320
IBM Model 3F, 4610-GR3, 4610-GB3
EPSON FP-81F, TH6000
NCR ΑΔΗΜΕ
Proline Ergospeed I, Ergospeed II
CPI PosiFiscal II, PosiFiscal III
Non-fiscal IBM, Wincor Nixdorf, NCR, EPSON, STAR, BIXOLON (all models)
Printers
Any UPOS-compliant PoS printer
Any Windows-compliant PoS printer
PoS peripherals All current IBM and Wincor Nixdorf peripherals are supported
Any UPOS-compliant peripheral
12
Minimum requirements
13
See next chapter for exact models and options. Valid at time of print. Please contact SingularLogic representative for the latest
models and configuration options.

12
Client Pentium-III (or equivalent), 256MB RAM, 10GB HD
Electronic Teraoka/Digi (all current models),

scales
Bizerba SC-class,
TEC (all current models)
Price Checkers Symbol Technologies PCK 9100
Scantec (all models)
Any Windows-based Price Checker
Portable Symbol Technologies PDT 3000 series

terminals
Motorola (all current models)
Any Windows CE (5.5 or higher) terminal
Label Printers Intermec/UBI EasyCoder series,
Eltron LP/TLP series
Any printer that is EPL2-compatible
Electronic Shelf PRICER ESL

Label
Management Teraoka/Digi
System
System Software
14
Application & Windows Server O/S
Database
Server Oracle Database 10g R2, Oracle MySQL 5.5
Client Windows XP, Windows 7
PoS Windows XP, Windows 7, Windows Embedded for Point of Sale,

Linux
14
In case the Application Server and the Database server are different machines the Database server can have any Operating System
supported by the RDBMS

Network
Topology Ethernet / Fast Ethernet, Token Ring
Protocol TCP/IP
Architecture Client-Server (Gartner Group Model 2 for all sub-modules except

for SRS/FO-PoS which follows Model 5)

© 1998-2013 SingularLogic SA
All Rights Reserved
The manufacturer reserves the right to change any of the technical

specifications mentioned herein without prior notice. This document can
not be used as a binding functional warranty of any kind and is not proof
of fitness for any business application.
This release contains forward-looking statements. All statements that are

not historical are forward-looking. Forward-looking statements may
relate to, but are not limited to, SingularLogic's future financial
performance, capital expenditures, revenues, acquisitions, earnings,
costs, product development plans, global expansion plans, estimated size
of potential customer markets, demand for its products, the projected
acceptance by existing or potential customers of new technologies and
the potential features of, or benefits to be derived from, the products
developed, marketed or sold by SingularLogic, market and technological
trends in the software industry and various economic and business
trends. Such forward-looking statements are only predictions and involve
a number of uncertainties and risks that may cause actual events or
results to differ materially. Factors that could cause actual events or
results to differ materially include, among others, the following: general
economic factors and capital market conditions, general industry trends
and the potential effects on us of competition in computer software
product and services markets, growth rates in the software and
professional services markets that we participate in, rapid technological
change that can adversely affect the demand for our products, shifts in
customer demand, market acceptance of new or enhanced products or
services developed, marketed or sold by us, delays in scheduled product
availability dates, actions or announcements by our competitors,
software errors, reduction in sales to or loss of any significant customers,
our ability to successfully integrate acquisitions, any failure by us to
protect our intellectual property rights, the dependence of certain of our
business units on licenses from third parties, our ability to attract and
retain qualified personnel.
All brand and product names mentioned in this document are

trademarks, registered trademarks or service marks of their respective
holders.
SingularLogic SA
Al.Panagouli & Siniosoglou
142 34 Nea Ionia, Attica, Greece
 +30 210 6266500
www.singularlogic.eu

SRS Technical and Functional Description en

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

SRS Technical and Functional Description en

Загружено:

Авторское право:

Integrated Retail Store

MAIN SRS/FRONT-OFFICE SYSTEM ........................................................................................................... 7

ADDITIONAL SRS FRONT-OFFICE MODULES ............................................................................................. 8

MAIN SRS STORE BACK-OFFICE SYSTEM .................................................................................................. 9

ADDITIONAL SRS/BACK-OFFICE MODULES............................................................................................... 9

MAIN SRS HEADOFFICE SYSTEM ............................................................................................................... 9

SINGULARLOGIC APPLICATION SERVER (SAS) ........................................................................................ 19

SAS Identity ......................................................................................................................................... 19

SAS Implementation Methodology ....................................................................................................... 19

Main SAS benefits ................................................................................................................................ 20

SRS DEVELOPMENT TOOLS...................................................................................................................... 22

Embarcadero Delphi XE ..................................................................................................................... 22

Sencha Ext JS ...................................................................................................................................... 22

MAIN TECHNOLOGICAL AND OPERATIONAL CHARACTERISTICS .............................................................. 23

Other functions .................................................................................................................................... 27

Document Issuing ................................................................................................................................ 28

04/02/13 Rev. 7 2 © 1998-2013 SingularLogic SA. All Rights Reserved

SRS/FO-PLU DEVICES ............................................................................................................................ 41

General PLU Device Support Parameters .......................................................................................... 41

Electronic Scales Support .................................................................................................................... 42

ESL Support ......................................................................................................................................... 43

Price-Checker Support ........................................................................................................................ 44

SRS/FO-CUSTOMER LOYALTY ................................................................................................................ 45

General Characteristics ...................................................................................................................... 45

Loyalty Programme / Campaign Customisation ................................................................................. 46

PoS functions ....................................................................................................................................... 47

Other functions and system extensions ................................................................................................ 47

Reports and Printouts .......................................................................................................................... 48

Examples of Customer Loyalty Offers ................................................................................................. 49

SRS/FO-DUTY FREE SUPPORT ................................................................................................................. 52

SRS/FO-STORED CREDIT ......................................................................................................................... 52

General Characteristics ...................................................................................................................... 53

WAREHOUSE AND ITEMS MANAGEMENT.................................................................................................. 55

Main functions ..................................................................................................................................... 55

Inventories package ............................................................................................................................. 57

PROCUREMENT MANAGEMENT ................................................................................................................ 58

Goods-receiving (purchases) - Invoice Control .................................................................................. 60

CASH-OFFICE MANAGEMENT ................................................................................................................... 62

SRS/BO-HANDHELD TERMINALS ............................................................................................................ 64

Main functions ..................................................................................................................................... 64

04/02/13 Rev. 7 3 © 1998-2013 SingularLogic SA. All Rights Reserved

SRS SYSTEM REQUIREMENTS ........................................................................................................... 66

04/02/13 Rev. 7 4 © 1998-2013 SingularLogic SA. All Rights Reserved

SRS PRODUCT IDENTITY

04/02/13 Rev. 7 5 © 1998-2013 SingularLogic SA. All Rights Reserved

GENERAL OVERVIEW OF SRS

Figure 1. SRS Application Architecture

04/02/13 Rev. 7 6 © 1998-2013 SingularLogic SA. All Rights Reserved

MAIN SRS/FRONT-OFFICE SYSTEM

The main SRS/FO system consists of the 3 following modules:

1. SRS/FO-PoS, the application software that runs on the PoS and

2. SRS/FO-Com middleware module, this module is the part of

3. SRS/FO-Kernel, the basic store management application, takes on

04/02/13 Rev. 7 7 © 1998-2013 SingularLogic SA. All Rights Reserved

ADDITIONAL SRS FRONT-OFFICE MODULES

1. SRS/FO-PLU Devices provides the ability of connecting and on-line

2. SRS/FO-Customer Loyalty supports the maintenance of additional

3. SRS/FO-Duty Free Support adds all the system functions required

4. SRS/FO-Stored Credit is the sub-system responsible for the

5. SRS/FO-Advanced Customer Loyalty is a next-generation complex

6. SRS/FO-EFT Connect adds the capability to transparently and

04/02/13 Rev. 7 8 © 1998-2013 SingularLogic SA. All Rights Reserved

MAIN SRS STORE BACK-OFFICE SYSTEM

 Warehouse and Storage location Management (inventories, stock control,

 Purchase Management (Orders, Receipts, Invoices, Purchase documents

 Store till management (miscellaneous receipts – expenses, cashier