View source | View content page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Show collection (0 pages)
Collections help


Projects:Loss Prevention/Functional Specification


Functional Specifications

Loss Prevention is the placeholder for two distinct types of loss: One caused by intentional fraud, another caused by un-intential neglection. The functionality that this document envisions, is a functionality that detects examples of (potential) loss with extensive capabilities to report the occurrences, either in real time or deferred.

Even though the mayor part of loss prevention focusses on the physical product as described below in Inventory Shrinkage, loss prevention in Openbravo also encompasses the detection of manipulative activities in order to obtain a fraudulent benefit. An example of this is the delayed purchase of an extended warranty, closely followed by a warranty claim for that product.



Inventory Shrinkage is the loss of products between initial receipt -either from production or from purchase- and sales. According to a study from 2015, approximately a third of inventory shrinkage is traced back to internal theft (intentional fraud) while anothe sixth is caused by administrative errors (un-intentional neglection).

Fraud is part of the reality in which we life, like it or not. As supplier of software and consultancy focussed on retail, it is our obligation to be aware, knowledgeble and assist our clients when and where possible with our know-how with the objective to fight and eliminate fraud from his business.

Fraud, in terms of IT systems, can be separated into two main activities: The detection of it and the prevention of it.

Fraud Detection & Prevention

Fraud (-detection) is an a-typical development in the sense that -from the development perspective, there is a seemingly endless list of potentialy fraudulent situations; The key-word here is 'situations' because it shows the difficulty to be more specific: A 'situation' can be anything and our best source for these situations come from the experienced people in the field. See below a list of Use-Cases from our own experience.

For detection of fraudulent activities in Openbravo, we first should define what activities or situations should be part of our scope. Also, we should be aware that there some activities -in itself- are not suspicious but in a specific context -behavior compared with fellow-workers and/or in a specific time-frame- they are. So, theoretically there is an unlimited list of situations that should be monitored or analyzed. And here lies the complexity of fraud detection: Newly concieved methods or ideas for fraud will go unpunished until it is detected, understood and transformed into a new indicator.

It is the purpose to list the known situations and present the occurence in an orderly and actionable manner.

errors, anomalies, inefficiencies, and biases which refer to people gravitating to certain dollar amounts to get past internal control thresholds. The analytic tests usually start with high-level data overview tests to spot highly significant irregularities.

Fraud Prevention Under this paragrapgh we list the situations that not necesarily are fraud but are situations where fraud could be easy to commit. These deserve a further investigation.


Study other systems and learn.

Un-intential Neglection

Design Considerations

Detection and Communication Framework

Fraud (-detection) is an a-typical development in the sense that -from the development perspective, there is a seemingly endless list of potentialy fraudulent situations; The key-word here is 'situations' because it shows the difficulty to be more specific: A 'situation' can be anything and our best source for these situations come from the experienced people in the field.

Nevertheless, we do recognize with this a few essential things that allows us to structure:

FraudDetection Framework.jpg

With this we at least can establish a basic foundation of the Fraud detection and prevention module:

In general, the goal of the specs would be to have a master-table where all fraud possible situations are registered. This table would enable us to prepare any report of create alerts for the information in it.

Master table definitions

A proposed definition of a Spider:

ID Type Description Parm-1 Parm-2 Program name Active LastRun
1001 Discounts Applying non-standard discounts aabbccdd Yes 2015-05-12 11:43
1002 Cashup Negative differences PaymentMethod=Cash Tolerance=10 bbccddee Yes 2015-05-12 11:43 Note that an integration with schedular is assumed.
1003 Delete=Cancel Delete orders or lines really cancels them NA Yes 2015-05-13 12:18
1004 Inventory Expires Notify to create promotions xxyyzzww Yes 2015-05-12 11:43

Since every spider can have several communications, this is stored seperately:

Spider-ID Sequence Moment Method Role of startpoint Role of endpoint Text Active
1001 10 Immediate SMS Cashiers Supervisors &SPIDER-NAME& for &AMOUNT& at &POS-ID& &END-USER& Yes Expressed here is that depending on WHO commits the situation, the SMS (in this case) is sent to a different role.
1001 20 Immediate SMS Supervisors Store managers &SPIDER-NAME& for &AMOUNT& at &POS-ID& &END-USER& Yes
1002 10 Immediate SMS Cashiers Supervisors Authorization request for &SPIDER-NAME& at &POS-ID& &END-USER& Yes
1002 20 Immediate SMS Supervisors Store Managers Authorization request for &SPIDER-NAME& at &POS-ID& &END-USER& Yes
1004 10 EOD Report Store managers Inventory close to expiry date - Proposed Promotions for &PRODUCT &LOT &BIN &EXPIRY-DATE &QTY &UOM Yes

A proposed definition of a Situation

Situation-ID Spider-ID Date/Time Organization POS-ID End-User Order/Line Amount Currency
9345531 1001 2015-05-12 11:43:48 White Valley East POS123 Maarten Tromp 22334455/1 -14,45 EUR
9345532 1003 2015-05-13 12:18:32 White Valley East POS123 Maarten Tromp 10002/1 -29,95 EUR
9345533 1002 2015-05-13 12:40:11 White Valley East POS123 Maarten Tromp -15,01 EUR

And the resulting communications

Situation-ID Method Date/Time Receiver Text
9345531 SMS 2015-05-12 11:43:50 +34 661 621 xxx (Ismael Ciordia) Non-standard discounts for -14,45 at POS123 Maarten Tromp
9345533 SMS 2015-05-13 12:40:13 +34 661 621 xxx (Ismael Ciordia) Autorization request for Negative differences at POS123 Maarten Tromp

The tools we now see would be:

History of Situations

Situation-messages should be stored to build up history for statistical review.


Preferences are used on Openbravo to set predefined values for specific situations and functions. These values can be used to default input in certain screens but can also be used as thresholds to define ceertain upper or lower limits.

The current set of preferences does not have a functional grouping theme, all are together in the same bowl. This absense of functional grouping provokes difficulties in configuring as it requires experience and knowledge in order to avoid incomplete -and therefore incorrect- configurations.

However, functional grouping is less trivial as it seems. A certain threshold can be grouped in multiple functional groups, depending the perspective of the viewer, for instance: A maximum Over-Receipt Tolerance (% or €...) for the purchase-order receipt will be seen as a Financial or Accounts Payable setting by the controller, while the warehouse manager might search for this in the group of Warehouse settings.

Use-Cases from the field


Please add here examples




Please add here your examples


Retrieved from ""

This page has been accessed 382 times. This page was last modified on 3 October 2017, at 12:17. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.