Rendering expense views

Rendering correct view that follow the local tax rules includes knowledge about what data you need to capture from the user, for example what type of entertainment fields to show if a user select an entertainment category, or what projects a user can select from. The fields endpoint is built to package that knowledge for the current user into a list of fields to display which means rendering of the expense views becomes a simple task.

This means you can implement a small set of display components in your own design and let the fields endpoint take care of the business logic to render the correct fields.

Here's how it works:

• Initiate the fields endpoint: Make an initial GET to the fields endpoint to either create a new empty expense, or include the expenseRecordId parameter to initiate it from an existing expense.
• Render the fields: Each field have a set of properties that defines how it should be render, for example the name, the type, if it's visible etc. See field properties for more information.
• Repost if needed: If the field has requiresUpdate=true it means you need to PUT the json body to the same endpoint with the updated values. This is because some fields affect other fields. A normal example is when the user selects the expense category it may force some fields to be mandatory, or requires more fields to be rendered.
• Save the expense: When the user chooses to save the expense the fields data can be posted to the expense endpoint which supports two formats.

With our solution, you'll not only save time but also ensure accurate and up-to-date compliance with local tax rules. It's time to take the hassle out of tax compliance and embrace a more efficient way of doing business.