2023-02-22 13:39:38 +00:00
|
|
|
|
-- Test invoice_tax_amount
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
|
create extension if not exists pgtap;
|
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
|
|
|
select plan(12);
|
|
|
|
|
|
|
|
|
|
set search_path to numerus, auth, public;
|
|
|
|
|
|
|
|
|
|
select has_view('invoice_tax_amount');
|
|
|
|
|
select table_privs_are('invoice_tax_amount', 'guest', array[]::text[]);
|
|
|
|
|
select table_privs_are('invoice_tax_amount', 'invoicer', array['SELECT']);
|
|
|
|
|
select table_privs_are('invoice_tax_amount', 'admin', array['SELECT']);
|
|
|
|
|
select table_privs_are('invoice_tax_amount', 'authenticator', array[]::text[]);
|
|
|
|
|
|
|
|
|
|
select has_column('invoice_tax_amount', 'invoice_id');
|
|
|
|
|
select col_type_is('invoice_tax_amount', 'invoice_id', 'integer');
|
|
|
|
|
|
|
|
|
|
select has_column('invoice_tax_amount', 'tax_id');
|
|
|
|
|
select col_type_is('invoice_tax_amount', 'tax_id', 'integer');
|
|
|
|
|
|
|
|
|
|
select has_column('invoice_tax_amount', 'amount');
|
|
|
|
|
select col_type_is('invoice_tax_amount', 'amount', 'integer');
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
|
truncate invoice_product_tax cascade;
|
|
|
|
|
truncate invoice_product cascade;
|
|
|
|
|
truncate invoice cascade;
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
truncate contact_tax_details cascade;
|
2023-02-22 13:39:38 +00:00
|
|
|
|
truncate contact cascade;
|
|
|
|
|
truncate tax cascade;
|
2023-02-28 11:02:27 +00:00
|
|
|
|
truncate tax_class cascade;
|
2023-03-04 21:15:52 +00:00
|
|
|
|
truncate payment_method cascade;
|
2023-02-22 13:39:38 +00:00
|
|
|
|
truncate company cascade;
|
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
2023-03-04 21:15:52 +00:00
|
|
|
|
set constraints "company_default_payment_method_id_fkey" deferred;
|
|
|
|
|
|
|
|
|
|
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, country_code, currency_code, default_payment_method_id)
|
|
|
|
|
values (1, 'Company 1', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', 'ES', 'EUR', 111)
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
insert into payment_method (payment_method_id, company_id, name, instructions)
|
|
|
|
|
values (111, 1, 'cash', 'cash')
|
2023-02-22 13:39:38 +00:00
|
|
|
|
;
|
|
|
|
|
|
2023-03-04 21:15:52 +00:00
|
|
|
|
set constraints "company_default_payment_method_id_fkey" immediate;
|
|
|
|
|
|
2023-02-28 11:02:27 +00:00
|
|
|
|
insert into tax_class (tax_class_id, company_id, name)
|
|
|
|
|
values (11, 1, 'tax')
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
insert into tax (tax_id, company_id, tax_class_id, name, rate)
|
|
|
|
|
values (2, 1, 11, 'IRPF -15 %', -0.15)
|
|
|
|
|
, (3, 1, 11, 'IVA 4 %', 0.04)
|
|
|
|
|
, (4, 1, 11, 'IVA 10 %', 0.10)
|
|
|
|
|
, (5, 1, 11, 'IVA 21 %', 0.21)
|
2023-02-22 13:39:38 +00:00
|
|
|
|
;
|
|
|
|
|
|
Split contact relation into tax_details, phone, web, and email
We need to have contacts with just a name: we need to assign
freelancer’s quote as expense linked the government, but of course we
do not have a phone or email for that “contact”, much less a VATIN or
other tax details.
It is also interesting for other expenses-only contacts to not have to
input all tax details, as we may not need to invoice then, thus are
useless for us, but sometimes it might be interesting to have them,
“just in case”.
Of course, i did not want to make nullable any of the tax details
required to generate an invoice, otherwise we could allow illegal
invoices. Therefore, that data had to go in a different relation,
and invoice’s foreign key update to point to that relation, not just
customer, or we would again be able to create invalid invoices.
We replaced the contact’s trade name with just name, because we do not
need _three_ names for a contact, but we _do_ need two: the one we use
to refer to them and the business name for tax purposes.
The new contact_phone, contact_web, and contact_email relations could be
simply a nullable field, but i did not see the point, since there are
not that many instances where i need any of this data.
Now company.taxDetailsForm is no longer “the same as contactForm with
some extra fields”, because i have to add a check whether the user needs
to invoice the contact, to check that the required values are there.
I have an additional problem with the contact form when not using
JavaScript: i must set the required field to all tax details fields to
avoid the “(optional)” suffix, and because they _are_ required when
that checkbox is enabled, but i can not set them optional when the check
is unchecked. My solution for now is to ignore the form validation,
and later i will add some JavaScript that adds the validation again,
so it will work in all cases.
2023-06-30 19:32:48 +00:00
|
|
|
|
insert into contact (contact_id, company_id, name)
|
|
|
|
|
values (7, 1, 'Contact')
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
insert into contact_tax_details (contact_id, business_name, vatin, address, city, province, postal_code, country_code)
|
|
|
|
|
values (7, 'Contact', 'XX555', '', '', '', '', 'ES')
|
2023-02-22 13:39:38 +00:00
|
|
|
|
;
|
|
|
|
|
|
2023-03-05 17:50:57 +00:00
|
|
|
|
insert into invoice (invoice_id, company_id, invoice_number, invoice_date, contact_id, currency_code, payment_method_id)
|
|
|
|
|
values ( 8, 1, 'I1', current_date, 7, 'EUR', 111)
|
|
|
|
|
, ( 9, 1, 'I2', current_date, 7, 'EUR', 111)
|
|
|
|
|
, (10, 1, 'I3', current_date, 7, 'EUR', 111)
|
|
|
|
|
, (11, 1, 'I4', current_date, 7, 'EUR', 111)
|
2023-02-22 13:39:38 +00:00
|
|
|
|
;
|
|
|
|
|
|
Move the product_id field from invoice_product to a separate table
We are going to allow invoices with products that are not (yet) inserted
into the products table.
We always allowed to have products in invoices with a totally different
name, description, price, and whatnot, but until now we had the product
id in these invoice lines for statistics purposes.
However, Oriol raised the concern that this requires for the products
to be inserted before we can create an invoice with them, and we do not
plan to have a “create product while invoicing” feature, thus it would
mean that people would need to cancel the new invoice, create the new
product, and then start the invoice again from scratch.
The compromise is to allow products in the invoice that do not have a
product_id, meaning that at the time the invoice was created they were
not (yet) in the products table. Oriol sees this stop-invoice-create-
product issue more important than the accurate statistics of product
sales, as it will probably be only one or two units off, anyway.
I did not want to allow NULL values to the invoice product’s product_id
field, because NULL means “dunno” instead of “no product”, so i had to
split that field to a separate table that relates an invoice product
with a registered product.
2023-04-19 17:30:12 +00:00
|
|
|
|
insert into invoice_product (invoice_product_id, invoice_id, name, price, quantity, discount_rate)
|
|
|
|
|
values (12, 8, 'P', 100, 1, 0.0)
|
|
|
|
|
, (13, 8, 'P', 200, 2, 0.1)
|
|
|
|
|
, (14, 9, 'P', 222, 3, 0.0)
|
|
|
|
|
, (15, 9, 'P', 333, 4, 0.2)
|
|
|
|
|
, (16, 10, 'P', 444, 5, 0.0)
|
|
|
|
|
, (17, 10, 'P', 555, 6, 0.1)
|
|
|
|
|
, (18, 11, 'P', 777, 8, 0.0)
|
2023-02-22 13:39:38 +00:00
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
insert into invoice_product_tax (invoice_product_id, tax_id, tax_rate)
|
|
|
|
|
values (12, 2, -0.15)
|
|
|
|
|
, (12, 5, 0.21)
|
|
|
|
|
, (13, 3, 0.04)
|
|
|
|
|
, (14, 4, 0.10)
|
|
|
|
|
, (14, 5, 0.21)
|
|
|
|
|
, (14, 2, -0.07)
|
|
|
|
|
, (15, 4, 0.10)
|
|
|
|
|
, (16, 4, 0.10)
|
|
|
|
|
, (16, 5, 0.21)
|
|
|
|
|
, (17, 5, 0.21)
|
|
|
|
|
, (17, 3, 0.04)
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
|
$$ select invoice_id, tax_id, amount from invoice_tax_amount $$,
|
|
|
|
|
$$ values ( 8, 2, -15)
|
|
|
|
|
, ( 8, 3, 14)
|
|
|
|
|
, ( 8, 5, 21)
|
|
|
|
|
, ( 9, 2, -47)
|
|
|
|
|
, ( 9, 4, 174)
|
|
|
|
|
, ( 9, 5, 140)
|
|
|
|
|
, (10, 3, 120)
|
|
|
|
|
, (10, 4, 222)
|
|
|
|
|
, (10, 5, 1095)
|
|
|
|
|
$$,
|
|
|
|
|
'Should compute the amount for all taxes in the invoiced products.'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
select *
|
|
|
|
|
from finish();
|
|
|
|
|
|
|
|
|
|
rollback;
|