GitLab

Hey all,

We have a few clients who are interested in the accruals accounting in CiviCRM and I've done some smoke testing with it, but there appear to be some major cases that are not covered / working correctly. I've listed them below to start a discussion about what should be done about them. I've focussed on Membership for the time being, but I assume we should also look into events functionality at some stage:

Membership

1. The system appears to allocate over n-1 months rather then the n months of membership:

If I create a membership with a start date say 1/1/2019 for 1 year at a value of $120 and record a payment immediately (completed contribution), I would expect my accruals to be mapped through each month from 1/1/2019 to 1/12/2019 - i.e. split across the 12 months as $10 released each month. Instead the accruals are split over n-1 for some reason. Not sure if this is intended? This also causes some rounding issues.

2. Refunds

If I then subsequently refund the membership payment, no adjustment is made to the accruals. They should be reversed out.

3. Changes to the membership dates after creation of membership.

If I create a membership with a start date say 1/1/2019 for 1 year at a value of $120 and record a payment immediately (completed contribution), but then change the membership dates. For example to the next year, 1/1/2020 - 31/12/2020, I would expect that the original accruals should be reversed and new dates based on the updated dates of membership are created. No changes are made.

Pending contributions / invoicing

If I create a membership with a start date say 1/1/2019 for 1 year at a value of $120 and do not record a payment immediately (pending contribution):

Issue 1: The accruals are not actually created when the original invoice is created.

Issue 2: The accruals are not actually created when the original invoice is marked as paid.

Pending contributions / invoicing and cancel of invoice before payment

I could not therefore test the scenario where:

If I create a membership with a start date say 1/1/2019 for 1 year at a value of $120 and do not record a payment immediately (pending contribution): but then cancel the contribution after a few months, as for example the member did not pay.

In that case we would need the entries to be reversed out.

Over/Underpayments

For completeness I would also want to look into how over and underpayments should be treated but not had time for this.

I must admit that I'm not suggesting we fix this (and certainly we don't have the resource too), but perhaps this functionality should be marked at least as experimental or removed from core as I think it is far from robust.

@JoeMurray FYI.

Best

Jamie

nb. Our plan will be to create a report which gives a correct "as at" view of what the accruals position should be at any point in time, that clients can use to post the accruals amounts manually in their systems.