Complex financial entities

[Coleman Watts]

Thanks Joe that makes sense. I didn't see in your example a way of creating multiple line items for one participant (e.g. from a price set), but I'm sure there's some syntax that would make sense.
Ok so some more questions about this:

• How to avoid a repeat of the the "Location" api (our last mega-api that collapsed under its own weight)?
• I've seen an example for Create, what about update and delete?
• Update is of course the stickiest and could potentially encompass crazy stuff like partial refunds, so we need to be careful about scope creep (not that I'm against partial refunds I think they would be great, just need to make sure the scope is doable for this project).
• Esp with regard to update I have some questions about the thick vs. thin approach. When updating a participant it doesn't make sense for the caller to be responsible for manually updating related line items, but neither does it make sense to make them go through a mega api to do the update. Would a happy medium be to keep the api's modular, but make them all a little smarter so that they all know how to keep their related entities in sync?

[JoeMurray]

http://wiki.civicrm.org/confluence/display/CRM/Invoice+API

[JoeMurray]

I'm renaming Invoice API to Order API to try to clear up confusion a bit.

What do people think of limiting the scope of the Order API to specifying and changing the things that are being 'purchased' or 'ordered'. Anything to do with money being received either online or offline or refunded would be handled by a new Payment API on a virtual object of payments.

The intent is to try to clarify processing, and hopefully lead to smaller, more understandable and easily maintained functions.

[Eileen]

Yes, I agree that separating orders & payments is a good idea.

As I've mentioned before,  I feel that CiviCRM breaks orders into processing paths depending on when they are paid for and it leads to a lot of complexity in the code & makes it hard to change things - e.g it's going to take a lot of work to be able to do back-office off-site credit card payments because they are just not allowed for in the way the order is created. Also, I'm trying to alter a payment by hook & depending on the form it might, or might not, have been saved to the database by the time the hook is invoked.