...
For this category, your service should be able to create standardised e-invoices from an existing information system or allow information importing to be imported from external sources. Although you are not expected to be able to extract information from a random source like websites or articles, services in this category should be able to process pre-formatted data. The service should extract any useful data from the source and assemble invoices as per the standard.
...
Your output should conform to the UBL 2.1 XML format. i.e. Your output should be able to pass any correctly implemented validator mentioned in the “Invoice Validation” section of this document. Since there are many fields and constraints in the standard, a microservice should consider starting by generating minimised invoices first.
...
Measure of Priority (Draft)
Grade | Requirements | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| All below and introducing a novel functionality specific to e-invoice creation. The API design should follow defense in depth, well documented errors, relatively quick response times, and fully deployed on cloud. | ||||||||
| All below and the API supports multiple input formats with great enhanced usability, follows efficient REST practices. eg. API authentication, flexibility for end users, and a comprehensive documentation. | ||||||||
| The API supports at least one input format with high accuracy and usability, follows appropriate REST practices. eg. status codes are appropriate, input and response formats are documented. | ||||||||
| The API supports at least one input format, and follows basic REST principles and practices. |
...
Grade | Requirements | |||||||
|---|---|---|---|---|---|---|---|---|
| All below and introducing a novel functionality specific to e-invoice creation. The API design should follow defense in depth, well documented errors, relatively quick response times, and fully deployed on cloud. Suggesting quick-fix methods would be a great addition as a novel functionality. | |||||||
| All below and the API supports multiple machine readable output formats with enhanced usability, follows efficient REST practices. eg. API authentication, flexibility for end users, and comprehensive documentation. Also provides more details on why the role was violated. | |||||||
| The API supports enhanced validation (majority of syntax and peppol rules), one output format with high accuracy and usability, follows appropriate REST practices. eg. status codes are appropriate, input and response formats are documented. | |||||||
| The API supports basic validation (wellformedness, some syntax and peppol rules), and provides at least one machine readable output format. |
Invoice Rendering
Not everyone can read notations for a computer like XML and JSON. People would prefer to see statistics shown in proper formatted tables or graphs. This category of service is targeted at end-users who may not be familiar with the UBL format of electronic invoices. Therefore, you should design your service to display the information contained in a machine-readable format file to a human-readable representation interface, in a reasonable manner.
...