Difference between revisions of "Use Case "Starting a Business in Another Member State" (DBA UC1)"

From DE4A
Jump to navigation Jump to search
m
m
Line 22: Line 22:
  
 
==[[DBA UC1 process|Process]]==
 
==[[DBA UC1 process|Process]]==
 +
The first version of the pilot process has been analysed and specified in the D4.5 deliverable. Subsequently, the processes have been further detailed by each of the pilot partners for their specific situation, required functionality has been specified, the processes have been aligned to the project start architecture (that has been designed after the delivery of D4.5), the solution architecture has been defined, national customisations and integration activities and gaps have been identified. This section specifies the interpretation of the [[Intermediation Pattern|reference pattern]] for the DBA pilot (see project start architecture).
 +
 +
 +
Points of attention when comparing to the initial pilot process design from D4.5 and the Member State specific detailed process designs (based on the solution architecture):
 +
 +
* Use case 1 cannot be implemented fully with the intermediation pattern. The subscribing of a company for updates is not part of the intermediation pattern and will not be included in the first pilot iteration.
 +
* The process “request authentication” (DE) in the DBA pilot includes also (1) requesting the identifying attributes of the company represented and (2) requesting a powers validation. This does not contradict to the reference pattern, but needs highlighting because of its importance for the DBA pilot.
 +
* The process “provide authentication details” (user) in the DBA pilot includes also identifying the company that the user wants to represent. This may be done by entering the company identifier, by selecting the company from a list of companies the user has powers for or by directly selecting the mandate to use. In any case, the user’s powers to represent need to be validated. The implementation is Member State specific and does not need harmonisation for piloting.
 +
* The process “establish user identity” (user) in the DBA pilot refers to record matching on the company represented as outlined in section 3.3.6.
 +
* The process “redirect user to another channel” (user) in the DBA pilot means: allowing the user to register the company by using currently existing in-person or paper-based procedures.
 +
* The process “determine procedural requirements” and “determine required cross-border evidence” have been simplified for the DBA pilot to reflect the decision to use just one evidence type. The procedural requirements and evidence to request are fixed in the scenario of each pilot partner.
 +
* Saving and resuming the eProcedure (user) will not be supported in the DBA pilot.
 +
* “Provide public service” in the DBA pilot initially means: registering the company at the eProcedure portal. Registering the company in all pilots’ scenarios is the pre-requisite for applying for eServices, like assessment of tax duties, filing tax and applying of a subsidy or grant.
  
 
==[[DBA UC1 data model|Data model]]==
 
==[[DBA UC1 data model|Data model]]==
 +
 +
* [[DBA UC1 data model#Data model diagram|Data model diagram]]
 +
* [[DBA UC1 data model#Attribute specification|Attribute specification]]
  
 
==[[DBA UC1 components|Components]]==
 
==[[DBA UC1 components|Components]]==

Revision as of 17:26, 12 April 2021

At the core of this use case is the fulfilment of procedural obligations to do business in another Member State, especially the initial registration of a company at an eProcedure portal (AT, NL and RO pilot scenarios), opening a branch and the assessment of tax duties in the destination Member State (in the Swedish pilot scenario). In this use case, a company representative authenticates to the eProcedure portal, registers the company at the portal and applies for a service.


This UC uses the Intermediation Pattern and the Subscription and Notification Pattern.


Definition

Scope

The first use case ends with a subscription to receive notifications of business events of the company involved. From a logical process point of view, this is strongly intertwined with the company registration: subscribing to notifications follows directly after registration of the company at the eProcedure portal, before the process ends. Hence it is an integrated part of the first use case. From an interaction pattern perspective, the subscription to notifications does not belong to the intermediation pattern but to the subscription & notification pattern. The first part of the subscription and notification pattern deals with managing subscriptions, the second part with sending notifications once a business event took place. So, the first use case spans two interaction patterns.

Major design decisions

Process

The first version of the pilot process has been analysed and specified in the D4.5 deliverable. Subsequently, the processes have been further detailed by each of the pilot partners for their specific situation, required functionality has been specified, the processes have been aligned to the project start architecture (that has been designed after the delivery of D4.5), the solution architecture has been defined, national customisations and integration activities and gaps have been identified. This section specifies the interpretation of the reference pattern for the DBA pilot (see project start architecture).


Points of attention when comparing to the initial pilot process design from D4.5 and the Member State specific detailed process designs (based on the solution architecture):

  • Use case 1 cannot be implemented fully with the intermediation pattern. The subscribing of a company for updates is not part of the intermediation pattern and will not be included in the first pilot iteration.
  • The process “request authentication” (DE) in the DBA pilot includes also (1) requesting the identifying attributes of the company represented and (2) requesting a powers validation. This does not contradict to the reference pattern, but needs highlighting because of its importance for the DBA pilot.
  • The process “provide authentication details” (user) in the DBA pilot includes also identifying the company that the user wants to represent. This may be done by entering the company identifier, by selecting the company from a list of companies the user has powers for or by directly selecting the mandate to use. In any case, the user’s powers to represent need to be validated. The implementation is Member State specific and does not need harmonisation for piloting.
  • The process “establish user identity” (user) in the DBA pilot refers to record matching on the company represented as outlined in section 3.3.6.
  • The process “redirect user to another channel” (user) in the DBA pilot means: allowing the user to register the company by using currently existing in-person or paper-based procedures.
  • The process “determine procedural requirements” and “determine required cross-border evidence” have been simplified for the DBA pilot to reflect the decision to use just one evidence type. The procedural requirements and evidence to request are fixed in the scenario of each pilot partner.
  • Saving and resuming the eProcedure (user) will not be supported in the DBA pilot.
  • “Provide public service” in the DBA pilot initially means: registering the company at the eProcedure portal. Registering the company in all pilots’ scenarios is the pre-requisite for applying for eServices, like assessment of tax duties, filing tax and applying of a subsidy or grant.

Data model

Components