|
|
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 |
1.1.4. Data will be collected from qualified electronic financial documents [i.e. Receipts must be retrieved digitally] |
|
|
WP2 Common Nordic Rulebook |
1.3.1 documents are categorized with its own document type e.g. sales invoice, purchase invoice, receipt, bank account statement, bookkeeping entry, warehouse entry, cash sales etc. |
|
|
WP2 Common Nordic Rulebook |
1.3.2 all needed information should be collected from the actual documents |
|
|
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 |
|
|
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. |
|
|
Financial reports must be aggregated over dimentions like products, clients, suppliers, countries, locations, qualities, quantities. |
Capture product information |
|
|
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 |
|
|
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 |
|
|
WP1 Recommendation of standards |
Business Transaction Documents should be compatible with Peppol eDelivery network |
|
|
WP1 Recommendation of standards |
Business Transaction Documents should implment document specifications compatible with Peppol BIS |
|
|
Other requirements- not put into documents |
API must be able to declare a version (and format standard used?) for the taxonomy used |
|
|
Other requirements- not put into documents |
API must support XBRL GL taxonomy |
|
|
WP2 Other |
Check the validity of e-Receipts and e-Invoices - to prevent fraud. Both fraud in creating false Invoices, and receipts - and also prevent using them more than once to verify expenses. |