Association blueprint


(Luca Cristaldi) #41

I agree, I’ll remove that.

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.


(Cédric Krier) #42

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).


(Luca Cristaldi) #43

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 :tm: 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

(Luca Cristaldi) #44

After some bit of thinking, you’re risht on using an one to many relationship @ced


(Cédric Krier) #45

Could you update the proposal so we are all on the same page to discuss further.


(Luca Cristaldi) #46

yes, sorry… I modified the top post as requested (only the model and not the wizards
for now)


(Luca Cristaldi) #47

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.

What do you (you all) think?


(Cédric Krier) #48

Yes that’s why I tried to explain.

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.

It is missing a link to a party.


(Sergi Almacellas Abellana) #49

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.


(Luca Cristaldi) #50

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).

Sorry, I’ll change it ASAP


(Luca Cristaldi) #51

and for formalizing the"multiple membership per member" the structure (as far I understand from the coment you gave me):

model

association.membership.line:

  • membership
  • start_date (optional)
  • end_date (optional)

association.member

  • membership (association.membership.line)

start_date and end_date are not required:
if not specified they should be equal to the join_date and leave_date (from association.member)

Conditions and checks:

  • end_date <= leave date
  • start_date >= join_date
  • you can have overlapping membership

(Sergi Almacellas Abellana) #52

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?


(Luca Cristaldi) #53

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?


(Cédric Krier) #54

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.


(Luca Cristaldi) #55

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.


(Cédric Krier) #56

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.