nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Session 1: Account Validation

JonesieAtJMP · 2018-06-26T13:44:06+00:00

Current Process Flow Challenges with current process * Volume validation requests * Urgency / turnaround time on requests * Biz Ops supports account creation for JMP worldwide * DP orders process is inconsistent – to address in separate session * Too many validation request emails – need a “feed” of validation requests *…

JonesieAtJMP

Current Process Flow

Screen Shot 2018-06-26 at 9.38.50 AM.png

Challenges with current process

Volume validation requests
Urgency / turnaround time on requests
Biz Ops supports account creation for JMP worldwide
DP orders process is inconsistent – to address in separate session
Too many validation request emails – need a “feed” of validation requests
Process for updating Validated Accounts. If account is validated that means the information is already in Orion and can be match to. Daily job for ynching will fix this.
Data quality between two systems
Creating accounts that are not validated -- adding junk to SF
The sites tied together. This will be accomplished in the sites related list in Salesforce. Matching should be done via the Ultimate Duns instead of Parent Duns.
Manual adding of Duns and site number
How do we tie accounts together that are associated entities?
How to answer the question: “What’s going on at GE?” in a simple way
Corporate address (Account) vs. user address (site) — need field in SF to feed corporate address to ORION and to sync with ORION
Salesforce account structure needs to mimic that of Orion; that is, a hierarchy of sites under accounts

Possible Approach

High level flow

Daily synch of data in ORION to Salesforce
Sales would first query the ORION table in SF for existing validated account/site
If found, associate with opportunity
If not found, request creation of new account by Biz Ops
Biz Ops would then notify sales when new account was available
Sales would update opportunity with account information

Assumptions

Would require clean up of current, non-validated accounts against ORION
Would need to train sales on what sources to query if account not found so that they can pass along useful information from which Biz Ops could create an account.
Train teams on whyfields are required
Success hinges on client-side validation and requirement of certain values in Salesforce, as well as training
New accounts need to have Duns and Site# in Salesforce after account created in ORION
Synch ORION account ID – Use company name and address to attempt match
Synch ORION contact ID – Use first and last name, company, state if email not available
Sources for new acct. validation: Google, Orion, Hoovers, company web site, Secretary of State, EIS

Proposed Flow (Draft)

Comments

kathycobb

I would like to add some definitions and examples to keep in mind when designing SalesForce 3.0

Definitions

Site

Within SAS, a Site refers to the unique number assigned to a license in the GIDB that identifies the software product(s) that are authorized for use on designated hardware and a designated operating system.
Each Site number must include a base or stand-alone product.
Each Site is linked to a Contract Number representing either a SAS Master License Agreement, Click Agreement, or possibly an Evaluation Agreement.
It is good to keep in mind "GIDB Site" for the above bullets

Externally, the term "Site" has a different meaning. Customers refer to a "site" as the number that appears on their setinit which is an 8 or 9 digit number consisting of the combined contract number and CPU group number, such as 01194004. This number can be searched in the GIDB using the “Tech Support #” or “Setnumid” variable.

Contract Number

Represents the unique value assigned on the GIDB for the License Agreement.
Depending on the type of License Agreement in place, multiple related Accounts can be licensed under the same Contract Number.
If a Click Agreement is in place, only (1) Account referencing (1) JMP Store order (customer can license JMP for Windows & Mac and JMP Pro for Windows & Mac thus resulting in (4) GIDB sites under (1) Click Agreement). After the original Click Agreement is in place, no additional software can be licensed under the Click Agreement.
REF4 was the previous variable name in the legacy IDB for Contract

Account

is a single legal entity at a unique physical location.
An Account can have several Contract Numbers based on the different License Agreements they have in place. For example: a customer can have (1) Site licensed under a Master License Agreement and (1) Site licensed under a Click Agreement.

The Products JMP and JMP Pro require (1) GIDB Site per product/operating system combination. This is for media and SETINIT (product authorization code) purposes.

The Solutions JMP Clinical and JMP Genomics require (2) GIDB Sites per Solution/operating system bitness (32 or 64)

The JMP Academic Suite Bundle requires up to (7) GIDB Sites: (1) Site for the Invoicing Product Code(s) and (1) Site for each product/operating system combination.

A JMP Partner license requires a minimum of (2) Sites: (1) Site is the fee-waived invoicing site with up to (3) Partner Type Product codes JMPCUSPTR, JMPTRNPTR, JMPCLNPTR and the other Site(s) are for each product and operating system.

Examples of JMP GIDB Sites

1. A Customer (Account) has an Annual license (Master License Agreement) for JMP on Windows and Mac. This is represented on the GIDB as (2) Sites under (1) MLA Contract Number:

Contract 67981

Site 623875 (1 WX6) JMP

Site 661342 (1 MX64) JMP+

(Note: the "1" in the parenthesis with the Operating System code is the CPU Group number. When Products/Sites are related, they are added to the same CPU Group number. In the case above, the JMP+ is an add-on to the base JMP product).

A Customer has 2 separate JMP Store licenses (Click Agreements) each for JMP on Mac. This is represented on the GIDB as 2 separate Contract Numbers each with 1 Site number:

Contract 112023

Site 906692 (1 MX64) JMP

and

Contract 111753

Site 905738 (1 MX64) JMP

A Customer (Account) has an Annual license (Master License Agreement) for JMP Clinical on Windows 32-bit and JMP Clinical on Windows 64-bit. This is represented on the GIDB as a total of (4) Sites:
1. (2) Sites for the JMP Clinical on Windows 32-bit (1 site for the SAS products of the solution and 1 site for the JMP Product of the solution)
  and
2. (2) Sites for the JMP Clinical on Windows 64-bit (1 site for the SAS products of the solution and 1 site for the JMP Product of the solution)

Contract 19675

Site 617977 (9 WNDW) SAS, CLINJMP

Site 617980 (9 WNDW) JMP4CLIN
Site 851855 (9 WX6) SAS, CLINJMP, CLINTLKT

Site 851856 (9 WX6) JMP4CLIN

An Academic Customer (Account) has an Annual Campus wide license (Master License Agreement) for the JMP Academic Suite that is represented on the GIDB as a total of 7 Sites: (1) Site is the invoicing site with the Product JMPACDST and the other (6) sites are for each product and operating system:

Contract 12854
Site 603156 (9 WNDW) JMPACDST
Site 543013 (9 WNDW) JMP
Site 603598 (9 WX6) JMPPRO
Site 603599 (9 MX64) JMPPRO
Site 603601 (9 WX6) JMP
Site 603602 (9 WNDW) SIMSTUDIO
Site 895105 (9 WX6S) JMPPRO
An Academic Customer (Account) has an Annual Campus wide license (Master License Agreement) for the JMP Academic Suite and the add-ons JMP Clinical for JMP Academic Suite and JMP Genomics for JMP Academic Suiterepresented on the GIDB under (1) Contract Number and a total of 14 Sites. (1) Site is the invoicing site for all (3) Offerings JMPACDST, JMPCLNACD, and JMPGENACD, and the other (13) sites are for each product and operating system:

Contract 39466
Site 527702 (107 WX6) JMP

Site 530070 (107 MX64) JMP

Site 565806 (107 WNDW) JMPACDST, JMPCLNACD, JMPGENACD

Site 565854 (107 WX6) JMPPRO

Site 589084 (107 MX64) JMPPRO

Site 589087 (107 WNDW) SIMSTUDIO

Site 589088 (107 WNDW) SAS, CLINJMP, CLINTLKT
Site 589089 (107 WX6) SAS, CLINJMP, CLINTLKT

Site 589090 (107 WNDW) JMP4GEN

Site 604227 (107 WNDW) JMP4CLIN
Site 606088 (107 WX6) JMP4GEN

Site 606090 (107 WX6) JMP4CLIN

Site 875507 (107 WNDW) SAS, GENOMICS

Site 875520 (107 WX6) SAS, GENOMICS

A JMP Partner (Account) has an Annual Partner license (JMP Partner Program Agreement) for JMP Pro on Windows and Mac that is represented on the GIDB as a total of 3 Sites: (1) Site is the fee-waived invoicing site with (2) of the (3) Partner Type Product codes JMPCUSPTR and JMPTRNPTR and the other (2) sites are for each product and operating system:

Contract 110619

Site 901090 (1 WX6) JMPCUSPTR, JMPTRNPTR

Site 901091 (1 WX6) JMPPRO

Site 901092 (1 MX64) JMPPRO

A GIDB Contract can have Sites licensed to more than (1) related Account. The Master License Agreement allows for related entities to each sign Supplements that reference the (1) Master License Agreement:

1. Agreement Structure.

1.1 MLA; Supplements; Conflicts. "...Customer and its related Entities, as defined below, may license SAS software ("Software") or may acquire services ("Services") from SAS by executing supplements to this MLA ("Supplements"). each Supplement will identify the entity that will be deemed "Customer" for the purposes of that Supplement. This MLA and each such Supplement (collectively, "Agreement") govern Customer's license of Software listed on teh applicable Supplement and related on-line documentation made available by SAS with each license of the Software ("Documentation") or Customer's acquistion of Services listed on the applicable Supplement....

1.2 Related Entities. A Related Entity may license Software or acquire Services by signing a Supplement referencing this MLA and paying the applicable Software license fees or Service fees. In such event, the Related Entity shall be the "Customer" and shall be deemed to have adopted all the terms and conditions of this MLA for purposes of that Supplement. One Customer may not access a different Customer's licensed Software even though the Supplements reference this same MLA. A "Related Entity" is a separate legal entity located in the same country as Customer that is controlled by, is under common control with, or controls Customer. The term "control" means (a) for commercial entities, ownership of more than fifty percent (50%) of the voting stock or assets of an entity or (b) for non-profit or governmental entities, statutory or other documented legal authority over the general budget and contracting rights of an entity."

Example: The Ultimate Parent, Rho, Inc. signed MLA 34619.

Rho, Inc. (the Ultimate Parent) signed Supplement 5 for JMP Clinical

ORION Account: Rho, Inc. (#2872625 SA) E

GIDB Company Name: RHO INC (Note that the GIDB does not list the proper Legal entity name)

Site 640144 (3 WX6) SAS, CLINJMP, CLINTLKT

Site 640496 (3 WX6) JMP4CLIN

RHO Federal Systems Division, Inc (a Subsidiary of Rho, Inc.) signed Supplement 14 for JMP Genomics

ORION Account: RHO Federal Systems Division, Inc (#2792624 SA) E
GIDB Company Name: RHO FEDERAL SYSTEMS DIVISION INC (Note that the GIDB does not list the proper Legal entity name)

Site 671804 (8 WX6) SAS, GENOMICS

Site 671939 (8 WX6) JMP4GEN

kathycobb

Here is some feedback, clarification, or additional comments...

Biz Ops supports ORION account creation for JMP worldwide
Process for updating Validated Accounts. If account is validated that means the information is already in Orion and can be match to. Daily job for synching will fix this.
- A reminder that all Account information in ORION is not always clean or up-to-date:
- The original process allowed for a lot of manual data entry, but the current process is for the DUNS number to drive the current D&B information. D&B is not always current so challenge information is provided to D&B for them to research and to update D&B as appropriate. So this could take weeks or a month or 2 for D&B and then ORION to be updated.
- There are some ORION Accounts that have been created, but not “verified”, so they will provide a message that the Account Needs Resolving. Some resolve accounts can be done by a user but some are more complex and need to be done by the ORION Team. So if an ORION Account has the “Needs Resolving” message, is should not be considered a “Valid Account” by SalesForce in the Proposed Flow (draft) flowchart.
- There are some ORION Accounts that were created in the wrong Salesgroup. So a new ORION Account will need to be created in the correct Salesgroup and then the ORION Team will need to move over any information on the incorrect Account.
- There are some ORION Accounts that have incorrect information and need to be reviewed and updated. There are fewer ORION users that have “Create Account” access to ensure data quality than when ORION was first released.
Manual adding of Duns and should be ORION Account ID not site number. Need to remove the (1) location of Site since an Account can have multiple site numbers & contract numbers.
Corporate address (Account) vs. user address (site) — need field in SF to feed corporate address to ORION and to sync with ORION – Note: The ORION Account Physical address (the physical location of the Company) equals the address in Hoovers and cannot be manually changed in ORION. There is a process to provide updated information to the D&B team and they will research and if can be confirmed with the customer, D&B will update Hoovers which will eventually update ORION.

The Account Screen in SalesForce needs to be redesigned. Here are some of our recommendations…

Remove Shipping & Billing labels and exchange with Corporate Physical Address and Corporate Mailing Address
Remove “Site” and “Contract #”
Remove “Reconciled with Orion”
Add Salesgroup (Need More Discussion on Salesgroup since not discussed in any of the previous SFDC 3.0 meetings)
Add ORION Account ID
Add D&B Primary SIC Code
Add Account Approved Date
Should we be addressing more parameters to address US SMB such as # of employees, Subsidiary yes or no, etc….?

Account needs the Corporate Physical Address which will be the address on the Licensing Documents (Need Physical Address & Mail Address)

Contacts should have an assigned Role with the shipping & billing information which are the GIDB Contact addresses.

Sales would first query the ORION table in SF for existing validated account/site

Would require clean up of current Validated and non-validated accounts against ORION
Need to add all existing Global GIDB customers in SalesForce and accounts to be validated. Note: The GIDB only allows for UPPERCASE so the Customer Name (Account Name) will not always be correct. Need to refer to ORION which has Mixed Case.
Train teams on why fields are required

Ensure the proper legal company (account) name is listed in SalesForce and Orion. Why?

We need a valid Account name in Orion. It is SAS’ global customer relationship tool and more. One version of a unique Account Name for data quality. Aka’s, tradestyle names, and legacy names can all be associated with the Primary Account Name.
It is important for us to follow that standard established by SAS even though JMP uses SalesForce because JMP Opportunities must flow through Orion to be processed by Legal and Licensing Operations Worldwide.
Consistent use of the proper legal company name on all quotes generated by JMP Sales in SalesForce and any potential licensing documents created out of Orion.

Confirm the SalesForce Corporate Physical Address is a valid location for the Account name and that the County or Province is listed in SalesForce. Why?

The Corporate Physical Address is used to search Hoovers in order to select the correct Account and DUNS number.
The Corporate Physical Address is required information to complete the Orion New Account and Validation Request webform if the Account cannot be found in Hoovers and Orion.
The County or Province is:

Required on the licensing documents
Criteria for determining some US and China JMP territories

Locate and add the DUNS number to the Account in SalesForce. Why?

Extra confirmation that we have the right account
An upcoming SalesForce enhancement will create an account related sites list based on the DUNS number.

Locate and add the Orion Account ID to the Account in SalesForce. Why?

The Orion Account ID is one of the JOI Project API requirements to open an Orion Opportunity and Comit Sales record.

Add the SalesGroup to the Account in SalesForce. Why?

The SalesGroup code is one of the JOI Project API requirements to open an Orion Opportunity and Comit Sales record.
The SalesGroup code drives the ORION currency values and COMIT routing table (determines who the request is assigned based on the territory code and SalesGroup code of the primary owner for the software Opportunity. The owner of the request is a member of sales processing, contracts or legal.)

New accounts need to have Duns and ORION Account ID Site# in Salesforce after account created in ORION
Synch ORION account ID – Use company name and address and Salesgroup code to attempt match
Synch ORION contact ID – Use first and last name, company, state if email not available.Need to have a separate meeting on Contacts.

Need to have Orion Contact ID and Roles for Contacts. Need to take into account GDPR rules. Here are Contact fields that are needed:
*Contact Input Source: (provide a drop-down list. Pick one):
com
Third Party
User Generated
*Contact Origin: (provide a drop-down list. Pick one):
American Banker
Brightvision
ClientIQ
Common Wealth
Company Homepage
Company Information
Direct contact (meeting or incoming call/e-mail)
DiscoverOrg
Eight
Facebook
GovWin IQ
Grow Nordic
Hoover’s
IBISWorld
IDA
Insight Event
JMP
Kakao Talk
Leadership Federal Government Insight
Legacy
Line
Linkedin
Management Events
Markedsforing
Money Live
Personal Card / Business Card
Retail Institute Scandinavia
SAS Chat
Sophia for Retail and Manufacturing
Twitter
WeChat
Wednesday Relations
Weibo
Xing
*Contact Origin Date: (Date first contact with Contact)
*Contact Name:
Contact Job Title:
*Contact Role: (provide a drop-down list. Pick one):
Administrator
Adversary
Advisor
Analyst
Analytic Champion
Beneficiary
Billing
Delivery
EDU – Books
EDU – Data
EDU – Invoice
EDU – Primary
EDU – Service Coordinator
EDU – Site Technical Specialist
End User
Financial
Key Decision Maker
Legal
Marketing
Media Relations
Other
Partner
Partner – Affiliate
Partner – Gold
Partner – Platinum
Partner – Silver
Power Sponsor
Power User
Procurement
Project Manager
Sponsor
Statistician
Technical
*Contact Phone:
□Do Not Call
*Contact Email:
□ Opt In □Opt Out
*Contact Address Type: (provide a drop-down list. Pick one):
Bill
CPU
Deliver
Home
Mailing
Market
Primary SAS Rep
Ship
Tax
*Contact Address Line 1
Contact Address Line 2
Contact Address Line 3
Contact Address Line 4
Contact City
Contact County
Contact ST/CO/PR
Contact Postal Code
Contact Country
Contact Language:

kathycobb

Here is a SWW link regarding ORION Contact Information with regards to GDPR:

http://smportal.sas.com/SMNews/articles/Pages/SU10MAY18S.aspx?utm_source=daily_update&utm_medium=archive&utm_campaign=10May2018

Here is the information...

Important ORION change for all Contact Records

BY DEIRDRE ARNOLD AND VOLKER EMDEN

The European Union's (EU) General Data Protection Regulation (GDPR) comes into effect on May 25, 2018. Under GDPR, we must be able to inform EU residents of the origin of the information we have about them.

How SAS will capture origin information in ORION

Starting May 12, ORION contact records will contain a new field called "Origin" that will complement the existing "Input Source" field. The "Input Source" field will be limited to three possible values:

User Generated: Contact data directly or manually entered into ORION via the "Contact Record" screen. This will be the only input source value that is available for Sales users of ORION.
Third Party: Contact data purchased from third parties and imported via staging or “Validator.” If Sales team members need to upload contact lists, they should work with their local Marketing Science contacts to ensure the "Third-Party Source" field is complete. Otherwise, errors will be encountered during the upload.
SAS.com: Contact data from SAS internal systems, such as www.sas.com, EDW, etc.

For all existing contacts in ORION, the "Origin" value will be set to “Legacy.” For all new contacts added to ORION, a value must be selected in the "Origin" field. This will be a required field globally.

The possible values for the "Origin" field will differ based on the "Input Source" value. The drop-down list of possible "Origin" values contains most of the known origins, including various social media platforms, contact databases and direct contact with an EU resident. Your ORION Champion can help you get new "Origin" values added to the drop-down list.

ORION users will also need to enter the "Origin Date" on the contact record, which is intended to be the date that we received or collected the personal data, not the date that the ORION contact record was created. Please remember, the "Origin" and "Origin Date" fields will become read-only once the contact record is saved.

How this affects our first communication with a contact

When contacting an EU resident, prospect or customer for the first time, we must be able to inform that individual of the source of the data we have about them. This is especially important when we've received their data from third-party sources. This requirement only applies to the first time you contact an individual.

Consult the "Origin" field in ORION before reaching out to an EU resident for the first time, so you're prepared to tell them where we obtained their personal data. If the "Origin" field says “Legacy” and your contact wants to know where we obtained his or her personal data, reach out to your local Marketing Science contact:

Asia Pacific – Greg Wood
Canada and Latin America – Marina Jovicic
EMEA – Søren Borg
US – Julie Chalk

Important reminders

Check the “Do Not Contact” flags in ORION before contacting a prospective customer.
If you're using social media to connect with or contact a prospective customer, make sure you're following oursocial selling guidelines. Contact your Legal representative with questions.
All marketing emails must contain an opt-out option and a link to the SAS Privacy Statement. In some countries, marketing communications sent via email or instant message require prior opt-in consent. Learn more.

kathycobb

I am adding email information from SAS Legal that was forwarded to Biz Ops by Kelli Jackson regarding GDPR and some examples. this information will be helpful in the design of SFDC 3.0 and to consider when discussing Contacts.

From: Melissa Roy
Sent: Friday, June 29, 2018 5:04 PM
To: Jeffrey Smith <Jeffrey.Smith@sas.com>; Alan Wrobel <Alan.Wrobel@sas.com>; David Yoon <David.Yoon@sas.com>; Matthew Montaigne <Matthew.Montaigne@sas.com>; Heather Bridgers <Heather.Bridgers@sas.com>; Kelli Jackson <Kelli.Jackson@sas.com>; Dudley Padgett <Dudley.Padgett@sas.com>; Tamisa Greening <Tamisa.Greening@sas.com>; Meghan Knight <Meghan.Knight@sas.com>; Ayse Yolcu <ayse.yolcu@sas.com>; Ramez Saad <Ramez.Saad@sas.com>; Okeletsang Mookeletsi <Okeletsang.Mookeletsi@sas.com>; Ying Zhang <Ying.Zhang@sas.com>; Digish Rawal <Digish.Rawal@sas.com>; Terry Williams <Terry.Williams@sas.com>; Chris Haskell <Chris.Haskell@sas.com>; Jimmy Elliott <Jimmy.Elliott@sas.com>; Ingo Macht <Ingo.Macht@sas.com>; Patricia Brown <Patricia.Brown@sas.com>
Cc: Brian Zuercher <Brian.Zuercher@sas.com>; Jay Exum <Jay.Exum@sas.com>; Kelly Perry <Kelly.Perry@sas.com>
Subject: GDPR scenarios and some additional information

Hi Everyone:

Several of you have asked for the “key” to the “Subject to GDPR/Not Subject to GDPR” game we played during our first GDP Mini Workshop. Please flow down to your reports.

These are the SAS scenarios that are subject to GDPR:

Receiving a data set that includes the names of EU citizens
Analyzing a data set in France that includes credit scores for EU citizens
Emailing a list of all employees in the EU who access a customer’s system
Storing data that includes email addresses of EU citizens
Remotely viewing data that includes usernames of EU citizens
Remotely viewing EU business email addresses for a proof-of-concept
Receiving a Customer Contact Information form with business contact information of the Customer’s SAS contracts in Denmark
Receiving a list of EU corporate officers and directors
Displaying a data set of EU names and addresses during a web conference
Storing anonymized EU personal data, where the customer has the “key” to decode it but SAS does not
SAS Technical Support remotely viewing a systems log with EU IP addresses
Using Finland employee email addresses for SAS’ administrative purposes – such as sending an invoice
Erasing records containing names of EU citizens

These are the SAS scenarios that are not subject to GDPR:

Analyzing a data set in the US only that includes credit scores of EU citizens
Receiving a data set that includes names of EU companies
Yoga outside a building in SAS Germany while wearing a name tag
Yoga at the RFC at SAS headquarters in Cary
Storing anonymized EU personal data where no key to decode it exists anywhere in the world
Eating an ice cream cone in Building R

Jay Exum has also kindly provided us with some more information about determining if GDPR applies. I’ve found it quite helpful, so I’ve added it to this email as follows:

People routinely assume that the application of the GDPR is driven by the nationality of the person about whom data is collected, but that’s not quite right. GDPR jurisdiction is a two-step analysis. One step is fairly straightforward, but the other is less so.

(The legal gibberish can be found in Article 3 of the GDPR for reference).

Step 1: Is the controller or processor that is engaged in processing the personal data established in the EU? If yes, then the GDPR applies to all personal data it processes regardless of whose personal data it is. If no, then go to step 2.

Example: You go on vacation in Paris and stay at the Paris Novatel. You are visiting from Botswana. Your data is covered by the GDPR because the Paris Novatel is established in the EU. The fact that you’re from Botswana doesn’t matter.
Nuance for nerds: generally this means that the entity is organized in the EU (i.e. it’s French corporation). But “establishment” can be broader than that. For most of our purposes, though, location of the corporate entity will serve as a fine proxy.

Step 2: We’re now dealing with a controller or processor who is not established in the EU. Our 2-part question is Does the processing activity done by this processor relate to either (a) the offering of goods and services to data subjects in the EU, OR (b) the monitoring of the behavior of data subjects that occurs in the EU? If yes, GDPR applies. If no, GDPR does not apply and none of its joys enter your life. Note that nowhere here is anyone’s citizenship considered.

Example: Oliver Schabenberger is German. When he goes to the Health Care Center and provides his information, the fact that he is German is of no consequence. He is not in the EU and is not being offered goods and services there, and to the extent any monitoring of him occurs, it is not being done in the EU. So the GDPR does not apply.
Example: You sell retread tires out of your garage in Fuquay, and learn that the Polish are really into retreads. You start advertising in Poland and collecting information about prospective customers. Even if you never set foot in Poland and dislike the climate, that information is covered by the GDPR and all of its requirements attach. This is true even though there are people in Fuquay who have never heard of Poland.
From a SAS Institute, Inc. perspective, we often use the shorthand “EU residents” as shorthand for a rule of thumb for extraterritorial application of the GDPR when we are teaching on it. “Residents” isn’t completely accurate either, because (i) it sort of implies permanent residency, which isn’t required; and (ii) unless it’s marketing goods and services or monitoring, even some processing of EU personal data would be out of scope. But I think it’s closer to the mark than “citizen” because it focuses on geography rather than nationality.

Have a great weekend,

Melissa

-----------------------------------------------------------------------------------------------------------------

Melissa Roy

Vice President and General Counsel

Global Sales and Services

Office: (919) 531-1623 ▪ Mobile (919) 389-3997

Fax: (919) 677-4444

SAS World Headquarters▪ SAS Campus Drive, Rm. T2048 ▪ Cary, North Carolina 27513

melissa.roy@sas.com

SAS® … THE POWER TO KNOW®

This message and any attachments contain information that may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy, print or disclose to anyone the message or any information contained in the message. If you have received this e-mail in error, please advise the sender by reply and delete the message and any attachments. Thank you.

kathycobb

Adding some information regarding AKA Name Types for ORION Accounts.

As part of ORION's move to utilize more of D&B data and limiting edit capabilities, it has been discovered that the AKA Account Name Type value deteremines if the AKA names are visible for GIDB and CDHub consumption.

The AKA Account Name Type of "International/Local" which is used for the International name (using special characters) is required for some countries when paperwork and invoicing requires the International name.

Here are the ORION AKA Account Names Types

Asia Pacific [AKA] Account Name Types

*Asia Pacific Names (AKA) Types for Accounts*
Type	Description
Business Name	Represents the business name.
International/Local	The account name in the local language should be captured using this account name type.
Legal	Represents the legal name.
Tradestyle 3, 4, or 5	Represents the Tradestyle name.
User Defined	Used to represent the correct name of the account.

Canada and Latin America [AKA] Account Name Types

*Canada and Latin America Names (AKA) Types for Accounts*
Type	Description
Business Name	Represents the business name.
Tradestyle 1–5	Represents the Tradestyle name.

EMEA [AKA] Account Name Types

*EMEA Names (AKA) Types for Accounts*
Type	Description
Business Name	Represents the business name.
International/Local, Legal	· The account name in the local language should be captured using this account name type. Represents the legal name.
Tradestyle 3	Represents the Tradestyle name.
User Defined	Used to represent the correct name of the account.

United States [AKA] Account NameTypes

*United States Names (AKA) Types for Accounts*
Type	Description
Business Name	One of the Location’s Business Names according to DNB.
Legacy	The Account’s Primary Name at one time. Legacy Names are no longer found in DNB. A Legacy Name might be the current Primary Name.
Tradestyle 1–5	One of the Location’s Tradestyle Names.
User Defined	An additional name that is not a current name according to DNB; might be selected as the Primary Name. A User-Defined name might be used while waiting on a correction from Dun & Bradstreet. Note: Only users with the appropriate permissions are able to add a User-Defined name.

D&B provides ORION with many valid names but they are provided as a “Tradestyle 1-5” or “Business Name” Type value.

International, Legal, etc. are not types we receive from D&B even though one of the names provided by a user/customer may very well be the International, Legal, etc.

A Type can only be used once but an AKA can have multiple types. For example, an Account can only have 1 International AKA name but that International AKA name could also be the Legal name.