2 Integration Architecture

This chapter provides information about the integration architecture between Oracle Retail POS Suite and merchandising products.

Oracle Retail POS Suite to Oracle Retail Sales Audit Integration Architecture

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.

RTLog Batch Generator

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.

Sleep Interval

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

Maximum Transactions

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

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

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.

Error Handling

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.

Import Status Logging

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.

The Logic

MA_STS_BNDL_IMP

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.

MA_STS_FL_IMP

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.

MA_FL_IMP_FLRS

Any failures encountered are logged in this table.

Reprocessing a Bundle

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.

Exception Flow

• 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.

Figure 2-1 Data Import Tables Logical Data Model

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"/>

Logging

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.

Bundles Using Multiple Threads

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.

RTLog Mapping and Translation

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

Table 2-19 Check Tender Method ID -- Char(6) in Oracle Retail Sales Audit

Check Tender Method ID	Char(6) in Oracle Retail Sales Audit	Notes
10 - Driver's License	DRVRLC
20 - Passport	PASSPT
30 - Military ID	MILTID
40 - State/Region ID	STRGID
50 - Student ID	STUDID
60 - Resident Alien ID	RSALID