verkoopdump

TL;DR

The read-only Azure MSSQL history database holding pre-2022 orders, the GA4 gap and the old pipeline's customer sequence.

The previous generation's order database, still holding history that exists nowhere else. CCC reads from it; CCC never writes to it. The source's own pipeline maintains its comparison sequence.

Read-only, without exception. This is the company's only copy of pre-2022 order detail and there is no backup story for it in this repository. The credential CCC holds is not read-only, so the only thing preventing a write is a check in the code. Reach it only through the model that performs that check.

What it delivers

FeedCovers
TransactionsBefore 2022, where NetSuite has nothing
Source and medium2022 onward, filling the window GA4 never reached
Customer order sequenceThe old pipeline's own numbering, kept for comparison

The third is the one people misread. It is not CCC's answer. CCC computes its own sequence and publishes that; this is the previous system's answer, stored beside it so the two can be compared. The table prefix says which is which: vkd_customersalesorders is imported, customersalesorders is CCC's own.

Cadence and window

The transaction history import is drained by hand, in slices, typically a year at a time, and switched off once a window is complete. That is why a line for it can sit in the schedule and be inactive: the schedule is the mechanism, the switch is the control.

The source/medium backfill is queued and drained separately. The comparison sequence has its own recurring reset and worker, so it continues to refresh independently of transaction backfill. Each dated reader can request the periods its source tables hold.

Quirks and limits

  • It is a different database engine from CCC's own, reached over a different driver.
  • Its records predate current conventions, so field meanings do not always match the modern equivalents. Check the dictionary before assuming a column means what its name suggests.
  • Its customer sequence is imported for comparison against CCC's own, so the two disagreeing is the expected result rather than a fault. CCC numbering lower often indicates history CCC does not hold; CCC numbering higher means CCC grouped more orders onto one customer.
  • Its sequence is NULL where the source never numbered an order, which is not the same as CCC's 0 for an order it deliberately did not count.

Where it lands

Historic transactions are transformed into the ordinary salesorders, invoices, itemfulfillments and prepayments families, not separate vkd_ transaction tables. The import also writes raw acquisition data. The comparison sequence alone lands in vkd_customersalesorders; it does not overwrite CCC's computed numbering.

Evidence

Read-only rule, the non-read-only credential and the single-model access route from AGENTS.md, Forbidden paths. Destination tables and transformations from app/jobs/verkoopdump/transactions.php; comparison refresh from customersalesordersreset.php, customersalesorders.php and .cron/ccc.cron. Prefix meaning and the two sequence tables from AGENTS.md, Models and database. Basis: code-checked against the current implementation.

How much of the pre-2022 window an environment holds is a property of that environment, not of the code: the historic import is switched on, drained a slice at a time, and switched off again.

About this document
  • Type
    source
  • Status
    active
  • Updated
    2026-09-14
  • Created
    2026-09-13