Commit Graph

5 Commits

Author SHA1 Message Date
jordi fita mas 97831668e5 Add the number of maximum nights that tourist tax applies
This is required by law.

I do not know why i have this value and the tax amount in the database,
but the payment percent and the number of days are hardcoded. I guess i
am such an inconsistent mess.
2024-02-27 20:06:28 +01:00
jordi fita mas f2143cd0e6 Add the admin page to see payments
Had to do a couple of changes to the database: add the currency_code to
the payment relation, to format the price according to the payment’s
currency instead of the company’s; and the reference SQL function, to
replace the equivalent golang function, so that i can use it to index
payments.

The rest is mostly the same as any other page, except that the
individual payment’s page is not a form, but a regular info dump.

I also moved the payment settings as a sub-route of payments, as i
believe this makes more sense than an additional user menu item.
2024-02-14 04:54:42 +01:00
jordi fita mas bd84df8169 Add down payment
Customer wants to require a down payment of 30 % for bookings made
one week or more before the actual date, and to make the full payment
otherwise.

This would require yet another relation to keep these values. Fuck it;
i added them to the function, as they are very unlikely to change.

That forced me to change the test for draft_payment to use relative
dates, otherwise there is no way i can have stable results in the
future.
2024-02-13 23:45:25 +01:00
jordi fita mas af31daba8a Add positive_integer and nonnegative_integer domains
This is easier to read and requires less unit tests, but i only used
them in the new relations and fields for HEAD, because i do not see any
point on creating migrations just for that.
2024-02-13 22:12:30 +01:00
jordi fita mas e4636592c5 Add payment relation and use it to compute the booking’s cart
I had to add the payment concept separate from the booking, unlike other
eCommerce solutions that subsume the two into a single “order”, like
WooCommerce, because bookings should be done in a separate Camper
instance that will sync to the public instance, but the payment is done
by the public instance.  There will be a queue or something between
the public and the private instance to pass along the booking
information once the payment is complete, but the public instance still
needs to keep track of payments without creating bookings.

To compute the total for that payment i had to do the same as was doing
until now for the cart.  To prevent duplications, or having functions
with complex return types, i now create a “draft” payment while the
user is filling in the form, and compute the cart there; from Go i only
have to retrieve the data from the relation, that simplifies the work,
actually.

Since the payment is computed way before customers enter their details,
i can not have that data in the same payment relation, unless i allow
NULL values.  Allowing NULL values means that i can create a payment
without customer, thus i moved all customer details to a separate
relation.  It still allows payment without customer, but at least there
are no NULL values.

Draft payments should be removed after a time, but i believe this needs
to be done in a cronjob or similar, not in the Go application.

To update the same payment while filling the same booking form, i now
have a hidden field with the payment slug.  A competent developer would
have used a cookie or something like that; i am not competent.
2024-02-12 05:21:00 +01:00