hvordan fakturere LMS kurspåmeldinger fra WooCommerce automatisk

hvorfor LMS-registrering og fakturering faller ut av synkronisering etter utsjekking

Team som selger nettkurs gjennom WooCommerce pluss LearnDash, Tutor LMS eller LifterLMS deler ofte oppfyllelsen på tre pulter. Checkout fanger opp betalingen. Noen i drift åpner bestillingen, kopierer kjøperens e-post til LMS-listen og tildeler kursproduktet som tilordnes en betalt SKU. Separat skriver finans den samme kjøperen inn i Fakturownia, wFirma, Comarch Optima eller en annen faktureringsstabel fordi butikkkvitteringen ikke er en skattefaktura i landet deres. Den doble oppføringen er der seter blir gitt uten dokument, eller dokumenter blir utstedt til feil VAT-ID mens studenten venter på tilgang. Feilmodus er ikke sjelden. Bunt SKU-er som låser opp to kurs, bedriftsseter kjøpt av en innkjøpssjef for fem ansatte, og fornyelsesordrer på abonnementsprodukter, bryter alle naive "én ordrelinje tilsvarer én registrering"-antakelser. Refusjon og delvis refusjon gjør det verre: LMS viser fortsatt aktiv tilgang mens regnskap allerede har utstedt en korrigerende faktura, eller det motsatte skjer og studenten mister tilgang før finans stenger kreditnotaen. Support bruker deretter ettermiddagen på å avstemme tre systemer som aldri har delt en korrelasjons-ID. Manuelle regneark skjuler forsinkelsen frem til en kohortstartdato. Hvis femti påmeldinger lander på en kampanje mandag morgen, kan ikke driften holde tritt med betalte bestillinger, så studentene sender en e-post med «Jeg betalte, hvor er kurset mitt» mens finans fortsatt samler fakturaer på fredag. Forretningsrisikoen er tilbakeføringer og tilbakeføringslignende tvister når kjøperen kan bevise betaling, men ikke kan bevise at tilgang ble gitt innen et rimelig tidsrom. Automatisering er berettiget når påmeldingsvolumet jevnlig overstiger det én person kan klarere samme dag uten feil, og når fakturanummerering skal være kontinuerlig for skattekontoret. Kursskapere snubler også når et gratis blymagnet-kurs ligger ved siden av betalte kull i samme LMS. Personalet gjenbruker ved et uhell den betalte produktkroken for gratis SKU, som enten fakturerer null-verdi tulldokumenter eller registrerer betalte studenter i feil dryppsekvens. Et annet hyppig gap er instruktørledede kull med en fast startdato: studenter kan betale uker for tidlig, så tilgang bør planlegges i stedet for å åpnes umiddelbart, mens finans fortsatt trenger fakturaen på betalingsdatoen. Denne delingen mellom regnskapsdato og tilgangsdato må kodes eksplisitt, ellers oppfinner støtten engangsunntak hver lansering. Lokalisering har betydning for mva. En polsk kjøper med en gyldig NIP forventer en skattefaktura formet for skattekontoret, mens et EU MVA-registrert selskap kan trenge omvendt betalingsanmerkninger. Hvis automatiseringen alltid sender ut et dokument i standardkvittering, gjør finans arbeidet på nytt for hånd og mister tilliten til køen. Registrer skatteklasse og kjøpertype i kassen, send dem gjennom uendret, og nekt å finne opp landregler i LMS-pluginen.

når en betalt WooCommerce-bestilling skal opprette en LMS-registreringsfaktura

Utløs arbeidsflyten når en WooCommerce-bestilling når en betalt status som butikken din behandler som endelig for digitale varer: vanligvis behandlet eller fullført, avhengig av om du holder virtuelle bestillinger i behandling til fullføringskrokene er ferdige. Lytt også etter betalinger for fornyelse av abonnement hvis kurset selges som et WooCommerce-abonnementsprodukt, og for manuelle vekslinger av adminstatus fra på vent til behandling etter at en bankoverføring er slettet. Ikke registrer eller fakturer på ventende eller mislykkede betalinger. For B2B-kassefelt, vent til validering av MVA-ID har lykkes eller er eksplisitt frafalt av en medarbeiderrolle, ellers vil du fakturere et plassholder firmanavn som finans må annulleres senere. Inkluder delvis registreringer fra betalingsgatewayer bare når butikkkonfigurasjonen din behandler bestillingen som betalt for digital levering. Ignorer ordrenotater og kundenedlastingstillatelse veksler som utløsere; de er for støyende. Hvis du bruker en læringsplattform utenfor WordPress som fortsatt fakturerer gjennom WooCommerce, behandler den eksterne registrerings-APIen som LMS-trinnet, men beholder den samme betalte statusporten.

hvordan registrere studenten og utstede fakturaen i én automatisering

1. Tilordne hver betalte ordrelinje til en LMS-kurs eller gruppe-ID ved å bruke en vedlikeholdt SKU-tabell, inkludert pakkeforeldre som utvides til flere kurs-IDer og seteantall for bedriftsprodukter.
2. Opprett eller oppdater studentbrukeren i WordPress, legg ved påmeldingen eller gruppemedlemskapet, og lagre WooCommerce-ordre-IDen pluss linjeelement-ID på LMS-registreringsmetaen slik at refusjoner kan reversere samme plass.
3. Bygg fakturaens nyttelast fra faktureringsfelt, MVA-ID og skatteklasse; send den til Fakturownia, wFirma, Optima eller ditt regnskaps-API; skriv eksternt fakturanummer og PDF-URL tilbake til bestillingsmeta.
4. Send studenten en enkelt melding med e-post som inkluderer kurspåloggingslenken og fakturavedlegget eller sikker nedlasting, med samme korrelasjons-ID i både LMS og regnskapslogger.
5. Ved refusjon eller abonnementsavslutning webhooks, tilbakekall eller planlegg-avslutt registreringen i henhold til retningslinjene, be om en korrigerende faktura eller kreditnota, og varsle finans hvis det eksterne dokument-APIet avviser korrigeringen.
6. Sett en nattlig avstemming i kø som viser betalte digitale bestillinger som mangler enten en registreringsmetanøkkel eller et fakturanummer, slik at operasjoner kan fjerne unntak før neste kohort-e-post.
7. Når tilgang må vente på en kohortstartdato, skriv en planlagt handlingsplanleggerjobb som gir LMS-setet ved starttidsstempelet mens du fortsatt utsteder fakturaen ved betaling.

dataflyt fra WooCommerce-betaling til LMS-sete og regnskapsdokument

WooCommerce er fortsatt den kommersielle kilden til sannhet for betalingsstaten. En webhook eller Action Scheduler-jobb legger inn ordre-ID-en til n8n eller en tilpasset PHP-lytter. Lytteren laster inn linjeelementer, løser SKU-til-emne-tilordninger fra en alternativtabell eller Google Sheet speilet inn i wp_options, og kaller LMS-registrerings-API- eller LearnDash-gruppekoblingsfunksjonene inne i WordPress når det er mulig, slik at funksjonskontroller forblir lokale. Fakturaoppretting overlater vanligvis WordPress: REST til Fakturownia eller wFirma for polske enkeltpersonforetak og små selskaper, eller en køeksport til Comarch Optima / enova når regnskapsteamet nekter skyfaktura SaaS. Foretrekker n8n når økonomisystemer endres ofte; foretrekker Action Scheduler pluss en liten plugin når du må holde hemmeligheter og påmeldinger inne i WP runtime. Hver hop skriver den samme order_id og en generert fulfilment_id inn i logger slik at støtte kan søke etter én nøkkel på tvers av LMS, butikk og regnskap. Vedvarende en oppfyllelsesstatusmaskin på bestillingen: betalt_mottatt, registrert, fakturert, varslet, avstemt_ok. Utsett disse tilstandene for en enkel adminlistetabell slik at operasjoner ikke trenger n8n-tilgang. Når Optima er involvert, skriver mange lag en iscenesettelsestabell som Optima-integratoren poller; ikke blokker studentmailen på Optimas batchvindu. Merk i stedet invoiced_pending_erp og la finansiere fullstendig nummerering, mens du fortsatt viser studenten en kommersiell bekreftelse. Persondata følger Datatilsynet-krav i databehandleravtalen med integrasjonsleverandøren. Regnskapssystemet kan være Tripletex, Fiken eller et ERP i stedet for kun et faktura-SaaS.

hva du skal gjøre når registreringen lykkes, men invoice API mislykkes

Hvis LMS-registreringssamtalen mislykkes etter betaling, ikke utsted fakturaen ennå; prøv på nytt med backoff, åpne deretter et Slack- eller e-postvarsel med bestillingslenken og la bestillingen være i en tilpasset "oppfyllelsesfeil"-status slik at dashboards i lagerstil også kan se digitale feil. Hvis registreringen lykkes og faktura-API-en returnerer 4xx på grunn av en dårlig VAT-ID, behold setet, flagg bestillingen meta invoice_error og vei til finans uten å blokkere studenten. Hvis faktura-API-en lykkes, men PDF-hentingen mislykkes, lagrer du den eksterne IDen og prøver å laste ned PDF på nytt separat. Dead-letter enhver jobb som er eldre enn din SLA, og aldri autoregistrer deg på en annen betalingswebhook for samme order_id uten en idempotensnøkkel. Dupliserte webhooks fra gatewayen er normalt. Gate hver sideeffekt på en idempotenspost tastet inn av order_id pluss evnenavn (registrering kontra faktura). Hvis en student allerede har livstidstilgang til kurset fra et tidligere kjøp, hopper du over gjenregistrering, men fakturerer fortsatt den nye kommersielle bestillingen hvis det er en separat betalt SKU, for eksempel coaching-tillegg. Dokumenter grenen slik at støtte ikke behandler hoppet påmelding som en feil.

når manuell LMS-fakturering fortsatt er billigere enn automatisering

Hopp over dette bygget når du selger færre enn omtrent tjue kursseter i måneden, utsteder fakturaer for hånd på under ti minutter hver, og aldri kjører kohortlanseringer som øker volumet. Hopp også over når hvert salg er en tilpasset bedriftskontrakt som allerede er fakturert i Optima før LMS-setet er gitt av en kontoansvarlig. Automatisering som bekjemper en menneskeforhandlet faktureringsprosess skaper dupliserte dokumenter og sinte finansteam. Bedriftslæringsavdelinger som fakturerer via årlige rammeavtaler i enova og kun bruker WooCommerce som katalogfront, bør ikke tvinge per-sete butikkfakturaer gjennom denne flyten. Bruk en hånd-off til å finansiere i stedet for falske detaljhandelsdokumenter.

KPIer for LMS-registreringsfaktureringsautomatisering

• Median minutter fra betalt ordre til LMS-registrering meta skrevet
• Andel av betalte digitale bestillinger med både registrerings-ID og fakturanummer innen 24 timer
• Antall bestillinger med oppfyllelsesfeil som er eldre enn din støtte-SLA
• Refusjoner der tilgangen forble aktiv mer enn én time etter kreditnota