StoreSettlement Worker - Configuration Parameters Documentation

For End Users and System Administrators

Overview

This document describes all configuration parameters for the StoreSettlement worker in POS Services. The StoreSettlement worker generates daily settlement files containing financial and operational data from the point-of-sale system. These files are used for accounting, reconciliation, and reporting purposes.

Settlement files contain various transaction codes (like IKU, IVA, B01, etc.) that represent different types of financial data. Each parameter below controls whether specific codes appear in the settlement file and how they are calculated.

Core Settlement Parameters

SettlementType

Purpose: Determines the level of detail in settlement reporting - whether settlements are generated per store, per operator (cashier), or per workstation (cash register).

Valid Values: Comma-separated list containing one or more of:

• Operator - Generates settlements grouped by cashier/operator
• Store - Generates settlements grouped by store (consolidated)
• Workstation - Generates settlements grouped by cash register/terminal
• ItemGroup - Generates settlements grouped by item group (rarely used)

Default: Operator, Store, Workstation

Example: value="Operator, Store, Workstation"

How It Works:

• When Store is selected, you get one settlement file per store per day with all transactions combined
• When Operator is selected, you get separate settlement data for each cashier who worked that day
• When Workstation is selected, you get separate settlement data for each cash register
• You can enable multiple types simultaneously to get different views of the same data

Impacted Code(s): All settlement codes - this parameter determines the grouping level for all generated codes

StoreSettlementOutputDirectory

Purpose: Specifies the folder location where settlement files will be saved after generation.

Valid Values: Any valid Windows file system path (must be accessible by the service account)

Default: c:\temp\

Example: value="c:\LPOS\Settlements\" or value="\\server\share\settlements\"

Important Notes:

• Ensure the directory exists before settlement runs
• Monitor disk space in this location
• Set up appropriate folder permissions
• Consider using a dedicated folder for settlements separate from other POS data

Impacted Code(s): All settlement codes - determines where all settlement files are saved

StoreSettlementPeriodType

Purpose: Controls how the settlement period is defined - whether it's a single business day, a date range, or a hybrid approach.

Valid Values:

• Date - Settlement for a single business day
• DateRange - Settlement spanning multiple days
• Hybrid - Combination approach (consult with support before using)

Default: Date

When to Use Each:

• Use Date for standard daily settlements (most common)
• Use DateRange when you need to generate settlements for multiple days at once (e.g., weekly settlements, re-running historical periods)

Impacted Code(s): All settlement codes - determines the time period for all data queries

StoreSettlementTimeOffset

Purpose: Adjusts the settlement day boundary to align with business day instead of calendar day. Useful when stores close after midnight.

Valid Values: TimeSpan format HH:MM (hours:minutes)

Default: 0:00 (no offset, settlement day = calendar day)

Example:

• value="0:00" - Settlement day runs from 00:00 to 23:59
• value="6:00" - Settlement day runs from 06:00 to 05:59 next day
• value="-3:00" - Settlement day runs from 21:00 previous day to 20:59

How It Works:
When you set an offset of 6:00, a settlement for "April 24" will include transactions from April 24 06:00 to April 25 05:59. This ensures late-night transactions (after midnight) are included in the correct business day.

Impacted Code(s): All settlement codes - shifts the time boundary for all transaction queries

Feature Enable/Disable Parameters

StoreSettlementEnableNonsale

Purpose: Controls whether non-sale items (items sold without affecting inventory) are included in settlement reports.

Valid Values: true, false

Default: false

How It Works: Non-sale items are special products that don't represent physical inventory but generate revenue (e.g., service fees, warranties, delivery charges, gift wrapping).

When to Enable:

• Your store sells service products or fees
• Need to track non-inventory revenue separately
• Accounting requires non-sale items in daily reports

Impacted Code(s): INO, N00-N99, O00-O99, P00-P99

StoreSettlementEnableCurrencyBalance

Purpose: Enables tracking and reporting of cash balances in multiple currencies for stores that accept foreign currency.

Valid Values: true, false

Default: false

How It Works: When enabled, the settlement file includes separate balance sections for each currency (NOK, SEK, EUR, USD, etc.). Each tender transaction is reported with both the original currency amount and the converted amount in the store's base currency.

When to Enable:

• Store is located near international border
• Store accepts multiple currencies as payment
• Accounting needs separate currency tracking for exchange rate management

Impacted Code(s): NO1-NO2, SE1-SE2, DA1-DA2, EU1-EU2, US1-US2, GB1-GB2, Z01-Z99

StoreSettlementEnableInboundOutboundChange

Purpose: Tracks cash movements into and out of the cash drawer during the business day (separate from sales).

Valid Values: true, false

Default: false

How It Works: Records two types of cash movements:

• Inbound Change (IVI): Cash added to drawer (e.g., bringing coins from back office, manager adding change float)
• Outbound Change (IVU): Cash removed from drawer (e.g., depositing excess cash to safe, removing large bills)

When to Enable:

• Stores perform mid-day cash drawer balancing
• Need to track cash drops separately from sales
• Accounting requires detailed cash movement audit trail

Impacted Code(s): IVI (Inbound), IVU (Outbound)

StoreSettlementEnablePaymentCardInCurrency

Purpose: Reports payment card transactions with the original currency in which the card was charged (relevant for international card payments).

Valid Values: true, false

Default: false

How It Works: When a foreign customer pays with a card, this setting ensures the settlement shows both the local currency amount and the currency in which the card issuer was charged.

When to Enable:

• High volume of international customers
• Need currency-specific reconciliation for payment card transactions
• Payment processor requires currency breakdown

Impacted Code(s): K01-K99 with currency codes (KNONOK, KSEUSEK, etc.)

StoreSettlementEnableCashInCurrency

Purpose: Reports cash transactions separated by currency type received.

Valid Values: true, false

Default: false

How It Works: Creates separate settlement lines for cash received in NOK, SEK, EUR, etc. This is different from EnableCurrencyBalance which tracks drawer balance - this tracks cash revenue by currency.

When to Enable:

• Border stores accepting multiple cash currencies
• Need to track which currencies customers are paying with
• Currency exchange operations within the store

Impacted Code(s): CNO, CSE, CEU, CUS, CGB, CDK, COT

StoreSettlementEnableDeliveredBalanceInCurrency

Purpose: Reports the opening cash float by currency type.

Valid Values: true, false

Default: false

How It Works: When cashiers start their shift with an opening float (starting cash), this tracks how much of each currency was in that float.

When to Enable:

• Using EnableCurrencyBalance
• Starting float contains multiple currencies
• Need detailed reconciliation of opening balances

Dependency: This parameter requires StoreSettlementEnableCurrencyBalance=true to function.

Impacted Code(s): LNO, LSE, LEU, LUS, LGB, LDK, LOT

StoreSettlementEnableInboundOutboundChangeInCurrency

Purpose: Reports inbound/outbound cash movements separated by currency.

Valid Values: true, false

Default: false

How It Works: Extends EnableInboundOutboundChange to show which currency was added or removed. For example, if manager adds €50 in coins mid-day, this appears as EUR inbound change.

When to Enable:

• Using EnableInboundOutboundChange
• Cash drops/additions happen in multiple currencies
• Need currency-specific cash movement tracking

Dependency: This parameter requires StoreSettlementEnableInboundOutboundChange=true to function.

Impacted Code(s): IVI, IVU with currency codes

StoreSettlementEnableFallbacks

Purpose: Enables fallback values when primary data sources are missing or incomplete.

Valid Values: true, false

Default: false

How It Works: If certain data isn't available (e.g., reason codes missing, item groups undefined), the system uses predefined fallback values instead of failing or skipping the transaction.

When to Enable:

• Data quality issues in source system
• Migration period with incomplete data
• Want settlement to always succeed even with missing data

Impacted Code(s): IRC, IRS and various codes when fallback logic applies

StoreSettlementEnableGrandTotal

Purpose: Adds a grand total line at the end of settlement file summarizing all transactions.

Valid Values: true, false

Default: false

How It Works: Calculates and outputs a summary line (ING) showing total revenue across all transaction types, providing a single reconciliation point.

When to Enable:

• Accounting system requires grand total for validation
• Quick check of total revenue without analyzing individual lines
• External system imports settlement and needs total amount field

Impacted Code(s): ING

StoreSettlementEnableLottery

Purpose: Enables lottery transaction processing and reporting in settlement files.

Valid Values: true, false

Default: false

How It Works: When enabled, lottery ticket sales, prize payouts, and related transactions are included in the settlement with appropriate categorization. Lottery sales are tracked separately from regular merchandise due to different commission structures and accounting treatment.

When to Enable:

• Store sells lottery tickets (e.g., national lottery, scratch cards)
• Need to track lottery revenue separate from merchandise
• Accounting requires lottery commission calculations
• External lottery system requires reconciliation data

Important Notes:

• Lottery sales typically don't count toward store revenue (commission only)
• Prize payouts reduce cash but aren't store expenses
• May require coordination with StoreSettlementPrizePayoutItemGroups

Impacted Code(s): IL1-IL9 (Lottery sales), IP1-IP9 (Prize payouts)

StoreSettlementEnableKickBack

Purpose: Enables kickback/commission calculation and reporting in settlement files.

Valid Values: true, false

Default: false

How It Works: Kickbacks are financial returns or commissions that the retailer receives from suppliers based on sales volume, promotion participation, or contractual agreements. When enabled, the settlement calculates and reports these amounts based on configured rules.

When to Enable:

• Store has supplier rebate agreements tied to sales volume
• Participation in vendor promotional programs with commission payments
• Accounting requires accrual of expected supplier rebates
• Need to track promotional incentives separately

Common Kickback Scenarios:

• Volume-based: 2% rebate on sales exceeding monthly threshold
• Promotional: Additional commission during campaign periods
• Category-based: Different rebate rates for different product types
• Placement fees: Compensation for shelf space or end-cap displays

Important Notes:

• Affects gross margin calculations in financial reports
• May require separate reconciliation with supplier invoices
• Tax implications vary by jurisdiction - consult accounting

Impacted Code(s): IKB, KB1-KB9

StoreSettlementHasItemTransactionReasonCodes

Purpose: Indicates whether non-sale item transactions (breakage, internal use, etc.) require and use reason codes.

Valid Values: true, false

Default: false

How It Works: When enabled, the settlement process expects reason codes on item transactions like breakage or internal use, and includes those reason codes in reporting. This provides audit trail for why items were removed from inventory.

When to Enable:

• Store policy requires documented reasons for inventory adjustments
• Need detailed shrinkage analysis by reason
• Audit requirements for non-sale inventory movements

Impacted Code(s): IV1-IV9 with reason code breakdown

StoreSettlementHasDiscountReasonCodes

Purpose: Indicates whether discount transactions require reason codes for audit and reporting purposes.

Valid Values: true, false

Default: false

How It Works: When enabled, the settlement process expects reason codes for discount transactions and includes them in validation and reporting. This is particularly important for manual discounts where managers must document why a discount was given.

When to Enable:

• Store policy requires managers to document all manual discounts
• Need detailed discount analysis by reason (price match, damaged goods, customer complaint)
• Audit compliance requires discount justification trail
• Loss prevention tracking for unauthorized discounts

Common Discount Reasons:

• Price match with competitor
• Damaged or defective merchandise
• Customer service recovery
• Manager approval special pricing
• Employee discount

Important Notes:

• If enabled, transactions lacking reason codes may be rejected or flagged
• Reason code master data must be maintained in system
• Different discount types (line, group, customer) may use different reason codes

Impacted Code(s): IRM, IRK, IRP, IRG, IGR with reason code details

VAT and Tax Configuration Parameters

StoreSettlementVatCodes

Purpose: Defines which VAT rates are used in settlement reporting and maps them to settlement file codes.

Valid Values: Semicolon-separated list in format CODE=RATE

Default: IM1=25;IM2=0;IM3=14;IM4=99

Example: value="IM1=25.00;IM2=15.00;IM3=12.00;IM4=0.00"

How It Works:

• Each VAT rate in the system is assigned to a settlement code (IM1-IM9)
• The settlement file shows revenue broken down by these VAT rates
• Must match legal VAT rates in your jurisdiction

Country-Specific Examples:

• Norway: IM1=25;IM2=15;IM3=0 (standard, reduced, zero)
• Sweden: IM1=25;IM2=12;IM3=6;IM4=0
• Denmark: IM1=25;IM2=0

Impacted Code(s): IM1-IM9

StoreSettlementDelayedPaymentVatRates

Purpose: Specifies VAT rates for delayed payment transactions (credit sales, invoiced sales).

Valid Values: Semicolon-separated list in format CODE=RATE

Default: Empty

Example: value="IZ1=25.0;IZ2=15.0;IZ3=0.0"

How It Works: Credit sales or invoiced transactions often need separate VAT tracking since payment happens later. These are sales where customer takes goods now but pays later (account customers, invoice sales).

When to Configure:

• Store offers credit accounts to business customers
• Invoice sales are common
• Accounting needs separate tracking of receivables VAT

Impacted Code(s): IZ1-IZ5

StoreSettlementDepositRefundVatRates

Purpose: Specifies VAT rates for bottle/can deposit refund transactions.

Valid Values: Semicolon-separated list in format CODE=RATE

Default: Empty

Example: value="IA1=25.0;IA2=0.0"

How It Works: Deposit refunds (bottle/can returns) have special VAT treatment. Original deposit usually includes VAT, refund should match. This configuration ensures correct VAT accounting for deposit returns.

Important Notes:

• Deposit IN (sale) and deposit OUT (refund) often have same VAT treatment
• Common in Nordic countries with pant (bottle deposit) systems
• Must coordinate with regulatory requirements for container deposits

Impacted Code(s): IA1-IA5 (IN), IB1-IB5 (OUT)

StoreSettlementPrizePayoutVatRates

Purpose: Specifies VAT rates for lottery prize payouts.

Valid Values: Semicolon-separated list in format CODE=RATE

Default: Empty

Example: value="IP1=0.0" (prize payouts typically have 0% VAT)

How It Works: When store pays out lottery prizes, these need separate VAT tracking. Prize payouts are typically VAT-exempt as they represent return of customers' money, not store revenue.

When to Configure:

• Using StoreSettlementEnableLottery=true
• Store validates and pays lottery prizes
• Need to track prize payout cash separately

Impacted Code(s): IP1-IP5

StoreSettlementGroceriesOnlineVatRates

Purpose: Specifies VAT rates specific to online grocery order transactions.

Valid Values: Semicolon-separated list in format CODE=RATE

Default: Empty

Example: value="IC1=25.00;IC2=15.00;IC3=0.00"

How It Works: Online grocery orders picked up in-store need separate tracking from regular POS sales. This allows analyzing online channel performance and ensures correct accounting treatment.

When to Configure:

• Store offers click-and-collect grocery service
• Online orders are processed through POS for payment/pickup
• Need separate reporting for online vs. in-store sales

Related Configuration: Use with StoreSettlementGroceriesOnlinePriceChannel

Impacted Code(s): IC1-IC5

StoreSettlementWebShopVatRates

Purpose: Specifies VAT rates for web shop transactions processed through the POS system.

Valid Values: Semicolon-separated list in format CODE=RATE

Default: Empty

Example: value="IW1=25.0;IW2=15.0;IW3=0.0"

How It Works: Similar to groceries online, but for non-food web shop orders. Separates e-commerce transactions from physical store sales in settlement reporting.

When to Configure:

• Store handles web shop order pickups or payments
• E-commerce transactions flow through POS
• Need channel-specific revenue analysis

Impacted Code(s): IW1-IW5

StoreSettlementRebateOwnMemberVatRates

Purpose: Defines VAT rates that apply to rebate transactions for own member organization.

Valid Values: Comma-separated list of VAT rates

Default: Empty

Example: value="25,15,0"

How It Works: Specifies which VAT rates apply when members of the retail chain's own loyalty program receive rebates or member discounts. This ensures correct VAT accounting for member benefit programs.

When to Configure:

• Store operates a loyalty/membership program with rebates
• Members receive periodic rebate payments or credits
• Need separate tracking of member benefits for accounting
• VAT treatment differs for member rebates vs. regular discounts

Common Usage Scenarios:

• Co-op member dividend programs
• Loyalty program cashback rewards
• Member-exclusive pricing benefits
• Annual member rebate distributions

Important Notes:

• VAT rates must match those defined in StoreSettlementVatCodes
• Member rebates may have different VAT treatment than instant discounts
• Coordinate with StoreSettlementRebateForeignMemberVatRates for complete member tracking

Impacted Code(s): IR1-IR5 (Own member rebates)

StoreSettlementRebateForeignMemberVatRates

Purpose: Defines VAT rates that apply to rebate transactions for foreign member organizations.

Valid Values: Comma-separated list of VAT rates

Default: Empty

Example: value="25,15"

How It Works: Used when members from partner organizations (e.g., reciprocal member agreements with other retail chains) receive rebates. Separates foreign member benefits from own member benefits in settlement and accounting.

When to Configure:

• Retail chain has reciprocal agreements with partner chains
• Foreign co-op members can shop at your stores and receive benefits
• Need to track and reconcile inter-organization member benefits
• Accounting requires separation of own vs. foreign member costs

Common Usage Scenarios:

• Cross-border co-op member agreements (e.g., Norwegian co-op members shopping in Sweden)
• Franchise network member programs
• Retail alliance member benefits

Important Notes:

• May require settlement with partner organizations for benefit costs
• Tax treatment may differ for foreign member benefits
• Ensure member organization codes are properly maintained

Impacted Code(s): IF1-IF5 (Foreign member rebates)

Item Group and Product Code Configuration

StoreSettlementEnabledItemTransactionTypes

Purpose: Specifies which types of non-sale item transactions should be included in settlement reporting.

Valid Values: Comma-separated list of transaction types:

• Breakage - Damaged items written off
• InternalUse - Items used internally by store
• Inventory - Physical inventory adjustments
• StockAdjustment - Manual stock corrections
• Return - Returns to supplier
• Shrinkage - Loss/theft

Default: Empty (no item transactions included)

Example: value="Breakage,Inventory,Shrinkage"

How It Works: Only the transaction types listed will appear in settlement. Use this to focus on specific inventory movements that need daily reporting.

When to Configure:

• Daily tracking of breakage for quality control
• Inventory adjustments need daily reconciliation
• Loss prevention monitoring of shrinkage

Impacted Code(s): IV1-IV9

StoreSettlementBreakageReasonAndActionCodes

Purpose: Defines which reason/action code combinations identify breakage transactions.

Valid Values: Comma-separated list of code pairs in parentheses (reason,action)

Default: Empty

Example: value="(10,5),(11,5),(12,5)"

How It Works: POS system uses reason codes and action codes to classify transactions. This parameter tells settlement which combinations mean "breakage" so they can be reported correctly.

When to Configure:

• Store tracks breakage separately from other shrinkage
• Need breakage reporting by reason (customer damage, handling damage, etc.)

Impacted Code(s): IV2, IBR

StoreSettlementDelayedPaymentReasonAndActionCodes

Purpose: Defines reason/action codes that identify delayed payment (credit) transactions.

Valid Values: Comma-separated list of code pairs (reason,action)

Default: Empty

Example: value="(16,11),(17,11)"

How It Works: Identifies sales where customer takes goods immediately but pays later (invoice sales, account customers). These need special handling in settlement.

When to Configure:

• Store has business customers with credit accounts
• Invoice sales are processed through POS

Impacted Code(s): IZ1-IZ5

StoreSettlementPaidInOutReasonCodes

Purpose: Defines reason codes for manual cash in/out transactions (not related to sales).

Valid Values: Comma-separated list of reason codes

Default: Empty

Example: value="101,102,103"

How It Works: When cashiers manually add or remove cash from drawer (not for change making), these codes identify the reason. Used for tracking non-sales cash movements.

Common Reasons:

• Petty cash withdrawal
• Bank deposit preparation
• Starting float addition
• Excess cash removal

Impacted Code(s): IIN, IUT

StoreSettlementDepositRefundOutItemGroups

Purpose: Specifies which item groups represent deposit refund out (bottle/can return) transactions.

Valid Values: Comma-separated list of item group numbers

Default: Empty

Example: value="1,8,15"

How It Works: Bottle and can deposits are tracked by item group. This parameter tells settlement which groups contain deposit refund items so they can be properly categorized.

When to Configure:

• Store accepts bottle/can returns for deposit refund
• Operating in jurisdiction with mandatory deposit systems (e.g., pant in Nordic countries)

Impacted Code(s): IUP, IIP

StoreSettlementPrizePayoutItemGroups

Purpose: Specifies which item groups represent lottery prize payout transactions.

Valid Values: Comma-separated list of item group numbers

Default: Empty

Example: value="50,51,52"

How It Works: When lottery prizes are paid out, the transaction is recorded against specific item groups. This identifies those groups so settlement can track prize payouts separately.

When to Configure:

• Using StoreSettlementEnableLottery=true
• Store validates and pays lottery prizes

Impacted Code(s): IP1-IP5

StoreSettlementAutomaticDepositRefundEans

Purpose: List of EAN codes (barcodes) that trigger automatic deposit refund handling.

Valid Values: Comma-separated list of EAN barcodes

Default: Empty

Example: value="7035620001017,7035620001024,7035620001031"

How It Works: These EANs are typically printed on reverse vending machine (RVM) receipts or deposit return vouchers. When scanned at POS, they automatically process the deposit refund without requiring manual intervention or item lookup.

When to Configure:

• Store has reverse vending machines for bottle/can returns
• RVM prints vouchers with specific EAN codes
• Want seamless redemption of deposit return vouchers at POS
• Operating pant (bottle deposit) system

Common Scenarios:

• Customer returns bottles to RVM outside store
• RVM prints receipt with barcode value of returned deposits
• Customer scans receipt at checkout
• System automatically recognizes as deposit refund and reduces amount owed

Important Notes:

• Each RVM or deposit system may use unique EAN ranges
• Coordinate with RVM vendor for correct EAN codes
• Test thoroughly to ensure automatic processing works correctly

Impacted Code(s): IUP, IIP, IA/IB codes

StoreSettlementGiftCardTypesCodes

Purpose: Defines gift card type codes used in the system for settlement categorization.

Valid Values: Comma-separated list of gift card type identifiers

Default: Empty

Example: value="GIFT01,EGIFT01,FOREIGN01"

How It Works: Identifies and categorizes different types of gift cards: own store cards (full liability), electronic/mobile cards, and third-party/foreign cards accepted for payment. This ensures proper accounting treatment for each gift card type.

When to Configure:

• Store sells and/or accepts gift cards
• Multiple gift card types in use (physical, electronic, partner brands)
• Need separate tracking of gift card liability
• Accounting requires distinction between own cards and third-party cards

Gift Card Categories:

• Own Gift Cards: Issued by retailer, represents liability until redeemed
• Electronic Gift Cards: Digital/mobile gift cards, same liability as physical
• Foreign Gift Cards: Third-party cards accepted (e.g., Visa gift cards, mall cards)

Important Notes:

• Gift card sales don't count as revenue until cards are redeemed
• Own cards = liability, Foreign cards = tender type (like cash)
• Must track breakage (unredeemed cards) for accounting

Impacted Code(s): IGK (Own gift cards sold), IG1 (Foreign gift cards), tender codes for redemptions

StoreSettlementReasonDateItemSales

Purpose: Reason codes that identify dated item sales (items sold at discount due to approaching expiration date).

Valid Values: Comma-separated list of reason codes

Default: Empty

Example: value="BESTBEFORE,EXPIRY,DATED,CLEARANCE"

How It Works: Tracks sales of items with date-related markdowns, typically perishables approaching best-before date or seasonal items past season. Provides visibility into waste reduction efforts and markdown effectiveness.

When to Configure:

• Store sells perishable goods (grocery, bakery, deli)
• Date-based markdown program in place
• Need to track waste reduction and markdown performance
• Inventory clearance tracking for seasonal items

Common Use Cases:

• Best Before: Food items 1-2 days before best-before date (30-50% off)
• Use By: Perishables on use-by date (deeper discounts, 50-70% off)
• Seasonal Clearance: Post-season items with production dates
• Discontinued Items: Items no longer stocked, clearing inventory

Business Benefits:

• Reduces food waste by selling instead of discarding
• Provides data for better inventory ordering
• Shows effectiveness of markdown strategies
• Helps calculate shrinkage and waste costs

Important Notes:

• These are regular sales with discounts, not write-offs
• Revenue is recognized at discounted price
• Different from breakage or expiry write-offs

Impacted Code(s): IDT, DT1-DT9 (Dated item sales)

Payment and Tender Configuration

StoreSettlementUnknownCashierNumber

Purpose: Specifies the cashier/operator number to use when actual cashier cannot be identified.

Valid Values: Any string value (typically numeric)

Default: 9999

Example: value="999999"

How It Works: Sometimes transactions occur without proper cashier login (system errors, technical issues). This fallback cashier number ensures settlement can still be generated.

Important Notes:

• Large number of unknown cashier transactions indicates process problems
• Should be monitored and investigated
• Not for regular use - only as system fallback

Impacted Code(s): All operator-level codes when operator cannot be determined

StoreSettlementCreditPaymentIssuerIds

Purpose: Specifies which payment card issuer IDs represent credit card transactions (vs. debit).

Valid Values: Comma-separated list of issuer ID codes

Default: Empty

Example: value="3,4,5,6" (Visa, Mastercard, Amex, Diners)

How It Works: Different cards may have different processing fees or settlement timing. This separates credit cards from debit cards in reporting.

When to Configure:

• Need to track credit vs. debit for fee analysis
• Different reconciliation processes for credit and debit
• Merchant agreements differ by card type

Impacted Code(s): K01-K99 with credit classification

StoreSettlementNegativeCountedValueCodes

Purpose: Identifies codes where negative counted values are valid (e.g., overage that must be removed).

Valid Values: Comma-separated list of code identifiers

Default: Empty

Example: value="IVI,IUT"

How It Works: Normally counted cash should be positive. However, some situations require recording negative amounts (removing excess cash, correcting overages). This prevents validation errors for legitimate negative values.

Impacted Code(s): Specified codes where negative values allowed

StoreSettlementPaymentCardTypes

Purpose: General payment card type classification for settlement reporting.

Valid Values: Comma-separated list of card type codes

Default: Empty

Example: value="VISA,MC,AMEX"

How It Works: Groups payment cards by type for summary reporting. Provides high-level view of payment mix.

Impacted Code(s): R01-R99

StoreSettlementPaymentCardsS

Purpose: Maps specific payment cards to 'S' category in settlement (typically store-branded cards).

Valid Values: Comma-separated list of card identifiers

Default: Empty

Example: value="12,19" (might represent store loyalty card IDs)

How It Works: Some retailers have their own branded credit cards. These are tracked separately from external cards for commission and partnership accounting.

Impacted Code(s): S01-S99

StoreSettlementPaymentCardsC

Purpose: Maps specific payment cards to 'C' category in settlement (typically customer cards or specific card programs).

Valid Values: Comma-separated list of card identifiers

Default: Empty

Example: value="COOP,TRUMF"

How It Works: Similar to PaymentCardsS but different category. May represent partner cards, co-branded cards, or specific card programs requiring separate tracking.

Impacted Code(s): C01-C99

StoreSettlementCouponTypes

Purpose: Identifies coupon tender types for settlement categorization.

Valid Values: Comma-separated list of coupon type codes

Default: Empty

Example: value="MFG,STORE,DIGITAL"

How It Works: Different coupon types (manufacturer, store, digital/mobile) may have different reimbursement processes. Separating them in settlement aids reconciliation.

Coupon Categories:

• Manufacturer Coupons: Reimbursed by manufacturer
• Store Coupons: Store-funded promotions
• Digital Coupons: App or website based coupons

Impacted Code(s): Q01-Q99

StoreSettlementCashDrawerTenderControlTypes

Purpose: Defines which tender control transactions affect cash drawer balance calculations.

Valid Values: Comma-separated list of control types:

• Drop - Cash drops to safe
• PayedIn - Cash added to drawer
• PayedOut - Cash paid out for non-sales
• Float - Starting cash float

Default: Empty

Example: value="Drop,PayedIn,PayedOut,Float"

How It Works: Cash drawer balance = opening float + sales + paid-in - paid-out - drops. This configuration determines which control transactions are included in that calculation.

Impacted Code(s): IDR, IKI, IIN, IUT

StoreSettlementGroceriesOnlinePriceChannel

Purpose: Specifies the price channel identifier for online grocery transactions.

Valid Values: String matching a price channel key in the system

Default: Empty

Example: value="ShopAndGoCheckTerminal"

How It Works: Price channels allow different pricing for online vs. in-store. This identifies which channel represents online grocery orders so settlement can categorize them correctly.

When to Configure:

• Using StoreSettlementGroceriesOnlineVatRates
• Online and in-store prices may differ
• Need channel-specific revenue analysis

Impacted Code(s): IC1-IC5 (online grocery codes)

Settlement Code Reference Table

Parameter Summary Table

Configuration Examples by Business Type

Standard Retail Store

<add key="SettlementType" value="Store, Workstation" />
<add key="StoreSettlementOutputDirectory" value="c:\LPOS\Settlements\" />
<add key="StoreSettlementPeriodType" value="Date" />
<add key="StoreSettlementVatCodes" value="IM1=25;IM2=15;IM3=0" />
<add key="StoreSettlementEnabledItemTransactionTypes" value="Breakage,Inventory" />

Multi-Currency Border Store

<add key="SettlementType" value="Store, Operator" />
<add key="StoreSettlementEnableCurrencyBalance" value="true" />
<add key="StoreSettlementEnablePaymentCardInCurrency" value="true" />
<add key="StoreSettlementEnableCashInCurrency" value="true" />
<add key="StoreSettlementEnableDeliveredBalanceInCurrency" value="true" />

Grocery Store with Online Orders and Deposit System

<add key="StoreSettlementGroceriesOnlinePriceChannel" value="ShopAndGoCheckTerminal" />
<add key="StoreSettlementGroceriesOnlineVatRates" value="IC1=25.00;IC2=15.00;IC3=0.00" />
<add key="StoreSettlementDepositRefundOutItemGroups" value="1,8" />
<add key="StoreSettlementDepositRefundVatRates" value="1=25.0;2=0.0" />
<add key="StoreSettlementAutomaticDepositRefundEans" value="7035620001017,7035620001024" />
<add key="StoreSettlementReasonDateItemSales" value="BESTBEFORE,EXPIRY" />

24-Hour Fuel Station

<add key="StoreSettlementTimeOffset" value="6:00" />
<add key="StoreSettlementDelayedPaymentReasonAndActionCodes" value="(16,11)" />
<add key="StoreSettlementDelayedPaymentVatRates" value="IZ1=25.0;IZ2=15.0" />
<add key="StoreSettlementCashDrawerTenderControlTypes" value="Drop,PayedIn,PayedOut,Float" />

Co-op Store with Member Programs and Lottery

<add key="StoreSettlementRebateOwnMemberVatRates" value="25,15,0" />
<add key="StoreSettlementRebateForeignMemberVatRates" value="25,15" />
<add key="StoreSettlementEnableLottery" value="true" />
<add key="StoreSettlementPrizePayoutVatRates" value="IP1=0.0" />
<add key="StoreSettlementPrizePayoutItemGroups" value="50,51,52" />

Retail Chain with Supplier Kickbacks and Gift Cards

<add key="StoreSettlementEnableKickBack" value="true" />
<add key="StoreSettlementGiftCardTypesCodes" value="GIFT01,EGIFT01,FOREIGN01" />
<add key="StoreSettlementHasDiscountReasonCodes" value="true" />

Validation Checklist

Before Deploying Configuration Changes:

Configuration File Syntax:

• ☑ All parameters use correct XML syntax
• ☑ Quotation marks properly paired
• ☑ Semicolons and commas in right places

Parameter Values:

• ☑ VAT rates match legal requirements
• ☑ Reason/action code pairs exist in database
• ☑ Item group numbers are valid
• ☑ Price channel keys match system values
• ☑ EAN codes for deposit refunds are correct
• ☑ Gift card type codes match system configuration

Directory and Permissions:

• ☑ Output directory exists
• ☑ Service account has write permission
• ☑ Sufficient disk space available

Testing:

• ☑ Test in development environment first
• ☑ Compare output with manual calculations
• ☑ Verify all expected codes appear
• ☑ Check totals match POS reports
• ☑ Test new parameters (lottery, kickback, gift cards, dated items, member rebates)

Version History

Document Version: 2.0 (Updated with 8 New Parameters)
Last Updated: November 2025
Applicable to: POS Services StoreSettlement Worker
Configuration Files: App.config, POSServices.Workers.exe.config

Changes in Version 2.0:

• Added StoreSettlementRebateOwnMemberVatRates parameter
• Added StoreSettlementRebateForeignMemberVatRates parameter
• Added StoreSettlementAutomaticDepositRefundEans parameter
• Added StoreSettlementEnableLottery parameter
• Added StoreSettlementGiftCardTypesCodes parameter
• Added StoreSettlementHasDiscountReasonCodes parameter
• Added StoreSettlementReasonDateItemSales parameter
• Added StoreSettlementEnableKickBack parameter
• Updated Settlement Code Reference Table with new codes
• Added new configuration examples for co-op stores and retail chains

End of Documentation