Heart-Profit ERP
July 03, 2024, 01:14:03 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Nieuwe opzet Export bestand met Printgegevens  (Read 955 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27445


View Profile WWW
« on: September 25, 2008, 11:42:22 am »

In 2000 is funktionaliteit ontwikkeld waarmee een overzicht welke eerst naar "het scherm" (of beter: TROEPPRFILE.PRN) geprint werd, werd gelezen, en werd omgezet naar DBF formaat.

Deze export werkt alleen op basis van standaard printoverzichten welke in kolomvorm zijn ingedeeld. De export funktionaliteit "leest" de kolommen, en vertaalt deze naar velden in de DBF.

Bij de eerste opzet werden alle kolommen als "tekst" vertaald, doch enkele jaren later is de export funktionaliteit uitgebreid m.b.t. "herkenning van het type data wat in de betreffende kolom wordt weergegeven".

Nb: En nog weer later werd het resultaat rechtstreeks in Excel gepresenteerd.

Aan het proberen te herkennen van welk type data een kolom is, is de afgelopen jaren nog wel eens gesleuteld, en nog steeds worden er af en toe situaties gevonden waarin een kolom onjuist "vertaald" wordt, danwel weliswaar als "numeriek" betiteld wordt, maar de bedragen een faktor 100 te hoog zijn.

Problemen die hierbij aan de orde zijn, is dat als ergens "25,000" in een kolom staat, dit 25 duizend kan betekenen ňf 25 met 3 cijfers achter de komma.

Niet ieder printoverzicht drukt haar numerieke waarden op dezelfde manier af, zo kunnen we de waarde "25 duizend" terugvinden als "25000", "25.000", of "25,000". Maak het nog wat complexer, dan geldt dat zodra het systeem in het Engels draait, de punt en de komma omgekeerd toegepast worden, en het printje welke e.e.a. in het nederlands presenteerde als "25.000" doet het in het engels als "25,000".

Maar ja... "25.000" kan óók weer een Artikelnummer zijn, of een Identifikatie van een Grootboekrekening, in beide gevallen betreft het dan alsnog "tekst".

M.i.v. deze Releasenote is de export naar DBF/CSF/Excel kompleet anders opgezet. Er wordt niet meer gekeken naar "nederlandse-/engelse versie", maar er wordt op basis van andere kenmerken bepaald of een punt als decimaal scheidingsteken, danwel als duizendtal wordt gebruikt.

Hierbij mag je denken aan regels als "zodra er én een punt én een komma in de kolom voorkomt, zal het laatste teken het decimale scheidingsteken moeten zijn".

Of, zodra een kolom enkel cijfers bevat, maar niet rechts is uitgelijnd (zoals bij Artikelnummers het geval), dan zal het niet als numeriek veld worden betiteld.

Merk overigens op dat er altijd situaties te vinden zijn waar we (helaas) niet in staat zullen zijn om korrekt te kunnen bepalen of een punt als decimaal scheidingsteken danwel als duizendtal wordt gebruikt. Zo zal een printje met Voorraaditems een Werkelijke Inhoud presenteren als "25.000", "16.000", "1.000".

Voor hetzelfde geldt hebben we echter een omzetprintje, waarbij bovengenoemde waarden voorkomen als "omzet". We weten dan niet te bepalen of de kolom nu "25" bevat of "25 duizend".

Nb: Dit overigens enkel in het geval dat er alléén bedragen van tussen de 1.000 en 999.999 op de print voorkomen, immers, zodra elder "1.000.000" bereikt wordt, zal er een regel zijn die zegt "2 keer een punt gevonden? Dan moét de punt representatief zijn voor een duizendtal scheiding". Hebben we een bedrag "650" op de print staan, dan konstateer het systeem dat hier géén punt in voorkomt, en dat het dus geen decimale punt kán zijn (immers dan zou de decimale punt bij iedere regel op dezelfde plek worden afgedrukt).

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
SYPREX      Export naar XLS/DBF/CSF    05-03-2008    25-09-2008
SYSS        Omschrijving (nog) niet bekend    07-08-2008    25-09-2008
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.14 seconds with 20 queries.