A Appendix: Xstore to Sales Audit Mapping Details

The mapping from the Xstore POSLog format to the Sales Audit RTLog format is defined in the Xstore configuration file RTLogMappingConfig.xml. This appendix provides details on the following ode types used by each of the applications that are used in this mapping:

Transaction Types
Tender Types
Tender Totals
Item Types
Sales Audit Reason Codes
Item Status/and Sales Types
Customer ID Types
Sales Audit Tax Codes
Reference Codes/Labels
Sale Return Transaction

Transaction Types

Both Xstore and Sales Audit support a number of similar transactions types, but each solution uses different codes for these transaction types. The table below shows how the transaction types in Xstore map to the transaction types and sub-transaction types used in Sales Audit. See also the Oracle Retail Sales Audit Implementation Guide for more details on these codes.

Table A-1 Transaction Type Mapping

Xstore Transaction Type	Sales Audit Transaction Type TRAT	Sales Audit Sub-Transaction Type TRAS	Description
ACCOUNT_LOOKUP	OTHER	OTHER	ACCOUNT_LOOKUP transactions are passed from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit.
BALANCE_INQUIRY	OTHER	OTHER	BALANCE_INQUIRY transactions are passed from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit.
CREDIT_APPLICATION	OTHER	OTHER	CREDIT_APPLICATION transactions are passed from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit.
ESCROW	OTHER	OTHER	ESCROW transactions are passed from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit.
EXCHANGE_RATE	OTHER	OTHER	EXCHANGE_RATE transactions are passed from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit.
GNRIC	OTHER	OTHER	GNRIC transactions are passed from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit.
INVENTORY_CONTROL	OTHER	OTHER	INVENTORY_CONTROL transactions are mapped from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit. Xstore should be configured so that inventory control transactions are not generated, and therefore not sent to Sales Audit.
INVENTORY_SUMMARY_COUNT	OTHER	OTHER	INVENTORY_SUMMARY_COUNT transactions are mapped from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit. Xstore should be configured so that inventory summary count transactions are not generated, and therefore not sent to Sales Audit.
MOVEMENT_PENDING	OTHER	OTHER	MOVEMENT_PENDING transactions are mapped from Xstore to Sales Audit for full visibility audit, but not otherwise implemented in Sales Audit. Xstore should be configured so that inventory summary count transactions are not generated, and therefore not sent to Sales Audit.
NO_SALE	NOSALE	NOSALE	NA
POST_VOID	PVOID	VOID	NA
RETAIL_SALE (can be mapped to multiple Sales Audit transaction types depending on other conditions)	SALE	SALE	Regular transaction.
	NOSALE	SUSPND	Suspend transaction.
	VOID	CANCEL	Cancel transaction.
	VOID	CANCEL	Cancel orphaned transaction.
SESSION_CONTROL	OTHER	OTHER	Issue till.
	OTHER	OTHER	Assign till/assign till tender transfer.
	OTHER	OTHER	Attach till.
	OTHER	OTHER	Remove till.
	OTHER	OTHER	Return till.
SYSTEM_CLOSE	CLOSE	CSTORE	Close store.
SYSTEM_OPEN	OPEN	OSTORE	Open store.
TENDER_CONTROL (can be mapped to multiple Sales Audit transaction types depending on other conditions)	OPEN	OTILL	Begin till count.
	CLOSE with TOTAL /OTHER	CTILL with CTILLT /OTHER	Till closing count (register accountability/till accountability).
	CLOSE and TOTAL	CTILL and CTILLT	Till reconcile. Each counted tender type has a corresponding TOTAL and CTILLT as a THEAD.
	PAIDIN	PITILL	Pay in.
	PAIDOU	POTILL	Pay out.
	OTHER	AUDIT	Till audit.
	PULL	PUTILL	Mid-day deposit. Place funds in store bank.
	OTHER	BANK	Bank deposit.
	LOAN	LOTILL	Till loan (cash transfer).
	PULL	PUTILL	Pick up till (cash pickup).
	OTHER	OTHER	Open store bank.
	OTHER	OTHER	Store bank reconcile.
TENDER_EXCHANGE	PAIDIN	PITILL	NA
TILL_CONTROL	OTHER	OTHER	NA
TIMECLOCK	OTHER	OTHER	Employee clock in.
TIMECLOCK	OTHER	OTHER	Employee clock out.
TRAINING_MODE_ENTRY	OTHER	NTRAIN	NA
TRAINING_MODE_EXIT	OTHER	XTRAIN	NA
WORKSTATION_CLOSE	CLOSE	CREG	NA
WORKSTATION_COMPLETE_REMOTE_CLOSE	CLOSE	CRGRC	NA
WORKSTATION_OPEN	OPEN	OREG	NA
WORKSTATION_START_REMOTE_CLOSE	OTHER	CRGRC	NA
GIFT_REGISTRY	OTHER	OTHER	Assign gift registry (register operation)
GIFT_REGISTRY	OTHER	OTHER	Reissue gift registry (register operation)
RAIN_CHECK	OTHER	OTHER	Redeem rain check.
BATCH_CLOSE	OTHER	OTHER	Credit and debit settlement.
REOPEN	REOPEN	NA	Used to reopen a previously closed store day in Sales Audit.

Tender Types

In order to communicate the tender type used on transactions, a specific mapping is used between Xstore and Sales Audit. The details below outline how the tenders in Xstore map to the Sales Audit tender groups and types. See also the Oracle Retail Sales Audit Implementation Guide for information on configuration of tender types and tender type groups.

Table A-2 Tender Type Mapping

Xstore		Xstore POS Log Tender Group Type		Sales Audit RTLog
Tender Type Code	Tender TypeI D	Tender Type	Tender ID	Tender Type Group	Tender Type ID
CURRENCY	USD_CURRENCY	Cash	USD_CURRENCY	CASH	If primary 1000, if alternate 1010.
	AUD_CURRENCY	Cash	AUD_CURRENCY	CASH	If primary 1000, if alternate 1010.
	CAD_CURRENCY	Cash	CAD_CURRENCY	CASH	If primary 1000, if alternate 1010.
	EUR_CURRENCY	Cash	EUR_CURRENCY	CASH	If primary 1000, if alternate 1010.
	GBP_CURRENCY	Cash	GBP_CURRENCY	CASH	If primary 1000, if alternate 1010.
CREDIT_CARD	VISA	CreditDebit	VISA	CCARD	3000
	MASTERCARD	CreditDebit	MASTERCARD	CCARD	3010
	AMERICAN_EXPRESS	CreditDebit	AMERICAN_EXPRESS	CCARD	3020
	DINERS_CLUB	CreditDebit	DINERS_CLUB	CCARD	3040
	DISCOVER	CreditDebit	DISCOVER	CCARD	3030
	JCB	CreditDebit	JCB	CCARD	3090
	DEBITCARD	CreditDebit	DEBITCARD	DCARD	8000
ACCOUNT	HOUSE_ACCOUNT	dtv:Account	HOUSE_ACCOUNT	CCARD	3120
ACCOUNT	A new type of credit card	CreditDebit	A new type of credit card	CCARD	Map to UNKNW.
CHECK	CHECK	Check	CHECK	CHECK	If primary 2000, if foreign 2050.
TRAVELERS_CHECK	USD_TRAVELERS_CHECK	dtv:TravelersCheck	USD_TRAVELERS_CHECK	CHECK	If primary 2020, if foreign 2060.
TRAVELERS_CHECK	CAD_TRAVELERS_CHECK	dtv:TravelersCheck	CAD_TRAVELERS_CHECK	CHECK	If primary 2020, if foreign 2060.
VOUCHER	GIFT_CERTIFICATE	Voucher	GIFT_CERTIFICATE	VOUCH	If primary 4030, if foreign 4100.
	ISSUE_GIFT_CERTIFICATE	Voucher	ISSUE_GIFT_CERTIFICATE	VOUCH	If primary 4030, if foreign 4100.
	ISSUE_MERCHANDISE_CREDIT_CARD	Voucher	ISSUE_MERCHANDISE_CREDIT_CARD	VOUCH	4050
	ISSUE_STORE_CREDIT	Voucher	ISSUE_STORE_CREDIT	VOUCH	4050
	ISSUE_XPAY_GIFT_CARD	Voucher	ISSUE_XPAY_GIFT_CARD	VOUCH	4040
	MALL_CERTIFICATE	Voucher	MALL_CERTIFICATE	VOUCH	4060
	MERCHANDISE_CREDIT_CARD	Voucher	MERCHANDISE_CREDIT_CARD	VOUCH	4050
	RELOAD_MERCHANDISE_CREDIT_CARD	Voucher	RELOAD_MERCHANDISE_CREDIT_CARD	VOUCH	4050
	RELOAD_XPAY_GIFT_CARD	Voucher	RELOAD_XPAY_GIFT_CARD	VOUCH	4040
	STORE_CREDIT	Voucher	STORE_CREDIT	VOUCH	If primary 4050, if foreign 4090.
	XPAY_GIFT_CARD	Voucher	XPAY_GIFT_CARD	VOUCH	4040
COUPON	COUPON	ManufacturerCoupon	COUPON	QPON	5000
COUPON	ROOM_CHARGE	CreditDebit	ROOM_CHARGE	VOUCH	4050
CREDIT_CARD	PAYPAL	TBD	PAYPAL	PAYPAL	3075
HOME_OFFICE_CHECK	HOME_OFFICE_CHECK	NA	NA	Not supported in this solution. Home office check tenders should not be used in Xstore if it is integrated with Sales Audit.

Tender Totals

Sales Audit uses tender totals to compare the total amount of a tender reported from the store (Accounted For) with the amount that it should have reported (Accountable For) based on store activity in a day. Totals are fully customer configured in Sales Audit. However, when integrating with Xstore, a few specific totals are expected to be created to total tenders. The totals that should be created and their ID are outlined in the table below, along with the Xstore tender type used for the total.

Table A-3 Total Tender ID Mapping

Xstore		Sales Audit RTLog
TenderType	TenderID	Total ID
CURRENCY	USD_CURRENCY	CASH
	AUD_CURRENCY	CASHAC
	CAD_CURRENCY	CASHAC
	EUR_CURRENCY	CASHAC
	GBP_CURRENCY	CASHAC
TRAVELERS_CHECK	USD_TRAVELERS_CHECK	TCHECK
	AUD_TRAVELERS_CHECK	TCHECKAC
	CAD_TRAVELERS_CHECK	TCHECKAC
	EUR_TRAVELERS_CHECK	TCHECKAC
	GBP_TRAVELERS_CHECK	TCHECKAC
	MXN_TRAVELERS_CHECK	TCHECKAC
CREDIT_CARD	CREDIT_CARD	CCARD
VOUCHER	GIFT_CERTIFICATE	GIFTCERT
	MALL_CERTIFICATE	MALLCERT
	MERCHANDISE_CREDIT_CARD	MCCARD
	RELOAD_MERCHANDISE_CREDIT_CARD	RMCCARD
	RELOAD_XPAY_GIFT_CARD	RXPAYGC
	STORE_CREDIT	STCRDT
	XPAY_GIFT_CARD	XPAYGC
	ISSUE_XPAY_GIFT_CARD	IXPAYGC
	ISSUE_STORE_CREDIT	ISTCRDT
	ISSUE_MERCHANDISE_CREDIT_CARD	IMCCARD
ACCOUNT	HOUSE_ACCOUNT	HACCNT
COUPON	COUPON	COUPON

Item Types

There are a number of different item types that are used in Xstore, and these all need to be mapped to item types used by Sales Audit. The table below outlines how the types in Xstore map to the Sales Audit item types.

Table A-4 Item Type Mapping

Xstore Item Type	Sales Audit Item Type	Description
Alteration	NMITEM	Non-Merchandise Item
Deposit	NMITEM	Non-Merchandise Item
dtv:GiftCertificate	GCN	Voucher
dtv:NonMerchandise	NMITEM	Non-Merchandise Item
dtv:Payment	NMITEM	Non-Merchandise Item
Fee	NMITEM	Non-Merchandise Item
ItemCollection	ITEM	Item
Service	NMITEM	Non-Merchandise Item
Stock	ITEM	Item
Warranty	NMITEM	Non-Merchandise Item

Sales Audit Reason Codes

Xstore has a single set of reason codes, used both for reason codes, price override codes, and other modifications. Sales Audit separates these concepts into individual sets. Because reason codes can be mixed coming out of Xstore, Sales Audit has mapped some code values to multiple code types to avoid the possibility of errors.

For more information on each of these categories of reason codes, see the Oracle Retail Sales Audit Implementation Guide.

Reason Codes

First is a general reason code that may be entered for specific transaction types to provide more information about the context of the transaction. This type of reason code is mapped to Xstore miscellaneous reason codes.

Table A-5 Sales Audit Reason Codes

Xstore Reason Code	Sales Audit Reason Code	Description
PV1	PV1	Cashier Error
PV2	PV2	Supervisors Discretion
PV3	PV3	Customer Satisfaction
NS1	NS1	Making Change
NS2	NS2	Employee Check Cashed
NS3	NS3	Petty Cash In
NS4	NS4	Petty Cash Out
NS5	NS5	Spiff/Bonus Out 1
CF1	CF1	Holiday Adjustment
CF2	CF2	Register Down
PAID_IN	PI1	Change from Paid Out
PAID_IN	PI2	Found Money
PAID_IN	PI3	Drawer Loan 1
PAID_IN	TENDEX	Tender exchange
PAID_OUT	PO1	Stocks
PAID_OUT	PO2	Delivery
PAID_OUT	PO3	Postage
PAID_OUT	PO4	Contractor Services
PAID_OUT	PO5	Store Incentives

Return Reason Codes

Sales Audit return reason codes are used to provide the context of the return in Sales Audit. These map to the Xstore reason codes as follows:

Table A-6 Return Reason Codes

Xstore Reason Code	Sales Audit Reason Code	Description
RET1	RET1	Did not like
RET2	RET2	Better price somewhere else
RET3	RET3	Did not fit
RET4	RET4	Damaged
RET5	RET5	Exchange
RET6	RET6	Poor quality
RET41	RET41	Open box
RET42	RET42	Unusable
RET43	RET43	Repairable

Discount Reason Codes

Used in Sales Audit to indicate the valid discount types for sales and return transaction, this table shows how these are mapped to the Xstore reason codes used for returns:

Table A-7 Discount Reason Codes

Xstore Reason Code	Sales Audit Reason Code	Description
DC1	S	Incorrect Label
DC2	MS	Manager Discretion
DC3	CP	Price Guarantee
DC4	D	Damage Adjustment
NEW_PRICE_RULE	NEWPRC	New Price Rule
DOCUMENT	DOC	Document
MANUFACTURER_COUPON	MCOUP	Manufacturer Coupon
REFUND_PRORATION	REFUND	Refund Proration
CALCULATED_WARRANTY_PRICE	CALWAR	Warranty Price

Item Price Override Reason Codes

This grouping of reason codes is used to hold the valid price override reason codes that are expected by Sales Audit. These map to the reason codes used in Xstore as follows:

Table A-8 Item Price Override Reason Codes

Xstore Reason Code	Sales Audit Reason Code	Description
AR_PR_1	AR_PR_1	Insufficient Funds
AR_PR_2	AR_PR_2	Wrong Amount
AR_PR_3	AR_PR_3	Wrong Amount
AR_PR_4	AR_PR_4	Wrong Invoice
COMMENT	NEWPRC	Other - Enter Comments
PC1	S	Incorrect Label
PC2	MS	Supervisors Discretion
PC3	CP	Competitive Price Match
PC4	D	Damage Adjustment
BASE_PRICE_RULE	BSPRC	Base Price Rule
PROMPT_PRICE_CHANGE	PROMPT	Price Prompt
AUTHORIZED_AMOUNT	AUTHMT	Authorized Amount

Item Status/and Sales Types

Valid values for item status in Sales Audit are:

V	Voided
S	Sale
R	Return
O	Other
ORI	Order Initiate
ORC	Order Cancel
ORD	Order Complete
LIN	Layaway Initiate
LCA	Layaway Cancel
LCO	Layaway Complete

Valid values for sales type in Sales Audit are:

R	Regular
I	In-Store Customer Order
E	External Customer Order

These two sets of codes are then mapped to the actions in Xstore as follows:

Table A-9 Item Status/ and Sales Type Mapping

Xstore Item	Xstore Action	Sales Audit Item Status	Sales Audit Sales Type
Regular Sale	Sale	S	R
	Return	R	R
	Void	S and V (two lines)	R
Layaway Item	Init	LIN	I
	Cancel	LCA	I
	Pickup	LCO	I
	Void	S and V (two lines)	I
Locate Order	Init	ORI	E
	Cancel	ORC	E
	Pickup	ORD	E
	Void when update or pickup	ORC	E
	Void when Init	S and V (two lines)	E
Special Order	Init	ORI	E
	Cancel	ORC	E
	Pickup	ORD	E
	Void when update or pickup	ORC	E
	Void when Init	S and V (two lines)	E
Work Order	Init	ORI	I
	Cancel	ORC	I
	Pickup	ORD	I
	Void when update or pickup	ORC	I
	Void when Init	S and V (two lines)	I
Pre-Sale	Init	ORI	I
	Cancel	ORC	E
	Pickup	ORD	E
	Void when update or pickup	ORC	E
	Void when Init	S and V (two lines)	E
On Hold	Init	ORI	I
	Cancel	ORC	I
	Pickup	ORD	I
	Void when update or pickup	ORC	I
	Void when Init	S and V (two lines)	I
Send Sale	Init	S	R
Send Sale	Void when Init	S and V (two lines)	R

Customer ID Types

Sales Audit has a set of codes that it uses for validating the various forms of identification that can be presented at the store for a transaction. However, Xstore always sends just one type - Customer ID or CUSTID. This customer ID type is part of the default Sales Audit implementation and should be configured to "Used" when implementing with Xstore.

Sales Audit Tax Codes

When implementing using US Sales Tax for some or all stores, the tax code sent by Xstore will always be sent as TOTTAX. This will be validated against the list of valid non-VAT tax codes in Sales Audit. This code is included in the initial Sales Audit configuration, but care should be taken not to remove or configure that code type off when integrating with Xstore.

Reference Codes/Labels

Sales Audit has a flexible method of taking in reference fields from a POS at various levels of the transaction. These can be configured differently by transaction and sub-transaction type within Sales Audit. In general, these are not used in the base Xstore implementation without customization with a couple of exceptions. The reference fields that Xstore uses are as follows:

Reference Number 1 (Transaction Header) - for the Day Close (DCLOSE) transaction type, this field will contain the file counter for the end of day
Reference Number 1 (Transaction Header) - for the Tender Total (TOTAL) transaction type, contains the tender ID/type
Reference Number 3 (Transaction Header) - incudes the employee ID if the sale was to an employee

For more on configuring reference fields in Sales Audit, see the Oracle Retail Sales Audit Implementation Guide.

Sale Return Transaction

This section describes sale return transaction mappings.

Transaction Header Mapping

This section describes mappings for the transaction header of sale return transactions. The transaction header format is defined at TransactionHeader RECODE_FORMAT in the RTLogFormatConfig.xml file.

A sale return transaction can be mixed with a sale line item, return line item, special order pickup line item, special order payment, work order line item, and so on. In this case, the sale and return transaction type and sub transaction type are defined as SALE. The actual types of line lines are specified at line item level.

The field Salesperson in Transaction Header is matched to -1. It means there is no Salesperson available at transaction level. Instead the field Salesperson in line item is populated, since it is possible to have different sales people for different line items in the same transaction.

OriginalTransactionNumber and Orig_reg_no are only populated for post void transactions. Mapper PostVoidOriginalTransactionInfoMapper indicates the mapping logic.

Line Item (TITEM) Mapping

This section describes mappings for line items of sale return transactions. The line item format is defined at TransactionItem RECODE_FORMAT in the RTLogFormatConfig.xml file.

The line item will not be exported for suspended, cancelled and post void transactions. It is disabled in retailTrnDetailrExportabilityMapper.

It would be one or more line item records in a sale return transaction.

There are two kinds of item types, physical/merchandise item (ITEM) or non physical/non merchandise item (NMITEM). Non physical items are service fee, payment, work order item, and so on.

The Item id of a physical item is set to Item field; the Item id for a non physical item is set to NonMerchandiceItem field of the RTLog record.

The default value of the ItemStatus field is S, which is set in the RTLogFormatConfig.xml file. If the line item is return, the value is set to R. Return reason code mapping can be found in /retailTransaction/lineItems/return source field VALUE_MAPPINGS.

The default value of SalesType for sale return line item is I (internal sale).

ItemVoidStatusMapper sets the void flag of the record to true if the line is voided. If a sale return line item record is voided, a clone of the sale return line item record will be created, the item status for the new record is set to "V". In this case the status of the two lines are "S" and "V" or "R" and "V". Sales Audit balances off a sale/return line with its voided line to zero.

Item Discount (IDISC) Mapping and Round off Discount Mapping

This section describes mappings for item level discounts of sale return transactions. The item level discount format is defined at ItemDiscount RECODE_FORMAT in the RTLogFormatConfig.xml file.

The item level discount will not be exported for suspended, cancelled and post void transactions. It is disabled in retailTrnDetailExportabilityMapper.

It would be zero or more item discount records for a line item.

If it is a Deal discount, the RMSPromotionType is mapped to 9999, otherwise it is mapped to 1004.

The discount type of ItemDiscount is mapped from reasonCode and discountReasonCode.of RetailPriceModifierType Poslog object.

The values of DiscountReferenceNumber, PromoComponent and RMSPromotionType are mapped from PromotionIDMapper. If the retail price modifier is voided, DiscountReferenceNumber and PromoComponent are set to zero. If the retail price modifier is not voided and it is a deal promotion, it is mapped based on the following conditions:

If it is an RPM promotion, DiscountReferenceNumber is set to RPM promotion id and PromoComponent is set to promotion component id.
If it is not an RPM promotion, RMSPromotionType is set to 2000, DiscountReferenceNumber and PromoComponent are set to zero.

PromotionIDMapper implements this logic.

DiscountAmountMapper calculates unit discount amount for the ItemDicount RTLog IDISC record and also sets roundedOffAmount to the RTLog record. The value of unit discount amount is the total discount amount divided by item quantity rounding by half up with unit discount scale. The value of roundedOffAmount is the difference between total discount amount and unit discount amount multiplies item quantity. Note that the roundedOffAmount is not a field of IDISC, therefore it is not going to be exported.

A round off discount record (ItemRoundedOffDiscount) is always created after a discount record (ItemDiscount) if the roundedOffAmount is not equal to zero. In a discount record, if the roundedOffAmount exists, a round off discount record will be cloned from the discount record, otherwise a new round off discount record will be created. The value of discount amount of a round off discount record is the round off amount of the corresponding discount record. The value of the quantity in a round off discount record is always set to zero. RoundedOffDiscountAmountMapper is specially used for this mapping.

The format of ItemRoundedOffDiscount record and ItemDiscount record are exactly the same, that is IDISC. The reason for adding a round off discount record is that Poslog uses discountAmount and RTLog uses UnitDiscountAmount. If a quantity of a line item is not one, such as 3, the UnitDiscountAmount times 3 is not equal to discountAmount in Poslog. To balance it off, an extra discount line is introduced to set the round off amount to unit discount amount. It guaranties the total discount value is equal to sum of the two IDISC records.

Item Level Tax Mapping

This section describes mappings for item level tax of sale return transactions. The item level tax format is defined at ItemGlobalTax RECODE_FORMAT in the RTLogFormatConfig.xml file.

Tax lines will not be exported for suspended, cancelled and post void transactions. It is disabled in retailTrnDetailExportabilityMapper.

It would be one or more tax lines for one sale return line item. It depends on how many tax authorities are applied on this item.

RTLog requires four digits decimal for TaxRate in ItemGlobalTax record format. AmountMapper object sets the scale of tax rate to four to fit the need.

RTLog requires four digits decimal for TaxAmount in ItemGlobalTax record format. AmountMapper object sets the scale of tax amount to four to fit the need.

The value of TaxAmountSign field is P when tax amount is positive, N when tax amount is negative. It is done is SignMapper.

The RTLog Generator application supports either VAT or non VAT. It does not support both of them in the application instance. VAT and non VAT configurable settings can be found at the roundedOffTaxAmountMapper spring bean in the RTLogMappingBean.xml file.

TaxCode mappings are different for VAT and non VAT systems. If the RTLog Generator application is set to VAT, the tax group id maps to the tax code. If the RTLog Generator application is set to non VAT, the tax code is always "TOTTAX". ItemTaxCodeMapper implements this logic.

The value of TotalTaxAmount is blank if the tax is voided. Otherwise, the value of TotalTaxAmount is the sum of the item taxes from all item tax authorities. It is implemented at ItemTotalTaxAmountMapper.

The value of TaxableIndicator of ItemGlobalTax is a flag to indicate the item has tax or not. If the TaxAmountSign amount sign is zero, the value of TaxableIndicator is set to N, otherwise it is set to Y.

Tender Line Mapping

This section describes mappings for transaction tender of sale return transactions. The transaction tender format is defined at TransactionTender RECODE_FORMAT in the RTLogFormatConfig.xml file.

The tender line will not be exported for suspended, cancelled and post void transactions. It is disabled in retailTrnTenderExportabilityMapper.

The actual mappings of transaction tender type group and tender type id (sub type) are listed on sourcePath "/transaction/lineItems/tender" in the RTLogMappingConfig.xml file.

There may be zero or more tender line items within one sale return transaction.

The tender type id is different for base currency and foreign currency and is also different for base traveler's check and foreign traveler's check. Object tenderTypeIDMapper is responsible for doing the actual currency and traveler's check mapping. If the tender type is currency or traveler's check, mapping value will be found from the mapper, the corresponding VALUE_MAPPINGS will be skipped. Otherwise, it will do the value mapping in the VALUE_MAPPINGS.

RTLog requires four digits decimal for TenderAmount in TransactionTender record format. Mapper amountMapper sets the scale of tender amount to four to fit the need.

The value of TenderSign field will be P when tender amount is positive, N when tender amount is negative. It is done in SignMapper.

There is a special tender line which is used for transaction rounded off amount. For detail information, refer to the next section.

Rounded Off Amount

Transaction rounded amount is used to balance off a transaction. The amount comes from the following areas.

Rounded amount from roundedTotal@RetailTransactionType Poslog object.
Total tax amount from the sum of amount@TaxType of each tax LineItem of RetailTransactionType Poslog object.
Total sale return line item tax amount from the sum of amount@TaxType of SaleType of LineItem of RetailTransactionType Poslog object.

Transaction rounded off amount = value of 1 + (value of 2 - value of 3).

RTLog exports line item taxes rather than exports transaction level taxes. The reason is that the payment amount in an order transaction includes a certain percentage of item price and tax amount. When doing a pickup, the transaction level tax is not zero, and the payment already includes the part of the tax. The total tax will be more than the value is supposed to be. The transaction will not balance off.

A special RECORD_FORMAT TransactionTenderRoundedOff is created for this purchase. The syntax of the format is exactly the same as the one for TransactionTender. The TenderTypeGroup is always set to CASH and TenderTypeID is always 1020. TenderAmount of TransactionTenderRoundedOff is the transaction rounded of amount, TenderSign is the transaction rounded of amount sign. RoundedOffAmountMapper accumulates the rounded amounts based on the algorithm above and sets the value and sign to TenderAmount and TenderSign fields.

This special tender line will not be exported for suspended, cancelled and post void transactions. It is disabled in retailTrnDetailExportabilityMapper. It will not be exported when the total rounded amount is zero.