Order to Invoice Data Flow — Navision Integration¶

Purpose: Document the complete data flow from customer order placement through invoice generation, showing all touch points with Navision/K3 and external systems.

Scope: Zwerfkei Old (legacy) order processing pipeline — from webshop order to Navision, to fulfillment, to invoice.

Complete Order Lifecycle Overview¶

graph TD
    Start["Customer Initiates Order"]
    Start -->|"Medewerkker or Klant
online plaatst bestelling"| OrderFlow

    OrderFlow["Order Created in Webshop"]
    OrderFlow --> MetaFile["Metafile door
webshop"]
    MetaFile --> OrderCheck{"Order wordt
aangepast?"}

    OrderCheck -->|"Ja: Medewerkker
aanpassing"| Adjustment["Adjustment of
volledig nieuw"]
    Adjustment --> Backend1["BACKEND ORDER
Orderstatus: Concept
Nieuw plichttaar"]

    OrderCheck -->|"Nee"| Backend1

    Backend1 --> Payment["Betaling en
plaats via PayPal"]
    Payment --> PayPalProcess["PAYPAL
Betaaldracht
post_dan wel negeer"]

    PayPalProcess --> K3Sync["K3 Sync Controller"]
    K3Sync --> Backend2["BACKEND
Order Status: Definitief
Zichtbaar"]

    Backend2 --> Magazijn["TOUCH MAGAZIJNBON
overzicht van
operationande artikelen"]

    Magazijn --> Werknemers["Werknemers
pakt in sterken"]
    Werknemers --> Backend3["BACKEND UPDATE
VERWERK
Operaties aan
operationale order"]

    Backend3 --> Webshop["Webshop verwerkt
order"]

    Webshop --> PostNL["POSTNIL
Voorsammeling
zending"]
    Webshop --> Factuur["Factuur generatie"]

    Factuur --> FacError["DEZE FACTUUR IS 'WEG'!
Het is een PDF die voor uit
en een factuur en maili meer
dan dit"]

    FacError --> Complete["Verzendabel/Betaalmidel"]
    PostNL --> Complete

    style Start fill:#fff3cd
    style OrderFlow fill:#fff3cd
    style MetaFile fill:#fff3cd
    style Backend1 fill:#d4edda
    style Backend2 fill:#d4edda
    style Backend3 fill:#d4edda
    style K3Sync fill:#e7f3ff
    style PayPalProcess fill:#e3f2fd
    style PostNL fill:#e3f2fd
    style Magazijn fill:#f8f9fa
    style Werknemers fill:#f8f9fa
    style Complete fill:#d4edda

Detailed Data Flow Stages¶

Stage 1: Order Creation & Validation¶

Trigger: Customer places order or medewerkker creates order via backend Duration: Seconds Systems Involved: Webshop, MySQL (local), Cache

Process:¶

1. Order initiated by customer or medewerkker
2. Metafile created in webshop with order details
3. Order verification checks if adjustments needed
4. Status set to: CONCEPT — order is not yet final

Data Written to Zwerfkei Database:¶

• Bestelling table: Order details, customer, items, totals
• Bestelling_artikel table: Line items with quantities
• Stock_reservation table (TYPE_USER): Reserve items in stock

No Navision interaction yet — orders queued locally¶

Stage 2: Payment Processing¶

Trigger: Customer confirms order → Payment validation
Duration: 2-5 minutes
Systems Involved: PayNL (external), Webshop, MySQL

Process:¶

1. Payment details sent to PayNL (configured payment provider)
2. PayNL processes payment (card, iDEAL, etc.)
3. Callback from PayNL confirms payment status
4. Order status updated to: DEFINITIEF (confirmed)

Data Written:¶

• Bestelling table: payment_status, payment_reference
• Order moved from CONCEPT → DEFINITIEF status

Critical: Stock reservations confirmed at this stage¶

• Cart reservations (TYPE_USER) still active
• On payment success: kept as TYPE_ORDER

Stage 3: K3 Sync & Navision Order Submission¶

Trigger: Order marked DEFINITIEF → K3 Sync Cron (every 5 minutes)
Duration: 5 minutes (worst case) + SOAP call latency (2-10 sec)
Systems Involved: MySQL, K3 Sync Controller, Navision

Process:¶

1. Cron job k3retail_sync fires (every 5 minutes)

   Query: SELECT * FROM k3_synchronization 
          WHERE status = 'pending' AND model = 'order'
   

2. For each pending order:

3. Lock the sync queue: GET_LOCK('k3_sync', 1)
4. Build SOAP request with order data

5. Call Navision SubmitOrder operation

6. Navision processes order:

7. Creates Sales Order in NAV
8. Assigns order a nav_id (Navision order number)
9. Updates NAV inventory

10. Returns confirmation

11. Success path:

12. Update k3_synchronization.status = 'ok'
13. Update k3_synchronization.nav_id = <returned_id>

14. Update Bestelling.nav_id in webshop database

15. Failure path (up to 10 retries):

16. Log SOAP fault
17. Increment retry counter
18. Retry with exponential backoff
19. If all 10 retries fail: Send alert to monitoring

Data Sent to Navision (SubmitOrder):¶

OrderNo              → Unique order ID from Zwerfkei
CustomerNo           → K3 customer number
OrderDate            → Order creation date
RequestedDeliveryDate → Expected delivery date
CurrencyCode         → EUR / USD
Lines[]              → Array of order items
  - ItemNo           → K3 article number
  - Quantity         → Ordered quantity
  - UnitPrice        → Price from Zwerfkei at time of order
  - LineDiscount     → Applied discount percentage
TotalAmount          → Order total
ShippingMethod       → PostNL or other carrier
PaymentTerms         → Payment method

Data Received from Navision:¶

SalesOrderNo         → NAV order ID (stored as nav_id)
Status               → OK / ERROR / WARNING
Messages[]           → Any warnings or errors

Database Updates:¶

• k3_synchronization table: status=ok, nav_id, date_ok
• Bestelling table: nav_id updated
• Bestelling_artikel table: nav_reference_id updated

Critical: If K3 sync fails, order is stuck → Manual intervention required

Stage 4: Warehouse Fulfillment¶

Trigger: Order confirmed in Navision
Duration: 1-24 hours (depends on warehouse hours)
Systems Involved: TOUCH (warehouse app), Navision, MySQL

Process:¶

1. TOUCH Magazine (Warehouse) App
2. Displays order in picking list (MAGAZIJNBON)
3. Shows items to pick with:
   • Item number & barcode
   • Quantity required
   • Location in warehouse

4. Warehouse staff scan barcodes and pick items

5. Quality Check:

6. Staff verifies all items present
7. If item missing: Marked as "manco" (short)

8. Updates order status for short items

9. Packing:

10. Warehouse staff packs items
11. Generates packing slip (PDF)

12. Associates tracking number (PostNL)

13. Backend Update:

14. TOUCH sends fulfillment data back to Zwerfkei
15. Updates order status to: VERWERKT (processed)

Data Sent to Navision (implicit via sync):¶

• Goods Issue/Receipt confirmation
• Updates NAV inventory (decrements available stock)
• Confirms shipment readiness

Stage 5: Shipment & PostNL Integration¶

Trigger: Order packed in warehouse
Duration: Same-day or next-day shipping
Systems Involved: PostNL (external), Navision, MySQL

Process:¶

1. Shipment Details Created:
2. Packing slip generated with tracking number
3. PostNL barcode assigned

4. Shipping method confirmed (standard, express, etc.)

5. PostNL Updates:

6. Webshop sends shipment info to PostNL via API
7. PostNL returns tracking number

8. Tracking number stored in database

9. K3/Navision Update (async):

10. Sync buffer queries: GetOrderStatus (continuous polling)
11. Navision returns updated shipment status
12. Webshop database updated with tracking info
13. Customer notified via email with tracking link

Data Flows:¶

Zwerfkei → PostNL API:
  - Order number
  - Recipient address
  - Package weight
  - Insurance flag

PostNL → Zwerfkei Callback:
  - Tracking number
  - Estimated delivery date
  - Barcode

Navision → Zwerfkei (Buffer sync):
  - Shipment status: Pending → Shipped
  - PostNL tracking number
  - Estimated delivery date

Database Updates:¶

• Bestelling table: tracking_number, shipment_status, estimated_delivery
• Bestelling_artikel table: Each line marked as shipped

Stage 6: Invoice Generation¶

Trigger: Order shipped (or based on payment success, depending on configuration)
Duration: Automatic (same-day or next-day)
Systems Involved: Navision, MySQL, PDF generator

Process:¶

1. Navision Generates Invoice:
2. After goods issue is confirmed
3. Creates invoice number (Fax/Factuurnummer)
4. Calculates totals with tax

5. Stores in value entries

6. Zwerfkei Retrieves Invoice:

7. Sync buffer: GetValueEntries (nightly cron, 3 AM)
8. Fetches latest invoices/GL entries

9. Stores in local database for reporting

10. Invoice PDF Generated:

11. Template with Zwerfkei & Navision data

12. Includes:

    • Order number (Navision order ID)
    • Invoice number
    • Customer details
    • Line items with prices & taxes
    • Total amount due
    • Payment terms

13. Delivery to Customer:

14. Email sent to customer with PDF attachment
15. PDF stored on server for download

Known Issue: Missing Invoice Files¶

Note: According to the orderprocess diagram, there's a known issue:

"Deze factuur is 'weg'! Het is een PDF die voor uit 
en een factuur en maili meer dan dit"

Translation: "This invoice is 'gone'! It's a PDF that is 
before and an invoice and mail more than this"

Implication: Some invoices are not being properly stored or delivered. This requires investigation into: - PDF generation failures - Email delivery failures - Database storage failures - File system permissions issues

Data in Invoice:¶

• Invoice number (from Navision)
• Order number
• Order date & delivery date
• Customer name & address
• Line items: Article name, quantity, unit price, line total
• Subtotal, tax amount, total due
• Payment terms & reference

Stage 7: Settlement & Accounting¶

Trigger: Invoice generated
Duration: 1-30 days (payment terms)
Systems Involved: Navision GL, POSTNIL (accounting), MySQL

Process:¶

1. Navision GL Entry Created:
2. Debit: Accounts Receivable
3. Credit: Sales Revenue
4. Amount: Invoice total

5. Stored in G/L ledger

6. Accounting Sync:

7. Nightly cron fetches GL entries: GetValueEntries (3 AM)
8. All value entries from Navision synced to Zwerfkei

9. Used for reporting & reconciliation

10. Payment Receipt:

11. Customer pays invoice (via bank transfer, card, etc.)
12. Navision records payment

13. GL entry updated: A/R cleared, Cash credited

14. POSTNIL Accounting Export:

15. Weekly/monthly export to accounting system
16. Sales journal entries
17. Used for financial reporting

Database Tables:¶

• K3_value_entry table: Accounting entries from Navision
• Used for reporting, not business logic

System Integrations (All Touchpoints)¶

Navision/K3 (Core ERP)¶

PayNL (Payment)¶

PostNL (Shipping)¶

TOUCH (Warehouse)¶

POS (Point of Sale)¶

Error Handling & Retry Logic¶

K3 Sync Failures¶

If SubmitOrder fails: 1. SOAP fault returned from Navision 2. Error logged with full details 3. Retry counter incremented (up to 10 retries) 4. Retry happens in next cron run (5-minute window) 5. Exponential backoff applied (1s, 2s, 4s, etc.) 6. Error lock file created to prevent retry storms (5-min cooldown)

If all 10 retries fail: - Order status: SYNC_ERROR - Alert sent to monitoring/ops team - Manual intervention required: - Check Navision availability - Verify order data is valid - Retry manually or create order in Navision directly

Payment Failures¶

If PayNL callback doesn't arrive: - Order remains in CONCEPT status - Background job checks for pending orders (old, unpaid) - Notifies customer to retry payment or abandon cart

Shipment Failures¶

If PostNL submission fails: - Order marked as "pending shipment" - Retry automatic (async) - Manual assignment available in backend if needed

Cron Jobs & Scheduling¶

Data Validation Rules¶

Order Submission Validation¶

Before sending to Navision via SubmitOrder:

Invoice Validation¶

Before marking order as completed:

Known Issues & Gaps¶

Invoice Storage Issue¶

Problem: Invoices are not being reliably stored or delivered to customers
Impact: Customers may not receive invoices; compliance/accounting issues
Status: Noted in orderprocess diagram — investigation needed
Suggested Fix: Audit PDF generation, email delivery logs, and file storage

Manco (Short Item) Handling¶

Problem: When warehouse finds item missing during picking, process for backfilling order unclear
Impact: Customer order may be incomplete; unclear whether partial shipment allowed
Status: TOUCH system handles it, but sync back to Navision/customer unclear

Negative Stock Handling¶

Problem: System allows negative stock in rare cases (overselling)
Impact: More orders than inventory; fulfillment issues
Status: K3 OPAANVRAAG status allows ordering from suppliers as workaround

Real-Time Stock Sync¶

Problem: Stock sync happens every 1 minute; no real-time visibility during high-traffic periods
Impact: Race conditions possible; customer orders may fail stock check after placing
Status: Acceptable for current load; will need optimization for high-volume periods

Future Improvements (Business Central Migration)¶

The current SOAP-based integration will be replaced with Business Central REST API for: - Simpler request/response format (JSON vs. XML) - Better error handling & status codes - Real-time webhooks instead of polling - Support for multi-tenant environments - Alignment with Microsoft's modern platform

References¶

• Legacy Integration Architecture
• Sync Triggers & Cron Methods
• ERP Sync Diagrams
• K3 Data Models
• SubmitOrder API Documentation
• Endpoint Inventory (Google Sheets)