Ist hier das falsche Abo eingetragen, rechnet die Schnittstelle mit einem zu großen oder zu kleinen Kontingent. Zu groß bedeutet: Pipedrive bricht Übertragungen ab, bevor die Schnittstelle es erwartet.
Siehe [API-Tokens](https://wiki.dako-it.com/books/finnpipedrive/page/api-tokens). ### Pipedrive-Firmendomain Nur der Name, nicht die vollständige Adresse. Lautet die Adresse `https://muster.pipedrive.com`, wird hier `muster` eingetragen.Über die Firmendomain wird die Pipedrive-API angesprochen — damit ist gleichzeitig festgelegt, in welches Konto übertragen wird.
### API-Token Zu finden in Pipedrive in den **persönlichen Einstellungen** des Benutzers, über das Benutzersymbol oben rechts, dort im Reiter **API**. Das Token gehört zu einem Benutzer. Alle übertragenen Datensätze bekommen diesen Benutzer als Besitzer, solange kein anderer Standardbesitzer eingestellt ist. Wird dieser Benutzer in Pipedrive deaktiviert, steht die Übertragung.
Deshalb empfiehlt sich ein eigener Benutzer für die Schnittstelle — nicht das persönliche Konto eines Mitarbeiters, der das Haus wechseln kann.
## Nach dem Eintragen: neu starten Sind Abo, Firmendomain und Token eingetragen, muss die Anwendung über **Neustarten** neu gestartet werden. Erst danach richtet FINN.pipedrive seine Grundzuordnungen ein. Ohne diesen Neustart bleiben die Bereiche und die Zeitsteuerung leer. Das ist die häufigste Rückfrage bei der Einrichtung.
Danach dauert der Aufruf der Einstellungen ein paar Sekunden länger: Alle Felder, Label, Pipelines und Benutzer werden dabei aus Pipedrive geholt.
## Der Aufruf der Einstellungen kostet TokensJeder Aufruf der Einstellungen fragt Daten bei Pipedrive ab und verbraucht dabei API-Tokens des Tageskontingents. Unnötige Aufrufe gehören vermieden — besser mehrere Änderungen in einem Aufruf erledigen als die Seite zehnmal öffnen.
## Standardbesitzer Legt fest, welcher Pipedrive-Benutzer als **Besitzer** der übertragenen Datensätze eingetragen wird.  | Feld | | | -------------------------------------------------------- | -------------------------- | | **Pipedrive-Standardbesitzer für alle übertragenen Daten** | einer der Pipedrive-Benutzer |Bleibt das Feld leer, wird der Benutzer eingetragen, dem das API-Token gehört — das ermittelt Pipedrive selbst aus dem Token.
## Protokoll und Fehlersuche | Feld | Wirkung | | ---------------------------------- | ------------------------------------------ | | **Pipedrive-API-Logs anzeigen** | schreibt je Zugriff eine Zeile mit dem Tokenverbrauch ins Protokoll | | **Debug-Modus aktivieren** | zusätzliche Protokollzeilen zur Fehlersuche |Die API-Logs sind das Mittel, um den Tokenverbrauch zu beobachten: In jeder Zeile steht, wie viele Tokens ein Zugriff gekostet hat und wie viele heute noch bleiben.
Beide Einstellungen machen das Protokoll deutlich voller. Für den Dauerbetrieb gehören sie ausgeschaltet — sonst ist im Protokoll nichts mehr zu finden, und die Protokolldateien werden schneller überschrieben.
Siehe [Log Informationen](https://wiki.dako-it.com/books/finnghost-systemhandbuch/page/log-informationen) im Systemhandbuch. ## Nächster Schritt [Kontakte](https://wiki.dako-it.com/books/finnpipedrive/page/kontakte) # Kontakte Die CRM-Adressen der SelectLine werden in Pipedrive zu **Organisationen** und **Personen**. Dieser Bereich ist der umfangreichste — und der, mit dem angefangen wird. In der SelectLine liegen Firmen und Ansprechpartner gemeinsam im CRM, in Pipedrive sind Organisationen und Personen zwei getrennte Bereiche. Deshalb ist fast jede Einstellung hier zweimal vorhanden — einmal für Organisationen, einmal für Personen.
Übertragen wird nur aus dem SelectLine-CRM nach Pipedrive. In Pipedrive angelegte Kontakte kommen nicht in die SelectLine.
## Grundeinrichtung Im **Firmenstammdaten-Mapping** und im **Personenstammdaten-Mapping** muss je ein Pipedrive-Extrafeld angegeben werden, in das die CRM-ID aus der SelectLine-Tabelle `CRM_ADRESSEN` geschrieben wird. Ohne diese beiden Mappings läuft die Kontaktübertragung nicht an. Die Schnittstelle bricht mit der Meldung ab, dass keine Zuordnung für die SelectLine-CRM-ID vorhanden ist.
Damit ist die Grundeinrichtung abgeschlossen — alles Weitere auf dieser Seite ist optional und kann später ergänzt werden.
Wie ein Mapping angelegt wird, steht unter [Zuordnung und Extrafelder](https://wiki.dako-it.com/books/finnpipedrive/page/zuordnung-und-extrafelder). ## Weitere Stammdaten übertragen Über dieselben beiden Mappings lassen sich beliebig viele weitere CRM-Felder in Pipedrive-Extrafelder schreiben — Kundennummer, Klassifikation, Status, Social-Media-Angaben. Für einzelne, häufig gebrauchte Angaben gibt es eigene Felder: | Einstellung | Inhalt | | ---------------------------------------------- | ---------------------------- | | **Pipedrive-Felder für Branchen** | die Branche der Organisation | | **Pipedrive-Felder für E-Mailadressen** | die E-Mail-Adresse der Organisation | | **Pipedrive-Felder für Kommunikationssprachen** | die Sprache, für Organisationen und Personen | | **Pipedrive-Felder für Geburtstage** | das Geburtsdatum der Person | | **Übertragung des Erstellungsdatums** | wann die Adresse in der SelectLine angelegt wurde | ## Kontaktgruppen ausschließen Mit **Kontaktgruppen-Handling aktivieren** lassen sich Kunden- und Lieferantengruppen der SelectLine von der Übertragung ausnehmen.Das ist mehr als ein Filter: Kontakte dieser Gruppen, die bereits in Pipedrive stehen, werden dort gelöscht — samt der Angaben, die jemand in Pipedrive daran gepflegt hat. Diese Einstellung gehört deshalb vor dem ersten Lauf gesetzt und danach nicht mehr geändert, ohne die Folgen zu bedenken.
Der typische Anwendungsfall ist eine Gruppe wie intern oder Einmalkunden, die im Vertrieb nichts zu suchen hat.
### Kundengruppe mit übertragen Unabhängig davon kann die **SelectLine-Kundengruppe** in ein Extrafeld geschrieben werden — je Extrafeld für Organisationen und Personen.Übertragen wird die Gruppe nur bei Kontakten, die die Schnittstelle als Kunden erkennt. Bei Lieferanten und freien Adressen bleibt das Feld leer.
## Label in Pipedrive Pipedrive kennzeichnet Kontakte über **Label**. Die Schnittstelle vergibt sie nach dem Adresstyp aus dem SelectLine-CRM.  | Adresstyp | Einstellung | | ---------------- | ---------------------- | | Kunde | **Kunden-Label** | | Lieferant | **Lieferanten-Label** | | Interessent | **Interessenten-Label** | | freie Adresse | **Kontakt-Label** | Jeweils getrennt für **Organisationen** und **Personen**.Dasselbe Label darf für mehrere Adresstypen vergeben werden — etwa wenn Kunden und Interessenten in Pipedrive nicht unterschieden werden sollen.
## Label nach Kaufverhalten: Lead-Handling Zusätzlich kann die Schnittstelle Kontakte danach kennzeichnen, wie lange die letzte Bestellung zurückliegt. Diese Funktion setzt voraus, dass in der Beleg-Synchronisation mindestens ein Belegtyp als akzeptierte Bestellung hinterlegt ist. Ohne das bleibt sie ohne Wirkung.
Siehe [Belege](https://wiki.dako-it.com/books/finnpipedrive/page/belege). Eingestellt werden zwei Zeiträume und die dazugehörigen Label: | Einstellung | | | ---------------------------------------- | ------------------------------- | | **Zeit-Intervalltyp für "Hot Leads"** und **Zeit-Wert** | Tage, Wochen, Monate oder Jahre | | **Zeit-Intervalltyp für "Warm Leads"** und **Zeit-Wert** | dito | | **"Hot Lead"-Label** | je für Organisationen und Personen | | **"Warm Lead"-Label** | je für Organisationen und Personen | ### Wie bewertet wird Geprüft wird, ob innerhalb des eingestellten Zeitraums eine akzeptierte Bestellung liegt: | Situation | Ergebnis | | ------------------------------------------------- | ----------------------- | | Bestellung innerhalb des Hot-Zeitraums | Label nach Adresstyp bleibt | | keine Bestellung im Hot-Zeitraum | **Hot-Lead-Label** | | keine Bestellung im Warm-Zeitraum | **Warm-Lead-Label** |Beide Prüfungen laufen nacheinander, und die zweite gewinnt: Trifft auch die Warm-Bedingung zu, wird das Warm-Label vergeben. Bei einem kurzen Hot- und einem langen Warm-Zeitraum ergibt das die Staffelung „kürzlich bestellt — länger nicht bestellt — sehr lange nicht bestellt".
Ein vergebenes Lead-Label ersetzt das Label des Adresstyps. Ein Kunde, der lange nicht bestellt hat, ist in Pipedrive dann nicht mehr als Kunde gekennzeichnet, sondern als Lead.
Die Bezeichnungen sind so zu lesen, wie Pipedrive sie verwendet — als Temperatur eines Leads. Wer das anders benennen will, vergibt einfach Label mit eigenen Namen; die Schnittstelle schreibt, was ausgewählt wurde.
### Label nachträglich neu setzen Für den Fall, dass die Label-Einstellungen geändert wurden, gibt es in der Zeitsteuerung die eigene Aufgabe **Kontakt-Label erneut exportieren**. Sie schreibt die Label aller bereits übertragenen Kontakte neu, ohne die übrigen Daten anzufassen.Das ist deutlich sparsamer als ein vollständiger Kontaktlauf — und der richtige Weg, wenn nur die Label-Vergabe geändert wurde.
## Umsätze und Bestellzahlen  | Einstellung | Inhalt | | ---------------------------------------- | ---------------------------- | | **Aktuellen Jahresumsatz exportieren** | Umsatz des laufenden Jahres | | **Letzten Jahresumsatz exportieren** | Umsatz des Vorjahres | | **Gesamtumsatz exportieren** | Umsatz über alles | | **Bestellungsanzahl exportieren** | Anzahl der Bestellungen | Je Häkchen erscheinen zwei Felder für das Ziel-Extrafeld — für Organisationen und Personen.Die Umsätze werden aus den Rechnungs- und Gutschriftbelegen der SelectLine berechnet und in der Währung des Mandanten übertragen.
Deals, die nur in Pipedrive existieren, gehen in die Berechnung nicht ein. Der Wert in Pipedrive ist also der Umsatz aus der Warenwirtschaft — nicht die Summe der Deals.
## Bestellte Produktkategorien Die Schnittstelle kann die Artikelgruppen aller bisher bestellten Artikel sammeln und in ein Extrafeld vom Typ **Mehrfachoption** schreiben. | Einstellung | | | ------------------------------------------- | ------------------------------ | | **Pipedrive-Extrafeld für Bestellhistorie** | je für Organisationen und Personen |Damit lässt sich in Pipedrive filtern, wer schon einmal eine bestimmte Warengruppe gekauft hat — die Grundlage für gezielte Ansprache.
Grundlage sind die Positionen der akzeptierten Bestellungen. Ohne mindestens einen Belegtyp dafür bleibt das Feld leer. Fehlt eine Produktkategorie in Pipedrive noch, wird sie beim Lauf angelegt — das kostet zusätzliche API-Tokens.
## Datumsangaben zu Bestellungen | Einstellung | Inhalt | | ---------------------------------------- | ------------------------------- | | **Übertragung des Erstbestelldatums** | Datum der ersten akzeptierten Bestellung | | **Übertragung des letzten Bestelldatums** | Datum der letzten akzeptierten Bestellung | Beide brauchen ein Extrafeld vom Datentyp **Datum** und mindestens einen Belegtyp für akzeptierte Bestellungen. ## Nächster Schritt [Produkte](https://wiki.dako-it.com/books/finnpipedrive/page/produkte) # Produkte Die Artikel der SelectLine werden in Pipedrive zu **Produkten**. Sie sind die Grundlage der Deal-Positionen — deshalb gehört dieser Bereich vor den Belegen eingerichtet. Übertragen wird ausschließlich von der SelectLine nach Pipedrive. In Pipedrive angelegte Produkte kommen nicht in die SelectLine.
## Grundeinrichtung Es muss festgelegt werden, wohin die **Artikelnummer** geschrieben wird. Zwei Möglichkeiten: | Ziel | Wann | | ---------------------------------- | ------------------------------------ | | das Standardfeld **Produktcode** | der Regelfall | | ein eigenes **Extrafeld vom Typ Text** | wenn der Produktcode schon anders belegt ist | Ohne diese Angabe läuft die Produktübertragung nicht an: Die Schnittstelle könnte einen Artikel in Pipedrive nicht wiederfinden und würde ihn bei jedem Lauf erneut anlegen.
Damit ist die Grundeinrichtung abgeschlossen. Alles Weitere ist optional.
## Was ohne weitere Einstellung übertragen wird | In Pipedrive | Aus der SelectLine | | ---------------------- | ------------------------------------------- | | Name | die **Bezeichnung** des Artikels; ist sie leer, die Artikelnummer | | Produktcode | die Artikelnummer | | Steuersatz | aus dem Steuerschlüssel des Verkaufs | | Anlagedatum | wann der Artikel in der SelectLine angelegt wurde | | Auswählbar | gesetzt, solange der Artikel nicht inaktiv ist | ## Preise | Einstellung | Wirkung | | ------------------------------- | ------------------------------------------ | | **Listenpreis exportieren** | überträgt den Listenpreis des Artikels | | **Alternativer Export-Preis** | überträgt stattdessen einen anderen Verkaufspreis |Die alternativen Preise sind die, die in der SelectLine in den Artikelstammdaten unter der Preisaufschlüsselung des Verkaufs stehen — etwa ein bestimmter Preistyp oder eine Preisgruppe.
Ohne einen dieser beiden Wege bekommen die Produkte in Pipedrive keinen Preis. Ein Deal lässt sich dann nur mit Menge, aber ohne Wert bilden.
Mehrere Preise je Artikel sind derzeit nicht möglich — es wird genau einer übertragen.
Siehe [Leistungsbeschreibung](https://wiki.dako-it.com/books/finnpipedrive/page/leistungsbeschreibung). ## Artikelstatus in einem eigenen Extrafeld Pipedrive kennt bei Produkten nur *auswählbar* oder *nicht auswählbar*. Wer die drei Zustände der SelectLine sehen will, hinterlegt ein Extrafeld vom Typ **Einzeloption**.  | Einstellung | | | ------------------------------------------- | -------------------------- | | **Status-Extrafeld verwenden** | schaltet die Funktion ein | | **Pipedrive-Extrafeld für Status eines Produkts** | das Extrafeld | | **Status für aktive Produkte** | ein Auswahlwert des Feldes | | **Status für auslaufende Produkte** | ein Auswahlwert des Feldes | | **Status für inaktive Produkte** | ein Auswahlwert des Feldes | ### Wie der Status ermittelt wird | In der SelectLine | Status in Pipedrive | | ------------------------------------------ | -------------------- | | Artikel ist **inaktiv** | inaktiv | | **Auslaufdatum** liegt in der Zukunft | auslaufend | | Auslaufdatum liegt in der Vergangenheit | inaktiv | | kein Auslaufdatum, nicht inaktiv | aktiv |Mit dieser Funktion sind alle Produkte in Pipedrive auswählbar — auch die in der SelectLine inaktiven. Die Sperre über Pipedrives eigene Deaktivierung wird dann nicht mehr genutzt. Der Vertrieb muss sich also auf das Statusfeld verlassen, statt darauf, dass ein Produkt gar nicht angeboten wird.
Der Vorteil: Der Grund ist sichtbar. Ein auslaufender Artikel lässt sich noch verkaufen, ein inaktiver ist als solcher erkennbar — statt einfach zu fehlen.
## Artikelbilder | Einstellung | | | ------------------------------- | ------------------------------------ | | **Produktbilder exportieren** | überträgt das Artikelbild zum Produkt |Ist der Haken gesetzt, erscheint in der Zeitsteuerung eine zusätzliche Aufgabe SelectLine-Artikelbilder exportieren. Sie läuft getrennt von den Artikeldaten, weil Bilder deutlich mehr API-Tokens kosten.
Ein Bild kostet bis zu 30 Tokens — ein Vielfaches eines Artikels. Bei großen Sortimenten gehört diese Aufgabe auf eine feste Zeit in der Nacht.
Siehe [API-Tokens](https://wiki.dako-it.com/books/finnpipedrive/page/api-tokens). ## Weitere Artikelfelder übertragen Über das **SelectLine-Artikelstammdaten-Mapping** lassen sich weitere Felder in Pipedrive-Extrafelder schreiben.  Zur Verfügung stehen drei Tabellen: | Tabelle | Inhalt | | ----------- | ---------------------------------------------- | | `ART` | die Artikelstammdaten | | `ARKALK` | die Kalkulation, etwa Einkaufs- und Kalkulationswerte | | `ARTLIEF` | die Lieferantenzuordnung des Artikels |Wer Einkaufspreise oder Kalkulationswerte aus ARKALK überträgt, macht sie damit allen sichtbar, die den Deal in Pipedrive öffnen. Das gehört vorher abgestimmt.
Dieser Bereich setzt Kontakte und Produkte voraus. Ein Deal hängt an einer Organisation oder Person und besteht aus Produktpositionen — fehlt beides, ist der Deal in Pipedrive nicht nachvollziehbar.
Siehe [Kontakte](https://wiki.dako-it.com/books/finnpipedrive/page/kontakte) und [Produkte](https://wiki.dako-it.com/books/finnpipedrive/page/produkte).Übertragen wird von der SelectLine nach Pipedrive. Die Einstellung Pipedrive-Deals importieren ist mit Coming Soon gekennzeichnet und hat derzeit keine Wirkung.
## Grundeinrichtung Drei Dinge sind nötig: | Schritt | Wo | | ------- | ------------------------------------------------------ | | 1 | Häkchen **SelectLine-Belege exportieren** im Bereich *Beleg-Austausch* | | 2 | mindestens eine **Pipedrive-Pipeline** aktivieren | | 3 | je zu übertragendem Belegtyp ein **Belegtyp-Mapping** anlegen | ### Pipelines aktivieren Nur Pipelines, die hier aktiviert sind, stehen der Schnittstelle zur Verfügung. Damit lässt sich die Schnittstelle auf den Vertriebsprozess begrenzen, für den sie gedacht ist — andere Pipelines im Haus bleiben unberührt.
### Belegtyp-Mapping Je Belegtyp der SelectLine wird die Zielphase in Pipedrive festgelegt.  Angegeben werden **Pipeline**, **Stage** und **SelectLine-Belegtyp**.Ohne mindestens ein Belegtyp-Mapping wird nichts übertragen. Was hier nicht steht, bleibt in der SelectLine.
Damit wird der Beleglauf im CRM sichtbar: Ein Angebot landet in der Angebotsphase, wird es zum Auftrag, wandert der Deal in die Auftragsphase — ohne dass jemand in Pipedrive etwas verschiebt.
## Belegangaben in Extrafeldern Fünf Angaben aus dem Beleg lassen sich in Pipedrive-Extrafelder schreiben: | Einstellung | Inhalt | | -------------------------------------------------------- | -------------------- | | **Pipedrive-Extrafeld für Belegnummer in der SelectLine** | die Belegnummer | | **Pipedrive-Extrafeld für Auftragsnummer in der SelectLine** | die Auftragsnummer | | **Pipedrive-Extrafeld für Projektnummer in der SelectLine** | die Projektnummer | | **Pipedrive-Extrafeld für abweichende Lieferadressen aus der SelectLine** | die Lieferadresse, wenn sie abweicht | | **Pipedrive-Extrafeld für Zahlungsbedingungen aus der SelectLine** | die Zahlungsbedingung |Das Feld für die Belegnummer ist das wichtigste: Damit ist im Deal zu sehen, welcher Beleg in der SelectLine dahintersteht — und der Vertrieb kann im Zweifel dort nachsehen.
## Akzeptierte Bestellungen Hier wird festgelegt, welche Belegtypen als **verbindliche Bestellung** gelten.  Je aufgenommenem Belegtyp lässt sich zusätzlich ein Extrafeld vom Datentyp **Datum** angeben, in das das Bestelldatum geschrieben wird.Diese Angabe wirkt weit über die Belege hinaus. Sie ist die Grundlage für Umsätze, Bestellanzahl, Erst- und Letztbestelldatum, die Bestellhistorie der Produktkategorien und das Lead-Handling in den Kontakten. Ohne mindestens einen Belegtyp bleiben alle diese Felder leer.
Üblich ist der Auftrag: Ein Angebot ist noch keine Bestellung, eine Rechnung kommt zu spät für die Vertriebssteuerung.
Siehe [Kontakte](https://wiki.dako-it.com/books/finnpipedrive/page/kontakte). ## Was am Deal ankommt | In Pipedrive | Aus der SelectLine | | ------------------------- | ------------------------------------------ | | Deal mit Titel und Wert | der Beleg | | Organisation oder Person | die Adresse des Belegs | | Positionen | die Belegpositionen als Produkte | | Rabatt | ein Belegrabatt, sofern vorhanden | | Phase | aus dem Belegtyp-Mapping | ## Wenn ein Beleg übergeben wird Übertragen wird immer der Beleg, der in der Belegkette am weitesten fortgeschritten ist. Wird aus dem Angebot ein Auftrag, entsteht der Deal in der Auftragsphase — und der Deal des **Vorgängerbelegs wird in Pipedrive gelöscht**.So steht je Vorgang genau ein Deal in Pipedrive und nicht eine Kette aus Angebot, Auftrag und Rechnung, die alle denselben Umsatz zeigen.
Gelöscht wird der ganze Deal — mit allem, was in Pipedrive daran hängt: Notizen, Aktivitäten, Dateien. Wer am Angebot arbeitet und Notizen im Deal führt, verliert sie, sobald der Auftrag in der SelectLine entsteht. Notizen gehören deshalb an die Organisation oder Person, nicht in den Deal.
Ebenfalls entfernt werden Deals, zu denen sich in Pipedrive kein Kontakt mehr finden lässt — etwa weil dessen CRM-Adresse inzwischen in einer ausgeschlossenen Kontaktgruppe liegt.
## Nächster Schritt [Aktivitäten](https://wiki.dako-it.com/books/finnpipedrive/page/aktivitaten) # Aktivitäten Die **Journale** der SelectLine werden in Pipedrive zu **Aktivitäten** — Anrufe, Termine, Aufgaben. Damit steht die Vorgeschichte eines Kontakts auch im CRM.Übertragen wird von der SelectLine nach Pipedrive. In Pipedrive angelegte Aktivitäten kommen nicht in die SelectLine.
## Grundeinrichtung Es wird festgelegt, welcher **Journaltyp** der SelectLine welchem **Aktivitätstyp** in Pipedrive entspricht. | Spalte | Inhalt | | ---------------------------- | ------------------------------------- | | **SelectLine-Journaltyp** | die Kontaktart des Journals | | **Pipedrive-Aktivitätstyp** | der Aktivitätstyp in Pipedrive | Angelegt wird ein Mapping über die Schaltfläche neben **Neues Aktivitätstyp-Mapping**.Nur Journale mit einer zugeordneten Kontaktart werden übertragen. Journale, deren Kontaktart in keinem Mapping steht, werden übersprungen — ohne Fehlermeldung.
Das ist der Filter dieses Bereichs: Statt einer Einstellung „welche Journale sollen mit" entscheidet die Liste der Mappings. Wer nur Anrufe und Termine im CRM haben will, ordnet nur diese beiden Kontaktarten zu.
## Woran eine Aktivität hängt | In Pipedrive | Aus der SelectLine | | ------------------------- | ------------------------------------------ | | Aktivitätstyp | über das Mapping aus der Kontaktart | | Teilnehmer | die im Journal verknüpften Adressen | | Deal | der im Journal verknüpfte Beleg, sofern er als Deal existiert |Ist am Journal ein Beleg verknüpft, der in Pipedrive als Deal steht, wird die Aktivität diesem Deal zugeordnet. So steht die Korrespondenz zum Angebot am Angebot.
## Zusammenspiel mit FINN.mail2SL Werden E-Mails über FINN.mail2SL automatisch als Journal abgelegt, erscheinen sie über diesen Bereich anschließend auch in Pipedrive.Das gehört bedacht, bevor beides zusammen eingeschaltet wird: Die Korrespondenz wird damit auch für alle sichtbar, die Zugang zu Pipedrive haben — nicht nur für die Anwender der SelectLine.
Siehe [FINN.mail2SL Handbuch](https://wiki.dako-it.com/books/finnmail2sl-handbuch). ## Aufwand Eine Aktivität kostet bis zu 5 API-Tokens, der Lauf selbst rund 52.Bei einem Haus mit vielen Journalen ist das der Bereich, der am schnellsten Tokens verbraucht.
Siehe [API-Tokens](https://wiki.dako-it.com/books/finnpipedrive/page/api-tokens). ## Nächster Schritt [Leads](https://wiki.dako-it.com/books/finnpipedrive/page/leads) # Leads Der einzige Bereich, der in die **andere Richtung** läuft: Leads aus Pipedrive werden in der SelectLine zu einem Beleg.Damit schließt sich der Kreis: Der Vertrieb erfasst eine Anfrage in Pipedrive, und in der SelectLine entsteht daraus ein Angebot — ohne dass jemand die Daten abtippt.
## Grundeinrichtung | Einstellung | Inhalt | | ------------------------------------------ | ------------------------------------ | | **SelectLine-Belegtyp für Pipedrive-Leads** | welcher Beleg in der SelectLine entsteht | | **Lead-Quellen importieren** | welche Lead-Quellen aus Pipedrive übernommen werden |Als Belegtyp ist das Angebot vorgegeben. Ein Lead ist eine Anfrage, kein Auftrag — deshalb ist das in fast allen Fällen der richtige Wert.
### Lead-Quellen Pipedrive vermerkt zu jedem Lead, woher er kommt — Webformular, Import, von Hand angelegt. Übernommen werden nur die Quellen, die hier ausgewählt sind.Ist keine Quelle ausgewählt, wird nichts übernommen. Der Lauf läuft dann durch, ohne etwas zu tun — das ist der häufigste Grund, weshalb keine Belege entstehen.
Die Auswahl der Quellen ist bewusst eng zu halten. Sonst landet jeder Lead, den jemand zum Ausprobieren anlegt, als Beleg im Mandanten.
## Welche Leads übernommen werden | Bedingung | | | ------------------------------------------------ | -------------------------- | | die Quelle steht in der Auswahl | Pflicht | | der Lead hängt an einer **Organisation oder Person** | Pflicht | | der Lead wurde seit dem letzten Lauf geändert | Pflicht |Ein Lead ohne verknüpften Kontakt wird übersprungen und im Protokoll vermerkt: Ohne Adresse ließe sich in der SelectLine kein Beleg anlegen. Wer die Übernahme nutzt, muss also in Pipedrive dafür sorgen, dass jeder Lead einem Kontakt zugeordnet ist.
Maßgeblich ist der Änderungszeitpunkt des Leads. Ein bereits übernommener Lead, der in Pipedrive erneut geändert wird, führt zu einem weiteren Beleg — die Übernahme aktualisiert keinen bestehenden.
## Was in der SelectLine entsteht Ein Beleg des eingestellten Belegtyps, mit der Adresse des verknüpften Kontakts. Die Belegnummer lässt sich in ein Pipedrive-Extrafeld zurückschreiben. | Einstellung | | | ------------------------------------------------ | -------------------- | | **Pipedrive-Extrafeld für Belegnummer in der SelectLine** | die entstandene Belegnummer |Das ist der Rückkanal: Am Lead in Pipedrive steht danach, welcher Beleg daraus geworden ist.
Diese Aufgabe schreibt in den Mandanten. Vor dem ersten Lauf gehört geprüft, welcher Belegtyp und welche Quellen eingestellt sind — und der erste Lauf am besten mit einem einzelnen Test-Lead.
## Aufwand Der Lauf kostet rund 22 API-Tokens; die entstehenden Belege selbst kosten keine, weil sie in der SelectLine angelegt werden.Das ist der sparsamste Bereich der Schnittstelle — er kann deshalb häufiger laufen als die übrigen.
Siehe [API-Tokens](https://wiki.dako-it.com/books/finnpipedrive/page/api-tokens). ## Nächster Schritt [Projekte](https://wiki.dako-it.com/books/finnpipedrive/page/projekte) # Projekte Die **Projekte** der SelectLine werden zu Projekten in Pipedrive — auf einem Board, in einer Phase, die sich aus dem Stand der Belege ergibt.Übertragen wird von der SelectLine nach Pipedrive. In Pipedrive angelegte Projekte kommen nicht in die SelectLine.
## Grundeinrichtung | Schritt | Wo | | ------- | ----------------------------------------------------------- | | 1 | ein **Pipedrive-Extrafeld für die Projektnummer** angeben | | 2 | mindestens ein **Pipedrive-Board** aktivieren | | 3 | je Phase ein **Projektphasen-Mapping** anlegen |Ohne das Feld für die Projektnummer läuft der Bereich nicht an — die Schnittstelle könnte ein Projekt in Pipedrive nicht wiederfinden.
## Projektphasen-Mapping Anders als bei den Belegen wird hier nicht ein Belegtyp einer Phase zugeordnet, sondern beschrieben, **was eine Phase bedeutet**. Aus den vorhandenen Belegen des Projekts ergibt sich dann die passende Phase. Je Mapping werden **Board** und **Projektphase** gewählt, dazu die Kennzeichen: | Kennzeichen | Bedeutung | | ---------------------- | ------------------------------------------------ | | **enthält Angebote** | in dieser Phase liegen Projekte, zu denen Angebote existieren | | **enthält Aufträge** | dito für Aufträge | | **enthält Rechnungen** | dito für Rechnungen | | **ist Erledigt** | die Phase für abgeschlossene Projekte | | **ist Standardphase** | die Phase für alles, was zu keiner anderen passt | In der Tabelle erscheinen diese Kennzeichen als **Übertragungskennzeichen** — eine kurze Buchstabenfolge: | Buchstabe | Kennzeichen | | --------- | ------------------ | | `A` | enthält Angebote | | `F` | enthält Aufträge | | `R` | enthält Rechnungen | | `E` | ist Erledigt | | `S` | ist Standardphase |Ein Mapping mit dem Kennzeichen AF ist also die Phase für Projekte, in denen sowohl Angebote als auch Aufträge liegen.
Die Standardphase lässt sich nur einmal vergeben. Ist sie einmal gesetzt, verschwindet das Häkchen aus dem Dialog. Sie ist das Auffangbecken für Projekte, auf die kein anderes Mapping passt — ohne sie bleiben solche Projekte in Pipedrive unsortiert.
Der Vorteil dieses Aufbaus: Die Phase in Pipedrive folgt dem tatsächlichen Stand des Projekts in der Warenwirtschaft. Kommt zum Angebot ein Auftrag, wandert das Projekt von selbst weiter.
## Aufwand Dieser Bereich ist der aufwendigste: Der Lauf kostet rund 152 API-Tokens, dazu 10 je Belegtyp und je aktiviertem Board, und 5 je Projekt.Bei knappem Tokenkontingent gehört diese Aufgabe auf eine feste Zeit — einmal am Tag genügt meist, weil Projekte sich seltener ändern als Belege.
Siehe [API-Tokens](https://wiki.dako-it.com/books/finnpipedrive/page/api-tokens). ## Nächster Schritt [Erstinbetriebnahme](https://wiki.dako-it.com/books/finnpipedrive/page/erstinbetriebnahme) # Erstinbetriebnahme Die Bereiche bauen aufeinander auf. Diese Reihenfolge führt zu einem Pipedrive, in dem alles zusammenpasst — und vermeidet Deals ohne Kunden und Positionen ohne Produkte. ## 1. In Pipedrive vorbereiten Bevor in FINN.ghost etwas eingestellt werden kann, muss in Pipedrive vorhanden sein: | Was | Wofür | | ---------------------------- | -------------------------------------------- | | ein **Benutzer** für die Schnittstelle | sein API-Token wird eingetragen | | die **Extrafelder** | für CRM-ID, Belegnummer, Projektnummer, Umsätze, Datumsangaben | | die **Label** | für Kunden, Lieferanten, Interessenten, Kontakte und die Leads | | die **Pipeline** mit ihren Phasen | Ziel der Belege | | das **Board** mit seinen Phasen | Ziel der Projekte |Diese Vorarbeit lohnt sich am Stück: Jeder spätere Aufruf der Einstellungen kostet API-Tokens, und ein Feld, das noch nicht existiert, erscheint hier nicht zur Auswahl.
## 2. Verbinden Abo, Firmendomain und API-Token eintragen, dann **Neustarten**. Siehe [Allgemeine Einstellungen](https://wiki.dako-it.com/books/finnpipedrive/page/allgemeine-einstellungen).Ohne den Neustart bleiben alle weiteren Bereiche und die Zeitsteuerung leer.
## 3. Kontakte einrichten Die beiden Stammdaten-Mappings für die CRM-ID anlegen, danach Label und die gewünschten Zusatzangaben. Siehe [Kontakte](https://wiki.dako-it.com/books/finnpipedrive/page/kontakte).Wenn Kontaktgruppen ausgeschlossen werden sollen, gehört das jetzt entschieden — nicht später. Nachträglich ausgeschlossene Kontakte werden in Pipedrive gelöscht.
## 4. Produkte einrichten Ziel für die Artikelnummer festlegen, Preis wählen. Siehe [Produkte](https://wiki.dako-it.com/books/finnpipedrive/page/produkte). ## 5. Belege einrichten Pipelines aktivieren, Belegtyp-Mappings anlegen, **akzeptierte Bestellungen** festlegen. Siehe [Belege](https://wiki.dako-it.com/books/finnpipedrive/page/belege).Die akzeptierten Bestellungen wirken zurück auf die Kontakte: Umsätze, Bestellzahlen und das Lead-Handling bleiben ohne sie leer. Deshalb danach noch einmal in die Kontakteinstellungen sehen.
## 6. Die übrigen Bereiche Aktivitäten, Leads und Projekte nach Bedarf — sie sind unabhängig voneinander. Siehe [Aktivitäten](https://wiki.dako-it.com/books/finnpipedrive/page/aktivitaten), [Leads](https://wiki.dako-it.com/books/finnpipedrive/page/leads) und [Projekte](https://wiki.dako-it.com/books/finnpipedrive/page/projekte). ## 7. Erstbefüllung von Hand starten Unter **FINN.pipedrive → Zeitsteuerung** die Aufgaben einmal in dieser Reihenfolge starten: | Reihenfolge | Aufgabe | | ----------- | ------------------------------------------- | | 1 | SelectLine-Kontakte exportieren | | 2 | SelectLine-Artikel exportieren | | 3 | SelectLine-Artikelbilder exportieren | | 4 | SelectLine-Belege exportieren | | 5 | SelectLine-Projekte exportieren | | 6 | SelectLine-Aktivitäten exportieren |Die Erstbefüllung ist der teuerste Vorgang der ganzen Einrichtung: Jeder Kontakt, jeder Artikel und jeder Beleg wird einmal angelegt. Bei größeren Datenbeständen reicht das Tageskontingent an API-Tokens dafür nicht aus — dann läuft die Befüllung über mehrere Tage.
Siehe [API-Tokens](https://wiki.dako-it.com/books/finnpipedrive/page/api-tokens).Deshalb lohnt es, mit den Kontakten anzufangen und erst weiterzugehen, wenn sie vollständig in Pipedrive stehen. Ein Deal ohne Organisation wird ohnehin wieder entfernt.
## 8. Ergebnis prüfen | Prüfung | | | ----------------------------------------------- | ------------------------ | | Stehen die Kontakte mit dem richtigen Label in Pipedrive? | Organisationen und Personen | | Ist die CRM-ID im Extrafeld gefüllt? | an einem Beispielkontakt | | Haben die Produkte einen Preis? | an einem Beispielartikel | | Liegen die Deals in der richtigen Phase? | in der Pipeline | | Steht die Belegnummer am Deal? | im Extrafeld |Ist die CRM-ID leer, wurden die Kontakte ohne Wiedererkennung angelegt. Dann gehört das Mapping ergänzt, bevor der nächste Lauf startet — sonst entstehen Dubletten.
## 9. Intervalle festlegen Erst wenn die Erstbefüllung steht, die Zeitsteuerung auf den Dauerbetrieb einstellen. Siehe [Automatisierung](https://wiki.dako-it.com/books/finnpipedrive/page/automatisierung). ## Nächster Schritt [Automatisierung](https://wiki.dako-it.com/books/finnpipedrive/page/automatisierung)