Define the charging policy first
A Lexoh pricing rule connects a charge calculation with the conditions under which it applies. Before editing rates, write down the service, site or zone, customer eligibility, currency, validity period and expected charge. Separate the intended policy from the fields available in the software.
Use the pricing controls supported by your deployed version and your administrator permissions. Confirm which rate types, conditions and test tools are available. An example in this guide is a method for checking a rule, not confirmation that every installation supports the same configuration.
Pricing and access permission answer different questions. A free rate does not, by itself, establish permission to enter. Verify the associated access rules separately.
Inspect the rules already in use
If a calendar or pricing simulator is available, use it to inspect a specific date and reproduce sample visits. Confirm which inputs it considers. A visual overlap or a colour alone does not prove which rule will be selected, and a simulator result should be checked against the supported charging workflow.
- Select the correct site or organization and review active rules alongside any planned replacements. Record their identifiers, names and effective dates.
- Check each rule’s scope: service or purchase, zone, payment channel and customer or credential conditions, where configured.
- Review days, time ranges, time zone and exceptional dates. Look for uncovered periods and overlapping rules.
- Check how the installed version resolves matching rules, including the priority direction, equal-priority cases and any fallback rule.
- Keep a record of the current configuration and a recovery procedure before preparing a change.
Specify the rule and its boundaries
Name and eligibility
Give the rule a name that identifies its purpose and effective period. State the eligible service, zones and customer groups. Check what an empty condition means in the installed version before leaving it blank.
Validity and time
Define start and end dates, days of the week and daily time ranges. Confirm whether boundaries are inclusive. Test overnight visits, holidays and time changes where relevant. Determine whether a visit uses the rule at entry, payment, exit or successive intervals.
Amount, unit and rounding
State the currency and charge unit: per visit, time interval, quantity or another supported basis. Confirm whether partial intervals are prorated or rounded up. If energy billing is supported, distinguish energy in kilowatt-hours (kWh) from power in kilowatts (kW).
Free periods and maximums
Define whether an initial free period is deducted from the visit or only waives the charge for visits shorter than a threshold. For a maximum, confirm its scope and reset boundary: a visit, calendar day and rolling 24-hour period are different. Verify how a blank or zero value behaves.
Taxes and customer display
Confirm whether the configured amount includes taxes and how the final breakdown is calculated. Have the responsible person validate tax settings. Check that the customer-facing price, payment screen and receipt describe the same rule.
Make the calculation unambiguous
For a fixed charge, define what the amount covers and when it repeats. For time-based pricing, define the first interval, each following interval and treatment of a partial interval. For a duration grid, make adjacent boundaries explicit and confirm whether a tier sets the whole charge or only a portion.
For a quantity or transaction-count rule, identify what is counted, whose records qualify and when the count resets. Confirm whether reaching a tier affects all units or only additional units. These are calculation questions to verify against the rate types available in your installation.
Illustrative test policy: the first 15 minutes are deducted from every visit. Each started 30-minute interval after that costs CAD 2, with a CAD 10 maximum per visit before taxes. No other rule or discount applies. These invented values demonstrate boundary testing, not a recommended tariff or a claim about Lexoh’s calculation engine.
| Visit duration | Charge before tax (CAD) |
|---|---|
| 15 min | 0 |
| 16 min | 2 |
| 45 min | 2 |
| 46 min | 4 |
| 165 min | 10 |
| 166 min | 10 |
How the results are calculated
Subtract 15 minutes, with a minimum billable duration of zero. Divide the remainder by 30 and round the interval count up. Multiply by CAD 2 and apply the CAD 10 cap. At 46 minutes, 31 billable minutes require two intervals, giving CAD 4. At 166 minutes, six intervals give CAD 12 before the cap reduces the charge to CAD 10.
What to test in the application
Enter equivalent cases in the supported test workflow and record the selected rule and amount. A different result may indicate different free-period, rounding, cap or priority behavior. Resolve that difference before applying the configuration to customers.
Check exceptions and overlapping conditions
Regular, event and holiday rules
Do not assign priority numbers from an example without verifying their meaning. Test a visit that matches both the regular rule and the exception, then confirm the selected rule. Also test equal priorities and a visit outside every intended rule.
Tags, account groups and discounts
Confirm which record carries the eligibility condition and when it is evaluated. Test an eligible visitor, an ineligible visitor and a missing association. Check whether discounts combine and whether they apply before or after a maximum or other adjustment.
Occupancy or quantity adjustments
If configured, identify the source, age and scope of the input. Define behavior when it is missing or stale. Test just below, exactly at and just above each threshold, and confirm whether a change affects visits already in progress.
Exceptional charges
For a lost ticket or another exceptional charge, document the condition, authorized operator action and customer explanation. Verify the actual supported workflow rather than assuming a missing entry record automatically triggers a fixed amount.
Test, activate and review the change
Do not use an unannounced customer charge as a test. Arrange the supported test environment or an approved operational test with the responsible administrator. When a result differs from the intended policy, retain the rule identifier and exact visit inputs so support can reproduce it.
- Build a test set covering ordinary visits, free-period and interval boundaries, maximums, overnight stays, exceptions and ineligible customers. Write the expected result before running each test.
- Record the inputs, selected rule, pre-tax amount, tax amounts and total returned by the supported test process. Investigate any unexplained difference.
- Confirm the effective date and how existing visits are treated. Check the rate displayed on each affected payment channel and on site signage.
- Use the authorized activation process and confirm which sites or devices have received the configuration. Keep the previous settings and recovery procedure available.
- Review an approved sample of resulting transactions and receipts after activation. Record the reviewer, date, outcome and any corrective action.