CRM and ERP

Create fields. In the CRM, on the sales opportunity, create a unique text field "procuris ID" for tender.id, a field "procuris state" for lastModified, a number field "Fit" and a field "Fit as of" for the time of the fit. On the account or business partner, create a unique text field "procuris organization" for organizations[].id. Through "procuris ID", your system recognizes the same tender again. Through "procuris organization", it recognizes the same contracting authority, provided procuris has recognized it as the same body. Two different id values do not rule out that it is the same body. In that case, two accounts appear in the CRM, which your sales team merges by hand. Step 7 needs the fields "procuris state" and "Fit as of".

Build a receiver with a queue. A small service accepts the messages and checks the signature with a ready-made library from Delivery and security. Then it puts the message into a queue and responds with 2xx before it writes into the CRM. This keeps it under the 15 seconds that procuris waits for a response. It writes into the CRM only in step 6.

Create an endpoint and choose events. The person with the role Owner creates the address of the service as an endpoint in procuris under Settings › Organization › Webhooks. The Webhooks section exists only once access has been set up after the contract is signed. Until then, the row of the same name in the On request section only requests a quote. Variant A: the event types tender.published with the filters for your industry and region, plus tender.updated for changed values, lots and deadlines and tender.archived for closing. Variant B: the event types search.hit, tender.updated and tender.archived, plus the saved searches whose hits should go into the CRM. Set on the endpoint that the selection of saved searches also applies to tender.updated and tender.archived. Then changed values, postponed deadlines and archiving arrive for every tender that has once been a hit of one of these saved searches, see Events. From the moment you save, the chosen events flow into the queue. Check with Send test message whether they arrive there.

Initial load (variant A). The initial load brings all tenders that already exist for your filters into the CRM once. Your service remembers the time at which it starts. Then it fetches through the API with the same filters as on the endpoint and creates one sales opportunity per tender, see Filters and timing. For every sales opportunity, it stores lastModified in "procuris state".

Catch-up fetch (variant A). Then it fetches a second time, with updated_since set to the time remembered in step 4. This way it gets what changed during the initial load.

Work through the queue. Only now does the service process the messages from the queue, and after them every new one. In variant B, the first hits arrive on the morning after the endpoint is created. The order of messages is not guaranteed, because retries and resent messages can arrive later. That is why every event except the test message can create a sales opportunity. The service skips messages with data.test set to true.

The procuris ID decides between creating and updating. The service first looks for a sales opportunity with procuris ID equal to data.tender.id. If there is one, step 7 applies. If there is none, it creates it from data.tender, for tender.archived directly with the status from the table under Map status. When creating, it stores data.tender.lastModified in "procuris state". For search.hit, it stores data.fit in "Fit" and the timestamp of the message in "Fit as of". It looks up the contracting authority through "procuris organization" and creates it only if it does not exist in the CRM.

In variant B, an opportunity without a fit can appear. This happens when tender.updated or tender.archived arrives for an earlier hit for which the CRM has no opportunity yet, for example a hit from before the endpoint was created. Only search.hit carries a fit. The field "Fit" then stays empty.

Apply changes. If data.tender.lastModified is newer than "procuris state", the service rewrites all mapped fields from data.tender, not only those in changedFields. Then it stores the new lastModified in "procuris state". If it is older or equal, it takes nothing from data.tender. It takes data.fit only if the timestamp of the message is newer than "Fit as of", and then stores this timestamp there. This way, neither a late nor a resent search.hit overwrites a newer state. Messages about changes that are already in the CRM from the initial load or the catch-up fetch drop out this way. In variant A, there is no gap between the initial load and webhooks, because the queue runs from the moment the endpoint is saved and the initial load starts only after that.

Close. For tender.archived, the service maps data.tender.archiveReason to the status in the CRM, see the table under Map status.

Nightly sync (variant A). The nightly sync updates tenders that dropped out and creates missing opportunities. If a tender no longer matches your filters after a change, for example because the contracting authority corrects the region, no further tender.updated arrives for it, only tender.archived. That is why the service fetches through the API every night without content filters, only with updated_since.

The first nightly run fetches everything from the start of the initial load. For this, the service sets updated_since to the time it remembered in step 4. This way it also covers tenders that have dropped out of the filters since the initial load began. From the second night on, the largest lastModified of the previous run applies.

The procuris ID decides what happens with a record. If it exists in the CRM, the service updates the opportunity by the rules from step 7. If it does not, the service checks itself whether the record matches the filters of the endpoint, for example through cpvClassifications and regionCodes. If it matches, the service creates the opportunity as in step 6, an archived one directly with status. This way, tenders whose message got lost also reach the CRM. It skips all other records.

At the end of the run, it stores the largest lastModified as the state for the next night. If a run returns nothing, the stored state stays unchanged. The fetch without filters gets every changed tender in the stock and therefore needs more requests than a filtered one, see Filters and timing.

Initial load. A load job fetches GET /v1/tenders with your filters and creates one project per record, with id as the key.

Nightly run. It fetches with updated_since set to the largest lastModified of the previous run. New, changed and archived tenders arrive. It closes archived ones in the ERP or merges them, according to the table under Map status.