A Zenamuban minden előfizetéses tagság teljes belső nyilvántartást vezet minden fontos eseményről: a létrehozás pillanatától az egyes megújításokon, szüneteken és lemondásokon át egészen az esetleges visszatérítésekig. Ez a nyilvántartás az Ön teljes előzménye és biztonsági hálója a viták rendezéséhez és a könyveléshez. Ez a cikk elmagyarázza, hol találja egy tagság tevékenységét, és hogyan értelmezze az egyes eseménytípusokat.
Hol találja egy tagság tevékenységét
Nyissa meg egy ügyfél tagságának részleteit az adminban, és a következőket látja:
A tagság jelenlegi állapota (aktív, szüneteltetve, fizetésre vár, lemondva és így tovább), a következő megújítás dátuma, és — ha valami sikertelen volt — részletek a türelmi időről és a sikertelen fizetésről.
A Rendeléseim rész: az ehhez a tagsághoz kiállított bizonylatok listája (létrehozás dátuma, fizetés dátuma, fizetési állapot, összeg, leírás, és egy link a bizonylat részleteihez). Ez a fő információforrása az egyes sikeres fizetésekről, és egyúttal a könyvelésének alapja.
A profiljában (a Megvásárolt tagságaim → részletek alatt) az ügyfél ugyanazt az állapotot és ugyanazt a rendeléslistát látja.
Fontos: A Zenamunak még nincs dedikált „Megújítási előzmények” képernyője, amely kibontaná az egyes eseményeket, például a szüneteket, a változatváltásokat vagy a korrekciókat. Ezek az események egy belső rekordban tárolódnak az adatbázisban, és a Stripe Dashboardon (a Subscriptions, az Invoices és az Events alatt) tükröződnek. Az alkalmazásban három helyen dolgozhat közvetlenül: a tagság jelenlegi állapota, a bizonylatok listája (Rendeléseim), és az ügyfél tevékenysége, ahol a fő eseményeket egyszerű nyelven leírjuk (megújítva, fizetés sikertelen, szüneteltetve vagy automatikusan szüneteltetve, folytatva, az ügyfél által lemondva, a Stripe oldalán vagy az időszak végén lemondva). Minden egyes esemény részletes sorrendjéért nézzen a Stripe-ba. Alább leírjuk azokat az eseménytípusokat, amelyeket a rendszer rögzít, hogy értelmesek legyenek, amikor keresni kezdi őket.
Az eseménytípusok, amelyeket a rendszer rögzít
Minden belső eseménynek van egy típusa, egy dátuma, és gyakran néhány extra részlete (egy összeg, egy ok, a kapcsolódó rekord azonosítója a Stripe-ban).
Tagság létrehozva (első vásárlás)
Egy tagság első sikeres vásárlása a tagság létrehozásaként jelenik meg (aktív állapot, vagy röviden fizetésre vár), és a Rendeléseim rész első bizonylataként. Ebből látja a dátumot, az ügyfél által választott változatot, és az első felszámított összeget.
Sikeres megújítás
A rendszer minden sikeres megújuló terhelést rögzít. Egy megújítás tartalmazza:
A megújítás dátumát és időpontját.
A felszámított összeget.
A számlázási időszakot, amelyet a fizetés fedez (ezt a Stripe-ban a számlán követheti nyomon).
A kiállított bizonylatot (nyugta vagy számla), amelyet a Rendeléseim részben talál.
Ha az ügyfél jóváírást használ (amely származhat például egy korábbi, kártya helyett jóváírásként kiadott visszatérítésből), és az fedezi az időszak teljes fizetését, a megújítás akkor is átmegy — a Zenamu belsőleg rögzíti, és a tagság folytatódik —, de nem jön létre hozzá könyvelési bizonylat. Semmit sem terheltünk a kártyára, így nincs mit dokumentálni. Arra az időszakra nem talál bizonylatot a Rendeléseim részben, sem a könyvelőjének szánt exportban. Az ügyfél jóváírása az időszak árával csökken.
Sikertelen megújítás
A rendszer rögzíti a Stripe minden olyan kísérletét, amely egy fizetés levonására irányult, de nem sikerült (a Stripe automatikus újrapróbálkozásai, egy manuális újrapróbálás és így tovább).
A kísérlet dátumát és időpontját.
A sikertelenség okát (a bank kódját — fedezethiány, elutasítva, lejárt kártya, hitelesítés szükséges és így tovább).
Egyetlen sikertelen megújítás több rekordot is generálhat (a Stripe a türelmi idő alatt több kísérletet tesz). Ezeket a kísérleteket és kódjaikat a legjobban a Stripe Dashboardon a számlán követheti nyomon.
A türelmi idő kezdete egy külön belső esemény; ezen felül a türelmi idő vége dátuma (jellemzően a sikertelenség után 7 nappal) közvetlenül az adminban jelenik meg, a tagság sikertelenfizetés-figyelmeztetésének részeként.
Tagság szüneteltetve
Ezt minden alkalommal rögzítjük, amikor egy tagság szüneteltetésre kerül. Azt, hogy egy tagság szünetel, közvetlenül az állapotából látja az adminban. Két eset van:
Automatikus szünet (mert a stúdió csomagja visszaminősült). Egy magyarázó megjegyzés, amely ezt az okot leírja, a rekorddal együtt mentésre kerül.
Manuális szünet (az adminból). Ezt megjegyzés nélkül mentjük — nem kerül be ok.
Az ügyfél tevékenysége is megkülönbözteti, hogy a tagságot szüneteltették (manuálisan) vagy automatikusan szüneteltették. Ez a különbség fontos, mert eldönti, hogy a tagság automatikusan megújul-e, amikor később visszatér az Ultimate csomagra (csak az automatikusan szüneteltetett tagságok újulnak meg).
Tagság folytatva
Ezt akkor rögzítjük, amikor egy szüneteltetett tagságot újraindítanak. Az ok megkülönbözteti, hogy:
„Automatikusan folytatva: a stúdió visszaváltott az Ultimate csomagra” — automatikusan, miután a stúdió visszatért az Ultimate csomagra.
Egy manuális folytatás az adminból vagy az ügyfél profiljából.
Változatváltás
Akkor jön létre, amikor egy ügyfelet egyik változatról a másikra váltanak. Az ügyfél tevékenységében az alkalmazás ezt az eseményt Változat váltva néven jelöli.
A dátumot.
Régi változat → új változat.
A változás típusát — áremelés, ütemezett árcsökkentés, számlázásiidőszak-változás vagy azonos ár (a változatot átnevezték és így tovább).
A forgatókönyvtől függően: egy áremelésnél azonnali számla jelenik meg a hátralévő napokra eső arányos különbözetre (a következő megújítás dátuma változatlan marad); egy ütemezett árcsökkentésnél nem jön létre bizonylat a váltás napján — az admin egy „Ütemezett változtatás {{date}}-tól” bannert mutat a tagságon, és a változás csak a következő megújításkor érvényesül; egy számlázásiidőszak-változásnál a ciklus újraindul, és egyetlen nettó számla jön létre (az új ár levonva az előző időszak fel nem használt részére eső arányos jóváírást).
Azt, hogy ki végezte a változtatást, az ügyfél tevékenységéből látja az adminban. Megkülönbözteti, hogy az ügyfél váltotta-e a változatot a profiljából, vagy a stúdió tette az adminból (a stúdió műveleteinél a munkatárs neve is mentésre kerül).
Ütemezett változatváltás visszavonva
Amikor egy ügyfél (vagy a stúdió a nevében) visszavon egy korábban beállított ütemezett változatváltást (mindig B forgatókönyv — árcsökkentés), az ütemezettváltás-banner eltűnik az adminból, és a rendszer belsőleg feljegyzi a visszavonást. Nincsenek pénzügyi következmények; a tagság egyszerűen visszatér az eredeti változatára, nyom nélkül.
Ritka helyzetek egy ütemezett változatváltás körül
Időnként egy ügyfél beütemez egy árcsökkentést, de valami szokatlan történik a beütemezés és a megújítás napja között — például a stúdió közben archiválja a cél változatot, vagy törli a csoportot. A Zenamu ezeket a helyzeteket automatikusan kezeli, és belsőleg feljegyzi őket.
Mi történhet, és mit csinál a Zenamu:
Mi történt | Mit csinál a Zenamu |
A stúdió a megújítás előtt archiválta a cél változatot | A változás nem alkalmazódik. Az ár visszaáll az eredeti változatra, és az ügyfél úgy folytatja, mintha soha nem ütemezte volna be az árcsökkentést. |
A stúdió teljesen törölte a cél változatot | Ugyanaz a viselkedés, mint az archiválásnál. |
A stúdió archiválta vagy törölte az egész csoportot | Ugyanaz a viselkedés; az ügyfél az eredeti változaton marad. |
Az ár visszaállítása technikailag nem sikerül (pl. egy rövid Stripe-kimaradás) | A Zenamu feljegyzi a helyzetet. A tagságon egy figyelmeztető állapotot lát az adminban. Ebben a ritka esetben ellenőrizheti az ügyfél aktuális előfizetési árát a Stripe Dashboardon, és szükség esetén manuálisan kiigazíthatja. |
Ezek a helyzetek nagyon ritkák (jellemzően az ütemezett változtatások kevesebb mint 1%-a). Az esetek túlnyomó többségében a változás pontosan úgy megy át, ahogy az ügyfél a beütemezés napján szándékozta.
Ár frissítve
A rendszer rögzíti, amikor a stúdió tömeges árváltozást alkalmazott erre az ügyfélre. A rekord tartalmazza:
A dátumot.
A régi és az új árat.
Egy megjegyzést, hogy az új ár csak a következő szokásos megújításkor érvényesül.
Tagság lemondva
Ezt minden lemondásnál rögzítjük — manuálisnál (az ügyfél a profiljából, a stúdió az adminból, vagy a Stripe fizetéskezelő portálján keresztül) és automatikusnál (a Zenamu által, a 7 napos türelmi idő lejárta után). Azt, hogy egy tagság lemondva van, közvetlenül az állapotából látja az adminban (vagy egy „Lemondás az időszak végén” bannerből egy dátummal). Ezen felül a belső rekord tartalmazza:
A lemondás dátumát.
A lemondás módját: vagy a jelenlegi időszak végén, vagy azonnal.
A lemondás okát (például manuális lemondás az időszak végén, azonnali lemondás, vagy automatikus lemondás a türelmi idő lejárta után). Ez a leírás csak tájékoztató jellegű: belsőleg angolul tárolódik, és nem az a pontos szöveg, amelyet az alkalmazásban látna.
Azt, hogy ki végezte a lemondást, látja. Mind a belső rekordból, mind az ügyfél tevékenységéből az adminban megállapíthatja, hogy az ügyfél, a stúdió, vagy a rendszer mondta-e le a tagságot a türelmi idő lejárta után. A stúdió által végzett műveleteknél a munkatárs neve is mentésre kerül. Amit a rekord nem tartalmaz, az egy link az esetleges visszatérítéshez. Azt a Stripe Dashboardon, a Refunds alatt találja.
Fizetés megerősítése szükséges, és visszatérítések — ezek másként jelennek meg
A fizetés megerősítése szükséges (3D Secure) egy megújításnál belső eseményként kerül rögzítésre, de a tagság állapota aktív marad. Amikor egy megújításnál extra hitelesítésre van szükség, a Zenamu nem vált fizetésre vár állapotra (az az állapot egy befejezetlen első vásárláshoz van fenntartva; lásd a „Tagsági állapotok” cikket). Az eredmény ezután vagy sikertelen megújításként jelenik meg (ha az ügyfél nem fejezi be a hitelesítést, és a Stripe abbahagyja a próbálkozást), vagy sikeres megújításként (ha időben befejezi).
A visszatérítések nincsenek külön tagsági tevékenységként naplózva. Egy teljes visszatérítés a tagság automatikus lemondásához vezet; egy részleges visszatérítés nem változtatja meg a tagság állapotát. Magának a visszatérítésnek az állapotát a bizonylaton (a Rendeléseim rész) vagy a Stripe Dashboardon találja.
Korrekció egy belső ellenőrzésből (ritka események)
Ez a rekordtípus egy olyan helyzetet naplóz, amikor egy belső ellenőrzés a Zenamuban eltérést talált a saját állapota és a Stripe-állapot között, és vagy kijavította, vagy feljegyezte későbbi kezelésre. A konkrét típusok:
Függőben lévő vásárlási rendelés — az ügyfél vásárolt, a Stripe megerősítette, de a Zenamu nem tudta létrehozni a belső rendelést. A rendszer megjelöli a rekordot, hogy később pótolja.
Függőben lévő megújítási rendelés — ugyanaz, egy megújításnál.
Függőben lévő visszatérítés egy versenyhelyzet után — a Zenamu pont abban a pillanatban mondott le egy tagságot, amikor a Stripe párhuzamosan levont egy fizetést. Az automatikus visszatérítés nem történt meg azonnal, de fel van jegyezve későbbi kezelésre.
Függőben lévő változatváltás — egy változatváltás valamelyik szakaszban nem fejeződött be tisztán.
Üzenet egy már nem létező tagsághoz — a Stripe üzenetet küldött egy olyan tagságról, amely már nem létezik a Zenamuban (az ügyfelet törölték).
Ezek nagyjából az öt leggyakoribb; a Zenamu több más specifikus jelölőt is használ a ritka versenyhelyzetekhez (amikor két dolog ugyanabban a pillanatban történik). Ezek a korrekciók a háttérben futnak; egy önálló korrekció általában önmagában rendben van — a probléma az, ha ugyanaz a jelölő ismétlődik ugyanazon a tagságon. Ha egy ilyen helyzettel találja szembe magát, lépjen kapcsolatba az ügyfélszolgálattal.
Ezek a korrekciók tájékoztató jellegűek, és abban az értelemben jelennek meg, hogy a tagság állapota a Zenamuban végül egyezik a Stripe-pal:
Egy egyszeri korrekció rendben van. A Stripe és a Zenamu közötti kis eltérések időről időre előfordulnak.
Egy ismétlődő eltérés ugyanannál az ügyfélnél vagy stúdiónál mélyebb problémára utalhat. A Stripe Dashboardon ellenőrizze, hogy a fiókja korlátozva van-e (az Account requirements alatt), és hogy az ügyfél összes legutóbbi előfizetése egyezik-e azzal, amit a Zenamuban lát. Ha az eltérés továbbra is fennáll, manuálisan újraszinkronizálhatja a Stripe-ban (mondja le, és hozzon létre egy új előfizetést).
Valós idejű állapotfrissítések
Az adminban a tagság állapota és a rendelések listája automatikusan, valós időben frissül. Ez azt jelenti:
Amikor a Stripe üzenetet küld a Zenamunak (egy sikeres fizetés, egy sikertelenség, egy lemondás), a Zenamu néhány másodpercen belül átállítja a tagság állapotát, és hozzáadja az esetleges új bizonylatot.
A stúdió a változást az oldal frissítése nélkül látja.
Egy ügyfél a profiljában a jelenlegi állapotot csak az oldal frissítése után látja. Az ügyfélfelület általában nem használ valós idejű frissítéseket. Ha egy ügyfél azzal keresi meg a stúdiót, hogy miért nem lát egy új fizetést, javasolja neki, hogy frissítse az oldalt. Bizonyos helyzetekben (közvetlenül egy fizetés után) az ügyfél böngészője a háttérben röviden ellenőrzi az állapotot, de főszabályként: az oldal frissítése = aktuális állapot.
A legtöbb esetben mindkét fél a tényleges esemény után néhány másodpercen belül vagy egy percen belül látja a változásokat a Stripe oldalán.
Hogyan használja egy tagság tevékenységét a gyakorlatban
A tagság állapota + a rendelések listája a Zenamuban és a Stripe Dashboard kombinációja több helyzetben is hasznos:
Egy adott fizetés elmagyarázása egy ügyfélnek
Amikor egy ügyfél azt írja: „Miért terheltek 24 000 Ft-t április 14-én?”, nyissa meg a tagságában a Rendeléseim részt, és látja:
A dátumot és a fizetési állapotot.
Az összeget.
Egy linket a bizonylat részleteihez (a nyugta). A fizetés által fedezett számlázási időszakot a Stripe-ban a számlán követheti nyomon.
Ezután a pontos részletekkel válaszolhat az ügyfélnek.
Megérteni, miért került egy tagság lemondásra
Azt, hogy egy tagság sikertelen fizetések után automatikusan véget ért, a jelenlegi állapotából (lemondva / nincs kifizetve) és a Rendeléseimben hiányzó sikeres fizetésből állapíthatja meg. Az egyes kísérletek idővonaláért és a türelmi idő vége dátumáért (jellemzően 7 nap) nézze meg a megfelelő előfizetést és számlákat a Stripe Dashboardon. Az ügyfél így tudja, hogy volt egy 7 napos türelmi ideje, amelyet nem használt ki.
Egy ügyfél visszatérítése egy fel nem használt időszakra
A rendelések listájában látja az utolsó sikeres fizetés dátumát; azt, hogy a tagság meddig érvényes, a tagság állapotából látja (a következő megújítás dátuma). Számolja ki a fel nem használt napokra eső arányos összeget, és adja ki a visszatérítést a Stripe Dashboardon.
Duplikált terhelések felderítése
Ha egy ügyfél azt állítja, hogy a Stripe kétszer terhelte, nyissa meg a Rendeléseim részt (és a biztonság kedvéért a Stripe-ban a számlákat is). Vagy csak egy fizetést lát (és az ügyfél téved), vagy kettőt, ebben az esetben az egyiket visszatérítheti.
Dokumentáció a könyveléshez
A rendelések listája egy az egyben megegyezik a Stripe Dashboarddal. Ha a könyvelőjének egy adott fizetés igazolására van szüksége, nyissa meg a bizonylat részleteit (a Stripe-ban pedig megtalálja a teljes számlázást, a fizetési határidőt és az adóügyi adatokat).
Gyakran ismételt kérdések
Egy ügyfél azt mondja, nem látja az utolsó fizetését a profiljában. Néhány lehetőség:
Egy jóváírás fedezte a teljes fizetést (nem mozdult pénz = nincs bizonylat, lásd fent).
Az ügyfél profilja nem frissül valós időben — kérje meg, hogy próbálja frissíteni az oldalt.
A Stripe üzenete késett; várjon egy percet, és frissítse az oldalt.
Exportálhatom egy tagság tevékenységét? A könyveléshez használja a szokásos bizonylatexportot az adminban (ISDOC vagy Pohoda XML). Tartalmazza az összes számlát és lemondást, amelyre a könyvelőjének szüksége van. Az egyes események részletes sorrendjét (sikeres és sikertelen megújítások, szünetek, változatváltások) nem találja külön jelentésként az alkalmazásban; az az adat az adatbázisban és a Stripe Dashboardon él. A legtöbb esetben a könyvelőjének nincs rá szüksége — a bizonylatokkal dolgozik.
Törölhetek egy eseményrekordot? Nem. A könyvelési és előzményrekordokat nem töröljük és nem írjuk át utólag; csak újakat adunk hozzájuk. Az ok: az előzménynek teljesnek kell maradnia, mind a könyvelés céljából, mind a viták rendezéséhez.
Mi van, ha valami váratlant látok a Stripe-ban vagy a tagság állapotában (például egy belső ellenőrzésből származó korrekció eredményét)? Lehet, hogy egy olyan helyzetről van szó, amikor egy belső ellenőrzés a Zenamuban eltérést talált a saját állapota és a Stripe-állapot között, és kijavította. Ha egyszeri, rendben van (időnként egy üzenet a Stripe-tól elveszik, és a belső biztonsági háló helyrehozza). Ha az eltérés ugyanannál az ügyfélnél fennáll, ellenőrizze az előfizetése állapotát a Stripe Dashboardon, és hasonlítsa össze azzal, amit a Zenamuban lát. Ha valóban nem egyezik, lépjen kapcsolatba az ügyfélszolgálattal, vagy szinkronizálja újra manuálisan a Stripe-ban (mondja le, és hozzon létre egy új előfizetést).
Kapcsolódó cikkek
A meglévő tagok kezelése — minden művelet, amely belső eseményeket generál, és megváltoztatja egy tagság állapotát
Amikor egy fizetés sikertelen — annak részletei, mi történik egy sikertelen fizetéskor, és a kapcsolódó események
Gyakori problémák és megoldásuk — hogyan kezelje azokat a konkrét helyzeteket, amelyek megértésében ezek a részletek segítenek