Association blueprint

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

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.

I do not think. User will check the fees before posting them.

For me, the creation and the posting can be done at once.

I do not think it is needed. A simple button on the fee is enough.

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

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?

I would be in favor of @dave proposal.

A post was split to a new topic: How to support “multi-company” in new module

ok, another point for discussion.
Should I implement a default date for member join/leave date (like @ced and @pokoli suggested in codereview )
here the discussion:

ced wrote:

wifasoi wrote:

pokoli wrote:
maybe we should add a default value for join date (probably today).

this date is important and it can’t be changed afterwards, so having a default
is very dangerous.

But normally you encode the date the member joined. So for me, it makes sense to
have a default.

If we decide to have a default, should i permit the user to modify the date in draft?
Now you can only modify the membership line when you go from 'running to ‘draft’, and you cannot go from ‘stopped’ to ‘draft’ (so the leave_date cannot be modified by the user via the gui)

My opinion is to not have a default, so the user will be force to check before committing the membership, and maintain the strict flow. But I’m open for discussion.

P.S:

But normally you encode the date the member joined. […]

What do you mean? You’re referring to the creation date of the record?

For me, yes. The default should not be a constraint.

I think the user should have the right to set the leave_date manually. I guess the button should launch a wizard which ask for a date (default today) and then run the transition for the date (using context).

You are probably right. For the foundation module, I did not set a default start date but I put a pre_validate on the button: http://hg.tryton.org/tpf/foundation_supporter/file/tip/foundation.py#l80

Ok, then I’ll add the pre-validation on the button and keep the “strict” flow (user cannot change the date (join/leave) after input, not even in the ‘draft’ state)

No in draft it should be allowed to edit the dates.

It seams there is a bit of ambiquity in this discussion, so sorry for the verbosity of this post.

Right now join_date can be changed in ‘draft’ (so the user can save the record in the draft state, and later modify it before approval), but if the record goes from ‘draft’ to ‘running’, the field will be permanently set to read-only. (I mimic similar behavior like sale_subscription with the start date)

If I understand correctly (and the above is not what you meant) you prefer:

  • no default
  • add pre-check for empty date field (this will be added regardless)
  • permit join_date to be changed in draft (leave date cannot be modified, because you cannot go from ‘stopped’ to ‘draft’ right now)

Please correct me if I’m wrong

For the subscription, the constraint exists because it is required for the computation. For me, such constraint should be added only if the computation can not deal with it.
So it should always be editable in draft except if some other value requires it to not be.

Understood.
There should be any problem, so I’ll relive the constraint.
The generating fee algorithm should be intelligent enough to generate the fees for the new date… but I’ll add a case in the unit test file, just to be sure.

What’s the current situation of this?

The module is under review. But as it is a large module it takes time and effort to review. It is on my TODO list but with a low priority. Others can help reviewing.