...
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.
...
An information system or an implemented mechanism to persist invoices. If an input is malformed, it is preferable that your service displays a human-readable message. Your service should allow someone else to extract invoices from your services. It is meaningless to only receive information without taking it out. Supporting more types of querying like filtering, modification or deletion can also enhance the service.
Marking
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. |