2023-02-16 22:09:10 +00:00
|
|
|
|
-- Test add_invoice
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
|
create extension if not exists pgtap;
|
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
select plan(17);
|
2023-02-16 22:09:10 +00:00
|
|
|
|
|
|
|
|
|
set search_path to auth, numerus, public;
|
|
|
|
|
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
select has_function('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]']);
|
|
|
|
|
select function_lang_is('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'plpgsql');
|
|
|
|
|
select function_returns('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'uuid');
|
|
|
|
|
select isnt_definer('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]']);
|
|
|
|
|
select volatility_is('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'volatile');
|
|
|
|
|
select function_privs_are('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'guest', array []::text[]);
|
|
|
|
|
select function_privs_are('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'invoicer', array ['EXECUTE']);
|
|
|
|
|
select function_privs_are('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'admin', array ['EXECUTE']);
|
|
|
|
|
select function_privs_are('numerus', 'add_invoice', array ['integer', 'date', 'integer', 'text', 'integer', 'tag_name[]', 'new_invoice_product[]'], 'authenticator', array []::text[]);
|
2023-02-16 22:09:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
set client_min_messages to warning;
|
2023-03-10 13:02:55 +00:00
|
|
|
|
truncate invoice_tag cascade;
|
|
|
|
|
truncate tag cascade;
|
2023-02-18 13:49:02 +00:00
|
|
|
|
truncate invoice_number_counter cascade;
|
2023-02-16 22:09:10 +00:00
|
|
|
|
truncate invoice_product_tax cascade;
|
|
|
|
|
truncate invoice_product cascade;
|
|
|
|
|
truncate invoice cascade;
|
|
|
|
|
truncate contact cascade;
|
|
|
|
|
truncate product 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-16 22:09:10 +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, invoice_number_format, default_payment_method_id)
|
|
|
|
|
values (1, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', 'ES', 'EUR', '"F"YYYY0000', 111)
|
|
|
|
|
, (2, 'Company 4', 'XX234', '', '666-666-666', 'b@b', '', '', '', '', '', 'FR', 'USD', '"INV"000-YY', 222)
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
insert into payment_method (payment_method_id, company_id, name, instructions)
|
|
|
|
|
values (111, 1, 'cash', 'cash')
|
|
|
|
|
, (222, 2, 'cash', 'cash')
|
2023-02-18 13:49:02 +00:00
|
|
|
|
;
|
|
|
|
|
|
2023-03-04 21:15:52 +00:00
|
|
|
|
set constraints "company_default_payment_method_id_fkey" immediate;
|
|
|
|
|
|
2023-02-18 13:49:02 +00:00
|
|
|
|
insert into invoice_number_counter (company_id, year, currval)
|
|
|
|
|
values (1, 2023, '5')
|
|
|
|
|
, (2, 2023, '55')
|
2023-02-16 22:09:10 +00:00
|
|
|
|
;
|
|
|
|
|
|
2023-02-28 11:02:27 +00:00
|
|
|
|
insert into tax_class (tax_class_id, company_id, name)
|
|
|
|
|
values (11, 1, 'tax')
|
|
|
|
|
, (22, 2, '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)
|
|
|
|
|
, (5, 2, 22, 'IRPF -7 %', -0.07)
|
|
|
|
|
, (6, 2, 22, 'IVA 10 %', 0.10)
|
2023-02-16 22:09:10 +00:00
|
|
|
|
;
|
|
|
|
|
|
2023-02-17 11:39:32 +00:00
|
|
|
|
insert into product (product_id, company_id, name, price)
|
|
|
|
|
values ( 7, 1, 'Product 2.1', 1212)
|
|
|
|
|
, ( 8, 1, 'Product 2.2', 2424)
|
|
|
|
|
, ( 9, 2, 'Product 4.1', 4848)
|
|
|
|
|
, (10, 2, 'Product 4.2', 9696)
|
|
|
|
|
, (11, 2, 'Product 4.3', 1010)
|
2023-02-16 22:09:10 +00:00
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
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')
|
|
|
|
|
, (14, 2, 'Contact 4.1', 'XX777', '', '999-999-999', 'e@e', '', '', '', '', '', 'ES')
|
|
|
|
|
, (15, 2, 'Contact 4.2', 'XX888', '', '000-000-000', 'f@f', '', '', '', '', '', 'ES')
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
select lives_ok(
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ select add_invoice(1, '2023-02-15', 12, 'Notes 1', 111, '{tag1,tag2}','{"(7,Product 1,Description 1,12.24,2,0.0,{4})"}') $$,
|
2023-02-16 22:09:10 +00:00
|
|
|
|
'Should be able to insert an invoice for the first company with a product'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
select lives_ok(
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ select add_invoice(1, '2023-02-16', 13, 'Notes 2', 111, '{}', '{"(7,Product 1 bis,Description 1 bis,33.33,1,0.50,\"{4,3}\")","(8,Product 2,Description 2,24.00,3,0.75,{})"}') $$,
|
2023-02-16 22:09:10 +00:00
|
|
|
|
'Should be able to insert a second invoice for the first company with two product'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
select lives_ok(
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ select add_invoice(2, '2023-02-14', 15, 'Notes 3', 222, '{tag3}','{"(11,Product 4.3,,11.11,1,0.0,{6})"}') $$,
|
2023-02-16 22:09:10 +00:00
|
|
|
|
'Should be able to insert an invoice for the second company with a product'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
2023-03-05 17:50:57 +00:00
|
|
|
|
$$ select company_id, invoice_number, invoice_date, contact_id, invoice_status, notes, payment_method_id, currency_code, created_at from invoice $$,
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ values (1, 'F20230006', '2023-02-15'::date, 12, 'created', 'Notes 1', 111, 'EUR', current_timestamp)
|
|
|
|
|
, (1, 'F20230007', '2023-02-16'::date, 13, 'created', 'Notes 2', 111, 'EUR', current_timestamp)
|
|
|
|
|
, (2, 'INV056-23', '2023-02-14'::date, 15, 'created', 'Notes 3', 222, 'USD', current_timestamp)
|
2023-02-16 22:09:10 +00:00
|
|
|
|
$$,
|
|
|
|
|
'Should have created all invoices'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
|
$$ select invoice_number, product_id, name, description, price, quantity, discount_rate from invoice_product join invoice using (invoice_id) $$,
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ values ('F20230006', 7, 'Product 1', 'Description 1', 1224, 2, 0.00)
|
|
|
|
|
, ('F20230007', 7, 'Product 1 bis', 'Description 1 bis', 3333, 1, 0.50)
|
|
|
|
|
, ('F20230007', 8, 'Product 2', 'Description 2', 2400, 3, 0.75)
|
|
|
|
|
, ('INV056-23', 11, 'Product 4.3', '', 1111, 1, 0.0)
|
2023-02-16 22:09:10 +00:00
|
|
|
|
$$,
|
|
|
|
|
'Should have created all invoice products'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
|
$$ select invoice_number, product_id, tax_id, tax_rate from invoice_product_tax join invoice_product using (invoice_product_id) join invoice using (invoice_id) $$,
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ values ('F20230006', 7, 4, 0.21)
|
|
|
|
|
, ('F20230007', 7, 4, 0.21)
|
|
|
|
|
, ('F20230007', 7, 3, -0.15)
|
|
|
|
|
, ('INV056-23', 11, 6, 0.10)
|
2023-02-16 22:09:10 +00:00
|
|
|
|
$$,
|
|
|
|
|
'Should have created all invoice product taxes'
|
|
|
|
|
);
|
|
|
|
|
|
2023-03-10 13:02:55 +00:00
|
|
|
|
select bag_eq(
|
|
|
|
|
$$ select company_id, name from tag $$,
|
|
|
|
|
$$ values (1, 'tag1')
|
|
|
|
|
, (1, 'tag2')
|
|
|
|
|
, (2, 'tag3')
|
|
|
|
|
$$,
|
|
|
|
|
'Should have added all new tags once'
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
|
$$ select invoice_number, tag.name from invoice_tag join invoice using (invoice_id) join tag using (tag_id) $$,
|
Remove the number field from new invoice form
Initially, this field was meant to be left almost always blank, except
for when we deleted invoiced and had to “replace” its number with a new
invoice; using the automatic numbering in this cas would not “fill in”
the missing number in the sequence.
However, we decide to not allow removing invoicer not edit their
numbers, therefore, if everything goes as planned, there should not be
any gap in the sequence, and that field is rendered useless.
Oriol suggested making it a read-only field, both for new and edit
forms, but i do not think it makes sense to have a field if you can not
edit it at all, specially in the new invoice dialog, where it would
always be blank. In the edit form we already show the number in the
title and breadcrumbs, thus no need for the read-only field as
reference.
I still keep a Number member to the form struct, but is now a string
(kind of “a read-only field”, in a way) and just to be written in the
title or breadcrumbs. I did not like the idea of adding a new SQL
query just for that value.
2023-04-01 13:57:56 +00:00
|
|
|
|
$$ values ('F20230006', 'tag1')
|
2023-03-10 13:02:55 +00:00
|
|
|
|
, ('F20230006', 'tag2')
|
|
|
|
|
, ('INV056-23', 'tag3')
|
|
|
|
|
$$,
|
|
|
|
|
'Should have assigned the tags to invoices'
|
|
|
|
|
);
|
|
|
|
|
|
2023-02-16 22:09:10 +00:00
|
|
|
|
|
|
|
|
|
select *
|
|
|
|
|
from finish();
|
|
|
|
|
|
|
|
|
|
rollback;
|