Association blueprint

(Cédric Krier) #37

I think the fee amount should be defined by a list with a from date. So to compute it will take the last amount with a from date before the period date. (Similar to the cost price of employee).

I do not see the point to make a tree structure.

Receivable should always be taken from party.

Yes it should be similar to the fiscal year.
But I think we should allow different kind of period (e.g. monthly, quaterly, yearly etc.). But it should just be a name. It does not require to have any frequency defined.
I do not know how we can call that. But it will be set on period and on membership.type

If it is not implemented in base, it will not be possible to extend the module to add it.

(Luca Cristaldi) #38

If I structure it more like the Fiscal year periods the “type”(like a product type) is not necessary: so we have something like:

  • membership.TBD

    • name
    • periods (a many2many field with period lines)
  • memership.period.line (TBD name)

    • name
    • to_date
    • from_date (so we can have non contiguous periods, dunno… summer vacation?)
    • fee (the fee amount)

and like the fiscal year, two wizard:

  • For generating contiguous periods (like Monty, weekly ecc…)
  • For creating a new “membership.TBD”(the one that collect all the period line) based from the one you select, but will add a year to all the period date.

then a wizard can generate all the fee lines (association.membership.fee) based on the “membership.TBD” the join_date and the leave_date (association.member ). (need to add “membership.TBD” filed to the “association.member” for this to work")

Sorry, but i think i misunderstood you. Can you elaborate more on this?

Thank you for all the feedback (specially @ced)

(Luca Cristaldi) #39

Ok, I’m proposing this structure:

  • association.membership
    • name
    • periods
    • account_revenue
    • company (from CompanyMultiValueMixin)
  • association.membership.period
    • name
    • start_date
    • end_date
    • fee_amount
    • membership (many2One)
    • company (function)
  • association.membership.fee
    • sequence (from sequence_ordered)
    • member (many2one of association.member)
    • fee_amount (multivalue)
    • period (the association.membership.period associated to this line)
    • payment_lines (a function field, like the one in the invoice model)
    • membership_move (the account.move.line associate with this fee line)
    • state (a function field with selector field, so you can check if the line is payed or not)
    • company (from CompanyMultiValueMixin)

and for the member:

  • association.member
    • state
    • code (read-only, set by member_sequence)
    • company (taken from context)
    • request_date (maybe this is not necessary)
    • join_date
    • leave_date
    • memberships (Many2Many to association.membership)
    • membership_fees (many2one field with all the association.membership.fee lines)

The new idea is that a member can have multiple “membership”(association.membership). with association.membership model is now possible to do so.

the association.membership in short:

  • there is no state to a membership (not like a fiscal year, and there is no need)
  • the association.membership defines the account revenue.
  • you need to add a ‘association.membership.period’, and the the wizard/cron job will generate all the association.membership.fee for each member based on a given date.

the association.membership.fee in short:

  • defined by a start-end date
  • the price can vary between periods

If there are no other comment/necessary feature to implement, I’ll start to program the module with this structure/feature

(Cédric Krier) #40

I do not see the point. For me, the order should be based on start_date of the linked period.

I would name it simply amount.
I do not think it should be a multivalue, it should be the value for the linked company.

Just name it move.

I think it is better to name it paid and store the reconciliation date (behave like the reconciled of invoice).

I think the create_date could be enough (or it could be delegated to customization)

I think it should be a One2Many with a Many2One to association.membership. The relation model should have a start and end date (so the join_date and leave_date move to this relation model).
It could still have a join_date and leave_date but they will be Function field computed out of the memberships.

(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):



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


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