Tuesday, April 9, 2019

I digested Mads Michael’s feedback about Lino Così (Friday, April 5, 2019).

I reviewed the specs page about lino_xl.lib.vat

New property lino_xl.lib.vat.VatRegime.needs_vat_id. The chooser for lino_xl.lib.contacts.Partner.vat_regime now also depends on whether the partner has a VAT id or not. The choicelist of the vat_regime field of a voucher wasn’t yet filtered. New function lino_xl.lib.vat.get_vat_regime_choices() used by both choosers. The lino_xl.lib.vat.VatRegimes table now shows all these properties.

Changes in lino_xl.lib.eevat : removed regime “Private person (reduced)”. The regime “Private person” can now be used for any area. Selling to private persons in other countries was not yet allowed.

In lino_xl.lib.vat I changed declaration_plugins to declaration_plugin because I realized that you can have only one declaration plugin.

New config setting eu_country_codes, and the list is now complete (at least at the moment of writing this).

lino_xl.lib.sepa.Payable now gives a more comprehensible warning “No trade type for {}” when the trade type for the voucher is undefined.

I reviewed the demo fixture of lino_xl.lib.contacts. It has become more readable. It no longer creates cities which don’t exist (and instead omits partners in these cities). I removed München and Kelmis because these are difficult to lookup because their name varies with the languages used on the site. Each contact now has at least a city.

The demo fixture for lino_xl.lib.vat now sets fictive VAT numbers for each company.

A runserver session in lino_book.projects.cosi_ee didn’t work because the DEBUG setting wasn’t set to True.

The Explorer menu actions of the VAT plugin were being added to the Sales menu because the sales plugin needs vat and therefore triggers its automatic installation, and in that case the automatically installed plugin does not have its own menu group but inherits the menu group of the plugin that needs it.

Note that the demo fixture of lino_xl.lib.sepa adds about 10 real companies with their real bank account numbers (gathered from their websites), but only some of them also have a VAT id. The others get a fictive VAT id in demo_bookings.

I started to convert the docs about demo fixtures from the API to prosa style in a new Demo fixtures page. I added a new directive and role fixture for documenting fixtures. I defined the concept of “loading phases”. Uff, this was quite some work! But I think it was needed. It helped me to better understand what’s happening with the demo fixtures for VAT functionality. It will make it easier to rename fixtures.

For some applications (e.g. Lino Tera) I converted the way of providing application-specific default values for plugin settings from the old way (by overriding setup_plugins) to the new way which is to override get_plugin_configs.


def setup_plugins(self):
    super(Site, self).setup_plugins()


def get_plugin_configs(self):
    yield super(Site, self).get_plugin_configs()
    yield ('foo', 'bar', 'baz')

It is important to note that setup_plugins is run after get_plugin_configs. This can cause unexpected behaviour when you mix both methods.

I realized something about the Difference between the “technical” plugin order and the order of the menu items:

End users want to see VAT after Sales in their menu because for them it is rather “implementation stuff”. But Sales needs VAT and therefore the VAT menu items merges into the Sales menu. One possibility is to remove vat from the needs_plugins of sales. But that would cause other problems because the sales plugin actually does need vat, and the demo_bookings fixture in VAT must come before those of sales.

The fact that VAT adds no entries to the user menu indicates this. Solution: In lino.core.site.Site.setup_menu() we now differentiate between the “technical” plugin order and the order “visible to the end user”. The end user wants to see menu entries of explicitly installed plugins before those of automatically installed plugins.

This change had some side effects to the ordering of menu items. IFAICS they are all positive: the order of menu items should indeed show explicitly requested functionalities before those which are indirectly required by the primary functionalities.

Lino now supports choicelist items without a value (i.e. lino.core.choicelists.Choice.value is None). Such choices cannot be stored to the database, otherwise they are like normal choicelists. lino_xl.lib.vat.VatRules is the first usage example.

New property lino_xl.lib.vat.VatColumn.common_account and a new data checker to verify that every VAT column has an account configured if it requires one.

Lino now supports unbound data checkers. If lino.modlib.checkdata.Checker.model is None, the checker is unbound, i.e. the problem messages will not be bound to a particular database object.

Lino Voga no longer sets the VatClasses.exempt as default_vat_class. The lino_book.projects.roger demo is just another case of lino_xl.lib.bevats (like lino_book.projects.lydia).

Fixed a bug in diag : the plugins were listed in a random arbitrary order.

Plugin.needed_by is now the immediate parent, not the top-level parent. The loop to the top is now done only in Plugin.get_menu_group.

I removed voga.specs.vat because it was useless.


Yes, I knew that we will have some work with #2810. The Lino Così project itself (write a simple accounting application) remains utopic and long-term, but it is important for most remaining TIM users, it might become our first stable hosting application, and last but not least Mads Michael is a perfect assistant for it: he is patient and competent.

It took much time because I also reviewed the documentation. This is a huge work, my long-term goal is to transfer 25 years of a developer’s experience with accounting databases into free documentation. It is normal that this will take some time.

Actually I am not done. Before I can release a new version I must do manual testing and some minor layout changes. But the test suites pass and the docs build, so I can push my work (about 9 repositories).