Ja veikala pasūtījumi, maksājumi un krājumi grāmatvedībā nonāk ar roku, katrs pasūtījums tiek ievadīts divreiz. Kļūdas rodas nevis tāpēc, ka darbinieki ir neuzmanīgi, bet tāpēc, ka divu sistēmu pārrakstīšana ir tieši tas darbs, kurā cilvēks kļūdās.
Šis raksts ir par to, kā plānot veikala un Moneo sinhronizāciju: kādi dati jāpārsūta, kā izvēlēties virzienu un kas jānoskaidro pirms projekta.
Kas jāsinhronizē un kurā virzienā
Starp interneta veikalu un grāmatvedības sistēmu ir trīs galvenās datu plūsmas:
- Pasūtījumi no veikala uz Moneo. Pasūtījums kļūst par rēķinu vai pārdošanas dokumentu, klients tiek atrasts vai izveidots.
- Maksājumi uz Moneo. Kad maksājums saņemts (karte, bankas pārskaitījums), tas jāsaista ar dokumentu, lai rēķins tiktu atzīmēts kā apmaksāts.
- Krājumi un cenas no Moneo uz veikalu. Ja preču kartītes un atlikumi tiek uzturēti grāmatvedībā, veikalam jāzina, cik preču ir pieejams.
Ieteikums ir sākt ar vienu virzienu un paplašināt tikai tad, ja bizness to prasa. Tas samazina risku un ļauj ātrāk redzēt rezultātu. Līdzīgu pieeju aprakstām rakstā par Jumis un WooCommerce integrāciju.
Kuram datu laukam kura sistēma ir patiesības avots
Pirms koda jāizlemj, kur dzīvo katrs lauks. Ja abas sistēmas drīkst mainīt vienu un to pašu lauku, agri vai vēlu rodas konflikts. Praktisks sadalījums:
| Dati | Parasti avots |
|---|---|
| Preču kartītes, artikuli | Grāmatvedība (Moneo) |
| Atlikumi | Grāmatvedība vai noliktavas sistēma |
| Cenas | Grāmatvedība, ja cenu saraksti ir tur; veikals, ja tās ir tikai tīmeklī |
| Pasūtījumi, groza dati | Veikals |
| Rēķini, maksājumu statusi | Grāmatvedība |
Tas ir sākumpunkts, nevis noteikums. Ja jūsu process ir citāds, to izlemj kopā ar grāmatvedi un pārdošanas vadītāju.
Pasūtījums kļūst par rēķinu: kas jāparedz
Pasūtījuma nodošana grāmatvedībai nav tikai kopēšana. Jāparedz:
- Klients. Vai tas jau pastāv Moneo? Pēc kā to atpazīt: reģistrācijas numurs, e-pasts? Kā rīkoties ar privātpersonām.
- PVN un valstis. Cena ar PVN vai bez, citu ES valstu klienti, atbrīvojumi.
- Atlaides, piegāde un papildizmaksas. Tās kļūst par atsevišķām rindām dokumentā vai tiek iekļautas cenā.
- Atcelšana un atgriešana. Ja pasūtījums tiek atcelts vai preces atgrieztas, jāizveido kredītrēķins. To bieži aizmirst projektēšanā.
Maksājumi: kā rēķins uzzina, ka klients samaksājis
Kartes maksājumi apstiprinās reāllaikā, bankas pārskaitījumi nāk ar kavēšanos, bet rēķini ar atliktu maksājumu tiek apmaksāti nedēļas vēlāk. Katram maksājuma veidam vajag savu noteikumu: kad pasūtījums tiek nodots, kad rēķins tiek atzīmēts kā apmaksāts un kas notiek ar daļējiem maksājumiem.
Ja maksājumu piegādātājs un grāmatvedība neapzinās vienu un to pašu pasūtījuma numuru, saskaņošana pārvēršas par mēneša beigu darbu. Tāpēc vienmēr izmantojiet vienu savstarpēji redzamu atsauci.
Krājumi: kā nepārdot vienu preci divreiz
Ja atlikumi tiek atjaunināti reizi dienā, veikalā var pārdot preci, kuras vairs nav. Biežāka atjaunināšana samazina risku, bet pilnīgi to novērš tikai tad, ja veikals rezervē krājumu pasūtījuma brīdī. Šie scenāriji jāizspēlē iepriekš: “kas notiek, ja diviem pircējiem vienlaikus paliek viena vienība?”
Ja noliktavā ir vairākas atrašanās vietas vai preces tiek pārdotas arī veikalā, krājumu avotam jābūt vienam, un veikals tikai rāda rezultātu.
Kas jānoskaidro par Moneo pirms projekta
Datu apmaiņas iespējas ir atkarīgas no jūsu Moneo versijas un moduļiem. Trešās puses izdevumu rīka dokumentācija, piemēram, apraksta ārējo API kontu izveidi Moneo integrācijas modulī un API atslēgas izsniegšanu (CostPocket), taču tas attiecas uz izdevumu dokumentiem, nevis veikala pasūtījumiem. Tāpēc pirms projekta mēs noskaidrojam:
- kuras Moneo versijas un moduļi jums ir un kādas datu apmaiņas iespējas tie dod;
- kuri dokumentu veidi jāveido automātiski (rēķins, pavadzīme, kredītrēķins);
- kas atbild par Moneo pusi, ja nepieciešama piegādātāja palīdzība;
- cik pasūtījumu dienā un cik atjauninājumu sinhronizācijai jāiztur.
Ja kāda iespēja nav pieejama, veidojam starpslāni, kas pārvērš datus formātā, kuru sistēma pieņem.
Kļūdas un uzraudzība
Sinhronizācija bez uzraudzības agri vai vēlu rada neatklātas kļūdas. Nepieciešams:
- kļūdu žurnāls, kurā redzams, kurš pasūtījums netika nodots un kāpēc;
- atkārtota apstrāde, lai neveiksmīgu darījumu varētu palaist vēlreiz bez dublikāta;
- paziņojums, ja integrācija apstājas;
- rindas loģika, lai pasūtījumi nepazustu, kad grāmatvedība ir īslaicīgi nepieejama.
Mēs šādas lietas ierakstām prasībās jau sākumā, jo vēlāk pievienot tās ir dārgāk.
Kā projekts parasti norit
Integrācijas projektu mēs sadalām posmos, lai katrā varētu pārbaudīt rezultātu:
- Analīze. Izpētām procesu, datu laukus, dokumentu veidus un iespējas, ko dod jūsu Moneo versija.
- Noteikumi. Vienojamies, kurš lauks kam pieder, kā atpazīt klientus un kā apstrādāt izņēmumus.
- Testa vide. Pārbaudām plūsmu ar testa pasūtījumiem, tostarp atcelšanu un atgriešanu.
- Palaišana ar uzraudzību. Sākumā pasūtījumus pārbauda cilvēks, pēc tam ieslēdzam automātisku apstrādi.
- Uzturēšana. Sistēmas mainās: jauna Moneo versija, jauns maksājumu veids, jauns pārvadātājs. Integrācijai jābūt kādam, kas to uztur.
Ja jums nav tehniskās komandas, ļoti svarīgs ir pēdējais punkts. Integrācija, kuru neviens neuztur, agri vai vēlu pārstāj darboties.
Lēmuma noteikums
- Ja pasūtījumu ir maz un tos var ievadīt ar roku bez kļūdām, integrācija vēl nav steidzama. Sāciet ar procesa sakārtošanu.
- Ja pasūtījumi tiek pārrakstīti ik dienu un kļūdas rada nepatīkamus labojumus, sāciet ar pasūtījumu nodošanu grāmatvedībai.
- Ja problēma ir preču atlikumi, sāciet ar krājumu sinhronizāciju no grāmatvedības uz veikalu.
Ja jūsu grāmatvedība ir Moneo un veikals vai CRM nerunā ar to, apskatiet mūsu pieeju CRM un ERP integrācijām un interneta veikalu izstrādei. Apspriest integrāciju.
Avoti
- CostPocket: Moneo integration, trešās puses dokumentācija par Moneo ārējiem API kontiem
