Retragerea SKU-urilor de produs vechi fără a întrerupe facturarea activă

Retragerea SKU-urilor de produs vechi fără a întrerupe facturarea activă.

Stabilirea ciclului de viață pentru retragere

Gestionarea unui catalog CPaaS white-label necesită un ciclu de viață strict pentru SKU-urile de produs. Când un SKU vechi ajunge la sfârșitul duratei de viață, trebuie să îl treceți într-o stare de 'retras' în loc să îl ștergeți. Ștergerea distruge istoricul registrului, ceea ce este catastrofal pentru auditurile de facturare. În schimb, marcați SKU-ul ca 'ascuns' în consolă. Acest lucru împiedică noii chiriași să selecteze produsul, permițând în același timp chiriașilor existenți să își continue ciclul de facturare fără întrerupere.

Gestionarea facturării active în registru

Chiriașii existenți legați de SKU-uri vechi trebuie să rămână funcționali până la migrare. Când un SKU este retras, registrul continuă să proceseze MRC și taxele bazate pe utilizare pe baza asocierii istorice. Nu forțați o migrare la mijlocul ciclului. Utilizați API-ul IOSOR pentru a marca aceste conturi pentru o perioadă de tranziție. Asigurați-vă că pragul de preplată de USD 20 rămâne activ pentru aceste conturi, deoarece registrul necesită un sold pozitiv pentru a procesa traficul DLR și SMS în curs.

Gestionarea JIT provisioning și a numerelor

Deoarece IOSOR utilizează JIT provisioning, SKU-urile vechi indică adesea către pool-uri de numere specifice. La retragere, trebuie să vă asigurați că logica de rutare E.164 rămâne intactă. Dacă un SKU vechi este eliminat din catalogul activ, motorul JIT trebuie să recunoască în continuare asocierea pentru numerele existente. Nu eliminați niciodată alocarea numerelor de la un SKU retras până când chiriașul nu a trecut cu succes la un nou nivel de produs, altfel riscați eșecul imediat al serviciului.

Integritatea auditului și conformitatea

Menținerea înregistrărilor istorice este nenegociabilă. Fiecare SKU retras trebuie să își păstreze metadatele, inclusiv prețurile originale și configurațiile fiscale. Aceste date sunt vitale pentru raportarea financiară. Dacă un chiriaș solicită exportul istoricului de utilizare, sistemul trebuie să poată mapa SKU-ul retras înapoi la o intrare validă în registru. Acest lucru asigură că jurnalele de audit rămân transparente și conforme cu standardele financiare interne.

Cele mai bune practici operaționale

Pentru a gestiona tranziția, monitorizați conturile care se apropie de pragul de USD 1.000/lună. Acești chiriași cu volum mare necesită adesea o revizuire ușoară înainte de a-i muta la SKU-uri mai noi. Utilizați următoarele resurse pentru a gestiona eficient operațiunile de catalog:

• Starea catalogului pe cotație și notele din registru
• Operațiuni de catalog la expedierea multor produse
• Retenția jurnalelor de audit: ce pot exporta și dovedi cumpărătorii

Începeți cu IOSOR

Deschideți consola de administrare IOSOR și actualizați intrarea din catalogul vechi la starea 'deprecated' în loc să ștergeți înregistrarea din baza de date. Configurați ascultătorii de webhook ai catalogului pentru a respinge noile cereri de provizionare, permițând în același timp ciclurilor de facturare active și deducerilor MRC să continue fără întrerupere. Înainte de a dezactiva vizibilitatea catalogului, verificați în consolă dacă regulile istorice de rutare JIT și mapările E.164 rămân atașate subconturilor active.

Rezumat IOSOR

Retragerea intrărilor din catalogul vechi necesită separarea executării facturării active de selectarea noilor produse, fără a distruge istoricul financiar.