Synology Office

[dirklammers]

Ik weet eigenlijk niet waar ik deze vraag specifiek moet zetten, dus dan maar even hier. Ik zie het wel als die naar een ander deel van het forum wordt verplaatst.
Ik maak redelijk veel gebruik van de Synology “Excel” toepassing maar loop tegen een vreemd probleem aan.
Voordat ik het hele verhaal ga wegschrijven eerst de vraag of er iemand in het forum is die zichzelf wel een soort gevorderde gebruiker/specialist zou durven noemen en die eens mee wil denken?

Groet, Dirk

[Babylonia]

In het verleden heb ik wel wat meer complexe dingen met Excel gedaan.

Ook wel eens de Office functies van het Synology pakket vergeleken.
Maar de functionaliteiten van het Synology pakket daarmee was / is(?)  zeker niet alles mogelijk in vergelijk met het Microsoft Office pakket.
Of bijv. het één op één over te zetten naar het Synology pakket.

Dus mocht je tegen problemen aanlopen, zou dat best wel eens kunnen liggen aan meer beperkte mogelijkheden van het Synology pakket zelf?
-

[Briolet]

Ik gebruik het pakket, maar slechts een heel klein deel van de functies. Ik gebruikte Excel al toen je nog niet eens een font per cel kon instellen. De font instelling was ooit voor de gehele spreadsheet. Inmiddels gebruik ik Excel al 20 jaar niet meer. Wel ben ik nog steeds een fanatieker gebruiker van spreadsheets, maar vooral Numbers van Apple.

Geef aan in welke richting het probleem zit. Gaat het om specifieke functies van dit office pakket?

[dirklammers]

Ja dan toch maar even wat uitleg want ik snap dat jullie zo in het algemeen lastig specifiek kunnen reageren.
Laat ik het gebruikte model als volgt versimpelen:

We hebben binnen onze kerk 4 bankrekeningen in gebruik. Voor elke rekening is er een tabblad dat simpel gezegd de volgende functie heeft: beginsaldo +/- mutaties = eindsaldo. Een andere vrijwilliger dan ik voert steeds deze mutaties in als maandelijkse batch.

Op een 5e tabblad voer ik zelf aan de hand van het laatste rekeningafschrift voor elke rekening het eindsaldo van die maand in.
Klopt dat voor een rekening met de stand van het betreffende tabblad dan wordt de cel groen, anders rood.
Zo zie ik snel of alle mutaties goed zijn ingevoerd.

Geen hogere excel-kunde en een simpele voorwaardelijke opmaak.

Voor 3 van de 4 rekeningen werkt dit prima, bij de 4e rekening wil de voorwaardelijke opmaak niet werken. Alle formules zijn hetzelfde - uiteraard met verschillende verwijzingen.

Vul ik echter op het tabblad van de foute rekening het eindsaldo handmatig in - ik overschrijf dus de berekening beginsaldo +/- mutaties = eindsaldo - dan werkt het wél.
Dat is gek!

Het lijkt wel of er "onder water" iets niet gelijk is aan elkaar, namelijk het berekende saldo op het betreffende tabblad van de foute rekening en het door mij handmatig ingevoerde saldo op het 5e tabblad. Dit terwijl er toch echt dezelfde getallen staan.....
De gegevenstypes zijn overal hetzelfde: aantal.

Snap er werkelijk niets van want het is toch niet moeilijker dan simpel voorbeeld:

1+1+1+1 = 4 op het tabblad klopt NIET met de handmatig ingevulde 4 op het controletabblad.
Direct de formule overschrijven met 4 klopt WEL met de handmatig ingevulde 4 op het controletabblad.

I'm lost.....

Groet, Dirk

[Briolet]

Met een spreadsheet heb je regelmatig last van afrondingen na een berekening omdat getallen onder water in een hexadecimaal systeem gerekend wordt. (dan kan 5 - 2 plots 2,999999 worden) Voor boekhoud toepassingen is het daarom vaak verstandig om alle getallen na een berekening geforceerd op twee cijfers af te ronden.

In mijn begintijd van programmeren deed ik veel met een 6502 processor. (C64 en Apple II) Die had een speciale decimale mode waardoor hij minder efficiënt werd, maar je geen last had van dergelijke afrond fouten door het omzetten van 16-tallig naar 10-tallig.

[Babylonia]

De uitleg is duidelijk.

Er zitten naar ik vermoed dan toch ergens verkeerde referenties / verwijzingen in de formules.
Absolute cel verwijzingen    versus   relatieve verwijzingen   of   gemengde verwijzingen.

https://support.microsoft.com/nl-nl/office/schakelen-tussen-relatieve-absolute-en-gemengde-verwijzingen-dfec08cd-ae65-4f56-839e-5f0d8d0baca9

Vergelijk met name ook wat je op het 5e tabblad aan formules gebruikt in relatie tot de eerdere 4 tabbladen van 4 rekeningen.


Je zou een  Excel  rekenblad kunnen maken, waarbij je mutaties van de bankrekeningen bijv. per maand als  *.CSV  bestand download.

Waarbij alle geïmporteerde mutaties direct automatisch worden verwerkt in het rekenblad.
Naar een overzichtsvorm zoals je dat nu "handmatig" invoert.

[dirklammers]

Ja ik snap wat je zegt en volgens ook mij moet het dáár ergens in zitten. Ik ga eens verder experimenteren...

Tegelijk zie ik de reactie van Babylonia binnenlopen. De formules kloppen echt en de verwijzingen zijn óók goed.

Ik heb ook het model eens geëxporteerd vanuit Synology Office zodat ik het nu in het "echte" Excel kan openen. Ook dáár lukt het niet met die ene rekening. Wellicht toch iets met de interne representatie van de uitkomst van de berekening.

Eens zoeken of de Synology Excel ook een afrondingsfunctie heeft.....

Groet, Dirk

[Babylonia]

M.b.t. afrondingsfouten:
Heb voor een docent wel eens rekenblad gemaakt die cijfers voor overhoringen, proefwerken e.d. doorrekende naar een rapport cijfer.
Het ene onderdeel telde zwaarder mee als het andere onderdeel.  Hij gaf die rekenmode keurig netjes door aan zijn leerlingen.
Zodat ze zelf reeds konden zien en narekenen waar ze uiteindelijk op uit kwamen.

Dat pakte  "aan het eind"  voor één leerling toch verkeerd uit, in vergelijk met een normale zak calculator.
Diverse keren werd het nagerekend.

Heb ik het aanverwante "programmeer" rekenblad aangepast met bewust een minimale 0,0001 waarde er bij opgeteld.
Dan pakte het wel goed uit.

Vergelijk bijv. ook eens de  "Entier"  functie:   https://nl.wikipedia.org/wiki/Entier
Een combinatie van  "Entier"  met een optelling van  +0,5   kun je afrondingsfouten daarmee ook inzetten in een rekenblad.

Heb in het verleden met "Claris Filemaker" een heel boekhoud programma opgezet.
Gecombineerd met een  "schoolfotografie"  administratie, met uitlezen van data met een barcode scanner, wat op de foto werd meegeprint.
Met bestel opties, en pakbon bladen.  Inclusief eenmalige incasso, van het bedrag.
Waarbij in "batch" met één opdracht de lopende incasso's voor een hele school werden geïnd.
Volledig gekoppeld met de EXIF-data van gemaakte foto's, zodat fouten met persoonsgegevens minimaal zijn.
(Bij fouten krijgen leerlingen de verkeerde foto's).

Scholen kregen volledig op alfabet van namen en per klas, zogenaamde "smoelenboeken" in PDF.

[Briolet]

Heb in het verleden met "Claris Filemaker" een heel boekhoud programma opgezet.

Ik gebruik Filemaker ook al bijna 40 jaar.  Begin jaren '90 heb ik er een facturering programma mee opgezet voor de zaak. Adressen en artikels haalt hij uit een aparte database. Tot op heden gebruiken we dat nog steeds op de zaak. Filemaker heeft intussen heel veel meer mogelijkheden dan toen ik mijn 1e versie schreef.

Hier had ik mijn eerste ervaringen met afrondproblemen en leerde dat je alles goed moest afronden. Anders rekende hij b.v. 1 cent verschil voor de btw bij een credit factuur van dezelfde factuur met positieve getallen. Dus alles direct op 2 decimalen afronden voordat je verder gaat.

[dirklammers]

Het probleem is - dankzij jullie suggesties - opgelost.
Het eindresultaat van "beginsaldo +/- mutaties = eindsaldo" wordt nu in de laatste optelling - die het eindsaldo berekent dus - bewerkt met round(eindsaldo, 2).
Nu werkt alles prima.
Wel vreemd dat bij het optellen van eenvoudige geldwaarden er toch kennelijk afrondingsverschillen ontstaan. Dat zou je verwachten bij vermenigvuldigingen en delingen, maar toch niet bij optellen en aftrekken.
Maar goed, soms zijn de wegen van zo'n rekenprogramma ondoorgrondelijk.....

Dank jullie beiden!

Groet, Dirk

[Briolet]

Ook bij simpele optellingen kunnen afrondfouten ontstaan omdat de microprocessor met hexadecimale getallen werkt. Die moet hij bij het terug converteren naar decimaal afronden. En dat kan dan net 5,0000000000000001 worden i.p.v. 5,00.

In 1981 of '82 heb ik een heel vak gehad waar we leerden om te gaan met het feit dat processoren een beperkt aantal getallen kunnen meenemen (dat staat los van de bovenstaande conversie hex-decimaal).  Als je b.v. de afstand tot het snijpunt van twee bijna paralel lopende lijnen wilt berekenen, dan moet je heel veel decimalen kunnen meenemen, want anders lopen de fouten snel op. Wij leerden dan dat je het probleem eerst naar een heel andere ruimte moest convergeren, waarbij het snijpunt heel dichtbij kwam te liggen. Dan de berekening uitvoeren en daarna weer terug convergeren.  Dan voorkwam je dat je twee vrijwel gelijke getallen, die alleen vanaf de 10e of 20e decimaal begonnen te verschillen, van elkaar moest aftrekken in je berekening.

Er zijn gewoon soorten berekeningen waar je met de beperkingen van een computer rekening moet houden.

[Babylonia]

Er zijn gewoon soorten berekeningen waar je met de beperkingen van een computer rekening moet houden.

Bij complexe rekenmodellen, waar mogelijk nogal wat zaken van afhankelijk kunnen zijn.

Juist die uitzonderingen, naast de "menselijke" factor aan vergissingen die in het gebruik van systeem implementaties ook worden gemaakt,
kosten het meeste tijd, om daar in software- of applicatie ontwikkeling op te anticiperen, en te corrigeren.
Verwerking van gegevens moet zoveel mogelijk "idiote" proef zijn.

En dan nog de mogelijkheid om er "handmatig" alsnog een correctie op te kunnen uitvoeren. Mocht dat nodig zijn.
Als de consequenties van die verkeerde doorberekening of invoer nogal wat impact kan hebben.

Al die extra maatregelen, worden vaak "overgeslagen" in bedrijfstoepassingen. (Bij toepassingen bij "overheden" komt dat ook vaak voor).
Dan geeft men het "systeem" de schuld als er iets fout gaat. Zonder oplossing of er menselijke verantwoordelijkheid voor te nemen.
Alsof je de consequenties van die imperfecte systemen maar voor lief zou moeten nemen.

Terwijl juist "het systeem" is ontwikkeld door "mensen".
Mensen zijn een diersoort die per definitie "niet volmaakt is".  De door hen ontwikkelde systemen (of applicaties) dus evenmin.
Dat moet men altijd voor ogen nemen.

[dirklammers]

@Briolet: ja is voor mij ook nog wel bekende materie zeker uit de begintijd van het zelf programmeren. Maar grappig dat je daar dan toch weer tegenaan loopt bij iets simpels als voorwaardelijke opmaak in “excel” wat natuurlijk alleen goed werkt als er echt een zuivere True of False uit de formule komt.

@Babylonia: Helemaal waar! Ik heb ik het oude MS-DOS verleden nog eens een uitgebreid ledenbeheer programma geschreven voor onze sportbond in Borland Turbo Pascal dat natuurlijk idiot proof moest zijn. Haast de helft van de code bestond uit het afvangen of voorkomen van invoerfouten, check op relatiecontroles etc. Bij geboortedata was de check of 29 februari nu wel of niet kon voorkomen in een bepaald geboortejaar altijd een leuk “stukje” code 

Zo zie je maar dat zelfs in de moderne tijd van “excel in de cloud” je nog wel eens wordt ingehaald door de aloude beperkingen/eigenschappen van de processoren.

Groet, Dirk

[Briolet]

Haast de helft van de code bestond uit het afvangen of voorkomen van invoerfouten,

Soms schieten ze ook door met dit soort controles.  Ik kan me belastingaangiftes herinneren waar je in een premie-veld geen negatieve getallen kon invullen. Maar de wetgeving was zo dat je daar in sommige gevallen toch iets negatiefs moest invullen.  Het meest ergerde ik me aan de helpdesk van de belastingdienst wand die kenden het probleem en adviseerden deze negatieve premie maar bij een andere premie in te vullen waar wel een negatief getal ingevuld kon worden. Op die manier klopte het bedrag van de aangifte voor die maand weer. Maar feitelijk riep de belastingdienst (of beter hun helpdesk) mij op om een valse aangifte te doen. (En das was niet de eerste keer omdat ze me een paar jaar eerder dwongen om aan te geven dat ik een agrarisch bedrijf had, omdat er dan alleen een vraag verscheen die ik als niet-agrariër moest invullen)

In mijn optiek was de enige juiste oplossing geweest om een maand uitstel voor de aangifte te geven, want het was de bedoeling dat de fout binnen een paar week verholpen zou zijn.