Custom invoice payment is carried by _service_paid_by_transaction function #470
Conversation
|
Child subscription date calculation is still a bit problematic as dates are counted from transaction date. If multiple custom invoices are paid child process lefts behind. |
…ction Custom invoice payment is carried by modified _service_paid_by_transaction function. Funcion has add_days input variable. Fixes issue: TampereHacklab#270 Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
Child subscription paid to date is calculated from days added to Parrent subscription. Days that single payment adds are substracted from days to add to Parent subscription. This is "virtualy" payment date. Single payment days of child subscription is added to virtual payment date. Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
Some users might found Dynamic pricing of payments missleading as normal access fee can be paid with dynamic pricing, but reorrucing custom invoice recalls flat rate. This commit changes custom invoice logic so that it allows dynamic pricing. Minimium payment is calculated from service minimum payment * service payment times. It can be disabled from settings.py or constance admin panel Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
sbeach92
force-pushed
the
mulysa-custom-invoice
branch
from
de291c5 to
2d1c8ad
Compare
Child service is paid by calling funcion again. So now if child service has childs, they get paid. Updated calcultaion so that multpile custominvoices wont break basic idea of child payments.
sbeach92
force-pushed
the
mulysa-custom-invoice
branch
from
e032aeb to
64320ca
Compare
Updated transaction commenting so that steps of transaction is easy to read Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
Admin can control if custom invoice can be paid multiple times. Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
With my childservice paymentlogic user could see increase of paid_to date. For example with initial transaction extradays are added to parent and chid services. It could be that shildservice after next payment is paid more to future than new transaction gives. This commit fixes that. Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
sbeach92
force-pushed
the
mulysa-custom-invoice
branch
from
b4bfed2 to
96f7736
Compare
Added testcases for payments. First testcase test normal payment of parent service, child service, and grand-child service. After those same are tested with custom invoice. Custom invoice is configured so that only one payment is registered. Also new feature of multple payment of single custominvoice is test. Second testcase test dynamic payment of parent service. Third testcase test dynamic pricing of custom invoice. Fourth testcase test child service payment when parent service is subscripted Ffth testcase test child service payment when parent service is unsubsripted Signed-off-by: Erkki Hietaranta <erkki.hietaranta@gmail.com>
Added support for childservice to pe paid indepentendly. Useful if member want to pay membership and parent service is intentionally suspended.
If user banktransfers are recalculated transaction comments would multiply. So cleaning lines before recalcultaion keeps comments tidy.
sbeach92
force-pushed
the
mulysa-custom-invoice
branch
from
c4e5df8 to
00a98c8
Compare
|
The way this works for the yearly membership subscription is bit problematic. Yearly membership shouldn't be a "subscription" in the first place, because it's not something that you can have unpaid dues for -- if you didn't pay your membership fees in 2023, you weren't an active member of the association in 2023, but are free to start paying them again in 2024. What we would probably need to fix this is a new toggle for services that disables the "negative days" feature for that service. Paying such a service when it's overdue always gives the user the full service's worth of subscription. This could then be used for yearly association membership. |
It is bit problematic. But this scales for other services, and custom invoices. One feature is allso that this way does not work as free ticket away from unresolved payments. |
|
@brndd "subscription" is still technical term here. |
Yearly membership still behaves like a subscription in Mulysa, while at least in Tampere Hacklab rules it's not a subscription, it's for a given year. You either pay your membership for 2024 or you don't, and if you don't, you can pay your membership for 2025 without having to also pay up for 2024. That's why yearly membership going into the negatives is questionable. |
|
Generally peoples need to resign form membership if they don't want to be member in some given year, so without specifically doing anything going to "minus" is very much proper action, even at Tampere. |
|
Does this change create a visible comment on every member payment received? If yes, then this will add a lot of "noise" to the list of bank transactions, making it much harder to notice error messages such as "insufficient amount", and notes from admins who have made manual changes to the transactions. Is there a way to handle the custom invoices without changing the signal/noise ratio in the bank transaction comments? |
Custom invoice payment is carried by modified _service_paid_by_transaction function.
Funcion has add_days input variable.
Changed basic transaction payment to pass that value allso
Fixes issue of child subscriptions not get paid: #270
If custom invoice service has child services they get paid allso. Payment is carried out at date when last reoccurring custom payment would virtually happen.
So If custom invoice payment pays whole year access fee, membership payment would be carried out at last month so membership would last another year.