I think I can leave this field out (I’ll add it on a separate module to satisfy my needs)
My idea (and please tell me if this can make sense), was that a member can have multiple subscription (so a one2many-many2many relation in this context make sense).
One user case to support this is to have a main annual membership, and the have a monthly based fee.
Sorry, but i didn’t quite understand.
If you mean that there be an join/leave date on association.membership, and the join/leave date of the member depends on that (just a function field) this will break down if I want add the many2many relation to membership. But most importantly this will not permit to register the join date/leave date for each member.
There is no point to use a many2many in this case because there are no reason to share the start/end date of multiple membership.
Not depend but computed out of those date.
Those dates are linked to when the member has an active membership.
But as it can be a complex scheme, I think it is even better to compute an active/inactive Boolean for a contextual date (default to today).
I think we are discussing two different implementation for the same thing.
So let me expose my idea/point:
association.membership is just a list of association.membership.period. So is act more like a “membership type” that a “fiscal year”
association.member can have multiple association.membership(so if we want to support this case I think many2many should be used, otherwise a classic many2one for just one membership per member)
join/leave date are facts! (for association is the date when the board decide to approve or expel the member), they should be inputted by the user and not calculated/derived (not even the end leave_date, but this can be argued). So they are different for each member (and they should be part of association.member), and they should not coincide with the start/end of a period (but they can).
You don’t need to close a membership every year. Just add more association.membership.period lines/records to the association.membership model, and the wizard will do the magic for you.
Do you want implement it more like a fiscal year (I think)? This complicate the association.membership a bit, but it can be done. The only positive side of it is that is easy to crate a new membership for the year with a wizard.
P.S: I have another proposal:
Does make sense to add a selection field in association.membership that can change the logic for creating the association.membership.fee lines (the receivable moves). something like:
next period
if join_date(association.member) is > start_date(association.membership.period), create association.membership.fee on next period
include
if join_date(association.member) is > start_date(association.membership.period), create association.membership.fee on this period
linear
change the fee linearly based on how many day remains to the end of the period
Added a theory of operation section with what the module should do.
I now see a possible problem with multiple membership for user:
For be an usable model, the use should be able to define a starting/ending date for each membership.
Maybe this is complicating things for nothing. So I think I’ll drop the multiple membership to a member.
For me it is needed if we want to allow to follow one member with different memberships over time.
But there could be some constraint like no overlapping and included in the join/leave dates.
Do we need to store the payment term of the fee?
For example for paying the anual quote in 12 periods.
Could you clarify this part? You say 4 states but only 3 are listed. An the transitions explanations include some state names that are not included on the list. Thank you.
Should I add the functionality?
I think it’s not necessary:
If you want have a mountly payment, the user should create 12 periods. And does make the module more complicated (need to check multiple line and reconciliation).
Well for me the fee is like an invoice document, where you track the amount and how it will be paid. The payment term defines how it will be paid, it may be in only one term but with some time delay.
As we create a move associated with the fee line I understand that this move will be between the party receivable account and the revenue account (like an invoice). So this move will have a maturity date.
How this maturity date will be computed? Using the period start_date? What if we agree with the member that the fee should be paid one week after the starting period?
I agree, it can be a useful feature/behavior, will complicate thing a bit but i think it can be worth it.
Unfortunately I’m not familiar with the payment term functionality, so I need to study how it works.
Where the payment term should be define/registered?
I think the payment term can (and should) be defined in the membership model (association.membership), or is best to define it on each period?
No because it is not an invoice. The member has to paid it to still be a member but he can also not to pay it.
So for me, there are no maturity date to set as we can not know nor force any date.
Ok, I’m slowly implementing all the feature. Before i go further i want to ask:
Should i create a new journal model (that have a journal and an account field), or make the user pick a journal for each membership?
I’m for the latter, but i want your opinion.
I think the simplest is to select the first journal with the right type (like in invoice) but allow to customize it by overriding a method on association.membership.
The module is almost ready for review.
I have only one doubt before i summit:
I generate a fee line (association.membership.fee) via a wizard + cronjob.
Should this wizard generate the move line as-well, or should be a manual process?
And if so:
should the move be posted manually (adding an action/button on the fee line that post the move)
or should the move be posted automatically by a wizard +cronjob
The first option imply that i create a tree view with a button that call the post action (like move), and will use the today date (or should be the starting date of the period? or should prompt the posting date)
the second imply a new wizard that will ask me the posting date.
Dave made some convincing point to change the name of the module association.membership → association.membership.type association.membership.line → association.membership
This model seems to represent a type of membership, is that right? If so
perhaps it should be called MembershipType and
association.membership.type?
I am thinking of “membership”, and “membership type” as used in this example:
My friend became a member of a club 5 years ago, his current membership runs
from the start to the end of the year. At the club there are 3 different types
of membership available called standard, honorary, and lifetime. He is an
honorary member, so does not need to pay any fees.
I’m in favor of changing association.membership to association.membership.type, but i want keep the association.membership.line.
What are your opinion in this matter?
for you.