Analytics, Finance, Inventory, and POS

Use This Dashboard Area Safely

Use this guide when event setup, attendee operations, staff work, payment-adjacent tasks, public pages, or closeout records need a controlled path. In this guide, Analytics, Finance, Inventory, and POS narrows that work to rego analytics, finance analytics, settlements, inclusion claim, inventory analytics, inventory tracking, Point of Sales, POS aliases, and payment views. Because this is a surfaces page, read it as part of the Event Management learning path rather than as an isolated checklist.

Event records become real-world instructions: what attendees see, what staff do, what money or inventory must reconcile, and what future organizers inherit. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What The Screen Controls

This page explains a specific surface. Treat every button, field, filter, and table as a way to view or change real records, not just as a visual layout. The intended readers are Finance staff, Logistics staff, and Event leads. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /rego/events/manage/rego-analytics?id=:eventId, /rego/events/manage/finance-analytics?id=:eventId, /rego/events/manage/settlements?id=:eventId, /rego/events/manage/inclusion-claim?id=:eventId, /rego/events/manage/inventory-analytics?id=:eventId, /rego/events/manage/inventory-tracking?id=:eventId, /rego/events/manage/point-of-sales?id=:eventId, /rego/events/manage/payments?id=:eventId, and /rego/events/manage/pos?id=:eventId.
• Records or contracts involved: Analytics, Settlements, Inventory, POS sales, and Inclusion claims.
• Main care point: Watch for changing one part of the event without checking attendees, staff, finance, communications, public information, and closeout records.
• Proof worth keeping: event ID, dashboard state, public page, attendee record, payment or refund state, check-in count, roster note, export, and reviewer signoff.

Read The Screen From Top To Bottom

1. Confirm you are on the right event, report, route, or file: Begin by naming the Event Management situation, the owner, and the exact item involved in Analytics, Finance, Inventory, and POS.
2. Read the current state before changing it: Use /rego/events/manage/rego-analytics?id=:eventId, /rego/events/manage/finance-analytics?id=:eventId, /rego/events/manage/settlements?id=:eventId, /rego/events/manage/inclusion-claim?id=:eventId, /rego/events/manage/inventory-analytics?id=:eventId, /rego/events/manage/inventory-tracking?id=:eventId, /rego/events/manage/point-of-sales?id=:eventId, /rego/events/manage/payments?id=:eventId, and /rego/events/manage/pos?id=:eventId to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Use the smallest action that matches the task: Keep Analytics, Settlements, Inventory, POS sales, and Inclusion claims in view so the work stays tied to the records or contracts it can affect.
4. Check the list, detail view, history, or public page afterward: Before handing off, save proof such as event ID, dashboard state, public page, attendee record, payment or refund state, check-in count, roster note, export, and reviewer signoff so the next operator can see what changed and why it was safe to continue.

Before You Leave The Screen

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on attendees, staff, money, public pages, communications, and post-event records.
3. Proof is findable: The handoff points to evidence that the next operator can see what changed and why it was safe to continue.

End-to-end operator runbook

Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.

1. Step 1 - Anchor the work to one event. Open the relevant analytics, finance, settlement, inclusion claim, inventory, or POS surface for the correct event. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the operational context first. Check the reporting period, event ID, filters, and source records before trusting totals. Pause here and confirm the attendee, staff, money, and public-page impact still matches the event plan.
3. Step 3 - Change only the intended event setting or record. Compare unusual numbers against registrations, payments, refunds, inventory movements, POS sales, and settlements. This keeps the event state understandable before another setting changes.
4. Step 4 - Check attendee, money, staff, and public impact. Record or export required numbers only after source records are reconciled. The next operator should be able to see why this step was taken.
5. Step 5 - Verify the dashboard and public result. For corrections, update the source record first, then rerun or refresh analytics. Check the related event records before continuing.
6. Step 6 - Leave a clear event handoff. Complete finance closeout only when totals, settlements, refunds, and inventory/POS records agree. This leaves a handoff trail another operator can understand.

Purpose

These surfaces help staff understand event health, reconcile money, track items, handle inclusion claims, and run on-site sales.

High-risk areas

• Settlement mismatches.
• Inventory below demand.
• POS sales not reconciled.
• Inclusion claims without stock.
• Analytics used without checking source records.

Common mistakes

• Treating analytics as final finance proof.
• Selling inventory already needed for inclusions.
• Forgetting to reconcile POS cash or provider payments.
• Ignoring negative remaining inventory.

Verification

• Analytics pages load for the correct event.
• Settlement records match payment expectations.
• Inventory remaining values make sense.
• POS activity can be traced to records.