1. Abstract

CRM marketing permissions are integrated into the end of purpose (EoP) check for SAP Business Partners. Whenever for a Business Partner it is checked whether it can be blocked, a corresponding check for CRM marketing permissions is performed. This article provides information on the semantics of this check as well as explanations and the reasoning behind it.

2. CRM Marketing Permission & "Business"

At first it is important to clarify whether CRM Marketing Permissions might be considered as "business". The semantic of the end-of-purpose check is: whenever there is ongoing business for a partner (Business Partner, customer vendor, ...) it cannot be blocked. Vice versa, in case there is no ongoing business and the end of business (EoB) plus an eventual waiting period which make up the end-of-purpose (EoP) date is in the past, the partner can be blocked.

Hence, in general for all applications / domains the question is: What is considered as business? In addition, the conditions for 'ongoing' business and 'completed' business need to be clarified. Finally, a date is required which can be taken as end of business. It needs to be clarified which business process' date is considered to represent the EoB.

2.1. Type of Business

Before being able to answer these questions, it is worth clarifying under which legal ground the CRM Marketing Permission falls. Principles relating to processing of personal data are defined in article 5 GDPR. 'Personal data shall [...] be processed lawfully' (article 5 no.1a GDPR). Lawful processing is defined in article 6 GDPR. The assessment is as follows:

Contract (article 6 no. 1b GDPR) - inapplicable
A CRM Marketing Permission does not suit the criteria of a contract. Amongst others, the best argument is, that a contract always involves at least two parties (e.g. sold-to party and vendor). However, for a CRM Marketing Permission there is only one party which just states an opt-in or an opt-out. Even though there is a 'receiver' to whom the CRM Marketing Permission was directed to this 'receiver' cannot impede it. There is no need to get any kind of acknowledgement by the 'receiver' (which is the data controller). The statement of intention is valid anyways.

Legal obligation (article 6 no. 1c GDPR) - inapplicable
A CRM Marketing Permission in general does not represent any legal obligation.

Protected vital interest (article 6 no. 1d GDPR) - inapplicable
A CRM Marketing Permission in general does not represent any protected vital interest.

Public interest (article 6 no. 1e GDPR) - inapplicable
A CRM Marketing Permission in general does not represent any public interest.

Legitimate interest (article 6 no. 1f GDPR) - hum...
A CRM Marketing Permission might be considered to represent a legitimate interest. The issue with this approach is, that the CRM Marketing Permission was not intended to represent a legitimate interest. It could be questioned if it is capable to do so. But anyways the next point will cut it.

Consent / Statement of intention (article 6 no. 1a GDPR) - applicable
A CRM Marketing Permission was intended to represent a statement of intention (~consent). Vice versa, a CRM Marketing Permission should not be mixed up with contract-like business or other of the above types. It is an own type/ category with own specifics and legal requirements.

2.2. Approaches or Opt-In vs. Opt-Out

Looking into worldwide data privacy legislation the world's jurisdictions can be divided into two camps. There are the ones where Opt-In is the basis whereas for others Opt-Out is the base approach.

Opt-In

If a statement of intention (~consent) is the legal ground for personal data processing the existence of it prior to the data processing is strictly required. Let's take the example from GDPR (which shows that opt-in is applicable in the entire European Union):

'Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject's acceptance of the proposed processing of his or her personal data.' (recital 32 GDPR)

Opt-Out

If there is no statutory requirement to obtain affirmative consent prior to personal data processing the jurisdiction operates under opt-out regime. In this case the data subject (the person whose personal data is processed) typically can restrict or even deny processing of personal data in some way.

Let's take a look at US state California. The United States operate under opt-out regime. However, there is many states specific legislation. The California Consumer Privacy Act (CCPA) allows any business to collect consumer's data by default. And CCPA requires data controllers to inform consumers prior to data collection.

'As long as a California resident is notified of data collection, companies may collect his or her personal data until he or she actively makes the choice to opt out. Other US states have no such notification requirement, and any opt-out options provided are more likely due to common industry practice or sector-specific legislation than to any particular blanket privacy regulation.' (To Opt-In or Opt-Out?, medium.com, 2020, link)

2.3. Statement of Intention & Opt-In / -Out & Withdrawal

Often the term consent is used in general no matter if the statement of intention actually is a consent or a declaration of opt-out. Notice that a declaration of opt-out is not a revocation because there is no need for the existence of a consent to revoke (refer to the example of CCPA in the previous section). The abstraction of a consent as well as a declaration of opt-out is the statement of intention. The latin declaratio voluntatis (declaration of will) is a legal term in European civil law. No matter which jurisdiction or rather which regime (opt-in or opt-out) we are contextualized both statements of intention can be relevant from the local legal perspective. Simply using the term 'consent' has a high chance for confusion.

Since the CRM Marketing Permission covers consent and also declaration of opt-out it is more appropriate to use the term 'statement of intention' or something else like 'marketing permission'. The term 'marketing permission' seems to be too specific as it already puts the assumption the statements of intention that are deals with are only and always about marketing purposes (which is indeed not obligatory). However, the positive aspect about this term is that is allows for a rejection.

As we already started to define a terminology it makes sense to complete it:

	Approach		Rollback	False-Friend-Rollback ⁽³⁾	Opposite
	Opt-In	Opt-Out	Rollback	False-Friend-Rollback ⁽³⁾	Opposite
Consent / Declaration of Opt-In	✅ available	✅ / ❌ ⁽¹⁾	Withdrawal or Rejection	❌ opt-out / declaration of opt-out ❌ contrary consent or rejection-consent	❔ undefined
Declaration of Opt-Out	✅ / ❌ ⁽²⁾	✅ available	Withdrawal or Rejection	❌ opt-in ❌ consent	❔ undefined

Terminology

Some of the table's content needs further explanations. Most important form a logical perspective the availability of consent does not make sense in an opt-out regime (1). As mentioned in a previous section no consent is required at all in an opt-out regime. However, legislation is not always logical 😉. There might be even logical reason for the existence of consent in an opt-out regime. For example, in general opt-out might apply whereas for health data special legislation requires opt-in due to the intimacy of health data. The same reasoning applies for an opt-out declaration in an opt-in regime (further reading: EU proposal COM(2017) 10 final for a regulation beyond GDPR).

There are certain false friends (3) to undo / roll back a consent or an opt-out declaration. In many cases these false friends are used because ordinary persons are not aware of legal systems (which indeed can be challenging).

(Maximilian Dörrbecker, Creative Commons, source)

In German legislation a statement of intention can be undone / rolled back under certain conditions. For example consumer contracts can be revoked guided by the regulations of §§355 ff. right of withdrawal in consumer contracts German Civil Code (BGB). Obviously these don't apply for consents. Article 7 no. 3 GDPR governs the withdrawal of consents. There cannot be any withdrawal of a consent without a consent. This implies that an opt-out declaration cannot be a withdrawal of a consent since this declaration can exist without any consent. Moreover, a 'rejection-consent' which is kind of a withdrawal is unsuitable since first of all it is a consent but to what? A consent to a withdrawal is abstruse.

For undoing opt-out declarations false friends exist too. A consent cannot serve as revocation of an opt-out declaration because typically the requirement of specificity (see articles 6 no. 1a and 7 GDPR) makes such a consent invalid.
Example: Person A declares opt-out O on all processing of personal data for company M. At a later point in time A wants to undo/ revert its decision. Using a consent C as opt-out-rejection the purpose(s) of this consent need to be 'for all purposes/ for all processing of personal data'. However, such generic purposes are illegitimate and would make consent C invalid. The only way to undo the opt-out declaration is to revoke itself.

2.3.1. Differences for CRM Marketing Permission

Most important aspect for CRM marketing permissions in the context of the current section is: These explanations do not apply for CRM Marketing Permissions!

A CRM Marketing Permission (the data record in database table CRMM_BUT_MKTPERM) cannot be withdrawn because the technical design does not allow so. The table definition is as follows:

Column Name	Key	Data Type	Length	Description
CLIENT	✔	char	3	Client
RECORD_GUID	✔	binary	16	Marketing Permission Record globally unique identifier (GUID)
PARTNERGUID		binary	16	GUID of SAP Business Partner who opted-in or declared opt-out (might be a legal person or a natural person)
CONTPGUID		binary	16	GUID of the contact person (SAP Business Partner) the record is dedicated to (might be empty)
CHANNEL		char	3	Communication channel see (view `CRMV_MKP_CHAN`)
PERMISSION		numc	3	001 (`given`) or 002 (`rejected`)
ORIGIN		char	3	Technical indicator in by which type the statement of intention was given (e.g. email, letter)
VALID_FROM		date	8	Valid-from date (day, month, year; no time)
VALUE		char	241	Free-text field for further notes (for manual processing)

Database table design for CRM Marketing Permissions

The design does not include any column like WITHDRAWN (Boolean indicator) or WITHDRAWN_AT (date or datetime). To withdraw a CRM Marketing Permission another marketing permission is required. In an opt-in regime a record of type given can only be 'withdrawn' by a rejected-record. Vice versa in an opt-out regime a rejected-record can only be 'withdrawn' by a given-record. However, none of these records are linked to each other. Even though a business partner want's to withdraw its consent (~ given-record) and therefore a rejected-record is created, both records do not contain any linkage. There is also no other storage of such a link in some other database table. In chapter Multiple Records it is explained how the determination approach works under these circumstances.

2.4. Scenario Determination for CRM Marketing Permissions

Since there are two 'opposite' regimes on legitimation of processing of personal data it is vital to determine which approach is to be applied during the end-of-purpose check. How does this determination work?

In short: it is complicated. In today's world there are companies/ vendors from all over the world interacting with consumers around the world. Which regime is applicable if company M, located in California (US), sends advertising emails to person A, German citizen, to its email post box hosted by an australian email provider? Without going into details you should know about the following principles of conflict of laws (also known as private internal law):

Law of the place of performance (Latin: lex loci solutionis, German: Marktortsprinzip)

'If a case comes before a court and all the main features of the case are local, the court will then apply the lex fori (Latin: the law of the forum/ court), the prevailing municipal law, to decide the case. If there are foreign elements to the case, the forum court may then be obliged under the conflict of laws system to consider whether the forum court has jurisdiction to hear the case ' (Wikipedia, Lex loci solutionis)

Home state regulation (German: Herkunftslandprinzip)

'Home state regulation is a principle in the law of the European Union for resolving conflict of laws between Member States when dealing with cross-border selling or marketing of goods and services. The principle states that, where an action or service is performed in one country but received in another, the applicable law is the law of the country where the action or service is performed.' (Wikipedia, Home state regulation)

Law of the domicile (Latin: lex domicilii, German: ~Wohnsitzrecht)

'The lex domicilii is the Latin term for "law of the domicile" in the conflict of laws. Conflict is the branch of public law regulating all lawsuits involving a "foreign" law element where a difference in result will occur depending on which laws are applied. When a case comes before a court, if the main features of the case are local, the court will then apply the lex fori, the prevailing municipal law, to decide the case. However, if there are "foreign" elements to the case, the court may then be obliged, under conflict of laws, to consider whether it has jurisdiction to hear the case' (Wikipedia, Lex domicilii)

For CRM Marketing Permissions the determination works based on the SAP Business Partners address(es) and the system configuration (implementation guide > Customer Relationship Management > Master Data > Business Partner > Marketing Permissions > Define Opt-In Settings).

Customizing for CRM Marketing Permissions (transaction SPRO)

The documentation of customizing activity Define Opt-In Identifiers tells:

'In this Customizing activity, you define an opt-in identifier to represent validity periods of different lengths. Validity periods specify for how many months a consent with the value Given is valid. The validity period starts on the Date of Consent entered in the marketing permission.

You make settings in this Customizing activity when the following conditions apply:

You have customers who are subject to opt-in type laws.

You will create entries for the Customizing activity Define Country-Specific Opt-In Settings.

[...] Use a meaningful name for the identifier, such as an abbreviation of the applicable law. For example, use 'DPA1988' for the UK Data Protection Act 1988, or 'BDSG2009' for the German Federal Data Protection Act 2009.'

So this customizing is about the definition of periods in first place but does not touch the aspect of which approach to apply. The documentation of customizing activity Define Country-Specific Opt-In Settings tells:

In this Customizing activity, you assign the country, region (if required), communication channel and opt-in identifier to define the opt-in characteristics of national laws. You make settings in this Customizing activity when you have customers who are subject to opt-in type laws. To determine the applicable jurisdiction for the account, the system uses the country, and, if required, the region in the main address data. To determine the applicable jurisdiction for contacts with a relationship to an account, the system uses the country and, if required, the region in the main address data of the account.

If in your business scenario, you do not use the main address data to determine opt-in settings, see the BAdI: Opt-In Evaluation for Accounts and Contacts.

The applied determination logic within the end-of-purpose check for CRM Marketing Permissions follows this approach. For an SAP Business Partner the currently valid address is determined (1). In case there is no address or no country within the determined address available there is no basis for a decision. An opt-in scenario is applied implicitly (2). (This matches the CRM Marketing Permissions design to only model opt-in scenarios in the customizing.) In case a country could be determined, the opt-in settings are determined (3). Depending on the customizing there might be either no settings for the respective country, one or multiple ones. In case no opt-in settings are applicable for the country opt-out is applied (4). In all other cases opt-in is applied (5). This determination logic is illustrated in the following figure. This decision logic is implemented in function module CRM_DPP_MKTPERM_EOP_CHECK lines 223-278.

Scenario determination logic for CRM Marketing Permissions during End-Of-Purpose Check

Typically, misconceptions on the behavior of CRM Marketing Permissions during end-of-purpose check arise in this scenario determination:

No, incomplete or incorrect customizing on opt-in settings
Before enacting simplified blocking and deletion (which amongst others applies an additional status for SAP Business Partner: blocked) missing, incomplete or incorrect opt-in settings might not have been recognized because their effects on business processes (like CRM marketing campaign execution for sending emails) are easy to be missed. However, when enacting simplified blocking and deletion their consequences are striking. In case opt-out applies for an SAP Business Partner it cannot be blocked, although or rather for the reason no CRM Marketing Permission exists (refer to the table at the beginning of the next chapter). Possible solutions are:
- All fine: No opt-in setting but opt-out is applicable. The system behaves correctly.
- For incomplete customizing the system behaves as if no opt-in is applicable. In case opt-in should be applicable this needs to be configured, otherwise the system won't know.
- In case of incorrect opt-in settings (country is configured as applicable for opt-in but is actually under opt-out regime or no configuration for the country exists (=opt-out) whereas actually it falls under opt-in regime) the system behaves (correctly) according to the configuration which leads to a wrong decision. Wrong configuration needs to be corrected.

Incomplete or incorrect master data (address data)
As mentioned the scenario determination bases on address data. In case it is missing/ incomplete or incorrect the incorrect scenario might be applied:
- In case no address data exists for an SAP Business Partner always opt-out applies for the lack of (better) knowledge. However, there are only rare cases of stateless persons. In most cases an address is either unknown or its maintenance has been forgotten. Anyways, such a case should be avoided, since it is a decision based on nescience.
- In case an address exists but no country is maintained the same situation like in the previous point applies.
- In case an address exists (incl. a country) but the data is incorrect this incorrect data controls the scenario determination. Of course, the system cannot know that the data is incorrect.

2.5. End of Business for CRM Marketing Permissions

The end-of-purpose is made out of the end-of-business date plus some waiting period (for more details refer to this article). Hence, it needs to be clarified in which case the end-of-business is reached for a CRM Marketing Permission as well as which is the actual date. Both aspects have different outcomes depending on the applicable scenario. The comparison illustrated in the following table shows that both regimes lead to opposite end-of-business decisions. Simply the fact that either Opt-In or Opt-Out semantics are applied result in blocking or not-blocking a business partner.

	Opt-In	Opt-Out
Business	none by default	'existing' by default
End of Business	indicated by the CRM Mkt. Permission(s)' end of validity	indicated by the CRM Mkt. Permission(s)' valid-from date
End of Business in case of no consent / no opt-out declaration	date in far past (e.g. 1^st of January 1970)	infinity (e.g. 31^th December 9999)

Comparison of Opt-In and Opt-Out on End-of-Business determination

2.5.1. Opt-In

The determination of the state of business as well as a potential end-of-business date in case of opt-in is as follows: In case there are no CRM Marketing Permissions for an SAP Business Partner (1) it is indicated that the partner is unknown from application CRM Marketing Permission (purpose completion indicator equals 1, PUR_CMPL_SATATUS='1'). In case there are CRM Marketing Permissions but there are no given ones (technical value 001 see domain CRMT_BU_MKTPERM_PERMISSION) there are only rejections (opt-out declarations) for the partner (2). However, opt-out declarations are irrelevant in an opt-in regime. It is indicated that the business for this partner is completed. A date far in the past (31.12.1972) is chosen as end-of-business date. No matter what the actually configured waiting period is, the date is too far in the past to prevent business partner blocking.

For the case that there is at least one given CRM Marketing Permission the latest one of type given is taken (3), considering the valid-from date. In case there is no CRM Marketing Permission of type rejected the end-of-business is the record's valid-to date (4). If there is at least one record of type rejected the minimum of the given-record's valid-to date and the earliest rejected-record valid-from date which at the same time greater than the given-record's valid-to date is taken as end-of-business (5). (Sounds complex but is not that hard. Check chapter Multiple Records.) Depending on whether or not the end-of-business date is in future the purpose completion status is (6) ongoing ('2') or (7) completed ('3'). The described determination logic is depicted in the following figure and implemented in function module CRM_DPP_MKTPERM_EOP_CHECK lines 345-464:

2.5.2. Opt-Out

In case of opt-out the absence of CRM Marketing Permissions (1) is indicating ongoing business. The end-of-business date is infinite (31.12.9999). If there are CRM Marketing Permissions the latest one considering the valid-from date is taken (2). If it is given-record it is interpreted that the SAP Business Partner might had put a rejected-record in the past but opted in again (3). Hence, ongoing business is indicated. The end-of-business date is infinite (31.12.9999). If the last CRM Marketing Permission is a rejected-record the end-of-business date is the record's valid-from date (4). Depending on whether or not the end-of-business date is in future the purpose completion status is (5) ongoing ('2') or (6) completed ('3'). The described determination logic is depicted in the following figure implemented in function module CRM_DPP_MKTPERM_EOP_CHECK lines 288-343

End-of-Business determination for opt-out scenarios

2.5.3. Multiple Records

It is possible to create multiple CRM Marketing Permissions for an SAP Business Partner. As result, the end-of-business determination may look complicated. Let's have a look into the base use cases. It is important to emphasize again that:

a rejected-record does not have any impact for opt-in without the existence of a previous given-record

a given-record does not have any impact for opt-out without the existence of a previous rejected-record

a rejected-record's validity lasts forever or till the timely next given-record

a given-record's validity lasts for a finite period according to the customizing or till the timely next rejected-record (depending on what occurs earlier); depending on the jurisdiction typical validity periods are 2 years

Opt-in

The following figures shows the end-of-business determination for multiple records in an opt-in scenario. By default, there is no business at all, indicated by the red coloured bar in (a).The end-of-business (EoB) is in the far past.

The business partner puts a rejected-record (Rejected₁) which does not have any influence on the end-of-business determination. Still, there is no business and the end-of-business is in the far past (b).

A given-record (Given₁) is put (c). As result there is some period of business (indicated by the green coloured bar). This period has an end controlled by the opt-in settings customizing. No additional record is required to end this period. The end-of-business is now equal to Given₁'s end of validity.

The business partner puts a rejected-record (Rejected₂). Because its valid-from date is within the validity period of Given₁) the end-of-business is preponed and matches Rejected₂'s valid-from date (d).

An additional rejected-record (Rejected₃) is put which is timely earlier than Rejected₂. Hence, the end-of-business is preponed further and matches Rejected₃'s valid-from date (e).

So far it was shown that the end-of-business resulting from a given-record can be preponed by multiple rejected-records that lie within its validity period. The end-of-business can also be shifted into the future. The business partner puts another given-record (Given₂). Its valid-from date is timely later than the one of Given₁. Since Rejected₃ is the timely earliest rejected-record within Given₂'s validity it is the one which controls the end-of-business (which has actually not changed compared to (e)). It could be stated that only Given₂ and Rejected₃ are relevant for the end-of-business determination. This determination would not come to any other result in case Given₁, Rejected₁ and Rejected₂ would not exist. However(!), the nonexistence of these would have effects on the business processes which rely on CRM Marketing Permission. The contact-allowed API (class CL_CRM_BUPA_MKTPERM_FILTER method CHECK_CONTACT_ALLOWED) does only return true in case you are timely within a green-bar-period. Don't mix these two aspects!

A third given-record (Given₃) is put. Given₃'s validity period is bound by Rejected₂. The end-of-business is shifted into the future and is now equal to Rejected₂'s valid-from date (g).

Another given-record (Given₄) is put. Because there is no rejected-record timely after it, the end-of-business is equal to Given₄'s end of validity which is controlled by the opt-in settings customizing.

A fifth given-record (Given₅) is put which lies timely between Rejected₁ and Given₁. Although it has an effect on business processes for a certain period of time there is no change on the end-of-business.

All base principles for the end-of-business determination in opt-in scenarios are shown in figures (a) to (i).

Opt-Out

By default, there is ongoing business, indicated by the green coloured bar. The end-of-business date is infinite (j).

The business partner puts a given-record (Given₁) which does not have any influence on the end-of-business determination. Still, there is ongoing business and the end-of-business date is infinite (k).

A rejected-record (Rejected₁) is put (l). As result starting from Rejected₁'s valid-from date there is no business any longer (indicated by the red coloured bar). The end-of-business is equal to this date.

Another rejected-record (Rejected₂) is put timely in advance to Rejected₁). Hence, the end-of-business is preponed and now equal to Rejected₂'s valid-from date (m). It is shown that for a set of rejected-records that are not discontinued by any given-record only the timely earliest has an impact on the end-of-business determination. The same applies to business processes that rely on CRM Marketing Permissions.

The business partner puts a 2nd given-record (Given₂). Because there is no timely succeeding rejected-record the end-of-business is again an infinite date and business is ongoing (n).

Another given-record (Given₃) is put timely in advance to Given₂ (o). This does not change the end-of-business date or that fact that business is ongoing. However, it has an effect on business processes which rely on CRM Marketing Permissions in that period (Given₃'s valid-from till Given₂'s valid-from).

A rejected-record (Rejected₃) is put. It changes the end-of-business date to Rejected₃'s valid-from. After this date there is no ongoing business (p). It is already shown that whenever there is no given-record timely after a rejected-record the last rejected-record's valid-from date marks the end-of-business. Any timely previous record has no influence on the end-of-business determination (but of course on business processes which rely on them).

More precisely from the most future-headed set of non-discontinued rejected-records which is not followed by any given-record (Rejected₃ and Rejected₄ in (q)) the oldest none controls the end-of-business date. It is irrelevant how many rejected-records are in this set.

A given-record (Given₄) is put. It discontinues the mentioned set of Rejected₃ and Rejected₄. Hence the end-of-business date is equal to Rejected₄'s valid-from date (r).

Putting another given-record (Given₅) timely before Rejected₄ has no influence on the end-of-business determination(s). Also, there are no effects on business processes which rely on them.

It was shown that in case the timely last record is of type given the end-of-business is an infinite date. In case it is of type rejected the oldest from the set this non-discontinued set of rejected-records marks the end-of-business date.

3. End of Purpose

CRM Marketing Permissions can only be used if business function CRM_MKT_PERMISSION is active in the system (see transaction SFW5). Vice versa the end-of-purpose check is performed for CRM Marketing Permissions in case this business function is active.

Checking the business function status in transaction SFW5

As outlined in Approaches or Opt-In vs. Opt-Out, Scenario Determination for CRM Marketing Permissions as well as in End of Business for CRM Marketing Permissions the approch for the end-of-purpose check depends on the customizing for CRM Marketing Permissions and the business partner's address data.

In contrast to the two-step-approach for CRM applications (see SAP Note 2044428) there is an on-the-fly determination for CRM Marketing Permissions. During end-of-purpose check all CRM Marketing Permissions of the SAP Business Partners in question are checked directly.

Another difference is that there is no ILM object for CRM Marketing Permission. Hence, the determination of a waiting period (see this article) omits the usage of application rules variants or rather uses an empty (value '') application rule variant (see line 469 in function module CRM_DPP_MKTPERM_EOP_CHECK).

In case a waiting period should be applied on top of the end-of-business date, so that the end-of-purpose date is later than the end-of-business date, an ILM residence rule in some ILM policy in audit area BUPA_DP for ILM object CA_BUPA with an empty application rule variant needs to be specified.

3.1. Business function is active in the system but no Opt-In settings are maintained in customizing

In a couple of situations it has been found that business function CRM_MKT_PERMISSION is active in the system but the Opt-In settings (customizing activity Define Opt-In Settings) for CRM Marketing Permissions are not maintained (empty).

As result, for business partners where an address is available an opt-out scenario is applied during end-of-purpose check. Only for business partners without any address opt-in applies (2). This is because the determination of opt-in settings (3) reveals no settings are present (4).

If in addition there are no CRM Marketing Permissions it is very likely that this situation is unintentional. Given this setup the following behavior can be observed in the system during the end-of-purpose check for business partners:

The output of report Blocking of Business Partner Data (BUPA_PREPARE_EOP) tells the respective business partner(s) are not blocked since they are used in application CRM.

Output of Blocking of Business Partner Data

In case logging for the CRM-end-of-purpose check is configured to be active (see SAP-Note 2582000), in the application log (transaction SLG1) for log object CRM_DPP_EOP_CHK_LOG there will be the following information provided:
- Business Switch CRM_MKT_PERMISSION is active. Performing EoP check.
- No Opt-In settings defined at all
- No marketing permissions found for Business Partner(s) as contact person/ account
- Opt-Out is applied for Business Partner ...
- Purpose not completed for Bus.Part. ...: Opt-Out and no mkt. permission

As solution you might want to define opt-in identifiers as well as define country-specific opt-in settings. Hence, for business partners with an address the customizing takes control. Looking at the business partner from the above screenshots (BP number 5100124790, see figures above) there is a German address:

If opt-in should apply for business partners with a German address there needs to be first of all a suitable opt-in identifier. In the following screenshot the identifier SOME_ID with a validity of 4 months is defined.

This identifier is assigned to a country DE (Germany), an empty region (= any region) and communication channel INT (E-mail) as shown in the following screenshot.

Having this setup in place, the end-of-purpose check has the following output when checking business partner 5100124790:

In contrast to the previous check for this business partner, the application log new reveals the following details:

Business Switch CRM_MKT_PERMISSION is active. Performing EoP check.

No Opt-In settings defined at all

No marketing permissions found for Business Partner(s) as contact person/ account

Opt-In is applied for Business Partner ...

Count of Opt-In settings applicable for Bus.Part. ...: 1

Opt-In setting from customizing with channel INT, OptID SOME_ID, validity 0000000004

No business for Bus.Part ...: Opt-In and no marketing permission

3.2. Omit CRM Marketing Permissions during End-of-Purpose Check

You might want to omit checking CRM Marketing Permissions during end-of-purpose check for business partners although business function CRM_MKT_PERMISSION is active in the system. In this case you can apply SAP-Note 3074009. If applied and the maintenance of customizing table SMOFPARSFA has been done, function module CRM_DPP_MKTPERM_EOP_CHECK (the end-of-purpose check for CRM Marketing Permissions) indicates n/a (no Business made with BP at all) (value 1) as purpose completion indicator for all business partners in the selection.

Customizing table SMOFPARSFA - omit CRM Marketing Permissions during End-of-Purpose Check

4. Archiving & Retention

CRM Marketing Permissions semantically belong to the SAP Business Partner. There is no dedicated archiving object for CRM Marketing Permissions. Rather, during archiving of SAP Business Partners all respective records will be archived along with the partner. The corresponding function modules CRM_BUPA_MKT_PERM_EVENT_ARCH3 (writing to archive as part of SAP Business Partner archiving) and CRM_BUPA_MKT_PERM_EVENT_ARCH3 (deletion after successful SAP Business Partner archiving) involved in these processes are located in development package CRM_BUPA_MKT_PERMISSION.

CRM Marketing Permission, End-of-Purpose Check & Archiving

Table of Contents