Financial issueshttps://lab.civicrm.org/dev/financial/-/issues2022-08-25T21:31:40Zhttps://lab.civicrm.org/dev/financial/-/issues/205CiviFinancial Blue Sky Dreaming2022-08-25T21:31:40ZJoeMurrayCiviFinancial Blue Sky DreamingThere has been talk over the years by different people about a LExIM shift to a new paradigm/implementation for CiviAccount. I have been approached by someone who could rustle up a tiny starting stake for such a huge effort (I'm not conf...There has been talk over the years by different people about a LExIM shift to a new paradigm/implementation for CiviAccount. I have been approached by someone who could rustle up a tiny starting stake for such a huge effort (I'm not confident there would be an ability to get to 50% needed to launch an MIH that will likely cost in the six figures at CT billable rates). Here is a blue sky dreaming of how a CiviFinancials LExIM might succeed.
1. We find funding for integrating payments into Form Builder - this seems likely to be possible and occur, yet is still a big lift. Imagine all the financial aspects of webform_civicrm.
2. When implementing the new interface for contribution pages and event reg pages, etc., we have some 'dependency injection' that allows calls to be made either to the existing financial APIs or to a new set.
3. We work to implement the guts of CiviAccounting in a new way. Discussion is needed here, but I would be in favour of some significant breaking changes like simplifying the Financial Type/Financial Account model into much more standard accounting, preferrably with simple, sensible defaults.
1. We could design our own CiviAccounts v2 from scratch.
2. We could aim to implement an interface with an existing open source accounting system. The aim is to store all the CiviCRM financial transactions in a standard, validated way without having the development and support burden of making it ourselves. We'd only need to keep the integration going strong. Two candidates I have found that might be feasible, and there are many others, are Front Accounting and GnuCash. https://sourceforge.net/projects/frontaccounting/files/FrontAccounting%202.4/stats/timeline?dates=2019-08-01+to+2022-08-01 has the same technical stack as CiviCRM (PHP and MySQL) but seems to be trending down in installs. https://sourceforge.net/projects/gnucash/files/gnucash%20%28stable%29/stats/timeline?dates=2019-08-01+to+2022-08-01 is much more popular and losing momentum more slowly. It is built in C and C++, so it would be more complex to integrate.
3. If there is a fully open source implementation via CiviAccounts v2 or integrating an open source accounting package, then I would be okay with there being integrations with closed source accounting systems that are popular like Xero and QuickBooks Online. I suppose we could allow the existing implementation of CiviAccounts to be the open source option. While more financially realistic, it might be bad for our reputation.https://lab.civicrm.org/dev/financial/-/issues/84Making the poor performance associated with the creditnote_id field opt in r...2021-03-31T02:07:56ZeileenMaking the poor performance associated with the creditnote_id field opt in rather than opt outSometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers pe...Sometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers permitted a prefix & had to be sequential. However, anecdotally most large sites have hacked it out because the performance is so bad.
During the Barcelona sprint a [patch was merged](https://github.com/civicrm/civicrm-core/pull/15232) making it possible to install [an extension](https://github.com/greenpeace-cee/at.greenpeace.creditnope) to opt out of having a credit note sloooowwwly calculated.
However, in the world of Lexim use-case specific functionality should be OPT IN rather than opt out. Ie it should be the case that you need to install an extension to GET the slow behaviour not to NOT get it.
This is also a good test case for the general practice of moving functionality out of core into an extension. Here are the steps I believe are required
1) Determine where the code interacts with core. I did this & determined that all the places where createCreditNoteID is called from other than Contribution.create are not hit & I added a [pr to deprecate them](https://github.com/civicrm/civicrm-core/pull/15492) & fix the one place where it is hit. As a result of this the only interaction required would be in the pre_hook so we don't need to add a hook to generate this field (per https://lab.civicrm.org/dev/core/issues/1308) - this is a good thing as the assumption that credit notes & contributions would not be many to one is flawed & we don't want to bake this into core - we want to get it out of core
2) Create an extension that can be installed to add the credit note id in the pre hook.
3) Get the extension reviewed & approved for automatic installation
4) Add this new extension so it is installed on upgrade for existing sites - this step will require some input from @totten on how to do it & not knowing how is a blocker but probably getting the extension ready is a necessary pre-step & is probably only a couple of hours of work
Also we should consider this proposed performance improvement https://github.com/civicrm/civicrm-core/pull/15235