2023-02-16 22:09:10 +00:00
|
|
|
-- Deploy numerus:add_invoice to pg
|
|
|
|
-- requires: schema_numerus
|
|
|
|
-- requires: invoice
|
|
|
|
-- requires: company
|
|
|
|
-- requires: currency
|
|
|
|
-- requires: parse_price
|
|
|
|
-- requires: new_invoice_product
|
|
|
|
-- requires: tax
|
|
|
|
-- requires: invoice_product
|
|
|
|
-- requires: invoice_product_tax
|
2023-02-18 13:49:02 +00:00
|
|
|
-- requires: next_invoice_number
|
2023-03-10 13:02:55 +00:00
|
|
|
-- requires: tag_name
|
Add SQL and helper PL/pgSQL functions to tag invoices
We plan to tag also contacts and products using the same tag relation,
but different invoice_tag, contact_tag, and product_tag relations for
each one. However, the logic is the same for all three, hence it makes
more sense to put it into a PL/pgSQL with dynamic SQL. Moreover, the
SQL for tagging in add_invoice and edit_invoice where almost exactly
the same, the only difference was deleting the existing tags when
editing.
I do not execute the tag_relation function in its test suite because
by itself it does nothing without supporting invoice_tag, contact_tag,
or any such relation, so it is being tested in the suite for
tag_invoice.
2023-03-25 18:34:27 +00:00
|
|
|
-- requires: tag_invoice
|
2023-02-16 22:09:10 +00:00
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
|
set search_path to 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
|
|
|
create or replace function add_invoice(company integer, invoice_date date, contact_id integer, notes text, payment_method_id integer, tags tag_name[], products new_invoice_product[]) returns uuid as
|
2023-02-16 22:09:10 +00:00
|
|
|
$$
|
|
|
|
declare
|
|
|
|
iid integer;
|
|
|
|
pslug uuid;
|
|
|
|
product new_invoice_product;
|
|
|
|
ccode text;
|
|
|
|
ipid integer;
|
|
|
|
begin
|
2023-03-05 17:50:57 +00:00
|
|
|
insert into invoice (company_id, invoice_number, invoice_date, contact_id, notes, currency_code, payment_method_id)
|
2023-03-10 13:02:55 +00:00
|
|
|
select company_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
|
|
|
, next_invoice_number(add_invoice.company, invoice_date)
|
2023-02-16 22:09:10 +00:00
|
|
|
, invoice_date
|
|
|
|
, contact_id
|
|
|
|
, notes
|
|
|
|
, currency_code
|
2023-03-05 17:50:57 +00:00
|
|
|
, add_invoice.payment_method_id
|
2023-02-16 22:09:10 +00:00
|
|
|
from company
|
2023-03-10 13:02:55 +00:00
|
|
|
where company.company_id = add_invoice.company
|
2023-02-16 22:09:10 +00:00
|
|
|
returning invoice_id, slug, currency_code
|
|
|
|
into iid, pslug, ccode;
|
|
|
|
|
|
|
|
foreach product in array products
|
|
|
|
loop
|
|
|
|
insert into invoice_product (invoice_id, product_id, name, description, price, quantity, discount_rate)
|
|
|
|
select iid
|
|
|
|
, product.product_id
|
|
|
|
, product.name
|
|
|
|
, coalesce(product.description, '')
|
|
|
|
, parse_price(product.price, currency.decimal_digits)
|
|
|
|
, product.quantity
|
|
|
|
, product.discount_rate
|
|
|
|
from currency
|
|
|
|
where currency_code = ccode
|
|
|
|
returning invoice_product_id
|
|
|
|
into ipid;
|
|
|
|
|
|
|
|
insert into invoice_product_tax (invoice_product_id, tax_id, tax_rate)
|
|
|
|
select ipid, tax_id, tax.rate
|
|
|
|
from tax
|
|
|
|
join unnest(product.tax) as ptax(tax_id) using (tax_id);
|
|
|
|
end loop;
|
|
|
|
|
Add SQL and helper PL/pgSQL functions to tag invoices
We plan to tag also contacts and products using the same tag relation,
but different invoice_tag, contact_tag, and product_tag relations for
each one. However, the logic is the same for all three, hence it makes
more sense to put it into a PL/pgSQL with dynamic SQL. Moreover, the
SQL for tagging in add_invoice and edit_invoice where almost exactly
the same, the only difference was deleting the existing tags when
editing.
I do not execute the tag_relation function in its test suite because
by itself it does nothing without supporting invoice_tag, contact_tag,
or any such relation, so it is being tested in the suite for
tag_invoice.
2023-03-25 18:34:27 +00:00
|
|
|
perform tag_invoice(company, iid, tags);
|
2023-03-10 13:02:55 +00:00
|
|
|
|
2023-02-16 22:09:10 +00:00
|
|
|
return pslug;
|
|
|
|
end;
|
|
|
|
$$
|
|
|
|
language plpgsql;
|
|
|
|
|
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
|
|
|
revoke execute on function add_invoice(integer, date, integer, text, integer, tag_name[], new_invoice_product[]) from public;
|
|
|
|
grant execute on function add_invoice(integer, date, integer, text, integer, tag_name[], new_invoice_product[]) to invoicer;
|
|
|
|
grant execute on function add_invoice(integer, date, integer, text, integer, tag_name[], new_invoice_product[]) to admin;
|
2023-02-16 22:09:10 +00:00
|
|
|
|
|
|
|
commit;
|