IOSOR Wiedza
Drugi miesiąc DID: Pełny MRC przy zmianie kalendarza UTC
Zrozum przejście z początkowych proporcjonalnych kosztów DID na pełną miesięczną opłatę abonamentową (MRC) wyzwalaną przez zmianę kalendarza UTC pierwszego dnia miesiąca.
Zarządzanie cyklem życia numeru wirtualnego wymaga jasnego zrozumienia tego, jak cykl rozliczeniowy zmienia się od momentu początkowego nabycia do fazy cyklicznego utrzymania. W przeciwieństwie do pierwszego dnia usługi, który podlega zasadom matematyka setup i prorate pierwszego miesiąca DID, drugi miesiąc wprowadza standardową miesięczną opłatę cykliczną (MRC) w całości. Przejście to jest ściśle regulowane przez kalendarz UTC, co zapewnia zsynchronizowane zdarzenie rozliczeniowe dla wszystkich globalnych zasobów przypisanych do Twojego konta.
Przejście UTC z pro rata na pełny czynsz
Kiedy numer jest przypisywany po raz pierwszy poprzez inicjację JIT (Just-In-Time), system oblicza częściową opłatę na podstawie pozostałych dni w bieżącym miesiącu. Jednak gdy zegar wybije 00:00 UTC pierwszego dnia nowego miesiąca, logika Tydzień fakturacyjny DID: wiersze proporcjonalne a pełny miesiąc ulega zmianie.
Logika salda prepaid pierwszego dnia miesiąca
IOSOR działa w oparciu o rygorystyczny model przedpłacony (prepaid). Aby zachować ciągłość usług, system musi posiadać wystarczające środki na pokrycie pełnego MRC wszystkich aktywnych numerów DID w momencie zmiany kalendarza UTC. Jeśli saldo spadnie poniżej wymaganej kwoty, system może uruchomić automatyczne protokoły zawieszenia, aby zapobiec ujemnemu kapitałowi własnemu.
Porównanie początkowej konfiguracji z cyklami cyklicznymi
| Zdarzenie rozliczeniowe | Czas | Typ obliczeń | Wpływ |
|---|---|---|---|
| Początkowe przypisanie | Żądanie JIT | Setup + Pro rata | Natychmiastowe potrącenie |
| Zmiana drugiego miesiąca | 1-szy 00:00 UTC | Pełny MRC | Potrącenie cykliczne |
| Kolejne miesiące | 1-szy 00:00 UTC | Pełny MRC | Faza stabilizacji |
| Miękki przegląd | Miesięcznie | Audyt użycia | Kondycja konta |
Progi skalowania i przeglądy salda
W miarę rozwoju operacji, całkowity MRC dla Twojego inwentarza DID może znacznie wzrosnąć. W przypadku kont, na których całkowite miesięczne koszty cykliczne lub opłaty za użytkowanie zbliżają się do miękkiego przeglądu w okolicach USD 1,000/miesiąc, nasz zespół finansowy przeprowadza rutynowy audyt.
Techniczne webhooki i status numeru
Aby zautomatyzować księgowość, możesz wykorzystać webhooki, które uruchamiają się po pomyślnym potrąceniu MRC. Gdy system przetwarza pełny czynsz 1-go dnia UTC, tworzony jest wpis w księdze głównej. Twoja aplikacja może nasłuchiwać tych aktualizacji w celu synchronizacji wewnętrznych baz danych. Jest to niezbędne do utrzymania dokładnego śledzenia DLR (potwierdzeń dostarczenia) i zapewnienia, że monitory HB (Heartbeat) dla ruchu 10DLC lub toll-free pozostają zielone.
Rozpocznij pracę z IOSOR
O 00:00 UTC pierwszego wiersz czynszu staje się pełnym MRC dla każdego wciąż przypisanego DID. Pierwszy miesiąc to setup plus pozostałe dni. Wyeksportujcie przewrót kalendarza, by finanse nie czekały kolejnego prorate na tym samym numerze.
Podsumowanie IOSOR
Drugi miesiąc to pełny kalendarzowy MRC, nie arytmetyka reszty dni.
Róbcie: sfinansujcie pełny czynsz przed 1. UTC. Nie róbcie: planować drugi miesiąc jako kolejny prorate.
Czy ten przewodnik był pomocny?
Powiązane przewodniki
- Przekazanie DID drugiego właściciela: kto może przypisywać i zwalniać
Opanuj granice operacyjne, provisionowanie JIT oraz progi finansowe prepaid podczas przekazywania numerów DID drugiemu właścicielowi.
- Limit Wydatków na DID: Najem i Ruch Wychodzący na Jednym Numerze
Kontroluj ekspozycję numeru w swoim white-label CPaaS za pomocą połączonego limitu wydatków na koszty stałe i ruch wychodzący.
- Routing webhooków przychodzących na numer DID: MO bez właściciela traci STOP
Kieruj webhooki przychodzące do odpowiedniego konta w sposób bezpieczny. Zapobiegaj osieroconym zdarzeniom MO i pominiętym rezygnacjom w white-label prepaid CPaaS.