OrderIn de orderflow maken we onderscheid tussen ordersoorten. Aan de verzendkant heeft dit meestal te maken met waar we ons in het proces bevinden en wat de gegevens zijn die nodig zijn in deze stap. In het geval dat we een orderstroom “functioneel” onderzoeken, beginnen we met:
- de offerte naar de klant.
- Als de klant deze offerte goedkeurt, kan deze worden omgezet in een Order.
- Als de bestelling is geaccepteerd en gepickt, kan de klant worden gefactureerd.
- Nadat de factuur is goedgekeurd, wordt een financiële mutatie aangemaakt in het bijbehorende grootboek.
Dit is in feite het complete proces van een orderstroom. Binnen APIcenter bepalen we in welke fase we onze “bestelgegevens” willen toevoegen en zijn er functioneel een paar differentiaties om het in het juiste formaat te plaatsen.
Welke ordertypes beschikbaar zijn, hangt af van de combinatie van applicaties die u gebruikt.
"Citaat"
Als een applicatie offertes via de api ondersteunt, gebruiken we de brongegevens en maken we een offerte in de doelsystemen. Logische integraties hiervoor zijn CRM-pakketten waarbij de klant een offerte uit het CRM ontvangt en Finance die gegevens in zijn ERP wil hebben. Of de klant heeft een offerte aangevraagd in zijn e-commercesysteem en wil deze voor opvolging naar zijn CRM-systeem sturen.
- Productgegevens moeten worden gesynchroniseerd tussen beide systemen. Als een product niet bestaat, gooien we een fout in het validatieproces.
"Order"
De meeste van de integraties die we maken zullen gebruik maken van het Ordertype “Order”. Als een bestelling in een webshop wordt geplaatst en betaald, moet deze naar het ERP en het magazijnsysteem worden gestuurd om te worden opgevolgd. Klanten worden gefactureerd vanuit het ERP-systeem. Logische integraties zijn E-commerce naar ERP- of POS-systemen, maar ook CRM-systemen die de status gewonnen hebben en hun offerte willen omzetten naar een order in het ERP-systeem.
- Productgegevens moeten worden gesynchroniseerd tussen beide systemen. Als een product niet bestaat, gooien we een fout in het validatieproces.
"Factuur"
Er zijn ERP-systemen die een aparte factuur-API ondersteunen, waarbij we een factuur in het systeem maken. Dit is normaal gesproken de stap nadat een bestelling is gemaakt en gepickt/verpakt. Over het algemeen leidt dit niet tot een voorraadmutatie in het doelsysteem, aangezien we de gegevens posten nadat dit normaal gesproken is gebeurd.
- Productgegevens moeten worden gesynchroniseerd tussen beide systemen. Als een product niet bestaat, gooien we een fout in het validatieproces.
“Directe factuur”
Er zijn ERP-systemen die een aparte Direct factuur API ondersteunen. Een directe factuur is vergelijkbaar met een contante bestelling en handmatige transactie met de klant. Er is materiaaloverdracht en directe betaling. Dit zou de voorraad moeten aanpassen en direct de bijbehorende boeking in het grootboek moeten creëren. U kunt aangeven dat het een combinatie is van bestellen/picken en factureren in één keer.
- Productgegevens moeten worden gesynchroniseerd tussen beide systemen. Als een product niet bestaat, gooien we een fout in het validatieproces.
"Verkoopfactuur"
Een verkoopfactuur verschilt van de normale factuur doordat er geen artikelen nodig zijn om een factuur te maken. De boekhouding wordt gemaakt op basis van standaard gedefinieerde waarden in het doelsysteem en meestal door de waarden die op de klant zijn ingesteld. Dit wordt meestal gebruikt tussen systemen die geen producten beheren en bijvoorbeeld diensten verkopen. De meeste integraties die hiervan gebruik maken, zijn tussen CRM-systemen en ERP-systemen. Zolang de verzendzijde de verkoopfactuur ondersteunt, kan deze met elke combinatie van integraties werken.
- Productgegevens zijn niet nodig bij dit type boeking, we maken een regel zonder artikel / sku erop
"Financiële mutatie"
Dit is normaal gesproken de laatste stap in het proces en dat is de daadwerkelijke aanpassing in het grootboek. Via deze manier maak ik direct een boeking aan in het grootboek, als een financiële mutatie ondersteund wordt differentiëren we in het type mutatie die we doen we maken een verschil in de complexiteit:
- Gemakkelijk; dit is een boeking die de hoogste omzet van de klant is, dus bijvoorbeeld
- Aanbevolen; dit is een boeking waarbij we de inkomsten splitsen in een belastinggedeelte en een inkomstengedeelte
- Geavanceerd; we splitsen ook de waarde op per "kosten" omzetregel zoals verzendkosten / vergoedingen etc
- Extreem; in zijn geval zal er per regelitem een regel in de financiële mutatie zijn, dit wordt niet aanbevolen omdat deze mogelijke problemen veroorzaken met het balanceren van de mutaties vanwege het berekeningsverschil tussen bron- en doelsystemen
Productgegevens zijn niet nodig bij dit type boeking, we maken een regel zonder artikel / sku erop