In particular in clubs each member has to pay a yearly membership fee. How much often depends on age, status (e.g. student or not), whether childs and spouse are also members etc.. Due to this each year the membership fee must be newly derived in regard to more than often really complex rules. Furthermore a member can have taken something on credit (e.g. drinks) or new members must pay a deposit.

Having derived an individual membership fee it must normally be payed yearly. Whereby a credit often is payed monthly. In case of a direct debit mandate, both can be collected directly via SEPA transfer. In any other case first an invoice must be created and send to the member. After a receipt of payment the payed member fee or credit must be marked as “payed”. If debit isn’t payed a system automatically should inform members again or escalate outstanding balances to a dedicated person.

Our typo3 plugin is based on our MotoGo Lib and in consequence inherits its full potential. In our base version following features are implemented and directly usable:

• Frontend user record is extended to have a fee, a credit and deposit attribute. Optionally requested working hours are added. Whereby a logic transfers not performed working hours into an additional fee.
• In regard to each discipline a status attribute is maintainable. Whereby it’s mostly set automatically. In particular, if a direct debit mandate is enabled, things are really easy.
• Settlement runs are implemented as scheduled jobs. For example the fee status is evaluated yearly and if not yet payed, it’s escalated per E-Mail to a dedicated frontend user. In case it’s meanwhile payed a newly fee is determined and a new settlement run can start.
• In a “hidden frontend area” a list of frontend users recognized as erroneous is shown.
• In a “hidden frontend area” resulting lists of fees, credits and deposits are accessible. This lists provide all functionalities needed for individual management.
• In particular search and sort opportunities provide a good overview over all fees, credits or deposits.
• In a “hidden frontend area” a direct debit can be created for all frontend users having agreed direct debit. The list of all direct debits provide all functionalities needed for direct debit management.
• In case the status of a direct debit is set to “payed” this is propagated to all encompassed frontend users. Means, their status is also set to payed.
• If no direct debit agreement exists, PDF invoices are created and send per E-Mail to frontend users. The payment state of such frontend users can be set manually.
• (Filtered) frontend entries can be exported in an EXCEL list.
• (Filtered) direct debit entries can be exported in an EXCEL list.
• Direct debits can be exported in a SEPA file.
• Frontend user fee, credit and deposit fields are also available and editable in typo3 backend.

In case listed features aren't enough, it’s simple to extend fields, add scheduled jobs or verifications. Also, it’s simple to extend the base functionality with own actions alias functionalities. The simplicity of the MotoGo Lib ensures that it’s a matter of few configuration changes or additional lines of code.

Moreover, for all frontend output pure CSS, jquery mobile as well as bootstrap layout can be used. Whereby it poses no problem to use two layouts in one solution if necessary. Thus the working hour list can be part of a jquery page, even though the direct debit management is performed in a separate bootstrap environment.