:date: 2019-01-17
==========================
Thursday, January 17, 2019
==========================
TIM still alive
==================
I am doing the yearly accounting report in TIM.
I optimized :file:`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 :ticket:`2798`
and started to work on it.
Of course the :ref:`cosi` 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 :attr:`ref_max_length ` for
:class:`lino_xl.lib.ledger.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
:xfile:`sales/VatProductInvoice/default.weasy.html` (in the :xfile:`config`
directory of :mod:`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?