Oracle® Retail POS Suite 14.1/Merchandising 14.1 Implementation Guide Release 14.1 E59307-03 |
|
Previous |
Next |
This chapter provides information about the integration architecture between Oracle Retail POS Suite and merchandising products.
The Point-of-Service terminal is the platform that the Point-of-Service client application resides on. The cashier and the store manager interact with the Point-of-Service client application, which generates transaction data. The Point-of-Service client application sends a serialized object structure representing the sales transaction to the Point-of-Service store server residing on the In-Store-Processor (ISP). The ISP is responsible for persisting the raw transaction data to the store database.
The major component of the POS Suite to Oracle Retail Sales Audit integration is:
RTLog Export Daemon Technician
Processes configuration settings from the Store Sever Conduit XML file; settings include sleep interval, maximum number of transactions per batch, export directory name, object factory class names, and export configuration files names.
Starts the RTLog Export Daemon Thread.
RTLog Export Daemon Thread
Starts the export process on a periodic basis based on the configured sleep interval. Calls the RTLog Batch Generator.
RTLog Batch Generator
Creates a list of transactions ready for export and calls the Export File Generator.
Export File Generator
Reads the transactions in the list and formats the export data based on the export configuration files.
In this integration, the Point-of-Service store server also maps the transaction table structure to RTLog format and places the RTLog-formatted transaction into a file. The individual components that comprise the RTLog generation are described in the following subsections.
The RTLog Batch Generator is a Java class that reads transactions from the store database and creates a physical RTLog file. The file format follows the standards outlined in Oracle Retail Merchandising System Operations Guide, Volume 1 - Batch Overviews and Designs - Release 13.1.
The RTLog Batch Generator consumes a configuration file that has the settings outlined in the following sections.
The RTLog batch generator runs in a daemon mode, which periodically outputs RTLog files created by pulling transactions from the database. In this configuration, Oracle Retail Sales Audit processes one or more RTLog files from any given store.
The default sleep interval value is 600 seconds. This value can be changed in the StoreServerConduit.xml
file. See Table 5-4, "Store Server Conduit File" for more information
The Maximum Transactions setting puts a cap on the number of RTLog transactions read from the store database during a processing cycle. If the number of transaction available is less than the maximum transactions setting, the RTLog Batch Generator reads the number of transactions available.
If Maximum Transactions is set to -1, then there is no limit to the number of RTLog transactions.
Oracle Retail Sales Audit is responsible for sales audit functionality at the store and at the corporate level. Store operations make use of Oracle Retail Sales Audit's functionality to determine over/short situations in stores, and make the necessary adjustments to raw transaction data in order to ensure integrity of data being sent to Oracle Retail Merchandising System and Oracle Retail Store Inventory Management.
Oracle Retail Sales Audit consumes unaudited transaction data in RTLog batch format. It then subjects the transaction data to numerous checks, and indicates exceptional conditions leading to out-of-balance situations. Oracle Retail Sales Audit outputs cleansed or audited RTLog data to be consumed by Oracle Retail Merchandising System, Oracle Retail Price Management, and Oracle Retail Store Inventory Management.
Data Import (DIMP) is a set of domain-specific modules within either Oracle Retail Back Office or Oracle Retail Central Office that enable the import of data from both Oracle Retail Merchandising System and Oracle Retail Price Management. Imports through Oracle Retail Back Office are persisted to the store database, affecting the data available to and read by Oracle Retail Point-of-Service.
Note: When discussing Data Import, functionality applies to both Oracle Retail Merchandising System and Oracle Retail Price Management. |
The DIMP subsystem and components are designed to enable external systems to send large volumes of data to the Oracle Retail POS Suite applications. The primary intent of this functionality is to allow for initial data seeding or routine data loading (and optional purging) to occur for such types of data as:
Taxation
Merchandise Hierarchy
Store Hierarchy
Employee
Item
Pricing
Customer
Currency (Exchange Rates)
Scan Sheet
Note: For more information about the XML format required by any import, refer to its specific XML Schema Definition (XSD). Some attributes are labeled required. All attributes listed as required in the XSD must be included in the import XML file. See Archive File Format in Chapter 3 for more information about import XML format. |
Note: Taxation, Employee, Customer and Currency information are not provided by Oracle Retail Merchandising System and Oracle Retail Price Management. Any of this information would come from third-party systems.For more information, see Third-party Tax and Employee Information in Chapter 6. |
POS Suite applications are not the system of record for data correctness. Error handling is limited to logging errors during the import and performing a retry in certain cases. Because the data imports can be interdependent, a failure in one file import may result in an abort of the import of the rest of the files in the import that depend on the failed data.
There were no changes made to the base data model to support the data import subsystem. However, a few tables exist (see Import Status Logging) to take care of data import error handling and to support any recovery or retry mechanism that might be put in place in the future (that may be custom developed).
For the current implementation, all Kill And Fill imports are applied into temporary tables. Once the import of the complete file is successful, the data is written onto the main tables. If any data operation fails, the entire file import is aborted. A FAILURE status message is logged for each of those files.
Incremental (Delta or Full) file imports continue even if a data operation fails. In that case, only the import batch containing the failure is rolled back and the error is logged. It is the customer's responsibility to decide how to handle the failed operations.
The act of aborting the import is configurable and can be changed based on implementation requirements. The class ImportErrorHandler
mapped to the Spring key persistence_ImportErrorHandler
in the Spring context file PersistenceContext.xml
can be configured to any other custom implementation of an ImportErrorHandler.
The following section describes the statuses and three tables in the data model that record Data Import attempts:
In case of failure in opening the bundle or reading a file in the bundle, the status in the tables is MA_STS_BNDL_IMP – FAILED
.
No other status is logged in any other table.
In case of failure in parsing a file, the statuses are:
MA_STS_BNDL_IMP – PROCESSED
MA_STS_FL_IMP – FAILED
for that file and all other files that are dependent on that file.
MA_FL_IMP_FLRS –
Failure exception details of the file.
In case of failure while persisting a batch:
If Kill And Fill then:
MA_STS_BNDL_IMP – PROCESSED
MA_STS_FL_IMP – FAILED
for that file and all other files that are dependent on that file.MA_FL_IMP_FLRS –
Failure exception details of the file that has failed.If Full Incremental or Delta Incremental then:
MA_STS_BNDL_IMP – PROCESSED
MA_STS_FL_IMP – PARTIALLY PROCESSED
for that file only.MA_FL_IMP_FLRS –
Failure exception details of the files that have failed.This is the Bundle Import Status table, which has the processing status at the bundle level. In a case where an input/output error occurs, such as unable to open the bundle or read a file from the bundle, the status is logged as FAILED. In all other cases where there is no input/output error, the status is PROCESSED. This is because a bundle can contain more than one file, and it is, from a performance standpoint, degenerative to keep track of how many files there are in the bundle and how many of them have succeeded and how many have failed. Therefore, unless an input/output error is encountered, the status PROCESSED is logged into the table.
File Import Status maintains the processing status of each file in a bundle. The status FAILED for a file indicates that there is a parsing exception, or there is a failure while persisting a Kill And Fill file (as complete processing is aborted in case of Kill And Fill). If a failure is logged in this table for a file, then all other files in the bundle that are dependent on the failed file also have a FAILED status.
The status PARTIALY PROCESSED for a Full Incremental or Delta Incremental import indicates there is a failure in persisting a batch. This status is irrespective of the number of records in the file. In an incremental type of import, a batch of records with no exceptions is persisted to the database and committed. Therefore, to note a FAILED status we must know how many records there are in the file, how many batches do these records form and the processing status of each of the batch. Performance-wise this is not advisable.
Also, if a bundle is re-processed, a FAILED status on an incremental file causes the file to be processed again, generating more exceptions.
Any failures encountered are logged in this table.
This facility is provided to reprocess any file that failed, that is, has a FAILED status in MA_STS_FL_IMP. No change is needed in the bundle to process a file again. If the same bundle is reprocessed, all the files with a status FAILED in MA_STS_FL_IMP are reprocessed. Therefore, if an incremental file has already crossed the point of parsing, (an exception while persisting) then the status for that file must never be logged as FAILED, as some of the batches might have been persisted and reprocessing the file generates more errors.
If there is a failure in any insert operation for a file of the Kill And Fill variety, the exception is logged and the complete file is aborted. Import of any subsequent file in the sequence that depends upon the failed/aborted file is also aborted. This is done to ensure that partial data inserts from the file are not performed, compromising the integrity of the data in the database. Import of files that do not depend on this particular file is not impacted.
If an operation (insert, update, delete) fails during the processing of an incremental file, delta or full, the current batch is aborted and subsequent batches are processed. The errors are logged for the failed batch and processing continues, starting with the next batch of the data in the file.
Figure 2-1 shows the logical data model for the tables being used in error handling in Data Import.
The archive file status is logged as CONSISTENT or INCONSISTENT in the table ImportBundleStatus, with the BundleID of the archive.
If an exception is encountered during the import of a file, the record where the problem is encountered is logged in the table ImportRecordStatus.
The exception is then sent up to the Data Import Controller where a FAILED status is logged on to the table ImportFileStatus. If the import has been successful for a file, a status of SUCCESS is inserted in the table.
Instrumentation for application monitoring can be provided by exposing beans to JMX through Spring, which orchestrates the process of creating JMX management interfaces for beans, and removes the need to compile them to the JMX API.
Example 2-1 must be configured in the Spring PersistenceContext.xml file:
Example 2-1 Sample JMX Configuration
<bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean"/> <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter"> <property name="beans"> <map> <entry key="bean:name=EmployeeImportDAOKey" value-ref="EmployeeImportDAO"/> </map> </property> <property name="server" ref="mbeanServer"/> </bean> <bean id="EmployeeImportDAO" class="oracle.retail.stores.commerceservices.employee.importdata.dao.EmployeeImportDAO"/>
At various points in the import process, exceptions such as SQLException and SAXException might be generated. They are generally rethrown as ImportExceptions and passed up the chain to the DIMP Controller, as well as logged for error tracking and resolution.
DIMP introduces a new Spring-based logging object to provide message consistency and allow retailer customization of messages. The underlying logging uses Apache Commons logging as the interface, and Log4j for the logging implementation. A MessageLogger is retrieved from the Spring service context. The logger gets message templates from a property file. Customers can define the layout of these messages to suit their needs, using the following format, where {x}
is a placeholder for input data from the calling program:
Message from {0} with {1} information.
The Spring bean ID used for the pluggable message logger component is shown in Table 3-1, "Spring Bean IDs Used for Each of the Pluggable Components". The mapping is shown in Example 2-2, "Message Bean Definition".
Example 2-2 Message Bean Definition
<bean id="service_MessageBuilder" class="oracle.retail.stores.commerceservices.importdata.MessageBuilder" singleton="true" lazy-init="true"> <property name="prefix"><value>${dimp.prefix}</value></property> <property name="texts"> <list> <value>${dimp.text1}</value> <value>${dimp.text2}</value> <value>${dimp.text3}</value> </list> </property> </bean>
See dimplogger.properties for configuration options for the DIMP MessageBuilder.
By default, each file in a bundle is processed by a single instance of DAO. To process this file using multiple threads, add the following attribute to the Manifest.mf file in the archive:
MultiThreaded: Y
Defining this attribute enables the DIMP infrastructure to parse the xml file and post the ImportBatch objects to the JMS queue based on the batch size defined in the spring.properties file. The MDB listener running on this queue hands over the ImportBatch objects to the respective DAO to complete processing. By default, there are 16 instances of MDB running. To increase the default MDB instances limit, add the worker manager configuration into the weblogic-ejb-jar.xml for the MDB DIMPProcessorMDB definition under the shared-ejb.jar file in the Central Office .ear file.
To view the status of the file processing, run the following query:
SELECT ID_BNDL,NM_BNDL_IMP, CS_STS_FL, TS_STR_IMP_PRC,TS_END_IMP_PRC, CNT_ENQ_JMS_MSG, CNT_DEQ_JMS_MSG, PS_STS_FL FROM MA_STS_FL_IMP
File processing is complete only if the CNT_ENQ_JMS_MSG count is equal to the CNT_DEQ_JMS_MSG count and PS_STS_FL is set to COMPLETE.
Note: If the file contains ADD, UPD, or DEL records for the same item, it is not guaranteed that they are processed in the same order. In those kind of situations, it is better to split those records into multiple files and add a dependency in the Manifest.mf file to process the records in the desired order. |
For RTLog format information, see "ReSA Interface File Layout [rtlog]" in the Oracle Retail Sales Audit Operations Guide.
Table 2-1 TransactionType (TRAT)
TransactionType | TRAT (Static) | TRAS (Static) Sub-Transaction Type |
---|---|---|
(1) Sale |
SALE |
SALE |
(2) Return |
RETURN |
RETURN |
(3) Void |
PVOID |
VOID |
(4) NoSale |
NOSALE |
NOSALE |
(1) Sale where an even exchange is made |
EEXCH |
EXCH |
(6) OpenStore |
OPEN |
OSTORE |
(7) CloseStore |
DCLOSE |
DSTORE |
(8) OpenRegister |
OPEN |
OREG |
(9) CloseRegister |
CLOSE |
CRGRC |
(10) OpenTill |
OPEN |
OTILL |
(11) CloseTill |
CLOSE TOTAL |
CTILL CTILLT |
(12) LoanTill |
LOAN |
LOTILL |
(13) PickupTill |
PULL |
PUTILL |
(14) SuspendTill |
NOSALE |
STILL |
(15) ResumeTill |
NOSALE |
RTILL |
(16) PayinTill |
PAIDIN |
PITILL |
(17) PayoutTill |
PAIDOU |
POTILL |
(18) HousePayment |
PAIDIN |
HOUSE |
(19) LayawayInitiate |
SALE |
LAYINT |
(20) LayawayComplete |
SALE |
LAYCMP |
(21) LayawayPayment |
SALE |
LAYPAY |
(22) LayawayDelete |
SALE |
LAYDEL |
(23) OrderInitiate |
SALE |
ORDINT |
(23) OrderInitiate and Order.OrderType = (1) SpecialOrder |
SPLORD |
ORDINT |
(24) OrderComplete |
SALE |
ORDCMP |
(24) OrderComplete and Order.OrderType = (1) SpecialOrder |
SPLORD |
ORDCMP |
(25) OrderCancel |
SALE |
ORDCAN |
(25) OrderCancel and Order.OrderType = (1) SpecialOrder |
SPLORD |
ORDCAN |
(26) OrderPartial |
SALE |
ORDPAR |
(26) OrderPartial and Order.OrderType = (1) SpecialOrder |
SPLORD |
ORDPAR |
(27) BankDepositStore |
NOSALE |
BANK |
(35) Instant Credit Enrollment |
NOSALE |
INSCRE |
(36) Redeem |
RETURN |
REDEEM |
(37) Enter Training Mode |
NOSALE |
NTRAIN |
(38) Exit Training Mode |
NOSALE |
XTRAIN |
(40) Payroll Payout |
PAIDOU |
PAYOUT |
(41) Enter Transaction Reentry |
NOSALE |
NTRENT |
(42) Exit Transaction Reentry |
NOSALE |
XTRENT |
Any transaction where Transaction.TransactionStatusCode = (3) Canceled |
VOID |
CANCEL |
Any transaction where Transaction.TrainingMode= ON |
NOSALE |
TRAIN |
Any transaction where Transaction.TransactionStatusCode = (4) Suspend Transaction. Note: (4) Suspend Transactions get sent in the RTLog. Subsequent resume or cancel actions simply change the transaction status code to (6) Resume Transaction or (7) Canceled Suspended Transaction. A new transaction is not created, hence no subsequent RTLog record, except if the Suspended Transaction is Resumed then SOLD, upon which a SALE transaction is created. |
NOSALE |
SUSPND |
Table 2-2 ReasonCode (REAC)
Reason entered by cashier for some transaction types. Required for Paid In and Paid out transaction types, but can also be used for voids, returns, and so forth. | REAC | Description |
---|---|---|
Till.TillPayInReasonCodes (53) BadCheckPayment |
NSF |
NSF Check Payment |
Till.TillPayInReasonCodes(54) VendingMachineRevenue |
TPIVMR |
TillPayIn VendingMachineRevenue |
Till.TillPayInReasonCodes(55) Miscellaneous |
TPIMSC |
TillPayIn Miscellaneous |
Till.TillPayrollPayOutReasonCodes (1) PayrollAdvance |
PAYRL |
Payroll Payout |
Till.TillPayrollPayOutReasonCodes (2) FinalPay |
PAYRL |
Payroll Payout |
Till.TillPayOutReasonCodes (56) Postage |
TPOP |
TillPayOut Postage |
Till.TillPayOutReasonCodes (57) Supplies |
TPOS |
TillPayOut Supplies |
Till.TillPayOutReasonCodes (58) Entertainment |
TPOE |
TillPayOut Entertainment |
Sale.NoSaleReasonCodes(1) CustomerChange |
NSCC |
NoSale CustomerChange |
Sale.NoSaleReasonCodes(2) ChangeForRegister |
NSCFR |
NoSale ChangeForRegister |
Sale.PostVoidReasonCodes(1) IncorrectPrice |
PVIP |
PostVoid IncorrectPrice |
Sale.PostVoidReasonCodes(2) DiscountIncorrect |
PVDI |
PostVoid DiscountIncorrect |
Sale.PostVoidReasonCodes(3) CustomerChangedMind |
PVCCM |
PostVoid CustomerChangedMind |
Sale.PostVoidReasonCodes(4) AssociateError |
PVAE |
PostVoid AssociateError |
Sale.PostVoidReasonCodes(5) OtherFormPayment |
PVOFP |
PostVoid OtherFormPayment |
Sale.PostVoidReasonCodes(6) Other |
PVO |
PostVoid Other |
Where transaction type = (18) House Payment |
HOUSE |
House Payment |
Table 2-3 Sale Line Item (SASI)
Status of the item within the transaction | SASI (Sale Line Item) | Static |
---|---|---|
SaleReturnLineItem.Quantity is negative |
R |
Return |
SaleReturnLineItem.Quantity is positive |
S |
Sale |
RetailTransactionLineItem.VoidFlag = true |
V |
Voided (when voided RTLog includes both original and voided line item) |
OrderLineItemStatus.ItemStatus = (0) New |
ORI |
Order Item Initiate |
OrderLineItemStatus.ItemStatus = (3) Canceled or (7) Voided |
ORC |
Order Item Cancel |
OrderLineItemStatus.ItemStatus = (4) Pickedup |
ORD |
Order Item Complete |
LayawayTransactionStatus.Status = (1) |
LIN |
Layaway Item Initiate (all sale return line items in the transaction take this status) |
LayawayTransactionStatus.Status = (3) Expired or (5) Canceled or (6) Voided |
LCA |
Layaway Item Cancel (all sale return line items in the transaction take this status) |
LayawayTransactionStatus.Status = (4) |
LCO |
Layaway Item Complete (all sale return line items in the transaction take this status) |
Table 2-4 Sale Item Type (SAIT)
Identifies what type of item is transmitted. | SAIT (Sale Item Type) | Static |
---|---|---|
Gift Cards or Gift Certificates |
GCN |
Voucher Number |
Stock Items |
ITEM |
Item |
Service Type items |
NMITEM |
Non-Merchandise Item |
Transaction level item |
REF |
Reference Item |
Table 2-5 UPCT
Identifies type of item number if item type is ITEM or REF | UPCT | Static |
---|---|---|
Item.ItemID |
ITEM |
Retek Item Number |
Table 2-6 OverrideReasonCodes (ORRC)
Reason an item price is overridden at the Point-of-Service. | ORRC (Price Override Reason Code) | Dynamic |
---|---|---|
(3) Defective |
D |
Damaged Goods |
(5) SignageError |
S |
Incorrect Signage |
Table 2-7 Sale Return Reason (SARR)
The reason an item is returned. | SARR (Sale Return Reason) | Dynamic |
---|---|---|
(33) Defective |
01 |
Damaged |
(33) Defective |
02 |
Defective |
(11) WrongColor |
06 |
Color Not As Shown |
(45) CustomerChangedMind |
19 |
CustomerChangedMind |
(55) PriceAdjustment |
20 |
PriceAdjustment |
Table 2-8 Merchandising System Promotion Type (PRMT)
The Merchandising System Promotion Type | PRMT (Merchandising System Promotion Type) | Static |
---|---|---|
Computed |
1004 |
In Store Discount |
Computed |
1005 |
Employee Discount |
Computed |
1006 |
Off Retail |
Computed |
2000 |
DTC Promotions |
Computed |
9999 |
Promotion |
Table 2-9 Sale Disc Type within a promotion (SADT)
The type of discount within a promotion. | SADT (Sale Disc Type within a promotion) | Dynamic |
---|---|---|
(2402,2006,2303,2105) Saturday Morning Special |
SATSPL |
Saturday Morning Special |
(2410,2014,2311,2113) Senior Citizen |
SENCIT |
Senior Citizen |
(2428,2022,2329,2121) Competition Special |
CMPSPL |
Competition Special |
(2436,2030,2337,2139) Store Coupon |
SCOUP |
Store Coupon |
(3) Defective |
D |
Damaged Goods |
(5) SignageError |
S |
Incorrect Signage |
(2) CompetitionPrice |
CP |
CompetitionPrice |
(1) AdPrice |
AP |
AdPrice |
(4) ManagersSpecial |
MS |
ManagersSpecial |
Table 2-10 TaxCode (TAXC)
Tax code to represent whether it is a state tax type, provincial tax, and so forth. | TAXC | Dynamic |
---|---|---|
TOTTAX (No Longer Used) |
TOTTAX |
Aggregate total of tax excluding VAT |
Table 2-11 TenderTypes (TENT)
High-level grouping of tender types. | TENT | Static |
---|---|---|
CASH Cash |
CASH |
Cash |
CRDT Credit Card |
CCARD |
Credit Card |
CHCK Check |
CHECK |
Personal Check |
ECHK E-Check |
CHECK |
Personal Check |
TRAV Travelers Check |
CHECK |
Personal Check |
MBCK Mail Bank Check |
CHECK |
Personal Check |
QPON Manufacturers Coupon |
COUPON |
Coupon |
DBIT Debit Card |
DCARD |
Debit Card |
MNYO Money Order |
MORDER |
Money Order |
GCRD Gift Card |
VOUCH |
Voucher (gift cert. or credit) |
GICT Gift Certificate |
VOUCH |
Voucher (gift cert. or credit) |
STCR Store Credit |
VOUCH |
Voucher (gift cert. or credit) |
MACT Mall Certificate |
VOUCH |
Voucher (gift cert. or credit) |
PRCH Purchase Order |
VOUCH |
Voucher (gift cert. or credit) |
VOUCH Voucher |
VOUCH |
Voucher (gift cert. or credit) |
Table 2-12 TenderType ID (POS_TENDER_TYPE_HEAD)
Tender Type ID. Low level grouping of tender types. | POS_TENDER_TYPE_HEAD | Notes |
---|---|---|
CASH Cash |
1000 CASH Cash - primary currency |
|
CHCK Check |
2000 CHECK Personal Check |
|
TRAV Travelers Check |
2020 CHECK Traveler Check |
|
QPON Manufacturers Coupon |
5000 COUPON Manufacturers Coupons |
|
DBIT Debit Card |
8000 DCARD Debit Card |
|
MNYO Money Order |
6000 MORDER Money Orders |
|
GICT Gift Certificate |
4030 VOUCH Gift Certificate |
|
GCRD Gift Card |
4040 VOUCH Gift Card |
|
STCR Store Credit |
4050 VOUCH Store Credit |
|
MACT Mall Certificate |
4060 VOUCH Mall Certificate |
|
PRCH Purchase Order |
4070 VOUCH Purchase Order |
|
VOUCH Voucher |
4080 VOUCH PrePaid |
No longer used. |
ECHK E-Check |
2030 CHECK E-Check |
|
MBCK Mail Bank Check |
2040 CHECK Mail Bank Check |
|
Visa |
3000 CCARD Visa |
|
MasterCard |
3010 CCARD Mastercard |
|
AmEx |
3020 CCARD American Express |
|
Discover |
3030 CCARD Discover |
|
DinersClub or Diners |
3040 CCARD Diners Club - N. America |
|
HouseCard |
3120 CCARD House Card |
|
JCB |
3090 CCARD JCB |
|
CASH Cash Alternate Currency |
1010 CASH Cash Alternate Currency |
|
CHCK Check Alternate Currency |
2050 CHECK Personal Check Alternate Currency |
|
TRAV Travelers Check Alternate Currency |
2060 CHECK Travelers Check Alternate Currency |
|
STCR Store Credit Alternate Currency |
4090 VOUCH Store Credit Alternate Currency |
|
GICT Gift Certificate |
4100 VOUCH Gift Certificate Alternate Currency |
Table 2-13 Credit Card Auth Source (CCAS)
Authorization Source | CCAS (Credit Card Auth Source) | Dynamic |
---|---|---|
Automatic, System |
E |
Electronic |
Manual |
M |
Manual |
Table 2-14 Credit Card Verification (CCVF)
Cardholder Verification | CCVF (Credit Card Verification) | Dynamic |
---|---|---|
CreditDebitCardTenderLineItem.CustomerSignatureImage is NULL |
C |
Card Shown |
CreditDebitCardTenderLineItem.TenderTypeCode = DBIT |
P |
PIN Entered |
CreditDebitCardTenderLineItem.CustomerSignatureImage is NOT NULL |
S |
Signature Verified |
Table 2-15 Credit Card Entered Manually (CCEM)
Credit card input type | CCEM (Credit Card Entered Manually) | Dynamic |
---|---|---|
Manual |
T |
Terminal Used |
MagSwipe |
MSR |
Magnetic Strip Read |
Table 2-16 Credit Card Special Condition (CCSC)
Credit card special condition | CCSC (Credit Card Special Condition) | Dynamic |
---|---|---|
If CCAS = E |
E |
Electronic-secured |
If CCAS = M |
P |
Phone |
Table 2-17 Card Weight (CW)
Unit of Measure | CW (Card Weight) | Notes |
---|---|---|
'LF' 'linear feet ' |
'LF' 'linear feet' |
|
'LM' 'linear meters ' |
'LM' 'linear meters' |
|
'PN' 'pounds net ' |
'LBS' 'POUNDS' |
|
'KG' 'kilograms ' |
'KG' 'KILOGRAM' |
|
'UN' 'units ' |
'EA' 'EACH' |
Table 2-18 Total ID for TOTAL type transactions -- Char(10) in Oracle Retail Sales Audit
Total ID (Reference Number 1) for TOTAL type transactions. | Char(10) in Oracle Retail Sales Audit | Notes |
---|---|---|
1000 CASH Cash - primary currency |
CASH |
|
2000 CHECK Personal Check |
CHCK |
|
2020 CHECK Traveler Check |
TRAVCHK |
|
5000 COUPON Manufacturers Coupons |
QPON |
|
UNKNW DCARD Unknown (unbranded Debit Card) |
DEBITCARD Unbranded |
DEBITCARD now will have branded/unbranded designations in Oracle Retail Sales Audit |
3000 DCARD Visa |
DEBITCARD Visa |
|
3010 DCARD Mastercard |
DEBITCARD MCard |
|
3020 DCARD American Express |
DEBITCARD AmEx |
|
3030 DCARD Discover |
DEBITCARD Disc |
|
3040 DCARD Diners Club - N. America |
DEBITCARD Diner |
|
3130 DCARD JCB |
DEBITCARD JCB |
|
2030 CHECK E-Check |
ECHECK |
|
2040 CHECK Mail Bank Check |
MBCHECK |
|
3000 CCARD Visa |
CCARDVisa |
|
3010 CCARD Mastercard |
CCARDMCard |
|
3020 CCARD American Express |
CCARDAmEx |
|
3030 CCARD Discover |
CCARDDisc |
|
3040 CCARD Diners Club - N. America |
CCARDDiner |
|
3120 CCARD House Card |
CCARDHCard |
|
3130 CCARD JCB |
CCARDJCB |
|
1010 CASH Cash Alternate Currency |
CASHAC |
|
2050 CHECK Personal Check Alternate Currency |
PCHECKAC |
|
2060 CHECK Alternate Currency |
TCHECKAC |
|
4090 VOUCH Store Credit Alternate Currency |
STCRDTAC |
|
4100 VOUCH Gift Certificate Alternate Currency |
GIFTCERTAC |