hvordan synkronisere woocommerce-ordrer til en erp uten å skrive på nytt

hvorfor woocommerce-ordrer fortsatt skrives inn på nytt i erp

Finance åpner fortsatt WooCommerce, kopierer ordrenummeret til Comarch Optima, enova365 eller Subiekt GT, og skriver inn NIP, leveringsadresse og hver linje på nytt. Denne rutinen bryter i det øyeblikket en kunde redigerer fraktmetoden etter betaling, en delvis refusjon lander, eller en bunt-SKU i butikken ikke eksisterer som et kort i ERP. Regnearkbroen som fungerte på femti bestillinger i måneden, kollapser med noen hundre: to personer redigerer den samme CSV-en, mva-satsene skiller seg, og lageret velger fra en status som regnskapet aldri ble publisert. Den dypere kostnaden er ikke skrivetid. Det er omstridte fakturaer, lager som ERP mener er gratis mens butikken allerede har solgt det, og månedsavslutninger som venter på at et menneske skal avstemme betalingsgateway-avgifter med dokumentnummerering. Byråer som kobler butikker under NDA ser det samme mønsteret gjentatte ganger: butikken er den kommersielle fronten, ERP er den juridiske hovedboken, og ingenting pålitelig sitter mellom dem bortsett fra stammekunnskap om hvilket tilpasset felt som betyr hvilket lager og hvilken betalingsmåte som er knyttet til hvilket kasseapparat. Uten en automatiseringskontrakt mangler du også idempotens. Oppdatering av takkesiden eller et gjenforsøk med webhook oppretter et andre ERP-dokument for samme WooCommerce ID. Personalet annullerer deretter dokumenter for hånd, noe som skaper revisjonsstøy og bryter sekvensielle nummereringsregler som noen regnskapsførere behandler som hellige. Flerspråklige B2B-butikker gjør det verre: faktureringsselskap på bestillingen er en MVA-gruppe, sending til er en filial, og ERP forventer begge som koblede entreprenører før en salgsordre kan legges inn. Markedsordrer videresendt til WooCommerce legger til enda en ekstern ID som må forbli korrelert slik at returer finner det riktige skattedokumentet. Valuta- og skattekantsaker hoper seg opp. En EUR-kasse mot et PLN-selskap i Optima trenger en eksplisitt kurskilde og postingsdato. Redusert moms på bøker eller mat på ett sted må ikke stille fall tilbake til standardsatsen fordi skatteklassestrengen i WooCommerce ble omdøpt under en temaopprydding. Frakt som egen avgiftspliktig tjeneste kontra frakt bakt inn i linjen totalt endrer hvordan enova forventer dokumentskjemaet. Gavekort, butikkkreditt og påfyll av lommebok må ofte aldri skape lagerbevegelser, men de trenger fortsatt et finansielt dokument, eller de forsvinner fra inntektsrapporter. En holdbar løsning behandler den betalte WooCommerce-ordren som en hendelse, kartlegger SKU-er og skatteklasser eksplisitt, skriver ett ERP-dokument per butikkordre-ID og speiler statusendringer tilbake slik at support aldri lover en forsendelse som hovedboken ikke har akseptert. Det er gapet denne brukssaken lukker: ikke et fancy dashbord, men en pålitelig overlevering fra handlekurv til regnskapsdokument med tydelig eierskap når kartlegging mislykkes og en avstemmingsbane når webhooks ble savnet over natten. Operatør-runbooks bør navngi personen som eier SKU-skattekart, personen som sletter dead-letter-ordrer, og eskaleringsbanen når en regnskapsperiode er stengt i ERP. Høysesongøvelser som gjengir gårsdagens betalte bestillinger til et sandkasseselskap i Optima eller enova fanger kartleggingsdrift før den treffer direkte dokumentnummer. Hold en skriftlig matrise over betalingsmåter til kasseapparater slik at en ny gateway ikke stille inn i feil kassa.

når en betalt woocommerce-ordre skal opprette et erp-dokument

Fire på WooCommerce `order.paid` eller `payment_complete`, og igjen på `order.updated` når leveringsadresse, ordrelinjer eller status flyttes etter den første vellykkede ERP-skrivingen. Planlegg også en femten-minutters avstemming som viser betalte bestillinger som mangler en ERP-dokument-ID for meta, som dekker webhook-avbrudd og admin-skapte bestillinger. Ikke utløs på "venter" eller "på vent" med mindre policyen din bestiller reservasjoner før fangst; de fleste polske og DACH-forhandlere venter på innhentet betaling, slik at Optima eller enova ikke oppretter fordringer som aldri klareres. Abonnementsfornyelser bør bruke fornyelsesordre-IDen som korrelasjonsnøkkel, ikke den overordnede abonnements-IDen alene.

trinn for å kartlegge woocommerce-ordrelinjer til erp-salgsdokumenter

1. Bekreft bestillingen: obligatoriske faktureringsfelt, NIP- eller VAT-ID-format for B2B, valuta tillatt av ERP-selskapet, og hver linje-SKU som finnes i kartleggingstabellen. Avvis med en strukturert feil hvis et gavekort eller en virtuell linje ikke har noen ERP-artikkel og policyen din forbyr stille hopp. Registrer valideringsfingeravtrykket slik at identiske gjenforsøk kortslutter.
2. Opprør entreprenøren i ERP. Match på NIP først, deretter e-post, og opprett deretter med faktureringsadresse. Legg ved forsendelsesadresse som sekundæradresse når Subiekt eller Optima modellerer filialer separat fra den lovlige kjøperen. Behold WooCommerce kunde-ID som en ekstern nøkkel for senere deduplisering.
3. Bygg salgsdokumentet: kartlegg ordrelinjer, avgiftssatser, frakt som servicelinje eller fraktfelt, kuponger som rabatter med samme avgiftsbehandling som butikken brukte, og betalingsmåte til ERP-kasseapparatet eller bankkontokoden. Inkluder markedsplassavgifter som kostnadslinjer bare når finans ber om dem på samme dokument.
4. Post eller lagre dokumentet i henhold til selskapets regler, lagre ERP-dokumentnummeret og den interne IDen i WooCommerce-ordremeta, og merk en synkroniseringstilstand for «posted», «draft» eller «needs_mapping» slik at brukerstøtten kan se det uten å åpne ERP. Send ut en intern hendelse for lager- eller WMS-lyttere.
5. Ved senere refusjoner eller kanselleringer oppretter du den samsvarende kreditnotaen eller kansellerer dokumentet knyttet til den originale ERP-ID-en. Oppfinn aldri et nytt salgsdokument for en refusjonshendelse. Skyv ERP-dokumentstatus tilbake til en egendefinert bestillingsstatus eller -notat når lagerkontering er fullført, inkludert delvise oppfyllinger når ERP støtter dem.

hvordan webhooks n8n og erp apis bærer bestillingens nyttelast

Foretrekk WooCommerce webhooks inn i n8n for nesten sanntidsoverlevering, med Action Scheduler eller WP-Cron som et sikkerhetsnett når webhook-endepunktet var nede. n8n holder kartleggingstabellene, gjenforsøk og dødbokstavkøen; direkte tilpasset PHP er greit for et enkelt Optima-selskap med stabile SKU-er, men det eldes dårlig når du legger til enova for en andre juridisk enhet. Nyttelastformen er butikkordre JSON normalisert til en intern DTO: kjøper, linjer, avgifter, betalinger og korrelasjons-ID-er. ERP-koblingen snakker da Optima API, enova webtjenester eller en Subiekt partner API eller SQL-prosedyre - velg én kobling per bedriftskode og del aldri tokens på tvers av selskaper. Hemmeligheter bor utenfor WordPress-databasen i automatiseringsvertshvelvet. Status tilbakeringinger fra ERP, når tilgjengelig, oppdater kun ordremeta; de finner ikke opp nye butikkordrer. Google Regneark er akseptabelt som et operatørsyn på feil, ikke som registreringssystemet. For høyt volum, batch avstemmingsskanningen, men behold den betalte bestillingsbanen ett dokument om gangen for å bevare idempotensnøkler. Hold behandlingsprotokoll i tråd med Datatilsynets forventninger når personopplysninger flyter.

hva du skal gjøre når erp avviser en woocommerce-ordresynkronisering

Klassifiser feil: validering (dårlig NIP, manglende SKU), transport (timeout, 429) og forretningsavvisninger (entreprenør blokkert, periode stengt). Valideringsfeil åpner en Slack- eller e-postbillett med bestillingslenken og prøv aldri på nytt før kartleggingen er fikset. Transportfeil prøver på nytt med eksponentiell backoff og jitter opp til et begrenset antall, deretter død bokstav. Business avviser fryse bestillingen i `needs_erp_review` og varsle finans; ikke fortsett å hamre en stengt regnskapsperiode. Skriv alltid nøkkelen med WooCommerce-bestillings-ID, så gjenforsøk forblir idempotente. Logg forespørsels- og svar-hasher uten å lagre fullstendige kortdata eller rå PESEL hvis det noen gang vises i egendefinerte felt. Hvis ERP-en godtok dokumentet, men butikken ikke klarte å lagre meta, må en avstemmingsjobb oppdage det foreldreløse ved å søke i ERP etter den eksterne ID-en i stedet for å legge ut på nytt. Få en ukentlig oppsummering av døde bokstavers alder slik at stille køer ikke råtner på en måned.

når manuell erp-inntasting fortsatt er billigere enn ordresynkronisering

Under omtrent åtti betalte bestillinger i måneden med en enkelt SKU-liste som aldri endres, kan en utdannet kontorist i Optima fortsatt være billigere enn å bygge og overvåke koblinger. Hopp også over hvis ERP-prosjektet er midt i migrering og dokumentskjemaer endres ukentlig - du vil automatisere kaos. Ren dropshipping hvor leverandøren fakturerer kunden direkte trenger ofte en annen dokumentflyt enn en klassisk salgsordre i Subiekt, så ikke tving dette mønsteret inn på den modellen.

kpis som viser woocommerce til erp sync er sunt

• Median minutter fra payment_complete til ERP-dokument-ID lagret på bestillingen
• Andel av betalte bestillinger eldre enn én time uten ERP-dokument-ID
• Antall dupliserte ERP-dokumenter sporet til samme WooCommerce-ordre-ID per måned
• Andel av synkroniseringsforsøk som ender med need_mapping versus posted