# Association blueprint
**URL:** https://discuss.tryton.org/t/association-blueprint/1282
**Category:** Ideas
**Created:** [March 31, 2019, 8:46pm UTC](https://discuss.tryton.org/t/association-blueprint/1282 "2019-03-31T20:46:36Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 14, 2019, 7:06pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/41 "2019-04-14T19:06:06Z")
> [@ced](#):
>
> > - sequence (from sequence\_ordered)
>
> I do not see the point. For me, the order should be based on start\_date of the linked period.
I agree, I’ll remove that.
> [@ced](#):
>
> > - request\_date (maybe this is not necessary)
>
> I think the `create_date` could be enough (or it could be delegated to customization)
I think I can leave this field out (I’ll add it on a separate module to satisfy my needs)
> [@ced](#):
>
> > - memberships (Many2Many to association.membership)
>
> I think it should be a `One2Many` with a `Many2One` to `association.membership` .
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.
> [@ced](#):
>
> 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` .
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 14, 2019, 9:43pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/42 "2019-04-14T21:43:35Z")
> [@wifasoi](#):
>
> 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).
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.
> [@wifasoi](#):
>
> If you mean that there be an join/leave date on `association.membership` , and the join/leave date of the member depends on that
Not depend but computed out of those date.
> [@wifasoi](#):
>
> But most importantly this will not permit to register the join date/leave date for each member.
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).
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 15, 2019, 3:44pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/43 "2019-04-15T15:44:36Z")
> [@ced](#):
>
> > 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).
>
> 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.
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
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 15, 2019, 4:15pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/44 "2019-04-15T16:15:20Z")
> [@wifasoi](#):
>
> `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)
After some bit of thinking, you’re risht on using an one to many relationship @ced
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 15, 2019, 6:19pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/45 "2019-04-15T18:19:42Z")
Could you update the proposal so we are all on the same page to discuss further.
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 15, 2019, 7:43pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/46 "2019-04-15T19:43:41Z")
yes, sorry.. I modified the top post as requested (only the model and not the wizards
for now)
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 16, 2019, 10:37am UTC](https://discuss.tryton.org/t/association-blueprint/1282/47 "2019-04-16T10:37:57Z")
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?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 16, 2019, 4:31pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/48 "2019-04-16T16:31:06Z")
> [@wifasoi](#):
>
> the use should be able to define a starting/ending date for each membership.
Yes that’s why I tried to explain.
> [@wifasoi](#):
>
> Maybe this is complicating things for nothing.
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.
> [@wifasoi](#):
>
> association.member
It is missing a link to a party.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [April 24, 2019, 1:12pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/49 "2019-04-24T13:12:53Z")
> [@wifasoi](#):
>
> association.membership.fee
>
> - member (many2one of association.member)
> - amount
> - period (the association.membership.period associated to this line)
> - payment\_lines (a function field, like the one in the invoice model)
> - move (the account.move.line associate with this fee line)
> - paid (store the date when the move was reconciled)
> - company (from CompanyMultiValueMixin)
Do we need to store the payment term of the fee?
For example for paying the anual quote in 12 periods.
> [@wifasoi](#):
>
> There will be 4 states:
>
> - draft
> - running
> - stopped
>
> form `draft` can go only on `pending` (the request\_date is required to change state);
> from `running` can go to `expelled` (the leave\_date is required to change state);
> from `stopped` is final (in case someone want to re-join, they need to create a new member).
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.
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 24, 2019, 8:30pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/50 "2019-04-24T20:30:30Z")
> [@pokoli](#):
>
> Do we need to store the payment term of the fee?
> For example for paying the anual quote in 12 periods.
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).
> [@pokoli](#):
>
> 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.
Sorry, I’ll change it ASAP
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 24, 2019, 9:04pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/51 "2019-04-24T21:04:15Z")
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
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [April 25, 2019, 8:40am UTC](https://discuss.tryton.org/t/association-blueprint/1282/52 "2019-04-25T08:40:36Z")
> [@wifasoi](#):
>
> > Do we need to store the payment term of the fee?
> > For example for paying the anual quote in 12 periods.
>
> 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?
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [April 25, 2019, 12:35pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/53 "2019-04-25T12:35:17Z")
> [@pokoli](#):
>
> 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.
I agree, it can be a useful feature/behavior, will complicate thing a bit but i think it can be worth it.
> [@pokoli](#):
>
> 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.
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?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 25, 2019, 1:50pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/54 "2019-04-25T13:50:45Z")
> [@pokoli](#):
>
> So this move will have a maturity date.
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.
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [May 12, 2019, 5:11pm UTC](https://discuss.tryton.org/t/association-blueprint/1282/55 "2019-05-12T17:11:39Z")
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [May 14, 2019, 10:32am UTC](https://discuss.tryton.org/t/association-blueprint/1282/56 "2019-05-14T10:32:19Z")
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`.
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [June 10, 2019, 9:45am UTC](https://discuss.tryton.org/t/association-blueprint/1282/57 "2019-06-10T09:45:41Z")
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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [June 10, 2019, 10:08am UTC](https://discuss.tryton.org/t/association-blueprint/1282/58 "2019-06-10T10:08:07Z")
> [@wifasoi](#):
>
> Should this wizard generate the move line as-well
I do not think. User will check the fees before posting them.
> [@wifasoi](#):
>
> should the move be posted manually
For me, the creation and the posting can be done at once.
> [@wifasoi](#):
>
> should the move be posted automatically by a wizard +cronjob
I do not think it is needed. A simple button on the fee is enough.
---
### Author:  [@wifasoi](https://discuss.tryton.org/u/wifasoi)
#### Post date: [June 21, 2019, 8:25am UTC](https://discuss.tryton.org/t/association-blueprint/1282/59 "2019-06-21T08:25:41Z")
Dave made some convincing point to change the name of the module
`association.membership` → `association.membership.type`
`association.membership.line` → `association.membership`
From the [codereview](https://codereview.tryton.org/277491002/)
> 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?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [June 21, 2019, 8:29am UTC](https://discuss.tryton.org/t/association-blueprint/1282/60 "2019-06-21T08:29:44Z")
I would be in favor of @dave proposal.
[Previous page](https://discuss.tryton.org/t/association-blueprint/1282.md?page=2)
[Next page](https://discuss.tryton.org/t/association-blueprint/1282.md?page=4)