> For the complete documentation index, see [llms.txt](https://kb.maica.com.au/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.maica.com.au/ndis-management/invoice-management/invoice-entry/alerts-and-validation.md). # Alerts & Validation ### Duplicate Invoice If you have a team of staff entering `Invoices,` there is always the possibility that the same `Invoice` could be entered multiple times by different users. Not with Maica! Maica has validation in place to ensure that the same Provider Invoice cannot be added and duplicated via the Invoice Entry component. At the point of entry, Maica validates the following fields to look for an existing `Invoice`: * Provider * Participant * Invoice Number If an existing `Invoice` is found, the following modal will be displayed to alert the user:

Duplicate Invoice Alert at time of entry

### Active Plan Info Panel Once a Participant has been selected, their Active `Plan` information is displayed in a handy info panel directly below so you can start to understand the budget position whilst submitting the Invoice. The criteria for displaying the `Plan` Info panel is: * Funding Structure = Plan Managed (set on the Invoice Entry top line) * AND Participant has an Active Plan (`Plan__c`.`Active__c` = TRUE) The `Plan` panel shows: 1. **Total Invoiced** = Total Amount of the `Invoice` records where: 1. `Status` = `'Claimed' OR 'To Be Paid' OR 'Partially Paid' OR 'Fully Paid'` 2. `Invoice_Date__c` = `THIS CALENDAR YEAR` 2. **Total Approved** = `Active Plan Total_Approved__c` 3. **Total Approved Percentage** = `Total Invoiced` / `Total Approved`

Participant Plan Panel on the Add New Invoice component

### Funding Structure Validation Maica enforces the following validation based on the `Funding Structure` selected at the top level of the Invoice Entry process.

Funding Structure pick list on the Invoice Entry component

#### Funding Structure = Plan Managed Where you have selected `Plan Managed` for the `Funding Structure`, only those Support Categories and Support Items defined in the Participant's `Service Booking` record(s) are displayed and available for selection in the drop down lists. This is to prevent any incorrect `Invoice` records being submitted for the Participant. For example: If you are trying to add an Invoice for **Level 1: Support Connection** (`07_001_0106_8_3`), the Participant **must have** a `Service Booking` that provides funding for the **Support Coordination** (`07`, `Capacity Building`) Support Category. Without this, the Support Category drop down list **will not** include Support Coordination for selection.

Support Category validation based on Plan Managed Funding Structure

#### Funding Structure = Self Funded When selecting `Self Funded` for the `Funding Structure`, all Support Categories will be displayed and available when entering Invoice Line Items regardless of an associated `Service Booking`. This effectively opens up the `Invoice` to select any `Support Category` and `Support Item` needed. ### Day of the Week Validation (Weekday vs Weekend) It is common within the NDIS that services will be delivered outside of 'traditional' business hours, meaning that you will very likely receive Invoices referencing Support Items delivered on a Saturday or Sunday. From an `Invoice` entry and `Claiming` point of view, Weekend services attract a higher price and furthermore, `Payment Request` records are validated to ensure that the correct Support Items are being claimed based on the day of the week. Essentially this means that you cannot claim for a Weekend Support Item on a Weekday and vice versa. The example below provides a practical example using the `Group Activities In The Community - 1:3 - Standard` bundle of Support Items. #### Weekday Support Item * `04_120_0136_6_1` - Group Activities In The Community - 1:3 - Standard - **Weekday** Daytime * This product is only valid for services delivered **Monday to Friday** #### Weekend Support Item - Saturday * `04_121_0136_6_1` - Group Activities In The Community - 1:3 - Standard - **Saturday** * This product is only valid for services delivered on a **Saturday** #### Weekend Support Item - Sunday * `04_122_0136_6_1` - Group Activities In The Community - 1:3 - Standard - **Sunday** * This product is only valid for services delivered on a **Sunday** #### **Invoice Entry Validation** Now, how does Maica support the validation described above? It is quite simple really. As soon as you select the `Service Date` for your `Invoice Line Item`, Maica understands the day of the week and uses this to **filter the list** of `Products` presented in the `Support Item` drop down. The logic applied is per the below: * If the selected `Service Date` is between Monday to Friday, only Support Items where the Product `Service Day` attribute = Weekday OR Anytime will be displayed * If the selected `Service Date` is a Saturday, only Support Items where the Product `Service Day` attribute = Saturday OR Anytime will be displayed * If the selected `Service Date` is a Sunday, only Support Items where the Product `Service Day` attribute = Sunday OR Anytime will be displayed

Service Date filtering the Support Item drop down

**Support Item (Product) Configuration** As mentioned above, the `Service Day` field on the `Product` record is referenced in the **Day of Week** validation. Please note: this value is set via the PRODA integration and you **do not need** to manually set or manage this value.

Product Configuration to support the Day of the Week validation

### Public Holiday Validation Building on the **Day of the Week** validation described above, Maica and the Invoice Entry functionality also handle the validation for Public Holidays! Similarly to Weekend Support Items, the NDIS Support Catalogue also contains Products specific to Public Holidays where a higher rate applies. In order to enable this validation, simply create the appropriate Holiday records via the standard Salesforce Holidays setting. This can be accessed by going to **Setup** and typing **Holidays** in the Quick Find. Maica supports both State Based and National Holidays.

Adding a Holiday record in Salesforce Setup

In order to work with Maica, the Holiday records need to be created in a specific way: #### State Based Holidays * In order to create a **State** specific Holiday, simply ensure that you include **both** the Short and Long `State Suffix` from the table below * For example: to create a **Victorian only** Holiday for the **Melbourne Cup** on 01/11/2022, you need to use the following `Holiday Name`: `Melbourne Cup (VIC) (Victoria)` #### National Holidays * In order to create a **National** Holiday, simply ensure that you type **only** the `Holiday Name` and do not include any reference to a `State Suffix` from the table below * For example: to create a National Holiday for **Christmas Day** on 25/12/2022, you need to use the following `Holiday Name`: `Christmas Day`

Manage Public Holidays via the standard Salesforce Holiday Setup

| State Name | State Name Suffix (Short) | State Name Suffix (Long) | | ---------------------------- | ------------------------- | -------------------------------- | | Victoria | `(VIC)` | `(Victoria)` | | New South Wales | `(NSW)` | `(New South Wales)` | | Queensland | `(QLD)` | `(Queensland)` | | Western Australia | `(WA)` | `(Western Australia)` | | South Australia | `(SA)` | `(South Australia)` | | Tasmania | `(TAS)` | `(Tasmania)` | | Australian Capital Territory | `(ACT)` | `(Australian Capital Territory)` | | Northern Territory | `(NT)` | `(Northern Territory)` | | National | Blank | Blank | #### Contact Mailing Address {% hint style="info" %} In order to determine which Holiday(s) to apply at the point of Invoice Entry, the `State` from the Participant's `Mailing Address` is referenced. The validation will support either the Short or Long Format, i.e. VIC or Victoria. So, if your Participant has VIC or Victoria defined as their Mailing State, all the Victorian AND National holidays will apply. {% endhint %}

Participant Mailing State Validation

#### Public Holidays and Product Service Day For any `Product` records where the `Service Day` is set to `Anytime` or is null, these will be skipped as part of the Public Holiday validation. Meaning that they will be available for selection in the `Support Item` drop down.
### Service Booking - Remaining Funding Warning :warning: At the **Invoice Line Item** entry level there are two points of validation, `Service Booking` and `Service Agreement`. From a `Service Booking` perspective, the Line Item `Total Amount` calculated based on the (`Quantity` \* `Rate`) is validated against the Participant's relevant/corresponding `Booking Item`, specifically the `Remaining Amount` field. Essentially, the validation displays a warning Icon :warning: to inform the user if the `Total Amount` for the Line Item exceeds the `Remaining Amount` for the related `Booking Item` for that `Support Category`. If so, Maica will display the icon with the following message: {% hint style="danger" %} Total Amount exceeds the Booking Item Remaining Amount: `${{bookingItem.maica__Remaining_Amount__c}}` {% endhint %} In the example below, the icon is displayed as Maica has determined the Line Item `Total Amount` of $3,342.61 **exceeds** the `Remaining Amount` of the Participant's associated `Booking Item` for the Support Coordination `Support Category`.

Service Booking Item - Remaining Amount Validation

### Service Agreement Warnings :warning: Service Agreements are a good way to reserve or '*quarantine*' funds between a specific Provider and Participant. Via Maica, you can use a `Service Agreement` record to capture and define what has been agreed between the two parties, in terms of both the **Support Item** and the **Amount** or Value. Once a `Service Agreement` has been defined, Maica uses this for validation purposes and also to track how the specifics of the Agreement (the `Agreement Item` records) are being utilised, i.e. how the Agreement budget is being consumed. From an Invoice Entry perspective, Maica validates the `Invoice Line Item` information added against *3 possible scenarios*. All of the validation scenarios check to see if a `Service Agreement` record exists **between the Provider and the Participant**. #### Scenario One: 1 Service Agreement Found (Support Category + Support Item Match) The first scenario handles the situation where a **single** (1), active `Service Agreement` exists between the Participant and the Provider and where the `Support Category` and `Support Item` has an exact match with a Service `Agreement Item` record. If the above conditions are true, the following scenarios are validated: Invoice Line Item `Total Amount` **exceeds** Service `Agreement Item` `Total Remaining` * If TRUE, the following text will be displayed in the warning icon popover: {% hint style="warning" %} `This Invoice Line Item exceeds the available funds within the Service Agreement.` {% endhint %}

Invoice Line Item Total Amount exceeds Service Agreement Item Total Remaining

Invoice Line Item `Total Amount` **does not exceed** Service `Agreement Item` `Total Remaining` * If TRUE, the following text will be displayed in the warning icon popover: {% hint style="warning" %} `This Invoice Line Item will reduce the available funds within the Service Agreement by ${{Invoice Line Item Amount}}.` {% endhint %}

Invoice Line Item Total Amount does not exceed Service Agreement Item Total Remaining

#### Agreement Item Alert This scenario is taken one step further when a `Service Agreement` (with `Agreement Item` records) is found between the Participant + Provider. When found, Maica will return any Support Item(s) taken from the Agreement Item(s) at the very top of the Support Item drop down list to indicate an Agreement Item exists. This may very well be the one your are looking for as the Provider will Invoice for Support Items that are part of their Service Agreement with the Participant.

Asterix indicates an Agreement Item for this Product exists in a Service Agreement

#### Scenario Two: > 1 Service Agreement Found (Support Category + Support Item Match) The second scenario handles the situation where **more than 1** active `Service Agreement` records exist between the Participant and the Provider and where the `Support Category` and `Support Item` has an exact match with a Service `Agreement Item` records. In this event, the following text will be displayed in the warning icon popover: {% hint style="warning" %} `Multiple Agreement Items exist for this Support Category + Support Item. Please check the Service Agreements for this Participant. Submission of this Invoice will not effect any Service Agreement.` {% endhint %}

More than 1 Service Agreement Found (Support Category + Support Item Match)

#### Scenario 3: No Agreement Item records found between the Participant and the Provider The third and last scenario handles the situation where there are no `Agreement Items` records between the Participant and Provider matching the `Support Category` and `Support Item` entered for the `Invoice Line Item`. In this event, the following text will be displayed in the warning icon popover: {% hint style="warning" %} `There are no Service Agreements for this Invoice Line Item.` {% endhint %}

No Agreement Item records found between the Participant and the Provider

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://kb.maica.com.au/ndis-management/invoice-management/invoice-entry/alerts-and-validation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.