Առցանց վճարումների համաձայնեցում CRM-ի և ERP-ի հետ

Հոդվածի ֆոկուսը

Առցանց վճարումների համադրում CRM-ի և ERP-ի հետ. ինչպես փակել օրը առանց ձեռքով քաոսիՎճարային օպերացիաներառցանց վճարումների հաշտեցումpending վճարումներ3-D Secure Հայաստան

Հաջորդ քայլերը

VPOS Reconcile Վճարումների հաշտեցում provider-ի, կայքի, CRM-ի, ERP-ի և ներքին հաշվետվության միջև: Կարգավիճակ Ինչպես տարանջատել API-ի, webhook delivery-ի, checkout-ի և fiscal queue-ի վիճակը:

Թե կոնկրետ ինչ է պետք ամեն օր ստուգել

Հաշտեցումը քաղվածքում մեկ գումարի որոնում չէ, այլ վճարման, պատվերի, CRM կարգավիճակի, ERP գրանցման և վերադարձի համեմատություն:

Մատակարարի հաշվետվություն -> Կայք -> CRM -> ERP — Յուրաքանչյուր վճարման կարիք ունի մատակարարի տեղեկանք, պատվերի ID, գումար, արժույթ և վերջնական բիզնես կարգավիճակ:

Եթե բիզնեսն ընդունում է առցանց վճարումներ, ապա յուրաքանչյուր աշխատանքային օր պետք է փակվի ոչ միայն բանկային քաղվածքով: Դուք պետք է հասկանաք, թե ինչ վճարումներ են կատարվել մատակարարի հետ, ինչ պատվերներ են փակվել կայքում, ինչ գործարքներ են թարմացվել CRM-ում և ինչ գրառումներ են անցել ERP կամ հաշվապահական միացում:

Հիմնական պատասխանը. ստուգման կարիք ունեն ոչ թե «գումարներն ընդհանուր առմամբ», այլ նույնացուցիչների հատուկ զույգերը: Նվազագույն հավաքածուն մատակարարի տեղեկանքն է, ներքին վճարման ID-ն, պատվերի ID-ն, գումարը, արժույթը, ստեղծման ժամանակը, վերջնական կարգավիճակը և գրանցման աղբյուրը: Եթե առնվազն մեկ ID բացակայում է, գործառնական թիմը ձեռքով կփնտրի վճարումները:

մատակարարի տեղեկանք բանկից կամ վճարումների մատակարարից.
ներքին վճարման ID-ն և պատվերի ID-ն կայքից կամ հետին պլանից.
CRM գործարք, հաշիվ-ապրանքագիր կամ առաջատար ID;
ERP փաստաթղթի ID, եթե պատվերը փոխանցվում է հաշվապահական հաշվառմանը.
վերադարձի id-ն և վերադարձման գումարը, եթե վերադարձը թույլատրվում է:

Ի՞նչ անհամապատասխանություններ են համարվում կարևոր:

Ամեն անհամապատասխանություն չէ, որ նշանակում է փողի կորուստ, բայց յուրաքանչյուրը պետք է ունենա իր տեսակը և պատասխանատուն:

Անհամապատասխանության տեսակները — Վճարված է մատակարարում, pending կայքում, բացակայում է CRM թարմացումը, գումարի անհամապատասխանություն, գումարի վերադարձ:

Ամենավտանգավոր դեպքն այն է, որ պրովայդերը հաջող է ցույց տալիս, բայց կայքը կամ CRM-ը դեռ տեսնում է pending: Հաճախորդն արդեն վճարել է, բայց պատվերը չի մշակվել, կառավարիչը ծանուցում չի ստացել, և աջակցությունը խնդրի մասին իմանում է միայն հաճախորդի խնդրանքից:

Այլ տիպիկ անհամապատասխանության դեպքեր. CRM-ի գումարը տարբերվում է մատակարարի գումարից, գումարի վերադարձը կատարվել է մատակարարի մոտ, բայց չի արտացոլվում ERP-ում, վճարումը հասել է առանց հստակ պատվերի ID-ի, webhook-ը չի հասել, և ձեռքով ուղղումը չի գրանցվել աուդիտի հետքում:

վճարովի մատակարար, կայք pending;
CRM վճարվեց, մատակարարը ձախողվեց կամ չեղարկվեց;
գումարի կամ արժույթի անհամապատասխանություն;
փոխհատուցումը հասանելի է մատակարարից, բայց ներառված չէ ներքին հաշվառման մեջ.
ձեռքով խմբագրում առանց մեկնաբանության կամ պատասխանատվության:

Ինչպես կառուցել աշխատանքային reconciliation հոսք

Օպերատորը պետք է աշխատի բացառությունների ցանկով, այլ ոչ բոլոր վճարումների ամբողջական աղյուսակով:

Ամենօրյա բացառությունների ցուցակ — Համապատասխան վճարումները փակվում են ավտոմատ կերպով. անհամապատասխանությունները դառնում են վերանայման առաջադրանքներ պատճառի և սեփականատիրոջ հետ:

Գործնական հոսքի տեսքը հետևյալն է. համակարգը բեռնում է մատակարարի տվյալները և ներքին գրառումները տվյալ ժամանակաշրջանի համար, համապատասխանեցնում է դրանք ըստ հղումների և պատվերի ID-ի, ավտոմատ կերպով փակում է համընկնումները և ավելացնում բոլոր անհամապատասխանությունները բացառությունների կարճ ցանկում:

Յուրաքանչյուր բացառություն պահանջում է տեսակ, պատճառ, սեփականատեր, մեկնաբանություն և վերստուգման արդյունք: Այնուհետև հաշտեցումը դադարում է լինել ձեռքով որոնում աղյուսակներում և դառնում է կառավարվող գործընթաց, որը կարող է փոխանցվել օպերատորին, հաշվապահական հաշվառման բաժնին կամ ինտեգրատորին:

ավտոմատ կերպով փակել ճշգրիտ համընկնումները;
անհամապատասխանությունները առանձին հերթում դնել;
գրանցամատյան ձեռքով որոշումներ և վերստուգումներ;
օգտագործել մեկ ժամային գոտու և կլորացման կանոններ.
առանձին վաճառք, գումարի վերադարձ և մասնակի վերադարձ:

FAQ

Արդյո՞ք հաշտեցումը պետք է կատարվի բանկային քաղվածքի կամ վճարման մատակարարի հաշվետվության միջոցով:

Ավելի լավ է օգտագործել երկու աղբյուրները: Մատակարարի հաշվետվությունն օգնում է համեմատել վճարման ID-ն և կարգավիճակները, իսկ բանկային քաղվածքը հաստատում է փողի շարժը և ժամանակաշրջանի փակումը:

Հնարավո՞ր է ամիսը մեկ հաշտություն անել։

Հնարավոր է, բայց մեծացնում է գործառնական ռիսկը։ e-commerce և CRM հաշիվների համար ավելի լավ է ամեն օր փակել բացառությունները, մինչդեռ հաճախորդը, պատվերը և վճարումը դեռևս հեշտ է վերականգնվել իրադարձությունների հիման վրա:

Ո՞րն է համարվում հաշտեցման լավ արդյունք:

Լավ արդյունքը ոչ թե բոլոր սխալների բացակայությունն է, այլ բացառությունների թափանցիկ ցուցակը, որտեղ յուրաքանչյուր անհամապատասխանություն ունի տեսակ, պատճառ, սեփականատեր և ուղղման պատմություն:

Sources

Stripe Documentation - Balance summary reportՊաշտոնական օրինակ այն բանի, թե ինչպես է վճարման մատակարարը կառուցում հաշվետվություններ մնացորդի և գործարքների հաշտեցման համար:
Stripe Documentation - How to select a reportԳործարքների, վճարումների և մնացորդի հաշտեցման համար հաշվետվություններ ընտրելու վերաբերյալ փաստաթղթեր:
Armeconombank - VPOSvPOS-ի պաշտոնական էջը պայմաններով, թեստային գործարկման և կայքի համար վճարման պահանջներով:

Հոդվածի ֆոկուսը

Թե կոնկրետ ինչ է պետք ամեն օր ստուգել

Ի՞նչ անհամապատասխանություններ են համարվում կարևոր:

Ինչպես կառուցել աշխատանքային reconciliation հոսք

FAQ

Sources

Կարդացեք նաև

Սպասվող վճարումներ. ինչ պետք է անի առցանց խանութը, CRM և աջակցություն

3-D Secure Հայաստանում առցանց վճարումների համար. ինչ պետք է հաշվի առնի կայքը

Փորձնական գործարկում vPOS. ստուգաթերթիկ նախքան REAL տեղափոխվելը