Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Նախ պետք է որոշել ճշմարտության աղբյուրը
Պատվերը կարող է ստեղծվել կայքում՝ CRM կամ ERP, սակայն վճարումը պետք է կապված լինի մեկ կայուն նույնացուցիչի հետ:
Նախքան 1C-ի, MoySklad-ի կամ այլ հաշվապահական համակարգի հետ ինտեգրվելը, դուք պետք է որոշեք, թե որտեղ է ստեղծվում պատվերը և ինչ նույնացուցիչն է կապում բոլոր ուրվագծերը: Եթե կայքը, CRM-ն և ERP-ն ստեղծում են առանձին փաստաթղթեր՝ առանց վճարման ընդհանուր ID-ի, ապա հաշտեցումը արագորեն վերածվում է ձեռքի աշխատանքի:
Նվազագույն մոդելը պետք է ներառի ներքին վճարման ID-ն, պատվերի ID-ն, հաշիվ-ապրանքագրի ID-ն, մատակարարի տեղեկանքը, գումարը, արժույթը, վճարվածը, ֆիսկալ կարգավիճակը և գումարի վերադարձման կարգավիճակը: Այս դաշտերը անհրաժեշտ են ոչ միայն մշակողին, այլ նաև օպերատորին, հաշվապահությանը և աջակցությանը:
- մի ստեղծեք մի քանի անկախ հաշիվներ մեկ վճարման համար.
- փոխանցել միայն ստուգված վերջնական կարգավիճակը ERP;
- խանութի մատակարարի տեղեկանք և ներքին վճարման ID.
- առանձնացնել պատվերը, վճարման փորձը, ստուգումը և վերադարձը:
Ինչպես կապել վճարումը, ստացումը և վերադարձը
Ֆիսկալ անդորրագիրը և գումարի վերադարձը պետք է լինեն առանձին իրադարձություններ, որոնք կապված են սկզբնական վճարման հետ:
Հաջող վճարումից հետո հաշվապահական հաշվառման համակարգը հաճախ պետք է ստանա ոչ միայն վճարովի կարգավիճակ, այլ նաև տվյալներ ֆիսկալ անդորրագրի, հաշվի փակման, առաքման կամ ծառայության համար: Եթե վճարման պահին չեկը ստեղծվում է համաժամանակյա, հարկաբյուջետային ծառայության ձախողումը կարող է արգելափակել հաճախորդի սկրիպտը:
Ավելի գործնական է չեկը մշակել ասինխրոն՝ վճարումը փակված է, ստեղծվում է ֆիսկալիզացիայի առաջադրանք, ստուգման արդյունքը վերադարձվում է CRM/ERP: Վերադարձը պետք է լինի նաև առանձին իրադարձություն՝ գումարով, պատճառաբանությամբ, սկզբնական վճարման հղումով և սեփական հարկային կարգավիճակով:
- ստեղծել անդորրագիր միայն հաստատված վճարումից հետո.
- չխառնել վճարովի և հարկաբյուջետային հաջողությունը մեկ կարգավիճակի մեջ.
- աջակցել մասնակի փոխհատուցմանը որպես առանձին սցենար.
- ցույց տալ օպերատորին վճարման և անդորրագրի միջև առկա անհամապատասխանությունները:
Ինչ ստուգել ամենօրյա հաշտեցման ժամանակ
ERP հաշտեցումը պետք է գտնի բացառություններ. վճարված է մատակարարից, բայց չի փակվում հաշվապահական հաշվառման մեջ կամ վերադարձվում է առանց ճիշտ արտացոլման:
Ամենօրյա հաշտեցումը պետք է համեմատի մատակարարի, կայքի, CRM-ի և ERP-ի տվյալները: Կարևոր է փնտրել ոչ միայն բացակայող վճարումները, այլև գումարի, արժույթի, չեկի կարգավիճակի, գումարի վերադարձի, ժամային գոտու և ձեռքով ճշգրտումների անհամապատասխանությունները:
Լավ գործընթացը չի ստիպում հաշվապահին վերանայել բոլոր վճարումները: Այն ինքնաբերաբար փակում է համընկնումները և ցույց է տալիս բացառությունների կարճ ցուցակը՝ պատճառի, սեփականատիրոջ և վերստուգման պատմության հետ:
- մատակարարը վճարված է, ERP չվճարված;
- ERP փակվել է, մատակարարը ձախողվել է կամ չեղարկվել;
- վճարումից հետո բացակայում է անդորրագիրը;
- փոխհատուցումը գոյություն ունի մատակարարում, բայց ոչ ERP-ում;
- ձեռքով ուղղում առանց աուդիտի հետքի:
FAQ
Հնարավո՞ր է վճարում ուղարկել 1C կամ MyWarehouse հաճախորդի redirect-ից անմիջապես հետո:
Ավելի լավ է ոչ: Backend-ը նախ պետք է հաստատի կարգավիճակը վճարման մատակարարի հետ կամ մշակի վստահելի webhook-ը, այնուհետև վերջնական իրադարձությունը ուղարկի հաշվապահական համակարգ:
Ի՞նչ պետք է անեմ, եթե անդորրագիրը չստեղծվի հաջող վճարումից հետո:
Վճարումը պետք է մնա որպես վճարված, իսկ ֆիսկալիզացիան պետք է տեղափոխվի նորից փորձի կամ ձեռքով վերանայման: Ավելի լավ է չխառնել այս ստատուսները, հակառակ դեպքում օպերատորը չի հասկանա, թե կոնկրետ որտեղ է ձախողումը։
Արդյո՞ք անհրաժեշտ է առանձին հաշտեցում ERP-ի համար:
Այո, եթե ERP-ը հաշվապահական օղակ է: Բայց հաշտեցումը պետք է լինի ընդհանուր գործընթացի մի մասը՝ մատակարար, կայք, CRM, ERP, ստուգումներ և վերադարձներ:
