Samma försäljning mot kassan betyder två olika saker för Epicor beroende på om köparen har ett konto, och Square skickar nu tillräckligt med pengar tillsammans med den för att ERP-systemet ska kunna skilja dem åt.
En tillverkares handelsdisk tar emot pengar från två typer av personer. Den ena är en entreprenör som betalar med kort och som aldrig kommer att ses igen, och den andra är en kund vars köp hör hemma på ett kontoutdrag och ibland mot ett projekt. Square registrerar båda identiskt, så dagens slutrapport går till ekonomiavdelningen och någon räknar ut vilken som var vilken utifrån minnet och ett nedklottrat namn. Kontoförsäljning missas, jobb blir underkostade. Integrationen mellan Square och Epicor skickar försäljningen med tillräckligt med kontext för att sortera sig själv, så räknaren slutar vara luckan i huvudboken.

En Square-försäljning gjord mot ett handelskonto bokförs till den kunden i Epicor, så den visas på deras kontoutdrag istället för att försvinna från dagens kassabelopp.
När en motförsäljning avser ett jobb når Square-transaktionen Epicor med jobbet bifogat, så kostnaden hamnar mot arbetet istället för att absorberas centralt.
Varor som säljs över disk tas ut från Epicor allt eftersom de överlämnas, så lagersiffran som resten av affärsplanerna använder återspeglar vad som faktiskt har gått förlorad.
Epicor når sina intäkter från Square allt eftersom, så stängningen av disken är en kontroll snarare än att någon transkriberar en utskriven sammanfattning efter att alla andra har gått.
En kollega väljer handelskontot i Square-kassan och Alumio bokför försäljningen till kunden i Epicor, så det som är utestående skulder hamnar på ett kontoutdrag medan äkta kontantförsäljningar stannar där de hör hemma i dagens intäkter.
En ingenjör samlar in delar till ett jobb och Square-försäljningen överför jobbreferensen till Epicor, så kostnaden för arbetet inkluderar det som hämtades vid disken snarare än bara det som utfärdades från butiken.
En del returneras och återbetalas via Square, och Alumio återför den i Epicor mot det belopp som den ursprungliga försäljningen omfattade, så ett jobb slutar debiteras för något som hamnade tillbaka på hyllan samma morgon.
Alumio fungerar som en central integrationsplattform mellan försäljningskanaler och logistiksystem. Order dirigeras, transformeras och valideras, samtidigt som statusuppdateringar skickas tillbaka till varje kanal.
Autentisera dina system med Alumios färdiga kopplingar. Välj bland över 200 kopplingspaket i vår marketplace, utöver obegränsade anpassade integrationer.
Definiera hur datafält mappas mellan system i ett visuellt gränssnitt. Justera format, berika poster och tillämpa affärslogik – helt utan behov av anpassad kod.
Konfigurera flöden så att de körs i realtid baserat på händelser, enligt ett schema eller både och. Minska manuell datainmatning och låt Alumio hantera förflyttning och transformering mellan system.
När din första integration är live, ansluter du enkelt ditt ERP, PIM, WMS eller CRM till samma hubb. Befintliga flöden fortsätter att köras. Ingen ombyggnad från grunden krävs.
De som frågar efter nästa anslutning sitter oftast bakom disken, och det de ber om är ett snabbare sätt att öppna ett konto. En entreprenör som köper för tredje gången den här månaden borde inte betala med kort, men att skapa dem innebär ett kreditbeslut som ingen vid disken kan fatta. Alumio har den anslutningen parallellt med denna, så en ansökan startar vid Square-kassan och svaret kommer tillbaka till Epicor.
Diskförsäljningen bokförs själva och bär det de behöver sorteras istället för att sorteras efteråt. Alumio tar Square-transaktionen med det konto eller jobb som valts i kassan och skapar matchningsposten i Epicor, så en kontoförsäljning når kunden och en kontantförsäljning når dagens intäkter. Artiklar försvinner från lagret oavsett hur, eftersom varorna har lämnat disken oavsett vem som betalade. Huruvida Epicor tar en jobbreferens på det sättet är en fråga om Epicor.
Nej, detta är konfigurerat snarare än kodat. Det är det som tas bort som dagens slutrapport som någon fyller i, och den timme som ekonomiavdelningen lägger på att omvandla den till Epicor-poster. Vilken Square-betalningstyp som mappas till vilken behandling, och hur ett konto väljs i kassan, konfigureras en gång i Alumio. Epicor-implementeringar medför lokala ändringar, så Code Transformer finns där ett fält inte mappas som det är.
Ingen, och det är rätt svar snarare än en lucka att fylla. En äkta kontantförsäljning bör förbli en kontantförsäljning i Epicor, eftersom att gissa ett konto från ett kortnamn skapar en utdragsrad som någon kommer att bestrida. Det som är viktigt är att göra kontot lätt att välja på torget medan kunden står där, eftersom en oidentifierad försäljning kostar mycket mindre att acceptera än en felaktigt identifierad.
En motförsäljning som bokförts som kontanter när den tillhörde ett konto är ett fel som är värt att upptäcka, eftersom pengarna står kvar och endast kundens utdrag är kort. Alumio övervakar varje överföring live och registrerar Square-transaktionen med Epicor-kontot eller jobbet den skickades till, så allt som vägras utlöser en varning med namn på försäljningen och orsaken. Återförsök körs där det är konfigurerat, så inga intäkter försvinner.
Prata med en integrationsspecialist på Alumio. Vi tar fram rätt arkitektur för dina system, i rätt skala, så att din verksamhet förblir stabil genom alla förändringar.