| Variable |
Attribute |
Definition |
| Beschreibung |
|
beschreibender Name für die Opportunity in Englisch |
Lokaler Name
(lokale Beschreibung) |
|
Beschreibender Name für die Opportunity in der Muttersprache, nur für AP, Kanada, EMEA und Lateinamerika |
| accountid |
|
eindeutige Kennung, die dem zugeordneten Orion-Kontonamen zugewiesen ist |
| salesGroup |
AE, AT, AU, BE, BG, CA, CH, CN, CZ, DE, DK, EE, ES, FA, FI, FR, GR, HK, HU, ID, IE, IN, IT, JP, KR, LN, LS, LT, MEIN, NG, NL, NEIN, NZ, PH, PL, PT, RO, RU, SA, SE, SG, SI, SK, TH, TM, TR, TW, UA, UK, VN, ZA (nur 1) |
Gibt das Standardland an, zu dem das Konto gehört. In der Regel repräsentiert dies ein Land, aber mehrere Vertriebsgruppen repräsentieren mehr als ein Land. Die salesGroup muss mit der salesGroup des Benutzers übereinstimmen, der die Anforderung sendet. Die Verkaufsgruppe des Landes der Vertriebsmitarbeiter muss berücksichtigt werden, wenn sie nicht Teil des Hoheitsgebiets ist. (Attribute listen nur die für JMP geltenden Verkaufsgruppen auf). (Siehe beigefügten Orion-Bericht für Vertriebsgruppenländer.) |
Art
(Opportunity-Typ) |
Software |
Standard ist Software |
inputSourceType
(Eingabequelle) |
Benutzer generiert |
Standard ist Benutzer generiert |
currencyCodeId
(Währungscode) |
AED, ARS, AUD, BRL, CAD, CHF, CLP, CNY, COP, CZK, DKK, DZD, EEK, EGP, EUR, GBP, HKD, Ft, IDR, ILS, INR, ISK, JMD, JOD, JPY, KES, KRW, KWD, LKR, WÜTEND, MWK, MXN, MYR, NGN, NOK, NZD, STIFT, PHP, PKR, PLZ, PTE, QAR, SAR, SEK, SGD, THB, TND, VERSUCH, TWD, USD, VEF, VND, XAF, XEU, ZAR, ZWD (nur 1) |
muss der Verkaufsgruppe angemessen sein. Einige Länder können mehr als eine Währung haben. Die Standardwährung basiert auf der Verkaufsgruppe. Liste pro Vertragswährungswebseite
|
| Menge |
|
steht für den Betrag der Upgrade-Gelegenheit |
Gelegenheit.MultinationaDeal
(Multinational) |
J oder N |
Dies sollte standardmäßig N für Standard-Upgrades sein. |
licenseBeginDate
(LBD) |
JJJJ-MM-JJ |
? Nicht in der API-Liste, sondern in der Beispieleingabe. Derzeit für eine Opportunity erforderlich. Das Datum des Inkrafttretens des Upgrades (15. oder letzter des Monats), sofern das Upgrade nicht am Jahrestag wirksam wird, an dem das Jahrestag der Site am 1. des Monats liegt. global bestätigen müssen). Die Fehlerprüfung für USA, Lateinamerika, Kanada und EMEA folgt diesen Regeln. |
customerBusinessObjectiveId
|
|
Standard ist Analytics-General (Sie müssen bestätigen, ob wir einen numerischen Wert für Analytics benötigen oder ob er der ID-Nummer von customerBusinessObjectiveGroupCode entspricht.) |
| customerBusinessObjectiveGroupCode |
|
Standard ist Analytics (Nicht in der API-Liste, sondern in der Beispieleingabe. derzeit für eine Opportunity erforderlich). |
liklihoodToCloseId
(Wahrscheinlichkeit zu schließen) |
10%, 25%, 40%, 50%, 60%, 75%, 90%, 99%, 100% |
Standard für Upgrades ist 100%. |
ips
(1) Datensatz besteht aus Employeeid, Territoryid, Roleid, OwnerType und Finder |
|
|
| Mitarbeiter-ID |
11177 - Pany Allen
6068 - Chuck London
4864 - Bonnie Rigo
9438 - Rene Kleinhans
9942 - Dara Hammond
2704 - Kathleen Watts
35814 - Robyn Godfrey
16994 - Anna-Christina De La Iglesia
36782 - Mike Pritchard
22160 - Krystal Barnes
31974 - Damian Carville
18696 - Rebecca Surendra
32832 - Malcolm Stevens
11331 - Christy Spanien
36785 - Nolan Mast
6798 - Lauren Buck
34832 - John Murphy
33552 - Frank Moser
13869 - Tim Pierce
11161 - Sam Tobin
18022 - David Schultz
32239 - Briana Bishop
33194 - Christopher Twardowski
31338 - Keith Blake
12489 - Bob Lamphier
0647 - Shelby Ross
17725 - Nick Salvatore
32879 - Stuart Nachbarn
32279 - Shawn Blakeman
36184 - Al Clark
0854 - Wendy Cottle
34691 - Margie Navas
33539 - Edgar Beere
36226 - Carl-Johan Hulten
36164 - Tony Conway-Hughes
33429 - Wolfgang Klein
E8078 - Manuela Merkhofer
37095 - Alexander Beck
E25619 - Simone Raab
35397 - Isabelle Swaenepoel
E29384 - Bernard McKeown
33167 - Ferenc Meszaros
34109 - Anna Roper
E23373 - Paolo Chiappa
E8238 - Akihiro Kawada
AP031 - Seiji Yamanaka
E60182 - Kiyomi Kato
32431 - Hiroko Imai
E60155 - Kenshu Shimomukai
E60330 - Satoru Kishi
E60082 - Hidehiro Jokan
32634 - Du ** piep ** o Kashima
35210 - Yosuke Adachi
E56233 - Daniel Tung
32604 - Xiaojun Shan
35422 - Maxing Lu
33834 - Jessica Wang
E56143 - Thomas Li
35423 - Elle Li
36745 - Iris Yuan
36543 - HoKeun Kil
36544 - JinYoung Lee
90960 - Luke Walker
3148 - Carol Gretz
|
RISIKO - Benötigen Sie eine Vorankündigung, wenn Änderungen an JMP AEs oder JMP IS Reps vorgenommen werden, um Zeit für die Orion-Programmierung zu haben. Dies ist eine ständig wechselnde Liste.
|
| territorial |
JA, J1, J2, J3, J4, J5, J8, J10, J13, J14, J16, J18, J19, J20, J21, J22, J24, J25, J26, J27, J28, J29, J30, J31, J32, J33, J34, J35, J36, J37, J38, J39, J40, J41, J42, J43, J44, J45, J46, J47, J48 |
Sie müssen bestätigen, dass dies der Gebietscode oder eine Nummer ist, die mit dem in der Attributliste angegebenen Gebietscode verknüpft ist. Hinweis Orion hat einen Gebietscode pro Verkaufsgruppencode in jedem Gebiet, haben sie also unterschiedliche ID-Nummern? Zum Beispiel: JA (SA) & JA (CA) oder J25 (LN) & J25 (LS) |
| Roleid |
|
KC, um mit Leigh Ann zu klären, ob wir "JMP AE" für alle JMP TSR Reps und JMP IS Reps verwenden können. Beeinflusst dies die Rolle, die in der GIDB für Standortzuweisungen abgerufen wird? |
| ownerType |
P (primär)
S (sekundär)
N (nicht Besitzer)
|
ein Vorschlag, den JMP AE (TSR) immer auf P und den JMP IS auf S zu setzen. Der Vertreter, der die ppw-Anforderung sendet, könnte als Finder markiert werden. Die Comit-Routing-Tabelle verwendet die Verkaufsgruppe des primären Eigentümers der Orion-Verkaufschance und acctid, die übereinstimmen sollten. Der Comit Sales Rep mit TSR sollte dann mit dem Primary (TSR) Rep vervollständigt werden. |
| Finder |
richtig oder falsch |
Nur bei (1) IP kann dies markiert werden. repräsentiert den Finder des Gegners. Vorschlag, entweder das JMP-Feld AE als Standard festzulegen, oder es könnte darstellen, wer den SF-Gegner zum Komitieren des Feldes AE oder des IS-Vertreters eingereicht hat. KEINE E-MAILS AN VERKAUFSREPPS !!! |
| firstPeriodTerm |
12 Monate, 13 Monate, 14 Monate, 15 Monate |
Standard für Upgrades sollte sein LEER |
| dealLength |
1, 2, 3, 4, 5 |
Standard für Upgrades sollte sein 1 |
| Aktualisierung |
richtig oder falsch |
Standard für Upgrades sollte sein wahr |
contactid
Kontaktname
|
|
|
Vertragsnummer
Vertrag |
bestehende Nummer |
eine bestehende Vertragsnummer pro Upgrade-Site, die auf die r-Nummer erforderlich ist |
| { Seite? ˅ } |
bestehende Standortnummer |
vorhandene Standortnummer, die aktualisiert wird. (Regel: Mehr als eine Standortnummer kann Teil derselben Upgrade-Gelegenheit sein, solange (sie ist Teil derselben Vertragsnummer) und das Upgrade für denselben Gültigkeitszeitraum gültig ist.)
LBD-Alias für das effektive Startdatum
Effective Period = LBD (Effective Start Date) + GIDB, bis zu welchem Datum bezahlt
|
offersId
Angebot / Produkt
|
2198 - JMP
4262 - JMP Clinical
2742 - JMP Genomics
4552 - JMP Pro
4554 - JMP-Software: Datenexploration
5516 - JMP-Software: ANOVA und Regression
5706 - JMP-Software: Klassische Versuchsplanung
5914 - JMP-Software: Kundendesign von Experimenten
Keine neuen Verkäufe, aber vorhandene GIDB-Sites mit diesen Legacy-Codes:
1674 - JMP 64-Bit-Edition
2132 - JMP Clinical 64-Bit-Edition
1372 - JMP Genetics
1966 JMP Genomics 64-Bit Edition
1955 - SAS Simulation Studio
|
Produkt, das aktualisiert wird.
siehe orion lookup codes: http: //misvap00.unx.sas.com: 7980 / SASVisualAnalytics / report? location =% 2FATLAS% 2FContent% 2FPublic% 2FOr ...
Hinweis: Bei einem Upgrade für E-Learning-Produkte wird nur die Opportunity von der Abteilung Bildung / Ausbildung durchgeführt (mit Carol bestätigen).
|
Menge (?)
FYF |
|
Standard Upgrade Gebühr pro C-calc.
Nicht standardmäßige Upgrade-Gebühr für manuelle Berechnungen.
|
bereinigter Betrag (?)
AFYF |
|
Standard für Standard-Upgrades ist LEER Wenn kein Rabatt gewährt wird, geben Sie die Gebühr ein, nachdem der Rabatt angewendet wurde. (Wenn ein Rabatt gewährt wird, muss eine Genehmigung beigefügt werden, um den Comit Sale-Datensatz zu ergänzen.) |
| Hebung (?) |
|
Standard für Standard-Upgrades ist LEER.
Die Standardeinstellung für nicht standardmäßige Upgrades ist LEER Sofern kein Erhöhungsprozentsatz gilt, wird ein Prozentsatz manuell eingegeben.
|
Prozentsatz (?)
Rabatt % |
|
Die Standardeinstellung für Standard- und Nicht-Standard-Upgrades ist LEER Sofern kein Rabatt gewährt wird, geben Sie den Rabatt in% ein. |
| Bestellnummer |
|
Standard für Upgrades ist LEER sofern keine Bestellnummer angegeben ist. |
| Quantentyp |
Benutzer insgesamt (nicht gleichzeitig) |
Gemäß dem GIDB-Quantentyp der Site
|
| Menge |
|
Der aktuelle Mengenbetrag pro GIDB (es sei denn, einige ausstehende Upgrades sind noch nicht auf der GIDB in der Warteschlange "Verträge" aufgeführt. Beispiel, wenn ein Kunde 5 separate Upgrades wünscht: 5-6, 6-7, 7-8, 8-9, 9-15. Für jedes einzelne Upgrade gibt es eine separate Gelegenheit. |
| Neue Menge |
|
Stellt die neue Menge dar, die sich nach dem Upgrade ergibt |
| urgentTypes |
Rechnung |
Standard ist BLANK. Wenn es eine Anfrage nach einem gibt Dringende Rechnung, Geben Sie INVOICE an und geben Sie die geschäftliche Berechtigung und die Genehmigung des Managers des Kunden in einer Notiz und einem Anhang an. |
| saleType COMIT-Verkaufstypen |
Aktualisierung |
Standard für Upgrades ist AKTUALISIERUNG |
| Notizen und Anhang |
|
Anhänge sollten Bestellungen, erforderliche Genehmigungen, Kundenautorisierungs-E-Mails usw. enthalten. Zitat oder Screenshot von c-calc. Notizen würden die Anhänge oder spezielle Anweisungen oder Verarbeitungsinformationen für Verträge enthalten. |
