Custom fields of an ordergroup can set financial_transaction_source to
true, to act as an source for a new collection of FinacialTransaction.
A typical usecase would be a variable membership fee, which will be stored
in a custom field on the ordergroup. When a new membership period begins
a collection with all membership fees can be created with one click.
When the charge_members_manually option is active there is no need for an
explicit balancing step. This new function allows to close_direct all
orders which have an assigned invoice, which is usually indication enough
to find orders which can be closed finally.
If multiple financial transaction belong to a bank transaction, it
is sometimes easier to create them as a collection and add the bank
transaction instead of adding all financial transaction to a link
created via a bank transaction.
A new checkbox will allow user to set the balance to a given ABSOLUTE value
in addition to changing it by a RELATIVE value. This can be used if the
balance is tracked outside of foodsoft and should be syncroniced or for
setting the balance to zero for multiple ordergroups.
Some browser request /:foodcoop/login with the HTTP-Accept-Header set
to "image/webp,image/*;q=0.8", which leads to an internal server error
due to a not existing template. Call respond_to to allow only html and
respond with the correct "406 Not Acceptable" HTTP status code.
This change introduces two new data types to group the financial
transactions. Now every transaction has a "type", which itself belongs
to a "class".
Types should be used add structured information to an transaction, instead
of writing it into the notice textfield. E.g. this could be used to have
different types depending on the source of money (cash vs. bank transfer).
Classes are shown as different columns in the tables and will be uses to
group transactions of specific types. They should be used if not the whole
amount of ordergroup should be used to order food. E.g. if there is a
deposit or membership fee, which is independent of the normal credit.
This will allow us to implement additional features based on classes in
the future. E.g. the sum of transactions in the "membership fee" class
must be positive to allow food orders or show a big warning if it is bellow
a certain value.