Dapat tumugma ang mga ulat sa DLR, hindi sa bilang ng naisumite

Nakakatuwang tingnan ang bilang ng naisumite: tinanggap ng API ang mensahe, kaya mukhang matagumpay ang linggo. Ngunit ang ginhawang iyon ay nawawala sa linggo ng pagsingil. Ang isang ulat na nagbibilang sa mga naisumite bilang tagumpay ay hindi tatagpo sa mga resibo ng DLR, mga bawas sa pitaka para sa trapikong may maraming segment, at mga audit ng webhook.

Ipinapatupad ng IOSOR ang panuntunan: ang mga pag-export ng ulat ay sumusunod sa mga resibo ng paghahatid. Ang mga katayuang naisumite, nakapila, at tinanggap para sa pagpapadala ay nananatiling mga operational na bakas lamang. Ang naisalin, nabigo, at hindi kilala ang mga kolum na pinagtatalunan ng pananalapi at produkto.

Ang naisumite ay isang bakas, hindi pangwakas na sukatan

Ang pagtanggap para sa pagpapadala ay nagpapatunay lamang na tinanggap ng system ang gawain. Hindi nito pinapatunayan na natanggap ng telepono ang SMS. Kung ang pangunahing KPI ng iyong ulat ay ang mga naisumite, labis mong tatasahin ang tagumpay tuwing tataas ang bahagi ng hindi kilala o nabigo. Panatilihin ang naisumite bilang isang kolum ng kapasidad kung kapaki-pakinabang — ngunit huwag kailanman gagamitin bilang kapalit ng naisalin.

Sumusunod ang mga kolum ng pag-export sa mga resibo

Maliwanag na pinangalanan ng schema ng pag-export ang mga estado ng resibo. Ang naisalin ay nangangailangan ng DLR. Ang nabigo ay nangangailangan ng huling senyales ng pagkabigo. Ang hindi kilala ay nananatiling hindi kilala hanggang sa dumating ang resibo — hindi ito itinuturing na bahagyang naisalin. Ang mga linggo ng pagsingil na nagtatago ng hindi kilala sa loob ng tagumpay ay nagdudulot ng hidwaan sa pagsingil.

Ipagkasundo ang mga webhook at ledger laban sa parehong mga resibo

Ang pag-reconcile ng audit ng webhook laban sa pag-export ng ledger ang paraan upang patunayan na ang ulat ay hindi kathang-isip. Ang mga pang-araw-araw na log ng webhook, estado ng DLR, at linya ng prepaid ledger ay dapat magsalaysay ng iisang kuwento. Kung ang mga webhook ay nagpapakita ng nabigo habang ang ulat ay nagpapakita ng tagumpay, mali ang ulat — ayusin ang pag-export, huwag 'i-adjust' ang pitaka.

Tanggihan ang mga linggo ng invoice na nakabatay sa naisumite

Anumang pagsasara na sumisingil o nagdiriwang batay lamang sa bilang ng naisumite ay dapat harangan. Baguhin ang pack upang maihanay ng pananalapi ang bahagi ng naisalin at hindi kilala. Kung ang kontrata ng kasosyo ay nagsasaad pa rin ng 'matagumpay na mga pagsusumite sa API', isalin ang pahayag na iyon sa mga tala ng DLR — huwag ibaluktot ang mga kolum upang tumugma sa maling pananalita.

Mga kaugnay na landas ng ops

• Linggo ng Pagsingil sa DLR: Ang hindi kilalang bahagi ay hindi naihahatid
• Pag-reconcile ng mga pang-araw-araw na Webhook log laban sa mga prepaid balance
• Linggo ng invoice sa SMS: kapag ang matematika ng segment at ang bayarin ay h…

Magsimula sa IOSOR

Buksan ang lingguhang report pack sa IOSOR console at tiyaking ang bawat headline KPI ay nakabatay sa DLR receipts — delivered, failed, at unknown — hindi sa submit o API accept. Kung may chart na tinatrato pa ang submit bilang tagumpay, palitan ng pangalan o alisin bago ang finance close. Mag-export nang isang beses at ibahagi ang parehong receipt columns sa product at finance.

Buod ng IOSOR

Nagsasara ang mga report sa DLR receipts: delivered, failed, at unknown — hindi sa submit. Ang submit ay throughput lang, hindi katotohanan ng delivery o argumento sa invoice.

Gawin: isang export schema naka-lock sa receipt fields. Huwag: magdiwang ang product ng accept habang nakikipagtalo ang finance sa failed DLR.