Back to work, over Horgoš.
At home, Brlja added some catal6.prg to material [warehousing]... This material accounting is prone to fuckups, because of costing the materials into the value of product. There are several methods, and our customers mostly stuck to the average price method, which was almost impossible before computers. It was actually possible but unfeasible, it caused delays, because one had to wait for the end of the month, then to calculate the average price (for each material) for that month, and then apply that price to each used amount. And they had to wait, because the paperwork was often late, what if some receipt comes in weeks later and disturbs everything? Even without that there were paradoxes - if there was something cheap on stock early in the month, then mostly used up, then more bought at a much higher price (which happened often in inflation years), the first takeout in the month would go per the average price for the whole month, so until that last acquisition the value of the item on stock would be negative. The method of current average price (paper to paper, not waiting for end of the month) had its paradoxes, because the old stock doesn't get reevaluated. I don't remember how the example went, but Nj (from Njujork) drew it quite graphically, like an economist should (which means „draws the gallows and says you have 1000 dinars“), and showed how even that method can produce a negative value on some item.
What I agreed with Brlja was to recalculate the values after each document, even with ridiculous dates (if they enter the acquisition two months later or cancel a takeout - which would be even crazier, it would have been taken out by then price and returned at current)... With fox being fast enough to resolve the whole rigmarole at invisible speed, why not. At least the number of paradoxes was minimized. And it didn't just recalculate the prices, it also updated the stock... actually we removed that. No stock table, it's just a bunch of totals, which we can rather recalculate each time, easier than taking care that it's always accurate, which was always prone to messes.
Third method, actually the oldest one, was to never recalculate the price, but rather to apply the cost price by age, oldest first. Which is most correct but not most realistic, because it makes the cost look smaller (the product comes cheaper because it's made of older materials, but then we need to have that on stock so we have to procure more, which now costs more). It's bad, because it relies on chronologically flawless influx of papers. In reality, it happened, many times, that the acquisitions were entered with a substantial delay, and takeouts also, and their order was generally random. Programmatically it would still be feasible but it's nearly unpredictable, what if they took out six of something, two at one price and four at another, and then an older takeout jumps in with three of it, so now two should be at this later price, and the other four at... that same other price? So despite being theoretically correct, it creates the most paradoxes.
In PolC, sending (separately main, separately lab) got a new dialog, generated by upitig2.prg, with just two fields - which office, and what's asked for - which is a longer text, doctors are verbose. Then some reports for the rendgen (i.e. röntgen aka exray) - why two... who knows, too lazy to read now. Then on 15th I poked into mnseshn.prg. It says "generated 95.01.31, 21:48:29 for the last time", which means I generated it and then amended by hand. That was the eternal dilemma, if generated code can't do something, should I add that thing to the generator or fix it manually this one time. The trouble with the later approach was that if the generator is re-run, the manual changes will be lost, overwritten by the newly generated code. The trouble with that was when I'd forget I did this and regenerated the code, then had to pull the manual changes out of the last zip.. If I'd change the generator, I'd have to re-run it in all places where the change would be beneficial, and then carefully handle the case which prompted the change.
I usually went for plan bee, adding new options to generators, mostly various hooks where manually written code could be called, so I had 'i jare i pare' (both the kid and the cash) - the visible stuff had the consistent looks throughout the app, that's generated, and the specific crunching and grinding would be behind the scene, manual code. This little menu was an exception, it was generated once, but then menus seldom changed, and the generator for it was quite simple, I didn't expect any fundamental changes, left this one on manual. And the decision proved correct, it changed very little later.
On sixteenths, early in the morning, poked at rucno4.prg (ručno - manually), which was for the manual closing of line items (invoices with payments), generated a dialog for it. And then, during the day, grouped ops in PolC, as the list was too granular, for bureaucratic micromanagement reasons, as if doctors really needed to decide among twenty types of conversation with a patient and ten kinds of taking temperature, so this gave them the ability to enter a preselected bundle at once, to reduce typing.
----
* secret economists' handshake... they all do it. The gallows are actually more like a T, for a two column table, no frame, debit left, credit right.
5-XII-2013 - 17-VIII-2025