Aanvulling op Releasenote:
http://ha1.heartprofit.nl/profit/index.php?topic=25708.0 Vandaag bereikte ons de melding dat een Layoutvariabele UF-FAKDAT sinds de Upgrade het formaat dd-mm-jj had, terwijl dit vóór de Upgrade formaat dd-mm-jjjj was (4 cijfers voor de eeuw).
E.e.a. blijkt inderdaad sinds bovengenoemde Releasenote te zijn veroorzaakt. De oorzaak hiervan is echter dat de variabele, altijd al bedoeld was als dd-mm-jj variabele. In de omschrijving stond de variabele ook als zodanig omschreven.
Waar blijkt het fout te gaan ?
Eigenlijk al bij de overgang naar de Windowsversie. In de DOS versie hadden we overal standaard maar 2 cijfers voor de eeuw; op het scherm, maar ook op printjes. Vandaar ook dat deze variabele als dd-mm-jj stond omschreven. Sinds de Windowsversie hebben we meer ruimte op het scherm, en staat standaard 'de eeuw' aan. Hierdoor worden datumvariabelen zowel op het scherm als op een print in 4 cijfers getoond. Sindsdien is dus eigenlijk een Layoutvariabele, die bedoeld was als formaat dd-mm-jj als formaat dd-mm-jjjj opgenomen (terwijl de beschrijving anders deed vermoeden).
Met bovengenoemde Releasenote zijn diverse datum formaten i.v.m. het amerikaanse datum formaat omgezet. Zo ook de datum in het formaar dd-mm-jj, immers, dit zou in het amerikaans mm-dd-jj moeten zijn.
In de oude versie werd echter het formaat een datum variabele zonder navolgend cijfer (de basis zoals deze door Genereren Layoutvariabelen beschikbaar werd gesteld aan het mechanisme die iedere datum variabele in talloze andere formaten beschikbaar stelt) niet aangepast. In de nieuwe versie wel. Hierdoor is de variabele weer opgenomen zoals oorspronkelijk bedoeld: als dd-mm-jj variabele (danwel mm-dd-jj in het amerikaans).
Of een datumformaat nou 2 of 4 cijfers voor de eeuw heeft maakt op zich niet al te veel uit. Wel echter voor de klant die e.e.a. aanmeldde, omdat daar Fakturen niet via Profit met VeryPDF naar PDF gekonverteerd werden, maar Fakturen naar een speciale PDF printer werden geprint, en een externe leverancier vervolgens software heeft ontwikkeld die dat document 'leest' en op basis van de inhoud akties ondernam (toekennen logo's, bepalen filename waar de PDF moest worden opgeslagen etc). Die externe software liep nu fout door een gewijzigd datumformaat.
Enerzijds moeten bugs natuurlijk opgelost kunnen worden, aan de andere kant is onze standaard werkwijze wel zo dat alles standaard werkt zoals voorheen.
M.i.v. deze Releasenote zal derhalve de inhoud van de datumvariabele zónder toevoeging (1,2,3 etc.) geformatteerd worden zoals de funktionaliteit deze beschikbaar stelt.
Alleen extra gegenereerde datumformaten (eindigend op 1,2,3 etc.) zullen hierdoor altijd een vast formaat hebben. Van de oorspronkelijke variabele kan niet meer op voorhand worden gesteld welk formaat ze heeft; dat hangt van de toepassing af die die variabele genereert.
#- = <formaat hangt af van de genererende toepassing>
Navolgende (aanvullende) variabelen hebben een vast formaat, welke afgeleiden zijn boven de oorspronkelijke Layoutvariabele:
#1 = 12 januari 2014 / January 12, 2014
#2 = 12-01-2014 / 01-12-2014
#3 = Zondag 12 Januari 2014 / Sunday January 12, 2014
#4 = Januari 2014 / January 2014
#5 = Zondag 12-01-2014 / Sunday 01-12-2014
#6 = 20140112
#7 = 01-2014
#8 = 12A14 maar ook 27E14; dag, maand als 1 positie, waarin 1 = A en 12 = L, jaartal.
#9 = 140112
#10 = 2014-01-12
#11 = ZO / SU (eerste twee posities dagnaam)
#12 = Sunday (dagnaam, expliciet in het engels)
#13 = 12-01-14 / 01-12-14
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APLVGNDT | Omschrijving (nog) niet bekend | 16-01-2014 | 18-02-2014 |
