IOSOR

IOSOR База знань

Unit class шаблону на debit rows

Кожен prepaid debit row має нести іменований unit class — template, session, segment або verify — щоб finance стикував spend без folklore-таблиць.

Settled debit без unit class — гроші без product-історії. Finance відкриває ledger і не відрізняє template send від session unit, SMS segment чи verify attempt — recon стає Slack-археологією. Ця сторінка — контракт мітки на ledger: кожен production debit row несе той самий unit class, що product замапив у каталозі. Це не есе про session-window pricing і не гайд «template vs session cost».

Пов’язані: Шлюз review шаблону та unit class, debit і delivery status в одному ledger, Рядки fraud burn на prepaid ledger.

IOSOR — white-label prepaid.

Unit class — поле ledger, не нотатка в чаті

Product може сказати «OTP template» у треді; finance потрібне filterable поле на debit row: unit class, template ID (якщо застосовно), amount, correlation ID, UTC timestamp. Pin у чаті — не ledger of record. Soft USD 1 000/міс вважає «ми знаємо, який це був class» боргом volume; USD 20 доводить: blank class не settles на pilot-коридорі.

Іменовані класи, які finance фільтрує

Unit class Типовий send Очікування finance
Template unit Approved outbound template Per-send template debit + template ID
Session unit User-initiated window Debit session-class, не folklore template
SMS segment Templated або plain SMS Segment × list; class усе одно named
Verify attempt OTP / code check Attempt або verify row — не «misc messaging»

Стиковка правди каталогу з кожним debit

Каталог тримає template ID, review state і unit class. Debit row має стикувати ці поля за те саме UTC-вікно. Version bump знову входить у Approved; bumped ID не успадковує вчорашній class silently. Retire зупиняє production debit під старим ID. Немає join-колонок — ранкові recon tickets.

Порожній або mismatched class — fail closed

Немає unit class → немає production settle. Class на debit ≠ class у каталозі → fail closed або hold release з чесним status — ніколи silent rewrite в інший class. Unknown template ID → немає settle. Спільний словник статусів гасить hero-коди: product і finance відкривають одну лексику. Soft USD 1 000/міс робить class mismatch exportable; USD 20 доводить коридор, де blank class не дебетує.

Чекліст покупця: unit class на debit rows

  1. Кожен settled production debit несе named unit class?
  2. Template send містить template ID + template unit (або mapped segment) для join?
  3. Session і verify класи роздільні — не згорнуті в «messaging»?
  4. Unit class каталогу збігається з debit row за те саме UTC-вікно?
  5. Blank / mismatched class блокує settle з чесним status?
  6. Soft volume language blocked, доки маркування class у draft?

Почніть з IOSOR

Вкажіть клас юніта та ідентифікатор шаблону безпосередньо у структурі шлюзу списань IOSOR для кожного вихідного трафіку. Налаштуйте правило жорсткого блокування (fail closed) у консолі: якщо запис списання не збігається з класом у каталозі шаблонів або містить порожнє поле, проведення розрахунку автоматично зупиняється.

Підсумок IOSOR

Цей матеріал довів, що клас юніта є обов'язковим атрибутом головної книги списань, а не текстовим коментарем у робочих чатах. Кожна дебетова строчка повинна жорстко зв'язуватися з актуальним каталогом шаблонів, версією та UTC-таймстампом. Порожні поля або невідповідності між заявленим і фактичним класом мають негайно блокувати проведення розрахунку, а не непомітно перезаписуватися.

Чи був матеріал корисним?

Пов’язані гіди