Invoices

[lcreid]

Entering invoices -- at least how much, and who pays -- is pretty basic to the usefulness of the site. There are some subtleties that would be worth discussing, and then perhaps writing a bit of a specification. Here are some random thoughts about invoices:

• We're not doing an accounting system
• By having the user enter each invoice against the RTP or other form that authorizes the payment, we can autofill a lot and reconciliation is more obvious (for the system)
• An alternative would be to simply allow entering of an invoice without explicitly linking it to authorization, and some cleverness (JavaScript/AJAX or otherwise) to help the user enter enough info that the system can reconcile the invoice to the authorization
• There may even be a way to do both of the above, so the user can choose the style that works best
• I see some possible trickiness in that invoices for services generally have a period for which they apply, whereas purchases simply have the purchase date
• For the anal retentive out there, we should probably allow a field to enter the vendor's reference number for the invoice. I don't see our system using it, but it's might be useful for users
• For that invoice where the RTP has run out, and subsequent invoices, we should show the user what they have to pay out of pocket. ("run out" means all the authorized funding has been spent, and the parent will have to pay for the rest of the invoice, and subsequent invoices, out of pocket)

[philcarrillo]

I think I may have asked this before, but how do provincial and federal sales tax impact the dollars. Are they all tax-exclusive or tax-inlclusive?

[lcreid]

The funding is for the total amount including tax.

[lcreid]

I think invoices are probably generic and the attributes of an invoice are not particularly tied to the funding authorization. There's only one thing I think we need to vary by type of authorization, and that's for invoices for services, that typically cover a period (month). But even that isn't related to the type of authorization, because a CF0925 can authorize one time and repeating items.

The bare minimum we need for an invoice is:

• service provider
• amount
• [for services] start and end date of service
• [optional if you have the service dates, but recommended] invoice date
• [optional] vendor's invoice number/reference

[philcarrillo]

I had a different vision for the invoices, so the data model is slightly different.

I was working under the assumption that the application is not checking or commenting on the validity of applying the invoice to any particular RTP. If this is the case, I question the requirement to have services start and end dates, for example. The key item would be the amount, as what we are trying to do is total amounts invoiced that are 'covered' by the RTP.

The present data model has the following items:

• amount (as above)
• invoice date (as above)
• supplier reference (as above)
• notes (free form, so could contain services dates or other info)
• status (allows users to mark invoices paid, cancelled, etc) -- good idea, yes.

Based on the above I should add

• supplier name (the RTP covers both service providers and suppliers - I believe the that term 'supplier' is more generic and applies to both. @lcreid: I strongly feel this way leads to madness. If we need to capture both supplier and provider, then we need both fields.
• start and end date of service.

What data integrity checks should be applied to the invoice before the invoice is considered valid (only valid invoices would be included in the summary report for the funded child)? Possible ideas

• none
• amount exists @lcreid: and is not 0
• amount is greater than 0 (Note a negative amount could represent a credit, there fore I suggest is valid). @lcreid: Agreed. Might have credits.
• invoice date is within a specified timeframe after the service end date in the RTP. @lcreid There's not business rule about this, so I think we should stay away from this.
• service dates are within the window of service dates on the RTP. @lcreid this is a requirement of getting funding.

[lcreid]

It looks like the routes all worked out automagically. I wonder how that works? I guess Rails is smart enough to know there's already a route for some actions, so it doesn't generate extra ones.

[lcreid]

According to our behaviour consultant, he doesn't bill for Section B expenses. He thought some consultants might bill for travel. He thinks Section B is more for parents who want to go to a conference or have some other, non-equipment, expense.

[lcreid]

I think I may have created some confusion. I wanted to avoid a situation where the user has to match invoices the RTPs, but I was expecting that the system might have to match invoices to RTPs. It turns out we do, because you can't properly figure out how much has been spent unless you can somehow align the different invoices to the different RTPs. For example, someone might be overspent with one agency, but underspent on another. Also, the date of the invoice has to line up with the RTP.

I think there's a good chance that if this ever became an operational system for a funding agency, that we'd have to add explicit ability to assign invoices to RTPs to handle edge cases of some sort. But that's for later.

I think I might have just come up with an algorithm that will handle all reasonable cases without doing explicit linking. I need to think on it a bit more.

[philcarrillo]

If we do use an algorithm to match invoices to RTPs, it must be something that is not going to confuse users in the event that a change is made to the data. This would mean, for example, that we need to guarantee that, if a new invoice is entered, the resulting summary will change funding in a seemingly arbitrary manner. My question would be, if we are making this relationship - should we not expose our decisions to the user? Or are the various cases of invoice entry so well defined that the summary will always 'make sense' to the user?

The downside of exposing the relationship is that the user may wish to 'override' the algorithm - a case which would complicate the algorithm itself.