Tuesday, November 17, 2015

More about #38

Now that #38 is done, I upgraded the Django in my default environment from 1.6.1 to 1.8.6 and then ran the test suites of my other projects, and –of course– there were some more failures.

Some of them were trivial, but at least one was not trivial at all. It occurred for example during initdb_demo in lino_cosi.projects.std:

django.db.utils.IntegrityError: Problem installing fixture
'/cosi/lino_cosi/lib/ledger/fixtures/demo_bookings.py': NOT NULL
constraint failed: finan_bankstatementitem.amount

A debug message tells me that the BankStatementItem does have an amount:

INFO 20151117 gonna save BankStatementItem(match=Movement #9 (u'PRC#3.3'),\
amount=Decimal('40.00'),account=2,partner=100,voucher=9)

Why then does it say “NOT NULL constraint failed: finan_bankstatementitem.amount”?

The amount is defined as follows:

class FinancialVoucherItem(VoucherItem, SequencedVoucherItem,
                           ProjectRelated, Matching):
    class Meta:
        abstract = True
        verbose_name = _("Item")
        verbose_name_plural = _("Items")
    ...
    amount = dd.PriceField(default=0)

And PriceField is just a thin wrapper around Django’s DecimalField:

class PriceField(models.DecimalField):
    def __init__(self, *args, **kwargs):
        defaults = dict(
            max_length=10,
            max_digits=10,
            decimal_places=2,
        )
        defaults.update(kwargs)
        super(PriceField, self).__init__(*args, **defaults)

The explanation was because Django now also calls the new clean() on virtual fields. And a BankStatementItem has two virtual fields debit and credit which have a rather special type DcAmountField <lino_cosi.lib.accounting.fields.DcAmountField>.

Summary of the changes:

• We no longer use a VirtualGetter object. Virtual fields must now support the case of getting called with ar being None (and return an empty value in that case)

• We no longer care about supporting Django 1.6, Lino now requires Django 1.8 and basta.

TODO: - welfare test suite still failing - building the Lino docs is failing

More about importing Bank statements

I spoke with Gerd about #505.

On page 27 of the Febelfin Implementation guidelines XML message for statement. (version 1.0) there is a picture. And the ISO 20022 standard camt.053.001.02 describes them fully:

• The ElectronicSequenceNumber (<ElctrncSeqNb>) is the “Sequential number of the statement, as assigned by the account servicer. Usage: The sequential number is increased incrementally for each statement sent electronically.”

• The LegalSequenceNumber (<LglSeqNb>) is the “Legal sequential number of the statement, as assigned by the account servicer. It is increased incrementally for each statement sent. Usage: Where a paper statement is a legal requirement, it may have a number different from the electronic sequential number. Paper statements could for instance only be sent if movement on the account has taken place, whereas electronic statements could be sent at the end of each reporting period, regardless of whether movements have taken place or not.”

These two data elements were absolutely present in our demo file, but the Dutch CAMT library (lino_cosi.lib.sepa.parserlib and lino_cosi.lib.sepa.camt) simply didn’t care about them. I adapted them (and lino_cosi.lib.sepa.models) accordingly.

Note: For me these parserlib, camt modules are very ugly because there is a lot of redundant code. As if they had been written by a Java programmer. One day I will rewrite them completely…

I think that we can safely ignore the electronic sequence number and import only the legal sequence number.

Miscellaneous

I created #625 because the whole topic of payables and their payments is going to cause quite some more work. It is required for both #143 and #353. The problem was caused by #143 and therefore is part of the welfare.accounting project.