# My test
## 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
**Test Scenarios**:
- Test with only `Store` to verify consolidated store-level reporting
- Test with `Operator` to verify per-cashier breakdowns
- Test with multiple values to ensure separate files are generated correctly
---
### 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\\"`
**How It Works**:
- The StoreSettlement worker writes output files to this directory
- Files are typically named with store number and date
- The service account running POS Services must have write permissions to this folder
- Network paths (UNC) are supported
**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`
**Example**: `value="Date"`
**How It Works**:
-`Date` mode: Settlement runs for exactly one business day (midnight to midnight, adjusted by TimeOffset)
-`DateRange` mode: Settlement can span from one date to another date
- The mode determines which database stored procedure is called (`sp_msvc_GetStoreSettlement` for Date, `sp_msvc_GetStoreSettlementForPeriod` for DateRange)
**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
**Common Use Cases**:
- Stores open 24 hours: Use offset to define when "business day" starts
- Late-night closing: Include after-midnight transactions in previous business day
- Multi-timezone operations: Adjust for timezone differences
**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`
**Example**: `value="true"`
**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 enabled, these items are included in settlement calculations.
**When to Enable**:
- Your store sells service products or fees that should appear in settlements
- You need to track non-inventory revenue separately
- Accounting requires non-sale items in daily reports
**When to Disable**:
- You only want physical product sales in settlements
- Non-sale items are handled in a separate system
- Standard retail operations without service products
**Impacted Code(s)**:
-**INO** - NonSale amount and quantity
-**N00-N99** - NonSale turnover by type
-**O00-O99** - NonSale gross profit by type
-**P00-P99** - NonSale cost price by type
---
### StoreSettlementEnableCurrencyBalance
**Purpose**: Enables detailed currency breakdown for multi-currency transactions in settlements.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
When enabled, settlement files include separate entries for each currency used in transactions (NOK, SEK, EUR, USD, etc.), showing both the original currency amount and the converted amount to base currency.
**When to Enable**:
- Store accepts multiple currencies
- You need currency-specific reconciliation
- Accounting requires foreign exchange tracking
- Border stores or tourist locations
**When to Disable**:
- Store only accepts one currency
- Currency conversion handled elsewhere
- Simplified settlement reports needed
**Impacted Code(s)**:
-**NO1, NO2** - Norwegian Krone (tender and balance)
-**SE1, SE2** - Swedish Krona (tender and balance)
-**DA1, DA2** - Danish Krone (tender and balance)
-**US1, US2** - US Dollar (tender and balance)
-**EU1, EU2** - Euro (tender and balance)
-**GB1, GB2** - British Pound (tender and balance)
-**DI1, DI2** - Other currencies (tender and balance)
---
### StoreSettlementEnableInboundOutboundChange
**Purpose**: Tracks the float/change fund balance - money set aside in cash drawer for making change.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
-**Inbound change**: Money added to the change fund (float deposited at start of day/shift)
-**Outbound change**: Money removed from the change fund (float withdrawn at end of day/shift)
- Tracks the last outbound balance from previous day and current day's inbound balance
**When to Enable**:
- Store uses a change fund/float system
- Need to track change fund movements separately from sales
- Reconciliation requires float tracking
**When to Disable**:
- No formal float/change fund system
- Change tracking done manually outside the system
**Impacted Code(s)**:
-**IVI** - Inbound change balance
-**IVU** - Outbound change balance
---
### StoreSettlementEnableDeliveredBalanceInCurrency
**Purpose**: Reports banking deposits broken down by currency.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
Tracks money delivered to the bank (banking deposits) separately for each currency. This helps reconcile multi-currency bank deposits.
**When to Enable**:
- Multi-currency environment with separate bank deposits per currency
- Bank requires currency-specific deposit reconciliation
- Need to track which currencies were deposited
**Impacted Code(s)**:
- Banking per currency section (currency-specific bank deposit codes)
---
### StoreSettlementEnableInboundOutboundChangeInCurrency
**Purpose**: Reports float/change fund movements broken down by currency.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
Similar to `StoreSettlementEnableInboundOutboundChange`, but provides separate reporting for each currency in the float. Useful when change funds contain multiple currencies.
**When to Enable**:
- Multi-currency change fund
- Need to track float by currency
- Reconciliation requires currency-specific float tracking
**Impacted Code(s)**:
- Currency-specific inbound/outbound change codes (extends IVI/IVU with currency detail)
---
### StoreSettlementEnablePaymentCardInCurrency
**Purpose**: Reports payment card transactions with original currency amounts.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
When customers pay with foreign currency cards, this tracks both the original currency amount and the converted amount. Helps reconcile card payments that were processed in foreign currencies.
**When to Enable**:
- Accept foreign currency card payments
- Card processor settles in multiple currencies
- Need to reconcile original currency vs. converted amounts
**Impacted Code(s)**:
-**K** codes with currency detail - Credit/debit card types with currency breakdown
---
### StoreSettlementEnableCashInCurrency
**Purpose**: Reports cash transactions broken down by currency received.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
Tracks cash payments in each currency separately (e.g., how much NOK, SEK, EUR was received in cash). Essential for multi-currency cash handling.
**When to Enable**:
- Store accepts cash in multiple currencies
- Need to count and reconcile each currency separately
- Cash register drawers contain multiple currencies
**Impacted Code(s)**:
-**CNO** - Cash in Norwegian Krone
-**CSE** - Cash in Swedish Krona
-**CEU** - Cash in Euro
-**COT** - Cash in other currencies
---
### StoreSettlementEnableFallbacks
**Purpose**: Enables fallback categorization for payment cards that don't match standard categories.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
When a payment card doesn't match the configured payment card types (in `StoreSettlementPaymentCardTypes`), this parameter determines if it should still be reported using a fallback category. Prevents "lost" transactions that don't fit standard categories.
**When to Enable**:
- You have payment integrations that might send unexpected card types
- Want to capture all payment card transactions even if not pre-configured
- Need complete transaction coverage without manual configuration updates
**When to Disable**:
- Only want explicitly configured payment types in settlement
- Prefer to identify and configure new payment types explicitly
**Impacted Code(s)**:
-**IRC** - Fallback for credit-type cards
-**IRS** - Fallback for other payment card types
---
### StoreSettlementEnableGrandTotal
**Purpose**: Includes the grand total from End of Business Day (EOBD) process in settlements.
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
The POS system calculates a grand total at end of business day. This parameter controls whether that pre-calculated total is included in settlement files. Useful for comparing calculated settlement totals against POS-reported totals.
**When to Enable**:
- Want to verify settlement calculations against POS grand total
- Need EOBD grand total for reconciliation
- Accounting process requires this specific total
**When to Disable**:
- Don't use EOBD process
- Settlement calculations are sufficient without grand total reference
**Impacted Code(s)**:
-**ING** - Grand Total per workstation from End of Business Day
---
### StoreSettlementHasItemTransactionReasonCodes
**Purpose**: Adds reason code detail to item transaction reporting (breakage, inventory adjustments, etc.).
**Valid Values**: `true`, `false`
**Default**: `false`
**Example**: `value="true"`
**How It Works**:
Item transactions (non-sales movements like breakage, internal use) can have associated reason codes explaining why the transaction occurred. When enabled, these reason codes are included in the settlement output for each item transaction type.
**When to Enable**:
- Need detailed tracking of why items were broken, transferred, or adjusted
- Accounting requires reason codes for inventory movements
- Want to analyze patterns in breakage or shrinkage causes
**When to Disable**:
- Reason code detail not needed in settlement files
- Simplified settlement reporting preferred
**Impacted Code(s)**:
-**IV1-IV9** - Item transaction codes now include reason code breakdown
---
## Item Transaction Parameters
### StoreSettlementEnabledItemTransactionTypes
**Purpose**: Specifies which types of non-sales item movements should be included in settlement reports.
**Valid Values**: Comma-separated list containing any combination of:
-`Breakage` - Broken or damaged items
-`InternalUse` - Items used internally (not sold)
-`DockingArea` - Items in receiving/docking area
-`StockAdjustment` - Manual inventory adjustments
-`Inventory` - Inventory count adjustments
-`InternalTransfer` - Items transferred between departments/locations
-`Return` - Items returned to supplier
-`Complaint` - Items involved in customer complaints
-`Shrinkage` - Missing/stolen items
-`BreakageRegistered` - Breakage recorded in system
-`BreakagePaid` - Breakage that was paid for
**Default**: Empty string (no item transactions in settlement)
**Example**: `value="Breakage,Inventory,InternalTransfer"`
**How It Works**:
Item transactions represent inventory movements that aren't regular sales. Each type has a specific business meaning:
-**Breakage**: Items damaged in store, need to be written off
-**Internal Use**: Items consumed by the store (cleaning supplies, etc.)
-**Inventory**: Adjustments from physical inventory counts
-**InternalTransfer**: Moving items between stockrooms or departments
-**Return**: Sending defective items back to supplier
Only transaction types listed in this parameter will appear in the settlement file.
**When to Configure**:
- Enable `Breakage` and `Inventory` for most retail environments
- Add `InternalUse` if you track store consumption
- Add `InternalTransfer` for multi-department or multi-location stores
- Add `Complaint` if you track customer complaint-related inventory
**Impacted Code(s)**:
-**IV1** - Breakage transactions
-**IV2** - InternalUse transactions
-**IV3** - DockingArea transactions
-**IV4** - StockAdjustment transactions
-**IV5** - Inventory transactions
-**IV6** - InternalTransfer transactions
-**IV7** - Return transactions
-**IV8** - Complaint transactions
-**IV9** - Shrinkage transactions
-**IVR** - BreakageRegistered/BreakagePaid (when using reason codes)
---
## VAT and Tax Parameters
### StoreSettlementVatCodes
**Purpose**: Maps internal settlement codes to VAT/tax rates used in your country.
**Valid Values**: `<Code>=<Rate>;<Code>=<Rate>` format where:
- Code: Settlement code identifier (e.g., IM1, IM2, IM3, IM4)
- Rate: VAT percentage as integer (e.g., 25 for 25%, 0 for 0%)
**Default**: `IM1=25;IM2=0;IM3=14;IM4=99`
**Example**:
- Norway: `value="IM1=25;IM2=15;IM3=0"` (25%, 15%, 0%)
- Sweden: `value="IM1=25;IM2=12;IM3=6;IM4=0"` (25%, 12%, 6%, 0%)
**How It Works**:
Sales data is grouped by VAT rate, and this mapping tells the system which settlement code to use for each rate. The system automatically calculates the VAT amount from the gross sales for each rate.
**Configuration Tips**:
- Use IM1 for your standard/high VAT rate
- Use IM2 for reduced VAT rate (food, books, etc.)
- Use IM3 for zero VAT rate (exempt items)
- IM4 can be used for special cases or "other" rates
- Ensure rates match your country's VAT regulations
**Impacted Code(s)**:
-**IM1** - VAT rate 1 (typically 25%)
-**IM2** - VAT rate 2 (typically 0% or reduced)
-**IM3** - VAT rate 3 (typically 15% or reduced)
-**IM4** - VAT rate 4 (other/special rates)
---
### StoreSettlementDelayedPaymentVatRates
**Purpose**: Specifies VAT rates for delayed payment transactions (items taken now, paid later - like fuel drive-offs or account customers).
**Valid Values**: `<SettlementCode>=<VatRate>;<SettlementCode>=<VatRate>` format
**Default**: Empty string
**Example**: `value="IZ1=25.0;IZ2=15"`
**How It Works**:
Delayed payments occur when customers receive goods/services but payment is deferred (e.g., corporate accounts, fuel drive-offs that are later paid). These transactions need separate VAT tracking because:
- They're recorded when goods are delivered
- Payment happens later (sometimes in a different settlement period)
- VAT implications may differ from regular sales
The system separates delayed payments into registered (negative - debt created) and paid (positive - debt settled).
**When to Configure**:
- You have account customers who pay later
- Fuel station with pay-at-pump or drive-off scenarios
- Corporate billing arrangements
- Any delayed payment scenario requiring VAT tracking
**Impacted Code(s)**:
-**IZ1-IZ5** - Delayed payment transactions grouped by VAT rate
- Works in conjunction with `StoreSettlementDelayedPaymentReasonAndActionCodes`
---
### StoreSettlementDepositRefundVatRates
**Purpose**: Defines VAT rates for deposit refunds (e.g., bottle deposits, container fees).
**Valid Values**: `<Number>=<VatRate>;<Number>=<VatRate>` where Number is 1-5
**Default**: Empty string
**Example**: `value="1=25.0;2=15"`
- Creates **IA1/IB1** for 25% VAT deposit refunds
- Creates **IA2/IB2** for 15% VAT deposit refunds
**How It Works**:
Deposit systems involve:
- Customer pays deposit when purchasing (outbound - IB codes)
- Customer receives refund when returning empty containers (inbound - IA codes)
Each configured number creates a pair of codes (IA and IB) for that VAT rate. This allows tracking deposits and refunds separately by VAT rate.
**Configuration Example**:
```
value="1=25.0;2=15"
```
Results in:
- IA1 = Deposit refunds IN at 25% VAT
- IB1 = Deposit fees OUT at 25% VAT
- IA2 = Deposit refunds IN at 15% VAT
- IB2 = Deposit fees OUT at 15% VAT
**When to Configure**:
- Beverage containers with deposits (bottles, cans)
- Packaging deposits (pallets, crates)
- Any deposit/refund system requiring VAT tracking
**Impacted Code(s)**:
-**IA1-IA5** - Deposit refunds IN (customer returns containers)
-**IB1-IB5** - Deposit fees OUT (customer pays deposit)
- Number of codes generated depends on how many VAT rates you configure
---
### StoreSettlementPrizePayoutVatRates
**Purpose**: Defines VAT rates for prize payouts (lottery winnings, jackpots, scratch cards, etc.).
**Valid Values**: `<SettlementCode>=<VatRate 0.00 format>;<SettlementCode>=<VatRate 0.00 format>`
**Default**: Empty string
**Example**: `value="IP1=25.00;IP2=15.00;IP3=0.00"`
**How It Works**:
Prize payouts are when the store pays out winnings to customers (lottery wins, gambling payouts, contest prizes). These often have special VAT treatment. This parameter creates settlement codes for tracking these payouts by VAT rate.
Must be used in conjunction with `StoreSettlementPrizePayoutItemGroups` to identify which item groups represent prizes.
**When to Configure**:
- Store sells lottery products with payouts
- Gambling/gaming operations
- Contest or sweepstakes with prize redemptions
- Any scenario where store pays out prizes to customers
**Impacted Code(s)**:
-**IP1-IP5** - Prize payout amounts grouped by VAT rate
-**IPR** - Total prize payout reconciliation
---
### StoreSettlementGroceriesOnlineVatRates
**Purpose**: Tracks VAT for online grocery orders (click-and-collect, home delivery) separately from in-store sales.
**Valid Values**: `<SettlementCode>=<VatRate 0.00 format>;<SettlementCode>=<VatRate 0.00 format>`
**Default**: Empty string
**Example**: `value="IC1=25.00;IC2=9.99;IC3=0.00"`
**How It Works**:
Online grocery sales may have different VAT rates or reporting requirements than in-store sales. This parameter creates separate settlement codes for online orders, grouped by VAT rate.
Works with `StoreSettlementGroceriesOnlinePriceChannel` to identify which transactions are online groceries.
**When to Configure**:
- Offer click-and-collect grocery service
- Home delivery for groceries
- Online ordering with in-store pickup
- Need to separate online from in-store sales
**Impacted Code(s)**:
-**IC1-IC5** - Groceries online sales grouped by VAT rate
---
### StoreSettlementWebShopVatRates
**Purpose**: Tracks VAT for webshop/e-commerce orders separately from other sales channels.
**Valid Values**: `<SettlementCode>=<VatRate 0.00 format>;<SettlementCode>=<VatRate 0.00 format>`
**Default**: Empty string
**Example**: `value="IW1=25.00;IW2=15.00;IW3=0.00"`
**How It Works**:
Webshop sales (online store orders) are tracked separately with their own VAT codes. This distinguishes between:
- Regular in-store purchases
- Online grocery/click-and-collect (IC codes)
- General webshop/e-commerce (IW codes)
**When to Configure**:
- Operate an e-commerce webshop
- Online sales need separate VAT reporting
- Different VAT treatment for online vs. in-store
**Impacted Code(s)**:
-**IW1-IW5** - Webshop sales grouped by VAT rate
---
## Reason and Action Code Parameters
### StoreSettlementBreakageReasonAndActionCodes
**Purpose**: Defines specific reason code and action code combinations that identify breakage transactions.
**Valid Values**: `(<ReasonCodeKey>,<ActionCodeKey>),(<ReasonCodeKey>,<ActionCodeKey>)`
**Default**: Empty string
**Example**: `value="(10,1),(20,2),(15,3)"`
**How It Works**:
Item transactions in the POS system have both:
-**Reason Code**: Why the transaction occurred (e.g., "damaged", "expired")
-**Action Code**: What action was taken (e.g., "write-off", "return to supplier")
This parameter specifies which combinations of these codes should be classified as breakage. Only transactions matching these exact pairs will be included in breakage settlement codes.
**Configuration Steps**:
1. Determine your reason codes for breakage (check DimReasonCode table)
2. Determine corresponding action codes
3. Pair them: (ReasonCode, ActionCode)
4. Multiple pairs can be defined
**Example Scenario**:
```
Reason Code 10 = "Damaged in store"
Action Code 1 = "Write off"
Reason Code 15 = "Expired product"
Action Code 1 = "Write off"
Configuration: value="(10,1),(15,1)"
```
**Impacted Code(s)**:
-**IV1** - Breakage transactions (amount and quantity)
-**BreakageRegistered/BreakagePaid** - When breakage is separated by payment status
---
### StoreSettlementDelayedPaymentReasonAndActionCodes
**Purpose**: Defines which reason/action code combinations identify delayed payment transactions.
**Valid Values**: `(<ReasonCodeKey>,<ActionCodeKey>),(<ReasonCodeKey>,<ActionCodeKey>)`
**Default**: Empty string
**Example**: `value="(16,11),(17,11)"`
**How It Works**:
Similar to breakage codes, but for delayed payments. These are transactions where:
- Customer receives goods/services immediately
- Payment is recorded as owed (account receivable)
- Payment is settled later
Common scenarios: corporate accounts, fuel cards, customer credit accounts.
**Configuration Steps**:
1. Identify reason codes for delayed payments (e.g., "Account customer", "Fuel card")
2. Identify action codes (e.g., "Create invoice", "Add to account")
3. Configure pairs to match your delayed payment scenarios
**Example Scenario**:
```
Reason Code 16 = "Account customer"
Action Code 11 = "Add to account receivable"
Configuration: value="(16,11)"
```
**Impacted Code(s)**:
-**DelayedPaymentRegistered** - When debt is created (negative amount)
-**DelayedPaymentPaid** - When debt is settled (positive amount)
-**IZ1-IZ5** - Delayed payments grouped by VAT rate (when `StoreSettlementDelayedPaymentVatRates` is configured)
---
### StoreSettlementPaidInOutReasonCodes
**Purpose**: Maps settlement codes to reason codes for paid-in and paid-out transactions (cash management operations).
**Valid Values**: `<SettlementCode>=<ReasonCodeKey>;<SettlementCode>=<ReasonCodeKey>`
**Default**: Empty string
**Example**: `value="I02=4;I04=5;U03=5;U10=0;I20=1"`
**How It Works**:
Cash management operations include:
-**Paid In**: Adding money to drawer (I codes) - bank deposits, safe drops, change fund
-**Paid Out**: Removing money from drawer (U codes) - expenses, change withdrawals
This parameter maps your custom settlement codes to the POS system's reason codes, allowing you to categorize different types of cash movements.
**Configuration Example**:
```
I02 = Reason Code 4 (Bank deposit)
I04 = Reason Code 5 (Safe drop)
U03 = Reason Code 5 (Petty cash withdrawal)
U10 = Reason Code 0 (Other paid out)
```
**When to Configure**:
- Track different types of cash deposits separately
- Categorize various paid-out reasons (expenses, withdrawals, etc.)
- Accounting requires detailed cash management codes
**Impacted Code(s)**:
-**I01-I99** - Paid-in transactions by reason code
-**U01-U99** - Paid-out transactions by reason code
---
## Payment and Card Parameters
### StoreSettlementCreditPaymentIssuerIds
**Purpose**: Identifies which payment card issuers should be classified as credit payments (for special handling like Collector, Resurs Bank financing).
**Valid Values**: Comma-separated list of payment card issuer identifiers
**Default**: Empty string
**Example**: `value="Collector,Resurs,KlarnaFinancing"`
**How It Works**:
Some payment methods are credit/financing arrangements rather than standard debit/credit cards (e.g., invoice payments, installment plans, buy-now-pay-later). This parameter identifies these payment types so they can be:
- Tracked separately in settlement
- Reported with currency breakdown
- Reconciled against financing company statements
**When to Configure**:
- Integrated with financing providers (Collector, Resurs, Klarna)
- Offer invoice payment options
- Buy-now-pay-later payment methods
- Need to reconcile financing payments separately
**Impacted Code(s)**:
- Currency breakdown for credit/financing transactions (SEK/NOK amounts for specified issuers)
---
### StoreSettlementPaymentCardTypes
**Purpose**: Maps settlement codes to specific payment card types for categorization.
**Valid Values**: `<SettlementCode>=<PaymentCardType>;<SettlementCode>=<PaymentCardType>`
**Default**: Empty string
**Example**: `value="R01=SteriaPay;R02=MobilePay;R03=Vipps;R04=ApplePay"`
**How It Works**:
Payment methods beyond standard credit/debit cards (mobile payments, digital wallets, etc.) need their own settlement codes. This parameter creates that mapping.
**Common Payment Types**:
- Mobile payment apps (MobilePay, Vipps, Swish)
- Digital wallets (Apple Pay, Google Pay)
- Store-specific payment cards
- Third-party payment systems
**When to Configure**:
- Accept mobile payment methods
- Multiple digital payment providers
- Need separate tracking for each payment type
- Accounting requires breakdown by payment method
**Impacted Code(s)**:
-**R01-R99** - Webshop/alternative payment types (amount and count per type)
---
### StoreSettlementPaymentCardsS
**Purpose**: Maps settlement codes to SoftPay payment card types (S01-S99 range).
**Valid Values**: `<SettlementCode>=<PaymentCardType>;<SettlementCode>=<PaymentCardType>`
**Default**: Empty string
**Example**: `value="S01=1;S02=2;S03=3"`
**How It Works**:
SoftPay is a specific payment integration system. This parameter categorizes different card types within the SoftPay system using the S-code range (S01 through S99).
**When to Configure**:
- Using SoftPay payment integration
- Need to distinguish between different SoftPay card categories
- Reconciliation with SoftPay statements requires breakdown
**Note**: This is integration-specific. Only configure if you use SoftPay.
**Impacted Code(s)**:
-**S01-S99** - SoftPay payment card types (filtered by PaymentCardType.Name = 'SoftPay')
---
### StoreSettlementPaymentCardsC
**Purpose**: Maps settlement codes to CoopPay payment card types (C01-C99 range).
**Valid Values**: `<SettlementCode>=<PaymentCardType>;<SettlementCode>=<PaymentCardType>`
**Default**: Empty string
**Example**: `value="C01=4;C02=5;C03=6"`
**How It Works**:
CoopPay is a specific payment integration system (used by Coop stores). This parameter categorizes different card types within the CoopPay system using the C-code range (C01 through C99).
**When to Configure**:
- Using CoopPay payment integration
- Part of Coop retail chain
- Need to distinguish between different CoopPay card categories
**Note**: This is integration-specific. Only configure if you use CoopPay.
**Impacted Code(s)**:
-**C01-C99** - CoopPay payment card types (filtered by PaymentCardType.Name = 'CoopPay')
---
## Coupon and Value Code Parameters
### StoreSettlementCouponTypes
**Purpose**: Maps settlement codes to different coupon types/providers for separate tracking.
**Valid Values**: `<SettlementCode>=<CouponType>;<SettlementCode>=<CouponType>`
**Default**: Empty string
**Example**: `value="Q01=C;Q02=V;Q03=M"`
**How It Works**:
Different coupon systems or providers may need separate reporting:
- C = Chain coupons (company-issued)
- V = Vendor/manufacturer coupons
- M = Mobile/digital coupons
- Custom providers
This parameter assigns a settlement code to each coupon type so you can track coupon usage by source.
**When to Configure**:
- Multiple coupon providers or systems
- Need to reconcile coupons separately by provider
- Accounting requires coupon breakdown by type
- Track promotional vs. manufacturer coupons separately
**Impacted Code(s)**:
-**Q01-Q99** - Coupon turnover by type (amount redeemed per coupon type)
---
### StoreSettlementNegativeCountedValueCodes
**Purpose**: Specifies which value code types should be reported as negative values in counted balance.
**Valid Values**: Comma-separated list of value code identifiers
**Default**: Empty string
**Example**: `value="VC01,VC02,VC05"`
**How It Works**:
Value codes (gift cards, prepaid cards, vouchers) normally show as positive amounts when sold. However, some value code transactions should be counted negatively in the balance (e.g., value codes used as payment, refunded value codes). This parameter identifies which ones.
**When to Configure**:
- Value codes can be used as payment method
- Gift cards redeemed (not sold)
- Prepaid card usage needs to reduce counted balance
**Impacted Code(s)**:
- Affects value code balance calculations in tender reconciliation
---
## Deposit and Refund Parameters
### StoreSettlementDepositRefundOutItemGroups
**Purpose**: Identifies which item groups should be treated as deposit refunds when sold (outbound direction).
**Valid Values**: `<ItemGroupNo>,<ItemGroupNo>,<ItemGroupNo>`
**Default**: Empty string
**Example**: `value="1,8,240"` (item groups 1, 8, and 240 are deposit-related)
**How It Works**:
Normally, deposit refunds are identified by article type. However, some systems use item groups to categorize deposits. This parameter allows you to specify:
- When items from these groups are sold (outbound), treat them as deposit fees
- When items from these groups are returned (inbound), treat them as deposit refunds
This is an alternative/additional method to the standard article type-based deposit tracking.
**When to Configure**:
- Your item groups are organized to include deposit items
- Need more granular deposit tracking than article type alone
- Different deposit types are in different item groups
**Configuration Example**:
```
Item Group 1 = Beverage bottles
Item Group 8 = Beverage cans
Item Group 240 = Pallets/crates
value="1,8,240"
```
**Relationship with Other Parameters**:
- Works with `StoreSettlementDepositRefundVatRates` to add VAT breakdown
- If empty, system uses only article type to identify deposits
**Impacted Code(s)**:
-**IUP** - Deposit refund OUT (affects this code when item groups are configured)
-**IIP** - Deposit refund IN
-**IA1-IA5/IB1-IB5** - Deposit refunds by VAT rate (when combined with `StoreSettlementDepositRefundVatRates`)
---
## Prize Payout Parameters
### StoreSettlementPrizePayoutItemGroups
**Purpose**: Identifies which item groups represent prize payouts (lottery, gambling winnings).
**Valid Values**: `<Item Group Number>,<Item Group Number>`
**Default**: Empty string
**Example**: `value="400,410,510"`
**How It Works**:
Prize payout transactions (paying customers for lottery wins, gambling payouts, etc.) are identified by item group. When items from these groups are sold in the inbound direction (negative sale = payout), they're treated as prize payments.
Must be used with `StoreSettlementPrizePayoutVatRates` to get VAT-categorized reporting.
**When to Configure**:
- Sell lottery products with payout capability
- Gambling/gaming operations
- Any prize redemption system
**Configuration Example**:
```
Item Group 400 = Lottery prize payouts
Item Group 410 = Scratch card prize payouts
Item Group 510 = Jackpot payouts
value="400,410,510"
```
**Impacted Code(s)**:
-**IP1-IP5** - Prize payout amounts by VAT rate
-**IPR** - Total prize payout reconciliation
- Only applies to inbound direction (returns/payouts) of specified item groups
---
## Cash Drawer and Control Parameters
### StoreSettlementCashDrawerTenderControlTypes
**Purpose**: Specifies which cash drawer control operations should be included in settlement reporting.
**Valid Values**: Comma-separated list of tender control types:
-`Drop` - Cash removed and placed in safe
-`PayedIn` - Cash added to drawer
-`PayedOut` - Cash removed from drawer (expenses, payouts)
-`PaymentOnAccountIn` - Payment received on customer account
-`PriceChanged` - Price override recorded
-`OpenDrawer` - Drawer opened (no-sale)
-`PaymentOnAccountOut` - Payment made to customer account
-`ReceiptCopy` - Receipt reprint (usually excluded)
-`TrainingReceipt` - Training mode transaction (usually excluded)
-`CustomersIn` - Customer count in
-`CustomersOut` - Customer count out
-`SignOn` - Cashier sign-on (usually excluded)
-`SignOff` - Cashier sign-off (usually excluded)
-`DepositSale` - Deposit transaction
-`PriceCheck` - Price check operation (usually excluded)
-`DeviceOn` - Device activation (usually excluded)
-`StartShift` - Shift start
-`EndShift` - Shift end
-`Float` - Starting float/change fund
-`SpotCheck` - Cash drawer spot audit
**Default**: Empty string
**Example**: `value="Drop,PayedIn,PayedOut,Float"`
**How It Works**:
Cash drawer control transactions track non-sales operations. The settlement file includes these operations to help reconcile:
- Where cash went (drops to safe, paid out for expenses)
- Where cash came from (paid in, starting float)
- When drawer was opened without a sale
Only the types listed in this parameter will appear in the settlement file.
**Common Configurations**:
-**Minimal**: `"Drop,Float"` - Only track safe drops and starting float
-**Standard**: `"Drop,PayedIn,PayedOut,Float"` - Track all cash movements
-**Detailed**: `"Drop,PayedIn,PayedOut,Float,StartShift,EndShift,SpotCheck"` - Include shift management
**Important Notes**:
- The system automatically EXCLUDES: `ReceiptCopy`, `TrainingReceipt`, `CustomersIn`, `CustomersOut`, `SignOn`, `SignOff`, `DepositSale`, `PriceCheck`, `DeviceOn`
- These are filtered out because they don't involve financial transactions
**Impacted Code(s)**:
-**IDR** - Drop to safe
-**IKI** - Cash paid in
-**IIN** - Cash paid in (alternative)
-**IUT** - Cash paid out
-**INS** - No-sale drawer opens
-**IBL** - Balance operations
-**IQP** - Payment on account in
-**IEP** - Payment on account out
---
## Price Channel Parameters
### StoreSettlementGroceriesOnlinePriceChannel
**Purpose**: Specifies the exact price channel identifier used for online grocery/click-and-collect orders.
**Valid Values**: Any valid price channel key from your system
**Default**: Empty string
**Example**: `value="ShopAndGoCheckTerminal"` or `value="OnlineGrocery"`
**How It Works**:
Price channels in POS systems identify where/how a sale was made:
- "Cashier" = Traditional checkout
- "SelfCheckout" = Self-service checkout
- "ShopAndGoCheckTerminal" = Scan-and-go terminal
- "OnlineGrocery" = Online order
This parameter tells the settlement system which price channel represents online grocery sales, so it can filter transactions for the `StoreSettlementGroceriesOnlineVatRates` reporting.
**When to Configure**:
- Offer click-and-collect or online grocery ordering
- Online orders are rung up using a specific price channel
- Need to separate online sales from in-store sales
**Configuration Steps**:
1. Determine which price channel is used for online groceries in your POS (check DimPriceChannel table)
2. Enter that exact price channel key
**Impacted Code(s)**:
-**IC1-IC5** - Filters transactions to only include the specified price channel
---
## Operator and Cashier Parameters
### StoreSettlementUnknownCashierNumber
**Purpose**: Default cashier/operator number to use when the actual cashier cannot be determined.
**Valid Values**: Any numeric string representing a cashier number
**Default**: `9999`
**Example**: `value="9999"` or `value="0000"`
**How It Works**:
Some transactions may not have an associated operator/cashier:
- Automated processes
- System-generated transactions
- Corrupted/incomplete transaction data
Rather than failing or omitting these transactions, the system assigns them to this "unknown" cashier number so they still appear in settlements.
**When to Configure**:
- Change default if 9999 conflicts with actual cashier numbers
- Use a specific code that means "system" or "unknown" in your organization
- Ensure the number doesn't overlap with real cashier IDs
**Best Practices**:
- Use a number clearly outside normal cashier ID range
- Document this as the "unknown cashier" for staff
- Review transactions under this ID regularly to identify system issues
**Impacted Code(s)**:
- Affects all operator-level settlement codes when operator is missing
- Used in operator-grouped settlements (`SettlementType=Operator`)
---
## Complete Settlement Code Reference
### Transaction and Sales Codes
-**K01-K99** - Payment by credit/debit card type
-**B01-B99** - Balance per tender type (counted/registered)
-**S01-S99** - Sales per tender type (cash, card, check, etc.)
-**IDP** - Deposit sales (container fees charged)
-**ITL** - Credit note sales (store credit issued)
### VAT and Tax Codes
-**IM1-IM4** - Sales grouped by VAT rate (main VAT reporting)
-**IA1-IA5** - Deposit refunds IN by VAT rate
-**IB1-IB5** - Deposit fees OUT by VAT rate
-**IZ1-IZ5** - Delayed payment by VAT rate
-**IP1-IP5** - Prize payout by VAT rate
-**IC1-IC5** - Groceries online by VAT rate
-**IW1-IW5** - Webshop sales by VAT rate
### Control and Cash Management Codes
-**IDR** - Drop to safe
-**IKI** - Cash paid in
-**IIN** - Cash paid in (alternative code)
-**IUT** - Cash paid out
-**INS** - No-sale (drawer opened without sale)
-**IBL** - Balance operations
-**IQP** - Payment on account in
-**IEP** - Payment on account out
### Receipt Level Codes
-**IOA** - Subtotal rounding (penny rounding adjustments)
-**ISK** - Scanned items count
-**IOP** - Price overridden items (manual price changes)
-**INS** - Null sale count (voided before completion)
-**IAN** - Cancelled receipts (voided after completion)
-**IPB** - On-hold transactions (parked/suspended sales)
### Item and Inventory Codes
-**IV1-IV9** - Item transactions by type (breakage, transfer, inventory, etc.)
-**IKU** - Number of customers (receipt count)
-**IVA** - Number of items sold (total quantity)
-**IKP** - Net cost of items sold
-**IXP** - Items sold excluding open price items
### Deleted Items Codes
-**ISV** - Deleted item lines (generic)
-**IS1** - Deleted items (last remaining)
-**IS2** - Deleted items (last registered)
-**IS3** - Deleted items (last remaining and registered)
-**IMB** - Deleted receipts (entire receipt voided)
-**IBS** - Deleted items from on-hold receipts
### Return and Discount Codes
-**IRE** - Returns (customer returns of sold items)
-**IRN** - Complaints (items returned due to complaints)
-**IRM** - Manual discounts (cashier-applied discounts)
-**IRK** - Customer/loyalty discounts
-**IRP** - Price rule discounts (promotional pricing)
-**IRG** - Group discounts
-**IGR** - Additional discount code
### Membership and Gift Cards
-**IME** - Membership type E sales
-**IMF** - Membership type F sales
-**IGK** - Gift cards own (store-issued gift cards sold)
-**IG1** - Gift cards foreign (third-party gift cards sold)
### NonSale Codes
-**INO** - NonSale total (all non-inventory sales)
-**N00-N99** - NonSale turnover by specific type
-**O00-O99** - NonSale gross profit by type
-**P00-P99** - NonSale cost price by type
### Currency Codes
-**NO1** - Norwegian Krone (tender)
-**NO2** - Norwegian Krone (balance)
-**SE1** - Swedish Krona (tender)
-**SE2** - Swedish Krona (balance)
-**DA1** - Danish Krone (tender)
-**DA2** - Danish Krone (balance)
-**US1** - US Dollar (tender)
-**US2** - US Dollar (balance)
-**EU1** - Euro (tender)
-**EU2** - Euro (balance)
-**GB1** - British Pound (tender)
-**GB2** - British Pound (balance)
-**DI1** - Other currencies (tender)
-**DI2** - Other currencies (balance)
-**CNO** - Cash in Norwegian Krone
-**CSE** - Cash in Swedish Krona
-**CEU** - Cash in Euro
-**COT** - Cash in other currencies
### Change Fund Codes
-**IVI** - Inbound change (float added to drawer)
-**IVU** - Outbound change (float removed from drawer)
### Order and Customer Order Codes
-**ISO** - Sales of paid customer orders (pre-ordered items picked up)
### Payment Method Specific Codes
-**S01-S99** - SoftPay payment card types
-**C01-C99** - CoopPay payment card types
-**R01-R99** - Webshop/alternative payment types
-**Q01-Q99** - Coupon types (by provider/source)
### Summary and Total Codes
-**ING** - Grand total per workstation (EOBD total)
### Fallback Codes
-**IRC** - Unmapped credit card fallback
-**IRS** - Unmapped payment type fallback
---
## Parameter Dependencies and Relationships
### Must Configure Together:
**For Deposit Refunds with VAT Breakdown**:
1.`StoreSettlementDepositRefundOutItemGroups` (identifies which item groups)
2.`StoreSettlementDepositRefundVatRates` (assigns VAT settlement codes)
- Without both: Only summary codes IIP/IUP generated
- With both: Detailed IA1-5/IB1-5 codes by VAT rate
**For Delayed Payments with VAT**:
1.`StoreSettlementDelayedPaymentReasonAndActionCodes` (identifies transactions)
2.`StoreSettlementDelayedPaymentVatRates` (assigns VAT codes)
- Without both: Delayed payments not reported
- With both: IZ1-5 codes by VAT rate
**For Prize Payouts**:
1.`StoreSettlementPrizePayoutItemGroups` (identifies prize item groups)
2.`StoreSettlementPrizePayoutVatRates` (assigns VAT codes)
- Without both: Prize payouts not reported
- With both: IP1-5 codes by VAT rate
**For Online Groceries**:
1.`StoreSettlementGroceriesOnlinePriceChannel` (identifies sales channel)
2.`StoreSettlementGroceriesOnlineVatRates` (assigns VAT codes)
- Without both: Online groceries not separated from in-store
- With both: IC1-5 codes for online only
**For Item Transactions**:
1.`StoreSettlementEnabledItemTransactionTypes` (enables types)
2.`StoreSettlementBreakageReasonAndActionCodes` (if tracking breakage)
3.`StoreSettlementHasItemTransactionReasonCodes` (if need reason detail)
---
## Configuration Examples by Business Type
### Standard Retail Store (Single Currency, Simple)
```xml
<addkey="SettlementType"value="Store, Workstation"/>
<addkey="StoreSettlementOutputDirectory"value="c:\LPOS\Settlements\"/>
<addkey="StoreSettlementPeriodType"value="Date"/>
<addkey="StoreSettlementTimeOffset"value="0:00"/>
<addkey="StoreSettlementEnableNonsale"value="false"/>
<addkey="StoreSettlementVatCodes"value="IM1=25;IM2=15;IM3=0"/>
<addkey="StoreSettlementEnabledItemTransactionTypes"value="Breakage,Inventory"/>
<addkey="StoreSettlementBreakageReasonAndActionCodes"value="(10,1)"/>
<addkey="StoreSettlementUnknownCashierNumber"value="9999"/>
```
**Results in**: Basic daily settlements per store and workstation with VAT breakdown and inventory tracking.
---
### Multi-Currency Border Store
```xml
<addkey="SettlementType"value="Store, Operator"/>
<addkey="StoreSettlementOutputDirectory"value="c:\LPOS\Settlements\"/>
<addkey="StoreSettlementPeriodType"value="Date"/>
<addkey="StoreSettlementEnableCurrencyBalance"value="true"/>
<addkey="StoreSettlementEnablePaymentCardInCurrency"value="true"/>
<addkey="StoreSettlementEnableCashInCurrency"value="true"/>
<addkey="StoreSettlementEnableDeliveredBalanceInCurrency"value="true"/>
<addkey="StoreSettlementEnableInboundOutboundChange"value="true"/>
<addkey="StoreSettlementEnableInboundOutboundChangeInCurrency"value="true"/>
<addkey="StoreSettlementVatCodes"value="IM1=25;IM2=15;IM3=0"/>
```
**Results in**: Detailed currency breakdown for all transaction types - essential for reconciling multiple currencies.
---
### Grocery Store with Online Orders and Deposits
```xml
<addkey="SettlementType"value="Store"/>
<addkey="StoreSettlementOutputDirectory"value="c:\LPOS\Settlements\"/>
<addkey="StoreSettlementPeriodType"value="Date"/>
<addkey="StoreSettlementVatCodes"value="IM1=25;IM2=15;IM3=0"/>
<addkey="StoreSettlementGroceriesOnlinePriceChannel"value="ShopAndGoCheckTerminal"/>
<addkey="StoreSettlementGroceriesOnlineVatRates"value="IC1=25.00;IC2=15.00;IC3=0.00"/>
<addkey="StoreSettlementWebShopVatRates"value="IW1=25.00;IW2=15.00"/>
<addkey="StoreSettlementDepositRefundOutItemGroups"value="1,8"/>
<addkey="StoreSettlementDepositRefundVatRates"value="1=25.0;2=0.0"/>
<addkey="StoreSettlementEnabledItemTransactionTypes"value="Breakage,Inventory"/>
```
**Results in**: Separate tracking for online vs in-store sales, deposit refund tracking, and standard inventory movements.
---
### Convenience Store with Lottery and Multiple Payment Types
```xml
<addkey="SettlementType"value="Store, Workstation"/>
<addkey="StoreSettlementOutputDirectory"value="c:\LPOS\Settlements\"/>
<addkey="StoreSettlementVatCodes"value="IM1=25;IM2=15;IM3=0"/>
<addkey="StoreSettlementPrizePayoutItemGroups"value="400,410,510"/>
<addkey="StoreSettlementPrizePayoutVatRates"value="IP1=25.00;IP2=0.00"/>
<addkey="StoreSettlementPaymentCardTypes"value="R01=MobilePay;R02=Vipps"/>
<addkey="StoreSettlementCouponTypes"value="Q01=C;Q02=V"/>
<addkey="StoreSettlementEnabledItemTransactionTypes"value="Breakage"/>
<addkey="StoreSettlementEnableFallbacks"value="true"/>
```
**Results in**: Prize payout tracking, mobile payment categorization, coupon provider breakdown, with fallback handling for unexpected payment types.
---
### 24-Hour Fuel Station
```xml
<addkey="SettlementType"value="Store, Operator"/>
<addkey="StoreSettlementOutputDirectory"value="c:\LPOS\Settlements\"/>
<addkey="StoreSettlementPeriodType"value="Date"/>
<addkey="StoreSettlementTimeOffset"value="6:00"/>
<!-- Business day 6 AM to 5:59 AM next day -->
<addkey="StoreSettlementVatCodes"value="IM1=25;IM2=15"/>
<addkey="StoreSettlementDelayedPaymentReasonAndActionCodes"value="(16,11)"/>
<addkey="StoreSettlementDelayedPaymentVatRates"value="IZ1=25.0;IZ2=15.0"/>
<addkey="StoreSettlementEnabledItemTransactionTypes"value="Breakage"/>
<addkey="StoreSettlementCashDrawerTenderControlTypes"value="Drop,PayedIn,PayedOut,Float"/>
```
**Results in**: 24-hour business day handling, delayed payment tracking for fuel cards, comprehensive cash management tracking.
---
### Enterprise Store with Account Customers
```xml
<addkey="SettlementType"value="Store, Operator"/>
<addkey="StoreSettlementOutputDirectory"value="\\server\share\settlements\"/>
<addkey="StoreSettlementPeriodType"value="Date"/>
<addkey="StoreSettlementVatCodes"value="IM1=25;IM2=15;IM3=0"/>
<addkey="StoreSettlementDelayedPaymentReasonAndActionCodes"value="(16,11),(17,11)"/>
<addkey="StoreSettlementDelayedPaymentVatRates"value="IZ1=25.0;IZ2=15.0;IZ3=0.0"/>
<addkey="StoreSettlementPaidInOutReasonCodes"value="I02=4;U03=5;U10=0"/>
<addkey="StoreSettlementCreditPaymentIssuerIds"value="Collector,Resurs"/>
<addkey="StoreSettlementEnabledItemTransactionTypes"value="Breakage,Inventory,InternalTransfer"/>
```
**Results in**: Corporate account payment tracking, delayed payment handling, financing provider integration, detailed cash management.
---
## Troubleshooting Guide
### Settlement File Not Generated
**Symptoms**: No output file appears in `StoreSettlementOutputDirectory`
**Check**:
1. Directory exists and POS Services has write permissions
2.`SettlementType` is configured (not empty)
3. Database connections in config are valid and accessible
4. Settlement request exists in `StoreSettlement.Request` table in messaging database
5. Check POS Services log file for errors
6. Verify `EnabledWorkers` includes `StoreSettlement`
**Solution**: Review log files, verify database connectivity, ensure directory permissions
---
### Missing Transaction Types in Settlement
**Symptoms**: Expected codes don't appear in settlement file
**Check**:
1.`StoreSettlementEnabledItemTransactionTypes` includes the transaction types you need
2. Reason/action code parameters are correctly configured with valid codes
3. Enable flags are set to `true` for currency, nonsale, or other features
4. Transactions actually exist in the database for the settlement period
5. Item group or price channel filters aren't excluding data unintentionally
**Solution**:
- Verify data exists: Query database tables directly for the settlement date
- Check configuration syntax: Ensure no typos in parameter values
- Review parameter dependencies: Some codes require multiple parameters configured
---
### Incorrect VAT Calculations
**Symptoms**: VAT amounts don't match expected calculations
**Check**:
1.`StoreSettlementVatCodes` matches your country's actual VAT rates
2. Decimal separator (point vs comma) matches regional settings
3. All VAT rate parameters use consistent format (e.g., "25.0" vs "25.00")
4. Item master data has correct VAT rates assigned
5. VAT calculation formula in stored procedures matches legal requirements
**Solution**:
- Standardize on one decimal format across all VAT parameters
- Verify VAT rates in configuration match legal rates
- Test with known transactions to validate calculations
---
### Currency Reporting Issues
**Symptoms**: Currency codes missing or showing wrong amounts
**Check**:
1. All currency enable flags are set to `true`:
-`StoreSettlementEnableCurrencyBalance`
-`StoreSettlementEnablePaymentCardInCurrency`
-`StoreSettlementEnableCashInCurrency`
-`StoreSettlementEnableDeliveredBalanceInCurrency`
-`StoreSettlementEnableInboundOutboundChangeInCurrency`
2. Multi-currency transactions actually exist in source data
3. Currency codes in `DimCurrency` table match expected values (NOK, SEK, EUR, etc.)
4. Currency exchange rates are properly configured in POS
**Solution**: Enable all needed currency flags, verify currency dimension data, test with known multi-currency transactions
---
### Settlement Code Mapping Problems
**Symptoms**: Wrong codes in file, duplicate codes, or missing mappings
**Check**:
1. Settlement code mappings use correct syntax (semicolon-separated, equals sign between code and value)
2. No duplicate codes defined in different parameters
3. Codes don't overlap with system-reserved codes
4. Reason codes and action codes exist in `DimReasonCode` table
5. Item group numbers exist and are assigned to products
**Solution**:
- Review all mapping parameters for syntax errors
- Query dimension tables to verify referenced codes exist
- Use unique code ranges for each parameter to avoid conflicts
---
### Time Boundary Issues
**Symptoms**: Transactions from wrong day appear in settlement
**Check**:
1.`StoreSettlementTimeOffset` is correctly configured for your business hours
2. Server time zone matches expected timezone
3. Transaction timestamps are in correct timezone
4. Offset direction (positive vs negative) is correct
**Solution**:
- For 24-hour stores: Set offset to when business day should start
- For late-night closing: Use offset to include after-midnight in previous day
- Test with known transactions at day boundaries
---
### File Permission Errors
**Symptoms**: Error messages about access denied or unable to write file
**Check**:
1.`StoreSettlementOutputDirectory` path is correct and exists
2. Service account has write permissions to the directory
3. Network path (UNC) is accessible from server
4. Disk space is available
5. Anti-virus or security software isn't blocking file creation
**Solution**:
- Grant write permissions to POS Services service account
- Test path accessibility from server
- Create directory if it doesn't exist
- Use local path if network path has issues
---
### Reason/Action Code Configuration Issues
**Symptoms**: Breakage or delayed payments not appearing correctly
**Check**:
1. Reason code and action code pairs are correctly formatted: `(ReasonCode,ActionCode)`
2. Multiple pairs separated by commas: `(10,1),(20,2)`
3. Codes exist in `DimReasonCode` table
4. Transactions are using the exact reason/action combinations specified
5. No extra spaces in configuration
**Solution**:
- Query `DimReasonCode` to get valid code numbers
- Query `FactItemTransactionRealTime` to see which code combinations are actually used
- Match configuration to actual transaction data
---
## Advanced Configuration Scenarios
### Seasonal Variation (Christmas Period Different Hours)
For stores with different business hours during holidays:
**Regular Configuration**:
```xml
<addkey="StoreSettlementTimeOffset"value="0:00"/>
```
**Holiday Configuration** (temporarily change):
```xml
<addkey="StoreSettlementTimeOffset"value="8:00"/>
<!-- Store opens at 8 AM during holidays instead of regular hours -->
```
**Note**: Restart POS Services after changing configuration
---
### Pilot Store Testing New Payment Method
When testing a new payment integration:
```xml
<!-- Enable fallback to catch unexpected payment types -->
<addkey="StoreSettlementEnableFallbacks"value="true"/>
<!-- Monitor fallback codes IRC/IRS in settlement files -->
<!-- Once you identify the payment type, add to standard mapping -->
<addkey="StoreSettlementPaymentCardTypes"value="R01=NewPaymentMethod"/>
<!-- Then disable fallback once all types are mapped -->
<addkey="StoreSettlementEnableFallbacks"value="false"/>
```
---
### Migrating from Weekly to Daily Settlements
**Phase 1** (Current - Weekly):
```xml
<addkey="StoreSettlementPeriodType"value="DateRange"/>
<!-- Generate weekly settlement covering 7 days -->
```
**Phase 2** (Transition):
```xml
<addkey="StoreSettlementPeriodType"value="Date"/>
<!-- Generate both daily and weekly for comparison period -->
```
**Phase 3** (Final):
```xml
<addkey="StoreSettlementPeriodType"value="Date"/>
<!-- Daily only, weekly settlements discontinued -->
```
---
## Validation Checklist
Before deploying StoreSettlement configuration changes:
### Configuration File Syntax
- [ ] All parameters use correct XML syntax
- [ ] No special characters that need escaping
- [ ] 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
- [ ] Currency codes are ISO standard (NOK, SEK, EUR, etc.)
### Directory and Permissions
- [ ] Output directory exists
- [ ] Service account has write permission
- [ ] Network paths are accessible
- [ ] Sufficient disk space available
### Dependencies
- [ ] Related parameters configured together
- [ ] Enable flags set for features being used
- [ ] Database connections valid
### Testing
- [ ] Test in development environment first
- [ ] Compare output with manual calculations
- [ ] Verify all expected codes appear
- [ ] Check totals match POS reports
- [ ] Run for multiple days to ensure consistency
---
## Support and Additional Resources
### When to Contact Support
Contact technical support if:
- Settlement files contain unexpected codes
- Calculations don't match POS totals
- Configuration changes don't take effect
- Database errors appear in logs
- Settlement generation fails repeatedly
### Information to Provide
When contacting support, provide:
1. Complete `<appSettings>` section from config file
2. Sample settlement file showing the issue
3. Log file entries from POS Services
4. Specific date(s) where issue occurs
5. Expected vs. actual results
### Database Queries for Verification
**Check settlement requests**:
```sql
SELECT * FROM StoreSettlement.Request
WHERE SettlementDate >= 'YYYY-MM-DD'
ORDER BY SettlementDate DESC
```
**Check available reason codes**:
```sql
SELECT * FROM DimReasonCode
WHERE Active = 1
ORDER BY ReasonCodeKey
```
**Check item groups**:
```sql
SELECT DISTINCT ArticleGroupKey, ArticleGroupName
FROM DimArticle
WHERE Active = 1
ORDER BY ArticleGroupKey
```
**Check price channels**:
```sql
SELECT * FROM DimPriceChannel
ORDER BY PriceChannelKey
```
---
## Summary of All Parameters
| Parameter | Purpose | Default | Key Codes Affected |
|-----------|---------|---------|-------------------|
| SettlementType | Grouping level (Store/Operator/Workstation) | Operator, Store, Workstation | All codes |
| StoreSettlementOutputDirectory | File output location | c:\temp\ | N/A (file system) |
| StoreSettlementPeriodType | Date vs DateRange | Date | All codes |
| StoreSettlementTimeOffset | Business day boundary | 0:00 | All codes |
| StoreSettlementEnableNonsale | Include non-sale items | false | INO, N00-N99, O00-O99, P00-P99 |
| StoreSettlementEnableCurrencyBalance | Multi-currency reporting | false | NO1-NO2, SE1-SE2, DA1-DA2, etc. |
| StoreSettlementEnableInboundOutboundChange | Track float/change fund | false | IVI, IVU |
| StoreSettlementEnableDeliveredBalanceInCurrency | Bank deposits by currency | false | Banking currency codes |
| StoreSettlementEnableInboundOutboundChangeInCurrency | Float by currency | false | IVI/IVU currency detail |
| StoreSettlementEnablePaymentCardInCurrency | Card payments by currency | false | K codes currency detail |
| StoreSettlementEnableCashInCurrency | Cash by currency | false | CNO, CSE, CEU, COT |
| StoreSettlementEnableFallbacks | Unmapped payment fallback | false | IRC, IRS |
| StoreSettlementEnableGrandTotal | EOBD grand total | false | ING |
| StoreSettlementHasItemTransactionReasonCodes | Item transaction reason detail | false | IV1-IV9 with reasons |
| StoreSettlementEnabledItemTransactionTypes | Which item movements to include | Empty | IV1-IV9 |
| StoreSettlementVatCodes | VAT rate mapping | IM1=25;IM2=0;IM3=14;IM4=99 | IM1-IM4 |
| StoreSettlementDelayedPaymentVatRates | Delayed payment VAT | Empty | IZ1-IZ5 |
| StoreSettlementDepositRefundVatRates | Deposit refund VAT | Empty | IA1-IA5, IB1-IB5 |
| StoreSettlementPrizePayoutVatRates | Prize payout VAT | Empty | IP1-IP5 |
| StoreSettlementGroceriesOnlineVatRates | Online grocery VAT | Empty | IC1-IC5 |
| StoreSettlementWebShopVatRates | Webshop VAT | Empty | IW1-IW5 |
| StoreSettlementBreakageReasonAndActionCodes | Breakage identification | Empty | IV1, Breakage codes |
| StoreSettlementDelayedPaymentReasonAndActionCodes | Delayed payment identification | Empty | IZ codes, DelayedPayment |
| StoreSettlementPaidInOutReasonCodes | Cash paid in/out mapping | Empty | I01-I99, U01-U99 |
| StoreSettlementCreditPaymentIssuerIds | Financing provider IDs | Empty | Currency credit codes |
| StoreSettlementPaymentCardTypes | Payment type mapping | Empty | R01-R99 |
| StoreSettlementPaymentCardsS | SoftPay mapping | Empty | S01-S99 |
| StoreSettlementPaymentCardsC | CoopPay mapping | Empty | C01-C99 |
| StoreSettlementCouponTypes | Coupon provider mapping | Empty | Q01-Q99 |
| StoreSettlementNegativeCountedValueCodes | Negative value codes | Empty | Value code balance |
| StoreSettlementDepositRefundOutItemGroups | Deposit item groups | Empty | IUP, IIP, IA/IB codes |
| StoreSettlementPrizePayoutItemGroups | Prize payout item groups | Empty | IP codes |
| StoreSettlementCashDrawerTenderControlTypes | Cash drawer operations | Empty | IDR, IKI, IIN, IUT, etc. |
| StoreSettlementGroceriesOnlinePriceChannel | Online grocery channel | Empty | IC codes |
| StoreSettlementUnknownCashierNumber | Unknown operator default | 9999 | Operator-level codes |
---
## Version History
**Document Version**: 1.0
**Last Updated**: 2025
**Applicable to**: POS Services StoreSettlement Worker
**Configuration Files**: App.config, POSServices.Workers.exe.config
---
**End of Documentation**
Page History
Overview
Content Tools