IOSOR Gabay
Template unit class sa mga debit row
Ang bawat prepaid debit row ay dapat magdala ng pinangalanang unit class — template, session, segment, o verify — upang maiugnay ng finance ang gastusin nang walang mga lumang spreadsheet.
Ang settled debit na walang unit class ay pera na walang malinaw na produkto. Hindi masabi ng finance kung ang send ay galing sa template, session units, SMS segments, o verify attempts — ang reconciliation ay nagiging archaeology sa Slack. Ang pahinang ito ay ang ledger label contract: ang bawat production debit row ay nagdadala ng parehong unit class product na naka-map sa catalog — hindi isang session-window pricing essay.
Nauugnay: Review gate ng template at unit class, debit row at delivery status sa iisang ledger, Mga row ng fraud burn sa prepaid ledger.
Ang IOSOR ay white-label prepaid.
Ang unit class ay ledger field, hindi chat note
Masasabi ng Product na «OTP template» sa isang thread; kailangan ng finance ang filterable field: unit class, template ID, halaga, correlation ID, at UTC timestamp. Ang mga chat pin ay hindi ang ledger of record.
Mga pinangalanang klase na mabilis ma-filter ng finance
| Unit class | Karaniwang send | Inaasahan ng finance |
|---|---|---|
| Template unit | Naaprubahang outbound template | Per-send template debit + template ID |
| Session unit | Traffic ng user-initiated window | Session-class debit, walang template folklore |
| SMS segment | Templated o plain SMS | Segment × list; may pangalan pa rin ang class |
| Verify attempt | OTP o |
Pag-ugnayin ang catalog truth sa bawat debit
Hawak ng catalog ang template ID, review state, at unit class. Ang debit row ay dapat iugnay ang mga field na iyon para sa parehong UTC window. Ang version bumps ay muling pumapasok sa Approved; ang bumped ID ay hindi tahimik na magmamana ng class kahapon. Pinipigilan ng Retire ang production debit sa ilalim ng lumang ID. Ang mga kulang na join column ay nagdudulot ng mga morning recon ticket.
Ang blangko o maling class ay fail closed
Ang nawawalang unit class ay nangangahulugan ng walang production settle. Ang class sa debit na hindi katugma ng class sa catalog ay nagreresulta sa fail closed o hold release na may honest status.
Checklist ng mamimili para sa unit class sa mga debit row
Siguraduhin na ang bawat row ay may nakatalagang class bago ang billing cycle. I-verify ang mapping sa catalog para sa bawat template ID. Iwasan ang paggamit ng generic labels na walang malinaw na policy ID. Ang bawat debit ay dapat na traceable pabalik sa isang valid na unit class.
Magsimula sa IOSOR
Buksan ang pagsasaayos ng ledger ng konsol ng IOSOR at paganahin ang mahigpit na pag-gate ng schema para sa lahat ng papalabas na debit na entry sa pagmemensahe. Itakda ang anumang transaksyon na walang malinaw na klase ng yunit o ID ng template ng katalogo na agad na mabigo nang sarado, na inilalagay ang hindi nauri na trapiko sa estado ng hold bago ang pagsettle sa pananalapi.
Buod ng IOSOR
Ang pagkakasundo sa pananalapi ay nakasalalay sa pagtrato sa klase ng yunit bilang isang hindi nababagong field ng ledger sa halip na isang hindi pormal na tala ng suporta.
Nakatulong ba ang gabay na ito?
Mga kaugnay na gabay
- Pamamahala ng Bulk Template Re-submission sa Panahon ng Recovery Sequences
Alamin kung paano sistematikong i-verify muli ang mga binagong template body pagkatapos ng mga update sa polisiya ng carrier sa loob ng IOSOR ecosystem.
- Pag-verify ng mga Rich Media Header Asset bago ang Template Submission
Alamin kung paano i-validate ang mga header image at document URL sa IOSOR upang maiwasan ang pag-reject ng template. Siguraduhing sumusunod ang iyong media assets sa mga pamantayan.
- Pag-synchronize ng mga Naaprubahang Template ng Mensahe sa mga Sub-account Environment
Masterin ang orkestrasyon ng mga naaprubahang template sa loob ng isang white-label CPaaS ecosystem. Matutong magpanatili ng mahigpit na data isolation habang tinitiyak ang pagsunod ng sub-account at mabilis na deployment sa pamamagitan ng JIT provisioning.