Printfile naar Excel VANUIT MANAGEMENT OVERZICHTEN decimale komma fout

[mdekraa]

Vanuit management overzicht inkoop gerealiseerd, kwam ik er achter dat als je aantal verschijnigen aanvinkt, de export problemen heeft met de duizendtallen.
3,900 (negenendertighonderd) rondt de export af naar 3.9 (drie-komma-negen)

Ik heb dit vaker gezien...

Gaarne correctie, want dit lijkt een vaker vookomende fout te zijn.

mvg

Marco

[Peter Stordiau]

Ik ben toevallig eens op zoek geweest naar zo'n soort "rare" fout ...
... die zo raar helemaal niet blijkt te zijn. Dit heeft namelijk te maken met het geweldig gebruikersvriendelijke aspekt van het in de Office omgeving kunnen instellen wat je decimaal teken is, maar wat door "de andere helft" van MS niet wordt gerespekteerd dan wel onderkend. Anders gezegd : wij hebben de mogelijkheid niet om te ontdekken dat jij je decimaal teken op een komma hebt staan en de duizendtallen op een punt, of andersom. Maar als bij *jou* Excel wordt opgestart, respekteert Excel dat helemaal automatisch en vanzelf wel. Helemaal voor jou.

Aan alles is wat te doen, maar dan zullen we in dit geval eerst in een .NET toepassing moeten kijken hoe Excel bij jou is ingesteld. Maar ja ... dat gaat wel erg ver denk ik.

Peter

[mdekraa]

We zijn hier in Nederland , dus komma is komma en punt is duizendtallen seperator...

Logisch toch?

MK

[dirkjan]

Geldt misschien bij jullie, ik vindt dat ieder voor zich dit mag en moet kunnen gebruiken wat hij het prettigste vindt.

Ik gebruik altijd punt als decimaal teken en van de duizendpunt wordt ik helemaal moe. Maakt de boel in smalle tabellen alleen maar onoverzichtelijker.

Dirk-Jan Gloudemans
LA

[Wouter Rijnbende]

Probleem heeft niets met Excel zelf te maken 

De exportfunktie leest de PRFILE.PRN en probeert per kolom te bepalen of de waarden in die kolom numeriek of character zijn, en zo dit numeriek is, of er decimalen aan de orde zijn of niet. In dit geval wordt er een waarde 3.082 getoond in kolom aantal, hetgeen in dit geval betekent "drie duizend twee en tachtig". De export leest dit echter als een werkelijke inhoud, 3 komma 082. Derhalve komt het bedrag ook niet als 3 duizend twee en tachtig in Excel, maar als 3 komma nul twee en tachtig.

Of dit op e.o.a. manier eenvoudig te herkennen is moet ik even uitzoeken. Merk op dat er duizenden printjes in Profit zitten, de een dit getal toont als 3.082, de ander als 3082 en er dan ook nog werkelijke inhouden zijn die als 3,082 danwel 3.082 getoond worden.

[Peter Stordiau]

We zijn hier in Nederland , dus komma is komma en punt is duizendtallen seperator...

Logisch toch?

Kun je dan ook aangeven welke toets je op je toetsenbord gebruikt om die mooie komma daadwerkelijk in te typen als je in een willekeurig pakket werkt buiten Office ? (tel Profit zelf gerust mee   ).

En als je dan toch op zoek bent naar die toets en je bent je toetsenbord aan het omkeren, kun je meteen even vertellen wat voor'n toetsenbord (land) het eigenlijk is ?

En mocht je je een keer in Word bevinden, en je bent een klacht aan het schrijven (doe maar naar M$) en je zet zaken tussen quotes, kun je dan aangeven wat je daarvoor moet doen, dan wel wat je hebt moeten ondernemen om het voor elkaar te krijgen dat het werkbaar werd (als je dat is gelukt), en met welke landinstelling je nu werkt ?

Moraal : als wij dat soort zaken zouden proberen uit te vlooien gaan we 10 keer nat. Er werken te veel andere dingen niet.

Mocht je er een Bedrijfsparameter voor willen, plus afvangen van het geheel dan mag dat voor mij. Maar houd er dan wel rekening mee dat die Bedrijfsparameter niet afdwingt hoe iedereen werkt in Excel. En hoe werkt iedereen in Excel ? nou, afhankelijk van de taal waarin het OS op je PC is geïnstalleerd. En dat hangt af van ... tja ... of je bijvoorbeeld nu al Vista wilt.

 

[Peter Stordiau]

Probleem heeft niets met Excel zelf te maken 

Oh nee ? het enige wat jij aangeeft is dat het nog verwarrender is dan dat het al was.
Wat ik heb aangegeven, blijft hoor.

[Peter Stordiau]

... maar kijk in elk geval of dit je (jullie) helpt : http://ha1.heartprofit.nl/profit/index.php?topic=17159.0
(wel een upgradeje nodig).

[Wouter Rijnbende]

Opgelost.

Deze situatie kon wel afgevangen worden, immers, als de . een decimale punt zou betreffen (zoals bij een werkelijke inhoud) dan mogen we ervanuitgaan dat die decimale punt bij iedere regel optreedt. Aangezien de kolom op de print ook waarden < duizend bevat en er in dat geval geen punt voorkomt, wordt nu gekonkludeerd dat die kolom geen decimalen bevat en dat de punt een scheidingsteken voor de duizendtallen is.

I.g.v. Taalkode Engels werkt de . en de , precies omgekeerd, maar zou e.e.a. ook moeten werken.

Nb: Vereist een nieuwe versie van de Systeemprogrammatuur (in jouw geval denk ik ook een Upgrade).

[Peter Stordiau]

Opgelost.

Deze situatie kon wel afgevangen worden, immers, als de . een decimale punt zou betreffen (zoals bij een werkelijke inhoud) dan mogen we ervanuitgaan dat die decimale punt bij iedere regel optreedt.
Aangezien de kolom op de print ook waarden < duizend bevat en er in dat geval geen punt voorkomt, wordt nu gekonkludeerd dat die kolom geen decimalen bevat en dat de punt een scheidingsteken voor de duizendtallen is.

Jaa ja. Niet opgelost dus. Is zo lek als een vergiet.

I.g.v. Taalkode Engels werkt de . en de , precies omgekeerd, maar zou e.e.a. ook moeten werken.

Mooi. Maar over een Taalkode hadden we het helemáál nog niet gehad. Dat betreft "slechts" wéér een dimensie (en wel een dimensie in Profit). Hooguit mag je stellen dat het voor Engelstaligen (als ze maar met decimale punt werken) een stuk eenduidiger is, en dié die prachtige feature van het kunnen instellen van de decimale komma niet gebruiken.

Nog wel een vraag : heb je nou de duizental punten/komma's eruit gesloopt ?

[Wouter Rijnbende]

Jaa ja. Niet opgelost dus. Is zo lek als een vergiet.

E.e.a. valt en staat inderdaad bij welke waarden c.q. verschillen in waarden er op de print voorkomen. Stel dat de print een kolom bevat met daarin allemaal waarden als 3.100, 5.000, 2.500 dan kan de exportfunktie niet bepalen of hier nu aantallen danwel inhouden mee bedoeld worden.  Merk op dat de bestaande Excelfunktie een export betreft die een ASCII file leest en interpreteert. Rechtstreeks naar Excel printen door in Profit te herkennen welke outputs gedaan worden en die naar Excel commando's te vertalen zou een veel betere manier zijn, maar moet wel 'even' gemaakt worden.

Nog wel een vraag : heb je nou de duizental punten/komma's eruit gesloopt ?

Wat bedoel je? Uit de print van de Inkoop Statistiek? Nee.

[Peter Stordiau]

Nog wel een vraag : heb je nou de duizental punten/komma's eruit gesloopt ?

Wat bedoel je? Uit de print van de Inkoop Statistiek? Nee.

Dan kan ik al niet voorspellen wat er gebeurt met numerieke waarden die duizendtal punten (of Engels : komma's) bevatten, en die terechtkomen in een Excel waarin is ingesteld dat dit komma's (resp. punten) betreft. Dit is iets verder gezocht dan het decimale punt verhaal (omdat mensen dat niet zo snel instellen), maar lijkt mij evengoed onjuist uit te pakken.

Wouter, het lijkt alsof je de essentie van mijn verhaal blijft missen, en wat wat mij betreft overeenkomt met het verhaal van de threadstarter. Althans, zo is erop gereageerd (door mij). Dat hetgeen jij nu hebt veranderd bijdraagt aan verbetering is helemaal okay, maar het is niet opgelost. Niet alleen voor wat betreft het vergiet, maar (dus) ook niet voor wat betreft de Excel instellingen.

Overigens verlang ik persoonlijk daarvoor helemaal geen oplossing, maar dat komt slechts omdat het geen doen is.
De klant zou het denkelijk kunnen oplossen door de output op te vangen in een voorgedefinieerd sheet met macro's of anderszins, welk sheet anticipeert op de instellingen van Profit. Merk op dat dit niét kan (of in elk geval hoort) te werken op het niveau van de PC (of zo je wilt userid), omdat je dan je eigenlijke instellingen moet verkrachten om de output van Profit goed te laten werken.
Als laatste : of de output naar Excel van Profit in een voorgedefinieerd sheet terecht kan komen is voor mij nog weer een andere vraag.