Povlačenje starih SKU-ova proizvoda bez prekida aktivne naplate

Povlačenje starih SKU-ova proizvoda bez prekida aktivne naplate.

Uspostavljanje životnog ciklusa povlačenja

Upravljanje white-label CPaaS katalogom zahtijeva strog životni ciklus za SKU-ove proizvoda. Kada stari SKU dosegne kraj svog životnog vijeka, morate ga prebaciti u stanje 'povučen' umjesto da ga izbrišete. Brisanje uništava povijest u glavnoj knjizi, što je katastrofalno za revizije naplate. Umjesto toga, označite SKU kao 'skriven' u konzoli. To sprječava nove stanare da odaberu proizvod, dok postojećim stanarima omogućuje nastavak trenutnog ciklusa naplate bez prekida.

Upravljanje aktivnom naplatom u glavnoj knjizi

Postojeći stanari vezani uz stare SKU-ove moraju ostati funkcionalni dok ne migriraju. Kada se SKU povuče, glavna knjiga nastavlja obrađivati MRC i naknade na temelju upotrebe prema povijesnoj povezanosti. Ne prisiljavajte migraciju usred ciklusa. Koristite IOSOR API za označavanje tih računa za prijelazno razdoblje. Osigurajte da prag pretplate od USD 20 ostane aktivan za te račune, jer glavna knjiga zahtijeva pozitivan saldo za obradu tekućeg DLR i SMS prometa.

Upravljanje JIT provisioningom i brojevima

Budući da IOSOR koristi JIT provisioning, stari SKU-ovi često ukazuju na specifične skupove brojeva. Prilikom povlačenja morate osigurati da logika usmjeravanja E.164 ostane netaknuta. Ako se stari SKU ukloni iz aktivnog kataloga, JIT mehanizam mora i dalje prepoznati povezanost za postojeće brojeve. Nikada ne uklanjajte dodjelu brojeva s povučenog SKU-a dok stanar uspješno ne prijeđe na novu razinu proizvoda, inače riskirate trenutni prekid usluge.

Integritet revizije i usklađenost

Održavanje povijesnih zapisa nije predmet pregovora. Svaki povučeni SKU mora zadržati svoje metapodatke, uključujući izvorne cijene i porezne konfiguracije. Ti su podaci ključni za financijsko izvještavanje. Ako stanar zatraži izvoz povijesti korištenja, sustav mora biti u stanju mapirati povučeni SKU natrag na važeći unos u glavnoj knjizi. To osigurava da vaši revizijski zapisi ostanu transparentni i u skladu s internim financijskim standardima.

Operativne najbolje prakse

Za upravljanje prijelazom pratite račune koji se približavaju pragu od USD 1.000/mjesečno. Ti stanari s velikim volumenom često zahtijevaju blagu provjeru prije prelaska na novije SKU-ove. Koristite sljedeće resurse za učinkovito upravljanje operacijama kataloga:

• Stanje kataloga na bilješkama ponude i glavne knjige
• Operacije kataloga pri otpremi mnogih proizvoda
• Zadržavanje revizijskih zapisnika: što kupci mogu izvesti i dokazati

Započnite s IOSOR-om

Otvorite IOSOR administratorsku konzolu i ažurirajte stari unos u katalogu na status 'deprecated' umjesto brisanja zapisa iz baze podataka. Konfigurirajte slušatelje webhooka kataloga da odbijaju nove zahtjeve za pružanje usluga, dok aktivnim ciklusima naplate i MRC odbicima dopuštate neometani nastavak. Prije nego što isključite vidljivost kataloga, provjerite u konzoli jesu li povijesna pravila JIT usmjeravanja i E.164 preslikavanja i dalje povezana s aktivnim podračunima.

Sažetak IOSOR

Uklanjanje starih unosa iz kataloga zahtijeva odvajanje aktivne naplate od odabira novih proizvoda bez uništavanja financijske povijesti. Meko označavanje starih SKU-ova čuva povijesno zaključavanje cijena, porezne konfiguracije i kontekst usmjeravanja potreban za usklađene revizije i neprekinutu isporuku usluga postojećim korisnicima.

Postavite stare unose u katalogu na zastarjele i dopustite nastavak automatske naplate dok račun ne dosegne planirani prozor migracije. Nemojte trajno brisati SKU-ove iz baze podataka kataloga niti prekidati povijesne JIT veze jer to trenutno prekida promet aktivnih korisnika i narušava financijske revizijske tragove.