# 130 · salespersonsfrombc

> Technisches Mapping des Jobs `salespersonsfrombc` (`BCSalesPersons`).

---

LLMS index: [llms.txt](/llms.txt)

---

| Eigenschaft | Wert |
|---|---|
| Order | 130 |
| Job | `salespersonsfrombc` |
| Mapping | `BCSalesPersons` |
| Richtung | BC → CE |
| Quellverbindung | BC_Test |
| Zielverbindung | CRM_Test |
| Quelltabelle (API) | `acdsalespersons` aus `singhammerITConsulting/dyce/v2.0` |
| Zieltabelle | `wysa_bcsalesperson` |
| Zeitplan | 0 */2 * * * * |
| Filter | `{{lastModifiedDateTime gt %watermark%}}` |
| Watermark | `lastModifiedDateTime` (Typ `datetime`) |
| Response-Job | — |
| Fachliche Doku | [Verkäufer aus BC](../stammdaten/bcsalespersons/) |

## Feldzuordnung

| Quellfeld | Zielfeld | Operation | Details |
|---|---|---|---|
| `id` | `wysa_bcsystemid` | — · **Schlüssel** | — |
| `code` | `wysa_code` | — | — |
| `displayName` | `wysa_name` | — | — |
| `eMail` | `wysa_emailaddress` | — | — |

## Alternate Key

```json
{
  "keyType": "CustomKey",
  "keyName": "wysa_bcsystemidkey",
  "keyValues": [
    {
      "attributeName": "id",
      "keyName": "wysa_bcsystemid",
      "rank": 1
    }
  ],
  "ignoreEmptySourceKey": false,
  "keyRank": 0
}
```

## Weitere technische Details

### Auflösung in den Belegketten

Das Nachschlagefeld ist stets `wysa_code`, nicht `wysa_bccode`:

| Mapping | Richtung | Operation |
|---|---|---|
| `BCAccounts` | BC → CE | `Lookup` über `wysa_bccodekey` |
| `CEAccounts`, `CEAccountUpdates` | CE → BC | `LookupValue` |
| `CEContacts`, `CEContactsUpdates` | CE → BC | `LookupValue` |
| `CEOpportunities` | CE → BC | `LookupValue` |
| `BCSalesQuotes` | BC → CE | `Lookup` über `wysa_bccodekey` |

### Beobachtungen

Auffällig ist, dass `BCContacts` den Verkäufer **nicht** aus BC abholt, obwohl beide
CE→BC-Mappings des Kontakts ihn senden.