Thursday, January 17, 2019

TIM still alive

I am doing the yearly accounting report in TIM. I optimized DLM/ee/PERKMD.REP (in 2018 I learned how to declare invoices from OVH)

No no, TIM won’t die so quickly! Don’t believe that TIM is dead :-) We had a funny bug in the beginning of 2019, but forgive me if I don’t translate it. Oliver asked “Kannst Du mir sagen woher der Fehler denn überhaupt kommt? Hier ist die Rede von einem System, dass bisher funktionierte und nun nicht mehr. (nun rundet es automatisch ab, vorher nicht)”. I answered: Woher der Fehler überhaupt kommt? Also wie im Rundbrief bereits erklärt, war das ein Bug, der 18 Jahre lang in TIM geschlummert hat. Aber da du fragst, willst du es offenbar genauer wissen. Und es ist ja auch eine interessante Geschichte. Aalso… Die Korrektur an sich kannst du hier sehen. Die dort sichtbare Funktion GetPeriode() macht z.B. aus einem Text “1995” einen Text “9501-9512”, aus 2012 macht sie entweder “1201-1212” oder “A201-A212” (je nachdem ob FixY2K eingeschaltet ist oder nicht). Manche TIM-Benutzer haben noch Daten aus dem vorigen Jahrtausend, und da stellt sich das Problem, dass “99” vor “00” sortiert wird. Deshalb haben solche Benutzer dann FixY2K eingeschaltet, so dass 2000 als A0 dargestellt wird. GetPeriode() wird nach dem Anmelden aufgerufen mit “str(year(UserDate()))”, um die erste Buchungsperiode des laut Anmeldedatum laufenden Jahres zu kriegen. Am 31.12.2018 war das “2018”. Daraus machte GetPeriode dann “B801-B812” oder “1801-1812”, das wurde dann an DevDefault() übergeben. Diese Funktion gibt die Währung einer Buchungsperiode zurück. TIM hat ja nicht nur den Jahrtausendwechsel sondern auch den Umstieg von BEF nach EUR mitgemacht. Ab Januar 2019 lautet die aktuelle Periode “1901” oder B901 (je nach FixY2K) Die Funktion GetPeriode() machte wie du sehen kannst einen Test “if val(x)>1900 and. val(x) < 3000” und glaubt beim Text “1901” also, dass wir uns im Jahr 1901 befinden, und TIM kommt dann zum logischen Schluss, dass wir noch in BEF arbeiten. In BEF gab es keine Kommastellen. Bist du mitgekommen? Reicht das?

A manual and a demo for Lino Cosi

Today I spoke with Yvonne, a passionate TIM user. But when they write offers it starts to become difficult to get young users aquaintained to TIM. So they start to get impatient. They want a Lino. Especially for writing offers. I explained her why she must still wait.

But afterwards I thought that Yvonne is intelligent and motivated to help with testing and giving feedback. What are we waiting for?! I opened #2798 and started to work on it.

Of course the Lino Così demo needs a bit of polishing before we can let Yvonne explore it.

For example the demo fixtures now also create a journal “Offers”. An offer is technically the same as an invoice, except that it doesn’t generate ledger movements.

The ref_max_length for lino_xl.lib.accounting.Journal is now 5 instead of the default 40.

And then printing invoices was broken (since we changed the default build method from appy to weasy). It said “No template found for sales/VatProductInvoice/default.weasy.html, excerpts/default.weasy.html”.

The solution was easy: I created a new template sales/VatProductInvoice/default.weasy.html (in the config directory of lino_xl.lib.trading).

Actually printing offers and invoices is not an easy topic because of the gory details.

At this point I stopped because it makes no sense for me to work on this alone.

Hamza and Tonis, who of you wants to continue with me on this?