|
|
1.1 Adoption of digital business documents |
1.1.1 Data will be collected from qualified electronic financial documents [i.e. Invoices must be retrieved digitally] |
|
|
1.1 Adoption of digital business documents |
1.1.3. Data will be collected from qualified electronic financial documents [i.e. Orders must be digitally] |
|
|
1.1 Adoption of digital business documents |
1.1.2 Data will be collected from qualified electronic financial documents [i.e. Bank account statement must be digitally] |
|
|
1.4 Standardisation of eReceipts |
1.1.5 All the general fields of eOrders are defined and mapped according a chosen standard. [i.e. Orders must be standardized with clear semantics] |
|
|
WP1 Architecture principles |
Build on open standards |
|
|
WP1 Architecture principles |
Use clearly defined, global semantics |
|
|
WP1 Architecture principles |
Protect user data |
|
|
WP1 Architecture principles |
Built to evolve |
|
|
WP1 Architecture principles |
Favor imperfect existing standards over perfect custom standards |
|
|
WP1 Architecture principles |
Enforce data portability |
|
|
WP2 Common Nordic Rulebook |
1.1.1 Data will be collected from qualified electronic financial documents [i.e. Invoices must be retrieved digitally] |
|
|
WP2 Common Nordic Rulebook |
1.1.2 Data will be collected from qualified electronic financial documents [i.e. Bank account statement must be digitally] |
|
|
WP2 Common Nordic Rulebook |
1.1.5 All the general fields of eOrders are defined and mapped according a chosen standard. [i.e. Orders must be standardized with clear semantics] |
|
|
WP2 Common Nordic Rulebook |
1.1.3. Data will be collected from qualified electronic financial documents [i.e. Orders must be digitally] |
|
|
WP2 Common Nordic Rulebook |
The information must be represented in a generic and system-independent way to record all of the details in any kind of ledger and bookkeeping |
|
|
WP2 Common Nordic Rulebook |
Capture product information |
|
|
1.1.5 All the general fields of eOrders are defined and mapped according a chosen standard. [i.e. Orders must be standardized with clear semantics] |
Build on open standards |
|
|
1.1.5 All the general fields of eOrders are defined and mapped according a chosen standard. [i.e. Orders must be standardized with clear semantics] |
Use clearly defined, global semantics |
|
|
The information must be represented in a generic and system-independent way to record all of the details in any kind of ledger and bookkeeping |
Enforce data portability |
|
|
WP4 Capabilities needed of the reference implementation |
Financial reports must be available for lookup [use case 6] |
|
|
WP4 Capabilities needed of the reference implementation |
Financial raw data must be available for lookup [variants 1-8] |
|
|
WP4 Capabilities needed of the reference implementation |
Financial reports must be aggregated over dimentions like products, clients, suppliers, countries, locations, qualities, quantities. |
|
|
Quality capabilities |
3.4 High avaliability |
|
|
Quality capabilities |
Authorisation and access control |
|
|
Quality capabilities |
User consent for B2B sharing |
|
|
Quality capabilities |
2.2. Manage change and deviations (was: Correctness incl. error detection and correction) |
|
|
Quality capabilities |
Authentication |
|
|
Quality capabilities |
Encryption |
|
|
Quality capabilities |
5.2 Keeping the data safe (integrity and ownership) |
|
|
Quality capabilities |
3.3 Adressing |
|
|
Quality capabilities |
Business systems |
|
|
Quality capabilities |
Standardized access (APIs) |
|
|
Quality capabilities |
Business systems |
|
|
3.4 High avaliability |
Financial reports must be available for lookup [use case 6] |
|
|
3.4 High avaliability |
Financial raw data must be available for lookup [variants 1-8] |
|
|
Authorisation and access control |
Data sharing controlled by the data originator |
|
|
Authorisation and access control |
If someone offers me a better deal or improved service, migrating to new service providers for services like book-keeping, inventory, reporting etc is just as easy as changing operator for my cell phone |
|
|
User consent for B2B sharing |
Data sharing controlled by the data originator |
|
|
Authentication |
Data sharing controlled by the data originator |
|
|
Encryption |
Strong enforcement of data integrity |
|
|
5.2 Keeping the data safe (integrity and ownership) |
Strong enforcement of data integrity |
|
|
3.3 Adressing |
Addressing - The endpoint(s) of the organisation’s ERP-system must be known |
|
|
Authentication SBB |
Authentication |
|
|
Authorization/power of mandates SBB |
Authorisation and access control |
|
|
Business systems |
2.2. Manage change and deviations (was: Correctness incl. error detection and correction) |
|
|
Users consent SBB |
User consent for B2B sharing |
|
|
Infrastructure for document exchange SBB |
Encryption |
|
|
Infrastructure for document exchange SBB |
5.2 Keeping the data safe (integrity and ownership) |
|
|
Adressing SBB |
3.3 Adressing |
|
|
Business systems |
3.4 High avaliability |
|
|
Standardized access (APIs) |
Standardized and detailed APIs for bookkeeping transactions creates an opportunity for extracting details and aggregated to business partners, e.g. Banks |
|
|
Business systems |
Standardized access (APIs) |
|
|
WP1 User principles |
I am in control of all the transaction and financial data of my business |
|
|
WP1 User principles |
I never manually enter information that is already maintained digitally by the producers, vendors or the government [TOOP] |
|
|
WP1 User principles |
I rarely perform manual steps related to inventory, book-keeping, bank-transactions, VAT- and other government reporting etc, unless I choose to verify the proposals from my systems |
|
|
WP1 User principles |
If someone offers me a better deal or improved service, migrating to new service providers for services like book-keeping, inventory, reporting etc is just as easy as changing operator for my cell phone |
|
|
WP1 User principles |
When I buy and sell goods and services I don't need to make any special arrangements when my trade-partners are in another Nordic country |
|
|
WP1 User principles |
The Government gives me feedback and assures me when everything is OK |
|
|
WP3 Take-aways from meetings with business system stakeholders v. 0.1 |
Addressing - The endpoint(s) of the organisation’s ERP-system must be known |
|
|
WP3 Take-aways from meetings with business system stakeholders v. 0.1 |
Standardized and detailed APIs for bookkeeping transactions creates an opportunity for extracting details and aggregated to business partners, e.g. Banks |
|
|
WP1 Desired attributes |
Data sharing controlled by the data originator |
|
|
WP1 Desired attributes |
Strong enforcement of data integrity |
|
|
Data sharing controlled by the data originator |
Protect user data |
|
|
Business systems |
1.1 Adoption of digital business documents |
|
|
Standardisation organisations |
1.4 Standardisation of eReceipts |
|
|
2.3. Common representation of transactions (semantics) |
The information must be represented in a generic and system-independent way to record all of the details in any kind of ledger and bookkeeping |
|
|
Business systems |
2.3. Common representation of transactions (semantics) |
|
|
Business systems |
2.1 Provide technical access points to detailed transaction data |
|
|
1.3 Product information - avaliable |
Capture product information |
|
|
Business systems |
1.3 Product information - avaliable |
|
|
Regulators |
1.1 Adoption of digital business documents |
|
|
Business systems |
1.2 Adoption of digital product and service information |
|
|
2.1 Provide technical access points to detailed transaction data |
Financial raw data must be available for lookup [variants 1-8] |
|
|
Business systems |
2.1 Provide technical access points to detailed transaction data |