Retailers offer a wide range of products, services, promotions, payment methods, and channels which requires a complex retail transaction organization, structure and content information model. Historically retail transaction is where ARTS started and is the most developed part of the data model.
Core Retail Transaction Functional Requirements
The Retail Transaction Theme organizes and defines the data structures required to support the recording of sales and returns and related business between the business unit and its customers. RetailTransaction entity instances are created at the point where the store's merchandise and services are transformed into tender and credited as sales (or the reverse for returns). The retail transaction subject areas and their entities answer questions like:
|•||What retail items did the store sell during a given period?|
|•||When were the retail items sold?|
|•||Where were the retail items sold in the store?|
|•||Who sold the retail items?|
|•||How much was charged for the retail items?|
|•||How much sales tax was collected in a given transaction?|
|•||What fees were earned in a given transaction?|
|•||What special allowances, discounts, markdowns and other price modifications were applied to the items? |
|•||How much tender was received or disbursed to settle the transaction?|
|•||What kind of tender was received or disbursed?|
ARTS Retail Transaction Design Principles
There are certain design principles the ARTS Operational Data Model incorporates into the Retail Transaction Views to emphasize fiscal and unit accounting integrity. These principles are:
|•||All retail transactions must be reducible to a standard set of accounting entries consistent with generally accepted retail accounting practices. This requirement is a key part of integrating retail transactions with the financial ledger for the store; |
|•||All debit and credit entries that originate from a retail transaction must balance; |
|•||All retail transactions must be traceable to the individual keying in the sale, the till used to collect tender, the workstation used to record the sale and the date and time the transaction is created; |
|•||Retail transactions involving merchandise sales or returns must be linked to the financial and merchandise unit control ledgers used to account for and audit the daily operation of the store; |
|•||The retail transaction is organized into three tiers: |
❖Transaction level: information to describe the people, place, time, location and type of business conducted between the store and a party;
❖Line level: information to describe the individual items that make up the transaction; and
❖Line modifier level: information to apply specific pricing rules, sales tax rules, sales restriction rules, and so on to individual line items in a transaction.
|•||Sale/return merchandise line items, deposit/redemption line item's, and sale/refund service line item's must be associated with a valid POSIdentity and through that entity to a valid Item. The POSIdentity entity type provides the point of sale system's item identity which is usually a GS1, UPC or EAN barcode and product number|
ARTS Retail Transaction for Different Business Segments
The ARTS ODM V7.0/7.1 supports a number of specialized retail transaction types as well as integration with customer orders (for scenarios where customers do not take the merchandise with them at the point of purchase). The retail transaction includes entities, relationships and attribute to handle:
•Retail Transactions and Customer Orders (see Logical 02315 - Retail Transaction - Customer Order View);
•Food services retail transactions (see Food Service & Hospitality);
•Forecourt retail transactions (seeForecourt) ; and
•Rental retail transactions (seeLogical 02370 - Retail Transaction - Rental View).
ARTS is continuing to extend the data model. The rapid proliferation of mobile devices and need to merge and rationalize customer-retailer interactions across all touch points will impact retail transaction in future releases of the operational data model.