Transaction classes: determine whether credit counts to account's total balance or not

[twothreenine]

When using multiple transaction classes, the respective credits are summed up in the account's total balance, from which the available credit (which can be used for ordering) is calculated. We need an option for a transaction class not to count to the account balance.

In our case, we have a transaction class for the actual credit (Guthaben), one for the membership subscription (Mitgliedsbeitrag) and one for a deposit (Einlage). Members pay in to each of them manually. From the membership subscription class, the actual fee gets subtracted monthly. Neither membership subscription nor deposit should be usable to order something. But Foodsoft sums them all up to the account's total balance. This will get confusing when e.g. a member prepays their membership fee for half a year, therefore has a lot of total credit, uses it for orders (while forgetting that only a part of it is actual credit) and then slips into the red when the next monthly fees are subtracted.

When adding something to the membership subscription column, the total balance including the available credit rises:

I think each transaction class should have an option to determine whether it counts to the total balance or not. This could be included in the following menu

[wvengen]

Thanks for the issue, this actually clears up a question I had about the available funds with regards to financial transaction classes.

The available funds (I guess that's available credit in the UI) are primarily what you have left to use when ordering, right? That would mean that only financial transaction classes that are used when an order is accounted, would need to be taken into account. I think we need to consider this part too when tackling this issue.

[twothreenine]

Yes, that's right, but the available funds are already calculated based on the balance. Therefore I think we only have to change the calculation of balance and count only transactions of certain classes. Or we introduce another attribute like "order balance" which is calculated that way, in order to keep an account's "total balance."

However, we've had discussions that it might be useful to optionally "freeze in" an equivalent amount of available funds if a certain transaction class, like membership fee, has a negative balance. That means it should count to the ordergroup's order balance only when it's negative, or the minimum amount which has to remain on the order balance (as set in the config) is raised for that specific ordergroup by a certain amount. There was also a suggestion by @paroga to optionally allow an ordergroup to overdraw its order balance by the positive balance of certain other transaction classes. With all that enabled, it would come down to the same as now, but more subdivided (or more confusing ...)

[wvengen]

Therefore I think we only have to change the calculation of balance and count only transactions of certain classes. Or we introduce another attribute like "order balance" which is calculated that way, in order to keep an account's "total balance."

Now that we have transaction classes, I would think that makes sense. This would also relate to what financial transaction class is used when an order is accounted.

That means it should count to the ordergroup's order balance only when it's negative, or the minimum amount which has to remain on the order balance (as set in the config) is raised for that specific ordergroup by a certain amount. There was also a suggestion by @paroga to optionally allow an ordergroup to overdraw its order balance by the positive balance of certain other transaction classes.

To me these sound like good features for a plugin, with Foodsoft providing the flexibility to hook into this.

[paroga]

To me these sound like good features for a plugin, with Foodsoft providing the flexibility to hook into this.

Not to me. This financial stuff is too much core handling and has too much quirks in it to move it to an plugin. I also don't see much sense to place everything in its own plugin, just to move it into a plugin.

[wvengen]

Not to me. This financial stuff is too much core handling and has too much quirks in it to move it to an plugin. I also don't see much sense to place everything in its own plugin, just to move it into a plugin.

I a little worried that Foodsoft is becoming more complex than necessary. But let's see if we can implement this in a way that doesn't make the logic harder to understand (but perhaps easier).

[paroga]

I a little worried that Foodsoft is becoming more complex than necessary.

This are all features used by multiple foodcoops in Austria, so it's not very specific. Since it comes preconfigured and nobody needs to change the financial entities, when not used in the "extended way", I see here no problem.