Dieses Plugin für Admidio errechnet Mitgliedsbeiträge und speichert sie in der Admidio-Datenbank.
The following export options are provided by the plugin:
The calculation of contributions is realized through role memberships (One role a contribution and a contribution period may be assigned in Admidio. These entries evaluates the plugin from.)
These three different types of roles have been defined:
The entire operation as well as the configuration is done via the web interface of the plugin.
Note: References in this specification to certain menu items of the plugin are presented as follows: → <Menu tab> - <item> - <if necessary. Single Point> (e.g. → Settings family prefix)
For installation the following steps are carried out:
include(SERVER_PATH."/adm_plugins/mitgliedsbeitrag/mitgliedsbeitrag.php");
The first time and each time you start the plugin checks whether the values of version.php (version number and status of the plugin) match those in the database. With differences a setup routine is called.
In the first passage of the setup routine the database is checked for missing fields and categories in the profile.
If profile fields or categories are missing, they can be “Next” created via the button.
Only if all required profile fields are available, you can switch to the second passage.
Second passage: target-actual comparison
The second passage of the setup routine is to show only a target-actual comparison how the necessary categories and profile fields should be defined. Differences are highlighted in bold.
It would, for example, possible that already registered image with the name “account number” exists, but it is not the numeric data types. Necessary changes are not performed by the setup routine.
The plugin calculates the membership fees based on the role membership of a member.
For the calculation of contributions only roles are relevant for which contribution and contribution period are defined (also a contribution of 0 € is possible, eg for honorary members). A member may be in one or more roles. Registered with the roles contributions are summed. The category of the roles are not important.
Finishes one member during the year his membership in a role, or assigned during the year to a new new role, a proportionate contribution calculation is performed.
The calculation pro rata:
Attention: A calculation of contributions, also a pro rata, is performed only for active members. That is, a member must on the day on which the calculation is carried out, be an active member of the role. Future and former role memberships will not be considered.
Proportionate contribution calculation of family roles:
The pro rata contribution calculation of family roles works on a similar principle.
A family role is always calculated up to the end, because it is not technically possible to assign an end date (to calculations from - to perform). Decisive for a calculation pro rata in family roles is the date on which the role was created. This date (rol_timestamp_create) does not appear in Admidio and is not changeable within Admidio.
For an age-graded contribution determining an appropriate role must be available for each age range. The entire age range must be covered (without gaps). The role name is crucial as it is the age range is specified with. The relevant age need to do so by delimiter (→ Preferences Age Graded roles separator) be enclosed. Possible delimiter would e.g. * Or # or + or - or _ or! or%.
Examples of role names:
Example of age graded roles
A new member is in its first inclusion in one or more of these ages staggered roles incorporated (into which does not matter). About → General contribution calculation Remapping a routine is initiated, the all members of ages staggered roles based on their age, based on the date (→ Preferences Age Staggered roll date) redistributed to the ages staggered roles.
Contributions, which are defined at a family role, valid for the whole family, not for each individual member. All members of a family role pay a joint contribution.
In order for the plugin family roles may be different from other post roles, all family roles must begin with a pre-defined prefix, eg “Fam.” or 'family' (→ Preferences family roles prefix). It can be arbitrarily defined many family roles (eg Fam100 contribution EUR 100 or Fam200 contribution EUR 200). Here, however, to ensure that all the prefixes differ (not “fam” use simultaneously with “family”.).
Important Note: Even if you do not work with family roles, at least one family roles prefix must be defined, otherwise the plugin interprets all contributions roles as family roles and the contributions calculated incorrectly.
Contribution, contribution period and description of family roles can ve changed through a routine globally (> Settings family roles).
Special payer
In family roles the first member, in which account data are stored, marked as payer by the plugin. This debtor be assigned to the calculated contributions.
When a family member account information stored, so a payer is determined randomly. This could also be a small child.
To prevent this particular case, in the family a conductor can be determined. The leader in this case is for the payer program, regardless of whether with Him account data is stored or not.
A head of a family can not be head of another family at the same time.
Example of family roles
All other roles, where a contribution and a contribution period defined falls under “defined contribution roles”. The names of these roles and the categories in which they are located, are not important. Once a member is assigned to one or more of these roles, the contribution of the role in the contribution calculation is involved.
With defined contribution it is possible to calculate:
The plugin is controlled by an Accordion Menu (similar Admidio organization lineups.) With three tabs:
General | Export | Settings |
Each menu item is also provided with a short help text.
About contributions calculation
About contributions payments paid-date can be written to the database.
If a membership fee was paid, this can be recorded in the database (→ General-contributions). For this purpose, the date of the payment day (Paid-date) is written to the database.
A global reset (delete) of this paid-date is about - possible> General-contributions calculation.
Important Note: Setting a Paid-Date also has the effect:
Various tests of contributions roles.
Note: The role test does not affect the calculation of contributions. It serves as the name suggests, only for testing certain data.
The role test checks, among other things, whether in the ages staggered roles a gap in the ages is whether members are assigned to multiple roles (required) (exclusion) and whether there are members in family roles, who should not be in this family role because of their age.
Example for the role test of family roles:
Five different family role prefixes are defined. It should be checked whether a member of a family role should not be in this family role because of his age. All tests of family roles relate to the date, which was defined in the ages staggered roles.
Prefix | Age ranges / Examination / Comment | Parameter |
---|---|---|
Fam. | general family role without examination | |
FamERW2- | 0 Persons between 0 and 17, 2 Persons between 18 and 59, 0 Persons between 60 and 99 | 0*17:0;18*59:2;60*99:0 |
FamERW2+JUG1 | 0 Persons between 0 and 13, 1 Person between 14 and 17, 2 Persons between 18 and 59, 0 Persons between 60 and 99 | 0*13:0;14*17:1;18*59:2;60*99:0 |
FamERW1+SEN1 | 0 Persons between 0 and 17, 1 Person between 18 and 59, 1 Person between 60 and 99 | 0*17:0;18*59:1;60*99:1 |
FamSEN2 | 0 Persons between 0 and 17, 0 Persons between 18 and 59, 2 Persons between 60 and 99 (with Syntax Error!!!) | 0*17:0;18*59::0;60*99:2 |
Family roles with the prefixes defined above
The settings for the role test
The result of the examination
Example of correct parameters for the role test of a family role
The following export files can be created by the plugin:
Settings for the ages staggered roles.
If you want to work with several age graduations, in the field “number of graduations” first the value for the additional number must be entered and press the Save button.
The next time the module then the delimiters for the various graduations can be entered.
To delete a staggering again, the value for the delimiter is simply to delete and press the Save button
Settings for family roles.
If you want to work with several family roles, first the field “number of family roles” for the additional number must be entered and press the Save button.
The next time the module is called then the data of family roles can be entered. To delete the configuration of a family role again, is delete either
and press the Save button.
About the Options you can define Text Length, select options and a database delimiter, and also member numbers are generated.
About menu item > Settings Options Member numbers (n) simple, you can create numeric and inter-organizational membership numbers.
Message if no membership numbers were generated.
Notification of assigned membership numbers.
Settings, who can call the plugin.
Note: A selected role also has the Admidio Role Management requires at least one of the following permissions:
The plugin provides the ability to send e-mails in two modules.
The call of the e-mail module and the delivery is almost identical in both modules (exception: In Module prior information can be sent to multiple users at the same time an e-mail.). Exemplary here is the dispatch of a SEPA preliminary information is presented.
If an e-mail address is being deposited, a letter icon appears in the respective modules.
Important Note: As a recipient e-mail address, the email address of the debtor is always used.
Pressing the letter-symbol, the e-mail module is called. In Module prior information it is also possible by clicking on “Email” to send an Email to all selected members simultaneously.
Depending on the calling module (contributions or prior information) is an predefined text shown:
This text can be changed as desired, and then sent.
On August 1st, 2014 (originally February 1, 2014) is the national payment procedures for transfers and direct debits with BLZ and account number by SEPA credit transfers and SEPA direct debits replaced (SEPA = Single Euro Payments Area). The SEPA Core Direct Debit here is mandatory for all euro area countries. A special scheme for clubs does not exist.
SEPA orders are not used in DTAUS, but must be admitted as an XML file at to the bank.
The national account identifier (BBAN, in Germany, the traditional account number and bank) is replaced by the IBAN (International Bank Account Number, International Bank Account Number).
Until 1 August 2014 national payment transactions, or until February 1, 2016 cross-border payments you are also obliged to provide a BIC (Bank Identifier Code, internationally valid routing number).
This plugin can also be used after the August 1st, 2014, because it was extensively expanded in version 3.2.1 to SEPA functions.
Important Note: All SEPA functions presuppose a previously conducted and completed contribution calculation.
All data generated on the SEPA functions such as mandate reference, mandate date, sequence type, etc. can be changed later using the Edit the profile of a member. A here performed manually change should be carefully considered. Each SEPA function builds on another and assumes the existence of certain data ahead.
A due date can only be set on the module with “edit due date” if a mandate reference and a mandate date are present. However, if a due date on the profile of a member is registered without mandate reference and mandate date are present, a malfunction may occur running the program.
Each debit submitter (payee) has a unique identifier to identify the so-called creditor identifier (CI, Creditor Identifier). This number and the assigned mandate reference of the payee are enabling the payer a simple balance of burdens on his payment account / checking account. The Creditor Identifier is 18 characters long in Germany and is supported by the Deutsche Bundesbank (www.bundesbank.de).
At SEPA direct debits, the payer grants, both to the payee and to the payment service provider, his consent to transfer a certain amount from the payment account (directly or indirectly via the payee).
The SEPA Regulation ensures that a valid mandate prior to February 1st, 2014 of a payee to transfer recurring direct debits within an old payment scheme. After this date will remain valid and when the payer's consent applies to notify his payment service providers who transfers the relevant payee recurring debits according to the SEPA Regulation, provided that no national legislation or customer agreements on the continuing validity of direct debit mandates exist. In Germany, it is ensured by a change in the terms and conditions of the payment service provider that existing German direct debit mandates can also be used from 9 July 2012, for debits in the SEPA Core Direct Debit Scheme. So it is not necessary to seek a new mandate for the SEPA Core Direct Debit - unless that is still present no debit authorization.
SEPA Core Direct Debits, having a valid mandate, can be returned without statements of reasons up to eight weeks after the debit day. Missing the signed mandate (unauthorized debit) the period is extended to 13 months.
The mandate is valid for an unlimited period until canceled by the payer. If there is no new collection within 36 months after the last collection, the mandate expires and must be re-obtained. The deadline is mandatory and must be observed in particular by the payee.
Each Direct Debit Mandate is (eg invoice number max. 35 characters) characterized by a mandate reference that assigns the debit contributor independently.
Each SEPA data must accompany a mandate date. As mandated date the date must be where the customer (ie, the “SEPA direct debit mandate”) signed its mandate, or, for customers with an existing direct debit authorization, when they were informed of the SEPA migration.
The following mandate runtimes are distinguished:
FRST | first debit |
RCUR | debit sequence |
FNAL | last debit |
OOFF | Once debit |
The SEPA Direct Debit includes future due date (Due Date) which is specified by the payee and to which the payer will be charged. This is the payer communicated by the payee (debit submitter) in advance. In this way, the payer may ensure that its payment account / checking account at the time the direct debit has enough coverage.
The SEPA Core Direct Debit initial and recurring direct debits must be submitted 5 business days and subsequent direct debits 2 business days prior to maturity.
Before the direct debit the payee should inform the debtor of the proposed catchment in writing a prior information (engl. Pre-Notification at least 14 days prior to loading). This can also be effected by a contract or an invoice, which can also contain multiple due dates and the relevant catchment amounts.
A SEPA direct debit is authorized with signing the mandate. Therefore, a SEPA direct debit is valid without a preliminary announcement from a legal perspective as authorized.
A prior notice is to recreate when changing the amount of a sequence debit.
Preliminary information, are generally to be sent to the Account owner. In exceptional cases (address of the account owner is not known) is to substitute inform the member, with the request to forward this information to the account owner.
All data for a prior information notice is stored in the profile of a member.
If the member is at the same time the account owner, the account owner may NOT have a field value. It must be empty. In this case, only the following data should be stated:
If the account owner / payer and member are not identical, this data must also be shown:
Tip: Basically an e-mail address should always be stored so that the preliminary information can be sent without much effort on the plugin via email to the account owner / payer.
An automatic conversion of bank code and account number to BIC and IBAN is via the menu item → “Settings Account data- Account data convert” possible.
Note: You may need to → Organizational sttings → Module → downloads the value of the maximum file size to be increased.
The mandate reference for a dues-paying member is the same for the entire period of his membership in the association. It is generated after the initial calculation of membership dues and should not be changed.
Note: If a mandate reference subsequently changed, a change of mandate is must be carried out.
A mandate reference is divided into 3 sections. The number of characters (= minimum length) can be individually defined in the setup.
Section 1 | Length 1 to x | Prefix |
Section 2 | Length x+1 to y | Number of points |
Section 3 | Length y+1 to z | Sequential number |
Prefix
The prefix can be set individually in the setup. There are three different options for:
Note: A prefix may, but need not be registered.
Number of points
The section 2 is to be filled with zeros(0), if the minimum length in the setup minimum is not reached.
Sequential number
Section three is a serial number. For this purpose, in the setup a database field is selected with unique content (eg membership number or user_id). The value of this database field is used as the serial number.
Example 1:
Example 2:
A mandate reference is created only for those members,
Each debit requires its own mandate with its own mandate reference. The ability to work with frame mandates (= Sets of debits under a mandate reference) have limited support by the plugin. Thus multiple withdrawals can be summarized under a mandate reference, you have to go through the family roles. The property of family roles, to use the same mandate reference for all members, can be used for frame mandates. These are all members, to be used for the same mandate reference, summarized within a family role. The contribution of the family role is the summary of the individual contributions of the members.
Example:
Die Beitragsgestaltung eines Vereins sieht folgendermaßen aus:
The “Mustermann” family consists of the following persons:
All bookings of family “Mustermann” are to be grouped under a framework mandate.
Solution:
With menu item → General →Mandate administration→mandate any mandate date can be added to a mandate reference.
A mandate change is required, provided that mandate data has changed since the last collection.
With menu item →General →Mandate administration → mandate you can edit the changes of a mandate for a payer.
Change of mandate (Debtor).
With menu item →Settings → Account information you can edit the changes of a mandate for a payer.
Change of mandate (the Payee).
To create a SEPA XML file the following steps are to run:
With menu item → General → Mandate Management → Mandate References mandate references can be created.
Message if no mandate references have been assigned.
Message if mandate references have been assigned.
With →General → Mandate reference → Mandat edit you can enter the mandate date to each mandate reference.
The XML file is produced with →Export → SEPA → XML file.
*Note: The plugin membership fee can only generate SEPA XML files * having a common sequence type * having the same due date. Before creating an XML file therefore is a combination of select due date / sequence type. == 5. Create preliminary information == The menu item → Export SEPA →Preliminary information creates a list in CSV format, which can be used as a source for a mail merge of preliminary information and offers the possibility of a preliminary information via e-mail. == 6. Pass XML file to the bank == After the XML file is created, it must be submitted to a bank. == 7. Set paid-date == In order to complete the whole process, it is important that a paid-date is set. By setting the date a sequence type FRST is changed to the sequence type RCUR. ===== First steps ===== * Create backup of database Admidio * Start membership fee for the first time; thereby missing profile fields are applied. * Specify which roles you want to work. * Configure the roles If age staggered rollers are used: * Create the roles according to the described naming convention and note that there are no gaps (eg “age -0- to -17-” or “age -18- to -99-”) If a member therby is older than 99 years - an error message → General-contribution calculation remapping is shown. * Define contribution and contribution period of these roles (description may, but need not be specified) * Define in → Settings → Age staggered roles a date (usually the 31.12 of each year.) and the separator character used. * With → General → Roles Summary it will be checked whether all age staggered rollers are detected and displayed. * All members who are in this age staggered roles, add to a roll. * With → General →contribution calculation Remapping remap all members (according to age). * Note: Members who were born after the date may not be in an age staggered role as they do not yet exist for the program (based on the date). These members therefore accommodate either a family or in a separate defined contribution role. Using Family roles: * Create all family roles and note that they begin with the same prefix. (eg prefix “family” for family “Meyer” and family “Huber” or prefix “Fam.” for Fam. Meier and Fam. Huber) * In → Settings → Family roles define the used prefix, the contribution and the contribution period (description may, but need not be specified) and save. * Check with → General → Roles Summary, if all family roles are detected and displayed. * Assign members to family roles If defined contribution rolls are used:**
All configuration data is stored in an additional table called adm_plugin_preferences in Admidio database.
Currently, in this table, the following configurations of plugins are stored:
The table entries of the plugins membership fee all begin here with the letters “PMB_”.
Current information regarding update or reinstall the Plugin are located in the readme.txt.