...
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 enhanced usability, follows efficient REST practices. eg. API authentication, flexibility for end users, and 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. |
Invoice Validation
Creates a report outlining any validation errors according to Australian rules.
...
Be in a Machine-readable format (i.e JSON, HTML, PDF)
Indicate which validation rules are violated.
Provide additional information on why the rule was violated.
*Optional* Suggest quick-fix methods to validate the rules.
Marking
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.
...
| View file | ||
|---|---|---|
|
Marking
Grade | Requirements | |||||||
|---|---|---|---|---|---|---|---|---|
| All below and introducing a novel functionality specific to e-invoice rendering. 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 output formats with enhanced usability (style templates), follows efficient REST practices. eg. API authentication, flexibility for end users, and comprehensive documentation. Detailed error codes on why the input couldn’t be processed. | |||||||
| The API supports rendering at a level which is accessible and follows a consistent format for invoices with different missing fields, handles invalid invoices appropriately and follows appropriate REST practices. eg. status codes are appropriate, input and response formats are documented. | |||||||
| The API supports basic e-invoice rendering in one of the output formats for a valid e-invoice input, essential REST practices. |
Invoice Sending
After invoices are generated, the system needs a way to distribute the invoices to corresponding recipients. This category of services should be able to deliver invoices from the internal of the system to some external environment. You need to design the way how invoices are delivered. Some possible ways can be email, SFTP or even SMS.
...
The observable output of this service includes a report and a side effect. After the API call, your service should send the invoice, then return a communication report. The format of the report can be but not limited to JSON, HTML, PDF. If there is any communication error. it is preferable that your service reacts with a human-readable message. A simple synchronous API call without delivering information to external is acceptable as a start, but not sufficient for the service.
Marking
Goals | Requirements | ||||||
|---|---|---|---|---|---|---|---|
| All below and introducing a novel functionality specific to e-invoice sending. The API design should follow defence in depth, well documented errors, relatively quick response times, and fully deployed on cloud. | ||||||
| All below and the API supports multiple mediums to send e-invoices with enhanced usability (style templates), follows efficient REST practices. eg. API authentication, flexibility for end users, and comprehensive documentation. Batch processing is a recommended feature. | ||||||
| The API is capable of sending e-invoices to using different mediums to multiple recipients, handles invalid invoices appropriately (with some useful output) and follows appropriate REST practices. eg. status codes are appropriate, input and response formats are documented. | ||||||
| The API supports basic e-invoice sending using one of the suggested mediums and a valid communications report is returned. |
Invoice Receiving
Invoices may also be exchanged between different systems. Therefore, to better manage invoices, the system needs a component that can receive invoices from the external environment. This category of service should be able to retrieve e-invoices from a developer-designated media, which can possibly be API calls, email, SFTP, chatbot, or even SMS. Your service should be able to detect the new invoices.
...
The observable output of this service includes a report. After the API call, your service should return a communication report. The format of the report can be but not limited to JSON, HTML, PDF. In a successful execution, the service should persist the invoice. If there is any communication error, it is preferable that your service reacts with a human-readable message.
Marking
Grade | Requirements | ||||
|---|---|---|---|---|---|
|
| |||||
|
| |||||
|
| |||||
|
|
Invoice Storage
Data becomes powerful only when information starts to have relations. It is not sufficient to only have thousands of separate electronic invoices files. A good invoicing system should include a component that is able to manage its storage. (Think about the relationship between a book, a librarian and a library.) This category of service manages the storage and saves a large number of standard invoices. Reliability and performance are the core of this type of service. You should design and implement a mechanism to stores store standardised e-invoices, making use of existing/open-sourcing technologies. You can include relational databases, NoSQL databases, file systems, or even caching mechanisms in your storage mechanism. In some cases, you may need to discuss the use cases and balance reliability and performance. To deliver extreme experiences, consider reliability and performance separately in different situations.
...
Grade | Requirements | |||||||
|---|---|---|---|---|---|---|---|---|
| All below and introducing a novel functionality specific to e-invoice storage. The API design should follow defence in depth, well-documented errors, relatively quick response times, and fully deployed on cloud. | |||||||
| All below and the API follows enhanced storing mechanisms to provide filtering, modification, deletion, follows efficient REST practices. eg. API authentication, flexibility for end users, and comprehensive documentation. Batch processing is a recommended feature. | |||||||
| The API should capable of storing e-invoices in different mediums, preserve state for users over long period of times, and follows appropriate REST practices. eg. status codes are appropriate, input and response formats are documented. | |||||||
| The API provides access to a basic e-invoice storage system allowing users to upload, store and retrieve one or multiple invoices. |