Modeling invoices in OCDS

[yolile]

Some countries (Ecuador, Paraguay) track the invoice information (date, amount, number) of contract implementation. This invoice doesn't represent a payment (transaction) yet, as it is just the invoice submission, and the actual payment comes after that, and sometimes that info is not tracked in the procurement system.

For Chile and others similar cases, we used Milestone (with a new value field) #438 (and Paraguay added their own extension #635)

But I'm wondering if, for invoices, we should use the same approach. Or maybe consider Transaction.status as suggested in #438 (comment). In any case, we could add a worked example that describes how to model this. We have a worked example for contract implementation milestones, but I don't think is the same as invoices.

[jpmckinney]

Per the discussion in #1160, the experience of tracking any status other than a final state yields incorrect and/or low-quality data.

An invoice is a document that has certain consequences and around which there is a process to handle it. If we were to focus on modelling the document, then this issue is related to #1169. If we were to focus on a consequence (e.g. a payment due date), then perhaps a milestone is sufficient. If we were to focus on the process of handling the invoice, then it might look more like #635.

Doing something like #635 would require a lot more work. If we're just looking at date, amount, number, then I don't think we have enough to do #1169. So it's looking like a milestone is fine for now?

[yolile]

So it's looking like a milestone is fine for now?

Yes, we only need to define what this milestone means and, therefore, what date type to use (dateMet or dueDate). The milestone could be "Invoice sent" and then we can use dateMet for the invoice date (and milestone status is always set to met) or the milestone could be "Payment obligation" but for that case, none of the dates fit well for the invoice date. So, I guess the first is best.

[jpmckinney]

Yeah, I guess we'd need a new date field for the submission/receipt date if we were to go with the 'payment obligation' perspective.