Webshopbestellingen en -betalingen van Lightspeed eCommerce komen in Oracle terecht als boekingen waarmee de financiële afdeling de maand kan afsluiten, in plaats van als een rapport dat iemand aan het einde van elke maand handmatig moet controleren.
Een webshop genereert de hele dag door verkopen en de financiële afdeling heeft deze nodig als boekhoudkundige gegevens, bij het juiste bedrijf en op de juiste rekeningen. Oracle accepteert geen verkoop waarbij niet staat bij welk onderdeel van het bedrijf deze hoort, dus uiteindelijk moet iemand dat per bestelling bepalen, meestal aan het einde van de maand, meestal aan de hand van een spreadsheet waar niemand anders inzicht in heeft. De integratie van Lightspeed eCommerce met Oracle legt deze beslissingen in één keer vast en past ze toe op alles. Elke bestelling komt binnen met een toegewezen order en de dagomzet komt overeen met wat de betalingsverwerker daadwerkelijk heeft uitbetaald.

Bestellingen die bij Oracle binnenkomen, worden direct toegewezen aan het juiste onderdeel van het bedrijf. Hierdoor is de maandafsluiting een evaluatie in plaats van een week lang uitzoeken waar alles thuishoort.
Betalingen en terugbetalingen komen tegelijk met de bijbehorende bestellingen binnen, waardoor het banksaldo en het boekhoudkundig saldo direct overeenkomen zonder handmatige vergelijking.
Een terugbetaling in de webshop wordt bij Oracle als een aftrekpost geregistreerd, waardoor de boekhouding laat zien wat er daadwerkelijk is ingehouden in plaats van een verkoopcijfer dat iemand later uit het geheugen aanpast.
De uren die je besteedt aan het kopiëren van webshopverkopen naar de boekhouding, verdien je terug, omdat elke bestelling binnenkomt met de bijbehorende klant, regels en totalen al in de vorm die het grootboek vereist.
Een bestelling wordt geplaatst in Lightspeed eCommerce en Alumio maakt de boeking aan in Oracle, gekoppeld aan het onderdeel van de organisatie dat de verkoop heeft gedaan. Zo blijven de boekhoudkundige gegevens actueel, zonder dat er telkens opnieuw hoeft te worden bepaald aan welke boeking het is gekoppeld.
De bestellingen, betalingen en terugbetalingen van die dag komen allemaal tegelijk binnen, zodat de financiële afdeling het totaalbedrag in Oracle kan koppelen aan wat de verwerker heeft uitbetaald en direct kan zien of de twee bedragen om de een of andere reden niet met elkaar overeenkomen.
Een klant krijgt een terugbetaling in de webshop en Oracle ontvangt de korting, waardoor niemand aan het einde van het kwartaal ontdekt dat de gerapporteerde verkopen nog steeds geld bevatten dat enkele weken eerder al aan een klant was terugbetaald.
Alumio fungeert als een beheerde integratie-backbone tussen verkoopkanalen en fulfillment-systemen. Orders worden gerouteerd, getransformeerd en gevalideerd, terwijl statusupdates naar elk kanaal worden teruggestuurd.
Authenticeer je systemen met de kant-en-klare connectors van Alumio. Kies uit meer dan 200 connector-pakketten in de marketplace, plus onbeperkte aangepaste integraties.
Bepaal in een visuele interface hoe datavelden tussen systemen worden gekoppeld. Pas formaten aan, verrijk records en pas bedrijfslogica toe, zonder dat er maatwerkcode nodig is.
Configureer flows zodat ze in real-time, op basis van events, volgens een schema of beide worden uitgevoerd. Verminder handmatige gegevensinvoer en laat Alumio de verplaatsing en transformatie tussen systemen afhandelen.
Zodra je eerste integratie live is, kun je je ERP, PIM, WMS of CRM eenvoudig op dezelfde hub aansluiten. Bestaande flows blijven gewoon draaien. Je hoeft niets opnieuw op te bouwen.
Een belastingdienst is een veelvoorkomende toevoeging zodra een webwinkel internationaal verkoopt, omdat het toepasselijke tarief afhangt van de locatie en de aankoop van de klant. Noch de webshop, noch de boekhouding wil die logica beheren. Beide systemen werken op dezelfde plek, waardoor het tarief dat bij het afrekenen wordt toegepast, het tarief is dat de boekhouding verwacht te zien.
Ja, en het punt dat de moeite waard is om te bepalen, is wanneer een bestelling een boekhoudkundige transactie wordt. Een winkelmandje is geen verkoop en een verzonden bestelling soms ook niet. Daarom handelt Alumio op het moment dat je de bestelling als definitief beschouwt, meestal de betaling, en verzendt de bestelling, de artikelen en de betaling samen. Terugbetalingen volgen dezelfde procedure, dus er hoeft niets handmatig te worden gecorrigeerd.
Nee, en de persoon die dit normaal gesproken instelt, werkt bij de financiële afdeling of de operationele afdeling, niet in een ontwikkelteam. Zij bepalen welke orders waar naartoe gaan en passen dit zelf aan wanneer het bedrijf een land of een merk toevoegt, zonder op iemand te hoeven wachten. Voor die ene regel die echt niet in een formulier beschreven kan worden, is er de Code Transformer.
Op het moment dat je besluit dat het wel degelijk nodig is, is het de moeite waard om die beslissing bewust te nemen. Sommige bedrijven registreren een verkoop wanneer deze betaald is, andere wanneer deze verzonden is, en het verschil is daarna zichtbaar in elke maandelijkse vergelijking. Oracle moet ook weten bij welk onderdeel van het bedrijf de verkoop hoort voordat deze überhaupt wordt verwerkt, zodat die toewijzing eenmalig wordt ingesteld in plaats van dat er per order over gediscussieerd wordt.
Het in evenwicht brengen van de rekeningen, afgezien van de kosten voor de verwerker, is de fout die een middag in beslag neemt, omdat alle bestellingen er wel zijn, maar het totaalbedrag nog steeds niet klopt. Alumio houdt elke transactie live bij en registreert de bijbehorende bedragen. Wanneer Oracle een transactie niet accepteert, wordt iemand direct op de hoogte gesteld en wordt de oorzaak uitgelegd. Indien geconfigureerd, worden er herhaalpogingen gedaan, zodat geen enkele verkoop ongemerkt blijft.
Spreek met een Alumio-integratiespecialist. Wij brengen de juiste architectuur voor jouw systemen in kaart, op de juiste schaal, zodat je bedrijfsactiviteiten bij elke verandering betrouwbaar blijven.