Oracle® Retail Xstore Suite 20.0/Oracle® Retail Merchandising Suite 19.2.000 Implementation Guide Release 20.0 F37856-03 |
|
![]() Previous |
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:
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. |
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) |
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. |
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 |
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. |
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 |
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. |
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 |
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 |
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.
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 |
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:
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 |
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 |
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 |
Void when Init |
S and V (two lines) |
R |
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.
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.
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.
This section describes sale return transaction mappings.
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.
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.
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.
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.
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.
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.