:date: 2017-08-02 ========================= Wednesday, August 2, 2017 ========================= Working on :ticket:`1933`. Lydia doesn't need a normal Belgian VAT declaration but a `special one `__. With the new infrastructure this is simply a new plugin :mod:`lino_xl.lib.bevats` which starts as a copy of :mod:`lino_xl.lib.bevat`. Before duplicating the plugin, I fixed a design flaw: it is not necessary to specify both the model and a table when declaring a new voucher type. The table is enough because it points to the model. With a little subtlety though: the table's model is not always resolvable when the table is being defined. To fix this, I added a new method :meth:`add_item_lazy ` to all choicelists and have it used by all voucher type definitions. For example, instead of saying:: from .models import ClientVoucher VoucherTypes.add_item(ClientVoucher, ClientVouchersByJournal) we can now say:: VoucherTypes.add_item_lazy(ClientVouchersByJournal) And I saw the optimization confirmed because at some places, until now, we had to write:: @dd.receiver(dd.pre_analyze) def pre_analyze(sender, **kw): VoucherTypes.add_item('sales.VatProductInvoice', InvoicesByJournal) which we can now write as well by a simple one-liner:: VoucherTypes.add_item_lazy(InvoicesByJournal) New specs pages :ref:`xl.bevat` and and :ref:`xl.bevats` Clearing the declared movements =============================== It would be nice if a VAT declaration would also "clear" the movements which it declares. But for this we would need a second match field, which seems to be overkill. Here is how I realized this. The "match" is a string which links a series of ledger movements together. When all movements of a given match have the sum of their debit equal to the sum of their credit, then all movements of the match are said to be "cleared". The match of an invoice is automatically generated using "journal + voucher number". The match of a financial voucher (bank statement, payment order, journal entry,...) is generated using "journal + voucher number + item number". A VAT declaration is like an invoice : its match is generated by "journal + voucher number". But a VAT declaration also does something new. It does not only generate a debth towards the tax office (an amount with a match which is to be cleared e.g. by a payment order) but it also clears all the movements into the due or deductible VAT accounts which had been created by the individual invoices. These movements do *not* have the match of that invoice, their match is empty (because an invoice's match is used only for the *partner movement* of an invoice). When registering a VAT declaration, all these movements would get the VAT declaration's match. And when deregistering the declaration their match would become blank again. I tried this. But the problem is that we would still need separate `match` and `cleared` fields for clearing per (general) account. Miscellaneous ============= The following test case in :ref:`welfare.specs.misc` was failing:: ses.set_confirm_answer(False) rv = ses.run(obj.edit_template) That was because :meth:`InstanceAction.run_from_session` calls :meth:`InstanceAction.request_from` which no longer uses :meth:`InstanceAction.setup_from`. But :meth:`InstanceAction.request_from` didn't inherit `_confirm_answer` to the child session. Now it does.