CRM und ERP

Felder anlegen. Im CRM an der Verkaufschance ein eindeutiges Textfeld „procuris-ID“ für tender.id, ein Feld „procuris-Stand“ für lastModified, ein Zahlenfeld „Passung“ und ein Feld „Passung vom“ für den Zeitpunkt der Passung. Am Account oder Geschäftspartner ein eindeutiges Textfeld „procuris-Organisation“ für organizations[].id. Über „procuris-ID“ erkennt Ihr System dieselbe Ausschreibung wieder. Über „procuris-Organisation“ erkennt es denselben Auftraggeber, sofern procuris ihn als dieselbe Stelle erkannt hat. Zwei verschiedene id schließen nicht aus, dass es dieselbe Stelle ist. Dann entstehen im CRM zwei Accounts, die Ihr Vertrieb von Hand zusammenführt. Die Felder „procuris-Stand“ und „Passung vom“ braucht Schritt 7.

Empfänger mit Warteschlange bauen. Ein kleiner Dienst nimmt die Nachrichten an und prüft die Signatur mit einer fertigen Bibliothek aus Zustellung und Sicherheit. Danach legt er die Nachricht in eine Warteschlange und antwortet mit 2xx, bevor er ins CRM schreibt. So bleibt er unter den 15 Sekunden, die procuris auf eine Antwort wartet. Ins CRM schreibt er erst in Schritt 6.

Zieladresse anlegen und Ereignisse wählen. Die Person mit der Rolle Inhaber legt in procuris unter Einstellungen › Organisation › Webhooks die Adresse des Dienstes als Zieladresse an. Den Bereich Webhooks gibt es erst, wenn der Zugang nach Vertragsschluss eingerichtet ist. Bis dahin führt die gleichnamige Zeile im Abschnitt Auf Anfrage nur zur Anfrage eines Angebots. Variante A: die Ereignisarten tender.published mit den Filtern für Ihre Branche und Region, dazu tender.updated für geänderte Werte, Lose und Fristen und tender.archived zum Abschließen. Variante B: die Ereignisarten search.hit, tender.updated und tender.archived, dazu die Suchaufträge, deren Treffer ins CRM sollen. Legen Sie bei der Zieladresse fest, dass die Auswahl der Suchaufträge auch für tender.updated und tender.archived gilt. Dann kommen geänderte Werte, verschobene Fristen und Archivierungen zu jeder Ausschreibung, die schon einmal Treffer eines dieser Suchaufträge war, siehe Ereignisse. Ab dem Speichern laufen die gewählten Ereignisse in die Warteschlange. Ob sie dort ankommen, prüfen Sie mit Testnachricht senden.

Erstbefüllung (Variante A). Die Erstbefüllung bringt einmal alle Ausschreibungen ins CRM, die es zu Ihren Filtern schon gibt. Ihr Dienst merkt sich den Zeitpunkt, zu dem er beginnt. Dann ruft er über die API mit denselben Filtern ab, die bei der Zieladresse stehen, und legt je Ausschreibung eine Verkaufschance an, siehe Filter und Takt. Zu jeder Verkaufschance speichert er lastModified in „procuris-Stand“.

Nachholabruf (Variante A). Danach ruft er ein zweites Mal ab, mit updated_since gleich dem gemerkten Zeitpunkt aus Schritt 4. So bekommt er, was sich während der Erstbefüllung geändert hat.

Warteschlange abarbeiten. Erst jetzt verarbeitet der Dienst die Nachrichten aus der Warteschlange, danach jede neue. In Variante B kommen die ersten Treffer am Morgen nach dem Anlegen der Zieladresse. Die Reihenfolge der Nachrichten ist nicht garantiert, weil Wiederholungen und Nachlieferungen später ankommen können. Darum kann jedes Ereignis außer der Testnachricht eine Verkaufschance anlegen. Nachrichten mit data.test gleich true übergeht der Dienst.

Die procuris-ID entscheidet über Anlegen oder Nachziehen. Der Dienst sucht zuerst eine Verkaufschance mit procuris-ID gleich data.tender.id. Gibt es eine, gilt Schritt 7. Gibt es keine, legt er sie aus data.tender an, bei tender.archived gleich mit dem Status aus der Tabelle unter Status abbilden. Beim Anlegen speichert er data.tender.lastModified in „procuris-Stand“. Bei search.hit speichert er data.fit in „Passung“ und den timestamp der Nachricht in „Passung vom“. Den Auftraggeber sucht er über „procuris-Organisation“ und legt ihn nur an, wenn es ihn im CRM nicht gibt.

In Variante B kann eine Chance ohne Passung entstehen. Das passiert, wenn tender.updated oder tender.archived zu einem früheren Treffer kommt, zu dem das CRM noch keine Chance hat, etwa zu einem Treffer von vor dem Anlegen der Zieladresse. Nur search.hit trägt eine Passung. Das Feld „Passung“ bleibt dann leer.

Änderungen nachziehen. Ist data.tender.lastModified neuer als „procuris-Stand“, schreibt der Dienst alle zugeordneten Felder aus data.tender neu, nicht nur die aus changedFields. Danach speichert er das neue lastModified in „procuris-Stand“. Ist es älter oder gleich, übernimmt er aus data.tender nichts. data.fit übernimmt er nur, wenn der timestamp der Nachricht neuer ist als „Passung vom“, und speichert diesen timestamp dann dort. So überschreibt weder ein verspäteter noch ein nachgelieferter search.hit einen neueren Stand. Nachrichten zu Änderungen, die schon aus Erstbefüllung oder Nachholabruf im CRM stehen, fallen so weg. Zwischen Erstbefüllung und Webhooks entsteht in Variante A keine Lücke, weil die Warteschlange ab dem Speichern der Zieladresse läuft und die Erstbefüllung erst danach beginnt.

Abschließen. Bei tender.archived bildet der Dienst data.tender.archiveReason auf den Status im CRM ab, siehe Tabelle unter Status abbilden.

Nächtlicher Abgleich (Variante A). Der nächtliche Abgleich zieht herausgefallene Ausschreibungen nach und legt fehlende Chancen an. Passt eine Ausschreibung nach einer Änderung nicht mehr zu Ihren Filtern, etwa weil die Vergabestelle die Region korrigiert, kommt für sie kein tender.updated mehr, nur noch tender.archived. Darum ruft der Dienst jede Nacht über die API ohne inhaltliche Filter ab, nur mit updated_since.

Der erste nächtliche Lauf holt alles ab dem Start der Erstbefüllung. Der Dienst setzt updated_since dafür auf den Zeitpunkt, den er sich in Schritt 4 gemerkt hat. So erfasst er auch Ausschreibungen, die seit Beginn der Erstbefüllung aus den Filtern gefallen sind. Ab der zweiten Nacht gilt das größte lastModified des vorigen Laufs.

Die procuris-ID entscheidet, was mit einem Datensatz geschieht. Gibt es sie im CRM, zieht der Dienst die Chance nach den Regeln aus Schritt 7 nach. Gibt es sie nicht, prüft er selbst, ob der Datensatz zu den Filtern der Zieladresse passt, zum Beispiel über cpvClassifications und regionCodes. Passt er, legt der Dienst die Chance an wie in Schritt 6, eine archivierte gleich mit Status. So kommen auch Ausschreibungen ins CRM, deren Nachricht verloren gegangen ist. Alle übrigen Datensätze übergeht er.

Am Ende des Laufs speichert er das größte lastModified als Stand für die nächste Nacht. Liefert ein Lauf nichts, bleibt der gespeicherte Stand unverändert. Der Abruf ohne Filter holt jede geänderte Ausschreibung des Bestands und braucht darum mehr Abrufe als ein gefilterter, siehe Filter und Takt.

Erstbefüllung. Ein Ladelauf ruft GET /v1/tenders mit Ihren Filtern ab und legt je Datensatz ein Projekt an, über id als Schlüssel.

Nächtlicher Lauf. Er ruft mit updated_since gleich dem größten lastModified des vorigen Laufs ab. Es kommen neue, geänderte und archivierte Ausschreibungen. Archivierte schließt er im ERP ab oder führt sie zusammen, nach der Tabelle unter Status abbilden.