Definition
Operator mapping is set during plan packaging. Each house plan has a one-to-one link to an operator tariff plan. When a user subscribes, the platform provisions the matching operator from that link, so plan provisioning takes effect on the right tariff. With more than one operator, the same plan can map to a different tariff for each.
What is mapped
- Product code: The operator’s product id for the plan or data bundle, passed on the operator API call.
- Tariff code: The operator’s tariff-plan id, used for billing and operator reconciliation.
- Several operators: China Mobile, China Unicom, and China Telecom each use their own codes. The same house plan needs a separate mapping for each.
What to maintain
When an operator changes a tariff, the mapping has to change with it. Otherwise plan provisioning can fail or billing goes wrong. Keep a change process, and stay in touch with the operator’s commercial or technical contact. A wrong mapping fails provisioning, makes data billing inaccurate, and throws off reconciliation.
A configuration example
Suppose the house plan “10GB monthly” maps to product code PROD_001 and tariff code FEE_001 on China Mobile, and to PROD_002 and FEE_002 on China Unicom. When a user subscribes to “10GB monthly”, the platform picks the codes for the operator on the SIM and calls that API. The same data plan needs one mapping set per operator. The table should hold the platform plan id, the operator, the product code, the tariff code, and the effective time, so older mappings can still be traced. When a plan goes live or an operator tariff changes, update the table and test plan provisioning and operator reconciliation.
Mapping and billing
The mapping feeds data billing and operator reconciliation. A wrong row makes plan provisioning fail, or makes the platform bill disagree with the operator bill. The row is configured at plan packaging. Plan subscription and plan provisioning then call the operator API from that row. Usage and the bill have to use the operator’s codes so reconciliation can match. This table is how the IoT Cloud Platform joins its own plans to the operator.
Keeping the table current
An operator tariff change has to be written into the mapping, or plan provisioning fails or the charge is wrong. Keep a change process and a line to the operator commercial or technical contact. The table should store the platform plan id, the operator, the product code, the tariff code, and the effective time, so history can be traced. A new plan, or a tariff change, is not done until provisioning and reconciliation have been tested against the new row.
Two tariff versions on one product code: which one is provisioned
Operator mapping is a cross-reference: for a house plan, on a given operator, during a given effective window, which product code and which tariff code apply. At provisioning, take the row that is valid at the current time for the operator that owns the SIM, and hand it to the API. The same plan usually has different rows for China Mobile, China Unicom, and China Telecom. They cannot share one code. When a code is upgraded, the old row gets an end time and the new row gets a start time. The two should not overlap. If they overlap, provisioning can hit either version at random, while reconciliation prices the other one. If there is no effective row, the subscription should fail before payment. Do not collect the money and then fail at provisioning with “no mapping.” SimtoLink keeps this table between the plan and the operator. After a change, run one test SIM through provisioning, then match one usage record or subscription record, and confirm the tariff code on the bill is the one in the table.
A wrong mapping can provision successfully and still bill wrong
A code that is off by one character is often rejected by the API, and that is the easier case to find. The harder case is a code that really exists, but it is another data tier or another monthly rent. The API returns success, the user still sees the house plan’s name, and the operator bills the wrong tariff. Mapping acceptance therefore cannot stop at a successful receipt. Also check the product code in the receipt, and whether the plan total returned by a query equals the house plan’s tier. The tariff code is for reconciliation. The product code is for opening service. If both are empty, or only one is filled, the other path fails. If a region limit or a directed-access rule is a separate add-on product on the operator side, it needs its own mapping row. Do not tuck it into a remark on the main plan code. Historical orders keep a snapshot of the code at the time of provisioning. Changing the table later does not affect SIMs already opened. A retry of a failed order uses the row that is valid at retry time, and the operator should be able to see that the code has changed.
If a multi-operator plan is missing one carrier, which SIMs cannot be sold
A house plan that claims to work on all three networks, but whose mapping has only two, can still be selected for a SIM on the third. Whether it can be sold should mean: this SIM’s operator has one mapping row under this plan that is valid now. A SIM with no mapping does not appear in the subscription list, or it appears and is clearly not selectable. When a new operator is connected, fill in the mapping and the test SIM first, then release stock. Do not sell the number range first. If an operator stops selling a tariff, SIMs already provisioned before the end date keep the old tariff until the cycle ends, and new subscriptions take the new row. If a reconciliation file contains an unknown tariff code, first check whether the mapping was missed or the operator changed the code on its own. Do not edit the platform selling price to force the bill amount to match. The mapping table should export by plan and by operator. At handover, this table belongs on the go-live list together with the price list. Every row on the list needs the receipt id of a verification SIM. A mapping row with no receipt stays unsellable.