2023-03-11 19:58:20 +00:00
|
|
|
|
-- Test edit_invoice
|
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
|
|
create extension if not exists pgtap;
|
|
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
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
|
|
|
|
select plan(15);
|
2023-03-11 19:58:20 +00:00
|
|
|
|
|
|
|
|
|
|
set search_path to auth, numerus, public;
|
|
|
|
|
|
|
|
|
|
|
|
select has_function('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]']);
|
|
|
|
|
|
select function_lang_is('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'plpgsql');
|
|
|
|
|
|
select function_returns('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'uuid');
|
|
|
|
|
|
select isnt_definer('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]']);
|
|
|
|
|
|
select volatility_is('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'volatile');
|
|
|
|
|
|
select function_privs_are('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'guest', array []::text[]);
|
|
|
|
|
|
select function_privs_are('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'invoicer', array ['EXECUTE']);
|
|
|
|
|
|
select function_privs_are('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'admin', array ['EXECUTE']);
|
|
|
|
|
|
select function_privs_are('numerus', 'edit_invoice', array ['uuid', 'text', 'integer', 'text', 'integer', 'tag_name[]', 'edited_invoice_product[]'], 'authenticator', array []::text[]);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
|
|
truncate invoice_product_tax cascade;
|
|
|
|
|
|
truncate invoice_product cascade;
|
|
|
|
|
|
truncate invoice cascade;
|
|
|
|
|
|
truncate contact cascade;
|
|
|
|
|
|
truncate product cascade;
|
|
|
|
|
|
truncate tax cascade;
|
|
|
|
|
|
truncate tax_class cascade;
|
|
|
|
|
|
truncate payment_method cascade;
|
|
|
|
|
|
truncate company cascade;
|
|
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 2', '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')
|
|
|
|
|
|
, (112, 1, 'bank', 'send money to my bank account')
|
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
set constraints "company_default_payment_method_id_fkey" immediate;
|
|
|
|
|
|
|
|
|
|
|
|
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 (3, 1, 11, 'IRPF -15 %', -0.15)
|
|
|
|
|
|
, (4, 1, 11, 'IVA 21 %', 0.21)
|
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
insert into product (product_id, company_id, name, price)
|
|
|
|
|
|
values ( 7, 1, 'Product 1.1', 1212)
|
|
|
|
|
|
, ( 8, 1, 'Product 2.2', 2424)
|
|
|
|
|
|
, ( 9, 1, 'Product 3.3', 3636)
|
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
insert into contact (contact_id, company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, country_code)
|
|
|
|
|
|
values (12, 1, 'Contact 2.1', 'XX555', '', '777-777-777', 'c@c', '', '', '', '', '', 'ES')
|
|
|
|
|
|
, (13, 1, 'Contact 2.2', 'XX666', '', '888-888-888', 'd@d', '', '', '', '', '', 'ES')
|
|
|
|
|
|
;
|
|
|
|
|
|
|
Replace tag relations with array attributes
It all started when i wanted to try to filter invoices by multiple tags
using an “AND”, instead of “OR” as it was doing until now. But
something felt off and seemed to me that i was doing thing much more
complex than needed, all to be able to list the tags as a suggestion
in the input field—which i am not doing yet.
I found this article series[0] exploring different approaches for
tagging, which includes the one i was using, and comparing their
performance. I have not actually tested it, but it seems that i have
chosen the worst option, in both query time and storage.
I attempted to try using an array attribute to each table, which is more
or less the same they did in the articles but without using a separate
relation for tags, and i found out that all the queries were way easier
to write, and needed two joins less, so it was a no-brainer.
[0]: http://www.databasesoup.com/2015/01/tag-all-things.html
2023-04-07 19:31:35 +00:00
|
|
|
|
insert into invoice (invoice_id, company_id, slug, invoice_number, invoice_date, contact_id, payment_method_id, currency_code, tags)
|
|
|
|
|
|
values (15, 1, '7ac3ae0e-b0c1-4206-a19b-0be20835edd4', 'INV1', '2023-03-10', 12, 111, 'EUR', '{tag1}')
|
|
|
|
|
|
, (16, 1, 'b57b980b-247b-4be4-a0b7-03a7819c53ae', 'INV2', '2023-03-09', 13, 111, 'EUR', '{tag2}')
|
2023-03-11 19:58:20 +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)
|
|
|
|
|
|
values (19, 15, 'P1.0', 1100)
|
|
|
|
|
|
, (20, 15, 'P2.0', 2200)
|
|
|
|
|
|
, (21, 16, 'P1.1', 1111)
|
|
|
|
|
|
, (22, 16, 'P2.1', 2211)
|
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
insert into invoice_product_product (invoice_product_id, product_id)
|
|
|
|
|
|
values (19, 7)
|
|
|
|
|
|
, (20, 8)
|
|
|
|
|
|
, (21, 7)
|
|
|
|
|
|
, (22, 8)
|
2023-03-11 19:58:20 +00:00
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
insert into invoice_product_tax (invoice_product_id, tax_id, tax_rate)
|
2023-03-13 13:32:02 +00:00
|
|
|
|
values (19, 4, 0.21)
|
|
|
|
|
|
, (20, 4, 0.21)
|
2023-03-11 19:58:20 +00:00
|
|
|
|
, (21, 3, -0.07)
|
|
|
|
|
|
, (21, 4, 0.21)
|
|
|
|
|
|
, (22, 3, -0.15)
|
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
select lives_ok(
|
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
|
|
|
|
$$ select edit_invoice('7ac3ae0e-b0c1-4206-a19b-0be20835edd4', 'paid', 13, 'Notes 1', 112, array['tag1'], '{"(20,,p1.0,D1,11.01,2,0.50,{4})","(,,p1.3,D3,33.33,3,0.05,{3})"}') $$,
|
2023-03-11 19:58:20 +00:00
|
|
|
|
'Should be able to edit the first invoice'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
select lives_ok(
|
|
|
|
|
|
$$ select edit_invoice('b57b980b-247b-4be4-a0b7-03a7819c53ae', 'sent', 12, 'Notes 2', 111, array['tag1', 'tag3'], '{"(21,7,P1.1,,11.11,1,0.0,{3})","(22,8,p2.1,D2,24.00,3,0.75,\"{3,4}\")","(,9,p3.3,,36.36,2,0.05,{4})"}') $$,
|
|
|
|
|
|
'Should be able to edit the second invoice'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
Replace tag relations with array attributes
It all started when i wanted to try to filter invoices by multiple tags
using an “AND”, instead of “OR” as it was doing until now. But
something felt off and seemed to me that i was doing thing much more
complex than needed, all to be able to list the tags as a suggestion
in the input field—which i am not doing yet.
I found this article series[0] exploring different approaches for
tagging, which includes the one i was using, and comparing their
performance. I have not actually tested it, but it seems that i have
chosen the worst option, in both query time and storage.
I attempted to try using an array attribute to each table, which is more
or less the same they did in the articles but without using a separate
relation for tags, and i found out that all the queries were way easier
to write, and needed two joins less, so it was a no-brainer.
[0]: http://www.databasesoup.com/2015/01/tag-all-things.html
2023-04-07 19:31:35 +00:00
|
|
|
|
$$ select invoice_number, invoice_date, contact_id, invoice_status, notes, tags, payment_method_id from invoice $$,
|
|
|
|
|
|
$$ values ('INV1', '2023-03-10'::date, 13, 'paid', 'Notes 1', '{tag1}'::tag_name[], 112)
|
|
|
|
|
|
, ('INV2', '2023-03-09'::date, 12, 'sent', 'Notes 2', '{tag1,tag3}'::tag_name[], 111)
|
2023-03-11 19:58:20 +00:00
|
|
|
|
$$,
|
|
|
|
|
|
'Should have updated all invoices'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
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
|
|
|
|
$$ select invoice_number, name, description, price, quantity, discount_rate from invoice_product join invoice using (invoice_id) $$,
|
|
|
|
|
|
$$ values ('INV1', 'p1.0', 'D1', 1101, 2, 0.50)
|
|
|
|
|
|
, ('INV1', 'p1.3', 'D3', 3333, 3, 0.05)
|
|
|
|
|
|
, ('INV2', 'P1.1', '', 1111, 1, 0.00)
|
|
|
|
|
|
, ('INV2', 'p2.1', 'D2', 2400, 3, 0.75)
|
|
|
|
|
|
, ('INV2', 'p3.3', '', 3636, 2, 0.05)
|
2023-03-11 19:58:20 +00:00
|
|
|
|
$$,
|
|
|
|
|
|
'Should have updated all existing invoice products, added new ones, and removed the ones not give to the function'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
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
|
|
|
|
$$ select invoice_number, product_id, name from invoice_product left join invoice_product_product using (invoice_product_id) join invoice using (invoice_id) $$,
|
|
|
|
|
|
$$ values ('INV1', NULL, 'p1.0')
|
|
|
|
|
|
, ('INV1', NULL, 'p1.3')
|
|
|
|
|
|
, ('INV2', 7, 'P1.1')
|
|
|
|
|
|
, ('INV2', 8, 'p2.1')
|
|
|
|
|
|
, ('INV2', 9, 'p3.3')
|
|
|
|
|
|
$$,
|
|
|
|
|
|
'Should have updated all existing invoice products id, added new ones, and removed the ones not give to the function'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
|
|
$$ select invoice_number, name, tax_id, tax_rate from invoice_product_tax join invoice_product using (invoice_product_id) join invoice using (invoice_id) $$,
|
|
|
|
|
|
$$ values ('INV1', 'p1.0', 4, 0.21)
|
|
|
|
|
|
, ('INV1', 'p1.3', 3, -0.15)
|
|
|
|
|
|
, ('INV2', 'P1.1', 3, -0.15)
|
|
|
|
|
|
, ('INV2', 'p2.1', 3, -0.15)
|
|
|
|
|
|
, ('INV2', 'p2.1', 4, 0.21)
|
|
|
|
|
|
, ('INV2', 'p3.3', 4, 0.21)
|
2023-03-11 19:58:20 +00:00
|
|
|
|
$$,
|
|
|
|
|
|
'Should have updated all invoice product taxes, added new ones, and removed the ones not given to the function'
|
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
select *
|
|
|
|
|
|
from finish();
|
|
|
|
|
|
|
|
|
|
|
|
rollback;
|