| Rechnungen an der höchsten Stelle, die wir abrufen | 0 | 0 | — | Ist diese Stelle belegt, gibt es wahrscheinlich auch eine nächste — und die rufen wir nicht ab. Beim Auftrag steht dann eine Rechnung weniger, mit Beträgen, die zu den vorhandenen Rechnungen passen. FACTUUR_VOLGNUMMERGRENS in packages/shared/src/factuurgrenzen.ts erhöhen — der Connector, diese Seite und die Rechnungsmessung lesen alle daraus — und danach eine vollständige Simar-Runde. Jeder Code kostet in jeder Runde Breite, also eins weiter und nicht fünf. Messen Sie zuerst, wie weit es tatsächlich reicht, über alle Referenzen: Die erste Seite von 999 findet den Ausreißer nicht. |
| Subunternehmerrechnungen (nur die Nummer abgerufen) | 0 | 0 | — | Aus den Subunternehmerreihen rufen wir nur die Rechnungsnummer ab, weil nach der vollständigen Runde vom 23.09.2026 bei keinem der 1599 Aufträge eine vorhanden war. Steht hier eine Anzahl, fehlen dieser Rechnung Datum, Betrag und Zahlungsstand. In FACTUUR_REEKSEN (packages/connectors/src/simar/codes.ts) den Subunternehmerreihen den vollständigen Feldsatz geben (Datum, Betrag, bezahlt, Typ), danach eine vollständige Runde. |
| Aufträge, deren Rechnungen sich nicht zum bezahlten Betrag summieren | 0 | 0 | — | Die Beträge pro Rechnung sollten sich zum Bruttobetrag abzüglich des offenen Saldos summieren. Weicht das ab, wird eines der Felder falsch gelesen — und das ist auf keiner Seite zu sehen, weil alle Zahlen dann plausibel sind. Vergleichen Sie einen abweichenden Auftrag mit Simar selbst (scripts/simar-veld-meten.ps1 auf @9120 bis @9124 und @173). Aufträge mit Einzelzahlungen zählen hier bereits nicht mit; Gutschriftpositionen schon, denn @173 ist der Nettobetrag. Was übrig bleibt, ist ein Lesefehler. |
| Aufträge ohne offenen Saldo (@174) | 2.712 | 2.712 | 100% | Zählen auf der Zahlungsseite in keinem Betrag mit; die offene Summe ist dann zu niedrig, ohne dass man es sieht. Eine vollständige Simar-Runde (simar_volledige_ronde in prd.tfvars). Neu hinzugefügte Felder kommen sonst nur für Aufträge herein, die sich noch ändern. |
| Aufträge ohne Wareneingangsmeldung (@1765)informatief | 2.712 | 2.712 | 100% | Die Einkaufsprognose kann sie nicht als geliefert zählen; sie bleiben unter „noch zu liefern“ stehen, auch wenn die Küche längst eingetroffen ist. Dieselbe vollständige Runde wie oben. Alte, abgeschlossene Aufträge ändern sich nie mehr und lassen dieses Feld sonst leer. |
| Aufträge ohne jeden Fortschrittsschritt (@1348/@1734/@1765 u. a.)informatief | 2.712 | 2.712 | 100% | Stehen auf der Auftragsfortschrittsseite mit leeren Spalten für In Bearbeitung, Bestellt, Bestätigt, Eingetroffen, Auslieferung und Montage. Das liest sich wie „es ist nichts passiert“, obwohl es „wir wissen es nicht“ bedeutet — der gefährlichste Unterschied auf dieser Seite. Die Vertiefungsrunde der Simar-Synchronisation füllt diese Felder. Alte, abgeschlossene Aufträge ändern sich nie mehr und bleiben daher leer; dafür ist eine vollständige Runde nötig (simar_volledige_ronde in prd.tfvars). |
| Aufträge ohne Lieferwocheinformatief | 0 | 2.712 | 0% | Fallen auf den Einkaufsseiten auf ihr Auftragsdatum und in der Prognose in den Abrufbereich zurück. Teils echt (Abrufaufträge), teils Verwaltung. Keine Korrektur im Dashboard: Die Lieferwoche wird in Simar eingeplant. Eine hohe Anzahl ist ein Signal an die Standorte. |
| Aufträge ohne Margenprozentsatz | 0 | 2.712 | 0% | Fehlen in der Marge der Vertriebsübersicht und in der Wolke „Marge pro Auftrag“; die Marge bezieht sich dann nur auf einen Teil der Aufträge. Die Marge wird während der Vertiefungsrunde aus den Auftragspositionen berechnet; läuft diese, holt sich das von selbst auf. |
| Auftragspositionen ohne Einstandspreis | 0 | 14.886 | 0% | Fallen aus dem Einkaufsvolumen und damit aus den Bonusgruppen: Das Bonusvolumen ist dann zu niedrig, und das sieht glaubwürdig aus. Einstandspreise kommen pro Position aus der Vertiefungsrunde der Simar-Synchronisation (costPricePerUnit). |
| Möbelpositionen ohne Ausführung (idmProperties)informatief | 5.918 | 5.918 | 100% | Der Reiter Küchentypen im Auftragsfortschritt bleibt leer: kein Fronttyp, keine Frontfarbe, kein Griff oder Korpus. Die Verteilung unter /inkoop/uitvoeringen rechnet dann nur über einen Teil der Positionen. Kommt aus der Vertiefungsrunde der Simar-Synchronisation. Nur Möbel und Arbeitsplatten gezählt — Geräte haben keine Frontfarbe, und sie mitzuzählen macht den Nenner unsinnig (Abdeckungstest 18.09.2026: Möbel 87,3 %, Zubehör 8,3 %). |
| Aufträge ohne Verkäufer | 1.901 | 2.712 | 70,1% | Zählen auf den Verkäuferseiten und im Beraterbonus nicht mit; die Standortsummen stimmen jedoch. Der Verkäufercode aus Simar (@KC2) konnte keinem bekannten Benutzer zugeordnet werden; prüfen Sie in den Sync-Protokollen, welche Codes unbekannt sind. |
| Leads ohne Verkäuferinformatief | 21.444 | 30.957 | 69,3% | Stehen auf dem Lead-Board unter 'Nicht zugewiesen' und verschwinden, sobald man nach einem Verkäufer filtert — auf dem Board und im Kalender, denn beide filtern nach derselben Spalte. Teilweise normal (nicht jeder Lead hat einen Eigentümer in GoHighLevel). Bleibt der Anteil hoch, gibt es zwei Ursachen: Der Eigentümer lässt sich keinem Verkäufer zuordnen (die Synchronisation nennt pro Runde, welche Namen das sind), oder der Lead ist älter als das Abrufzeitfenster von 30 Tagen und kam nie wieder vorbei. Letzteres erfordert eine vollständige Runde: pnpm sync:ghl 750. |
| Termine mit einem Berater, den wir nicht kennen | 0 | 8.522 | 0% | Der Kalender zeigt bei diesen Terminen keinen Berater, und dieselben fehlenden Namen lassen Leads ohne Verkäufer hereinkommen. Die Namen kommen aus /users/ pro Sub-Account und landen in ghl_kalender_teamleden. Ist diese Tabelle leer oder unvollständig, hat die GoHighLevel-Anbindung für dieses Sub-Account keine Rechte auf Benutzer — siehe Administration → Anbindungen. |
| Kampagnen ohne Standort | 5 | 45 | 11,1% | Werbeausgaben, die in keiner Standortzahl mitzählen — nur die Hauptverwaltung sieht sie. Ordnen Sie sie unter Administration → Kampagnen einem Standort zu. |
| Angehakte Bonusmarken ohne Einkaufspositionen | 0 | 0 | — | Ein Häkchen, das auf nichts passt, zählt stillschweigend null Volumen mit — der Inventum-Fall. Seit dem schreibweisenunabhängigen Vergleich fängt dies nur noch wirklich tote Namen. Prüfen Sie unter Administration → Bonusgruppen, ob die Marke in den Daten anders heißt, und haken Sie den gültigen Namen an. |
| Servicemeldungen ohne Rechnungsbetraginformatief | 76 | 623 | 12,2% | Diese Meldungen zählen mit 0 € in den Servicekosten, nicht als unbekannt. Ist der Anteil hoch, ist jeder Servicekostenbetrag auf den Serviceseiten eine Untergrenze — das erklärt Standorte, die bei 0 € stehen, obwohl es Meldungen gibt. Teilweise normal: Garantiearbeiten werden nicht weiterberechnet. Der Betrag kommt aus der Vertiefungsrunde (120 Aufträge pro Runde, rotierend), daher ist die Abdeckung kurz nach einem neuen Feldcode oder einer leeren Datenbank niedrig und steigt von selbst. Bleibt sie niedrig, prüfen Sie, ob invoiceAmount in Simar gefüllt wird. |