Allocation by client
| Client | Events | Messages | Parts | Share | Cost | Export |
|---|
Downloads
Event detail
| Sent | Client | Site | Device | Parts | Message | Matched by |
|---|
How this works
Anything the tool could not attribute to a client lands here rather than being quietly dropped. Each entry is the smallest decision that clears a group of messages, so a month with hundreds of stray parts usually reduces to a handful of prompts.
A SIM or device answer is written to the registry and a message pattern answer becomes a rule. Either way the answer is remembered and applied to every month already imported, so you are never asked twice.
Needs a decision
Where the registry comes from
The registry maps a SIM serial (ICCID) or a device name to a client, and for Fortress Fund to a site. It is the first thing the allocator checks, so getting it right fixes every future month at once.
Entries are ranked by where they came from: ThingsTeam beats a manual decision, which beats one mined from history. So a ThingsTeam sync always wins, and history never overwrites a real decision.
Sync the SIM register
SIMs sending SMS but not in the register
| SIM (ICCID) | Parts | Events | Last seen |
|---|
Registry
| Key | Type | Client | Site | Source | Note |
|---|
When a rule is the right answer
Some alarms never name a device — MQTT Broker: …,
STANNES TANK LEVEL - LOW ALARM - 34.90%. A rule matches on the text
instead. Rules also cover Fortress site codes: one
device_prefix rule on KS catches every device at Kokstad,
including ones that have never sent an SMS before.
Rules are tried in priority order, lowest first, and only after the registry. The registry always wins, so a rule can never silently override a known SIM.
Test a message
Rules
| Priority | Match on | Pattern | Client | Site | Note |
|---|
One-off message overrides
| Signature | Matches on | Client | Site |
|---|
Clients
| Client | Per site | Sites | Notes |
|---|
Sites
| Site | Client | Merge into… |
|---|
People with access
Administrators can import a month, answer the review queue, edit the registry, rules, clients and rates, and mark a month final. Viewers see every figure and can download the workbooks, but change nothing. New accounts get a temporary password, shown once, which they must replace at first sign-in.
| Name | Role | Status | Last signed in | Sessions |
|---|
Cost per part
Rates are dated, so entering a new one never changes a month you have already signed off. Leave a client blank to set the default that applies to everyone. Until a non-zero rate exists, every report shows volumes with the cost columns at zero and says so.
| Effective from | Client | Rate / part | Currency | Note |
|---|
Imported months
| Month | Status | Parts | Unallocated | Source file | Imported |
|---|
Seed the registry from the old reports
Reads the legacy Updated_SMS_List (YYYY-MM).xlsx files and mines a
registry entry for every device and SIM in them. Where those reports disagree with
themselves it takes the most recent month and flags the entry for review rather than
guessing. Safe to re-run; it never overwrites a ThingsTeam sync or your own decision.
About the numbers
Volumes are parts, counted across every delivery status, because that is what SMS Portal charges for. The export reports delivered / undelivered / expired only for the account as a whole, never per message, so a per-client delivery rate cannot be derived from it.
SMS Portal's REST API has no reporting endpoint — only authentication, balance, send
and WhatsApp — so the monthly export has to be uploaded by hand. Their send API does
accept costCentre and campaignName per batch. If the sending
platform ever stamps those, SMS Portal will do this allocation itself and this tool
will read it straight off the export instead of inferring it.