Synderen fundet: Dato-formater forsinker konkursramtes lønudbetaling

Tre af de systemer, som Lønmodtagernes Garantifond skulle knytte sammen med et nyt SAP-system, har haft problemer med at få datoerne rigtige, og det forsinker sagsbehandlingen.

Lønmodtagernes Garantifond har flyttet systemerne, der skal bruges til at håndtere udbetalingen af løn og feriepenge til medarbejdere i konkursramte virksomheder, fra mainframes til en ny SAP-platform, og det har givet problemer.

»Vi har bygget et nyt system med en masse integrationer. Tre af integrationerne har drillet. Det kører nu, men det har været en træls periode,« siger kundechef Mogens Højland fra Lønmodtagernes Garantifond til Version2.

Læs også: Nyt it-system forsinker konkursramtes løn i månedsvis

Problemerne med det nye system har været med til at forlænge sagsbehandlingstiden de seneste måneder, fordi medarbejderne, der skulle arbejde med sagerne, i stedet har måttet bruge tid på at teste systemerne.

Det nye system indeholder integration til en stribe it-systemer både internt hos ATP, der administrerer Lønmodtagernes Garantifond, og eksternt til eksempelvis Skat.

En af de integrationer, som særligt gav problemer, var netop til Skats e-indkomstsystem.

»Vi har haft problemer med at få datoerne rigtige. Det har vi brugt rigtig meget tid på,« fortæller Mogens Højland.

Løn hænger nøje sammen med datoer, fordi de afgør de beløb, der er optjent og skal udbetales, og det har da også været netop datoer, der har givet problemer for Lønmodtagernes Garantifond.

Udover e-indkomst har der været problemer med integrationen til ATP's Feriekonto og derudover til en lille snes andre feriegarantiordninger, hvor det har været nødvendigt at udvikle integration til hver enkelt, så feriedage og feriepenge kunne håndteres automatisk.

Både for Feriekonto og de forskellige feriegarantiordninger har der været problemer med datoerne, som skulle sikre, at der blev registreret de korrekte perioder.

Endelig har ATP og Lønmodtagernes Garantifond haft problemer med dannelse af det slutbrev, som skal bruges til afregning, når en medarbejders løn skal dækkes. Slutbrevet indeholder op mod 120 datafelter, der henter data fra en række forskellige datakilder.

»Det kører, men har været langsomt. Det har taget op mod syv minutter at danne slutbrevet, så det har været en flaskehals. Det arbejder vi stadig på, men er nede på to-tre minutter,« fortæller Mogens Højland.

Ud over problemerne med datoer og den langsommelige dannelse af slutbrevene ser problemerne efter det komplette skifte fra mainframe-platformen til SAP ud til nu at køre.

Læs også: Mainframe-æra slut: Nu udbetaler SAP dine feriepenge

Næste store prøvelse for Lønmodtagernes Garantifond bliver lanceringen af en digital indberetning, som skal erstatte papirblanketter og vil blive lanceret i løbet af marts måned efter en prøvetid på blot halvanden måned.

Kommentarer (25)

Pascal d'Hermilly

»Vi har haft problemer med at få datoerne rigtige. Det har vi brugt rigtig meget tid på,« fortæller Mogens Højland.

Dato formater kan give meget bøvl. Hvert system har af en eller anden grund sit eget native format.
Det der virker i praksis er unix time - antal sekunder siden 1970-01-01 UTC.
Det er et godt eksempel på KISS. Det fungerer med alle systemer - og det er særlig smart når de skal snakke sammen.

Ditlev Petersen

Unix-time kan kun bruges, hvis man er sikker på, at der ikke kommer datoer før 1970. Og det vil man kunne opleve, både i CPR og i sundhedssektoren. Og sikkert mange andre steder.

I øvrigt vil programmørerne være kontrære, hvis deres programmeringssprog bruger et andet format, fordi det så bliver en smule mere besværligt at bruge et fremmed format. Det kan dog klares med en stor hammer.

Det største grin, jeg har oplevet med datoer, var da SAGs Natural skiftede datoformat. Det var (er?) i et eller andet BCD-format med fortegn. Og så skiftede de koden for fortegnet ud med en anden!

En anden spøjs oplevelse var med Java, hvor datoer før 2. Verdenskrig blev talt én dag op, hver gang man kiggede på dem (de fik fokus i brugergrænsefladen). Hvad det skyldtes, ved jeg ikke.

Jesper Lund Stocholm
Poul-Henning Kamp

Nej, hvorfor dog bruge en ISO-standard [...]

ISO standarden er faktisk ikke særlig brugbar når det kommer til stykket. For at undgå at jokke på nogen nationale ligtorne var man nødt til at specificere et format som overhovedet ingen brugte, med det resulatat at overhovedet ingen bruger det, fordi det i bund og grund er ulæseligt.

Dertil kommer alle de "implementation defined" "detaljer" om konvertering og arithmetik.

Den bedste løsning jeg kender, er astronomernes MJD format, som dog stadig har en lille krølle med skudsekunder.

Pascal d'Hermilly

Unix-time kan kun bruges, hvis man er sikker på, at der ikke kommer datoer før 1970. Og det vil man kunne opleve, både i CPR og i sundhedssektoren. Og sikkert mange andre steder.


Forkert. Man benytter negative tal.

Ang. bits så ja(!) det kan anbefales at bruge 64 bit. Med 32 bit har du kun mulighed for at bruge årene 1901-2038 hvilket ikke er smart. Med 64 bit når solen at brænde ud.
Hvis man designer systemer idag som ikke kan håndtere mere end 4GB RAM uden nogen som helst grund anden end at 32 bit er X, så er løbet kørt alligevel.

@jesper: Fordi en integer er så simpel at man ikke behøver en ISO standard. Derfor opstår der færre fejl.

Christian Nobel

Havde det ikke været smartere, at man, uagtet hvilket datoformat man havde tænkt sig at ende op med, havde undersøgt hvordan de forskellige delelementer man ville integrere så ud - før man lavede en løsning?

Jesper Lund Stocholm

ISO standarden er faktisk ikke særlig brugbar når det kommer til stykket. For at undgå at jokke på nogen nationale ligtorne var man nødt til at specificere et format som overhovedet ingen brugte, med det resulatat at overhovedet ingen bruger det, fordi det i bund og grund er ulæseligt.


Det er jo ikke korrekt. Selvfølgelig skal man definere en passende profil af ISO8601 (hvilket man jo eksempelvis har gjort i nogle dokumentformater og ex i xsd:datetime), men derefter bør det være relativt smertefrit at bruge for langt de fleste - og i hvert fald i det scenarie, der her fremstilles. Selvfølgelig kan man hitte corner-cases, hvor det ikke giver mening, men jeg har endnu til gode at opleve ét eneste eksempel, hvor ISO8601 ikke har kunnet løfte opgaven ... og jeg laver ikke andet end at designe og lave integrationsløsninger imellem heterogene systemer.

@jesper: Fordi en integer er så simpel at man ikke behøver en ISO standard. Derfor opstår der færre fejl.


Right ...

(V2: og så kunne det da være interessant at høre om de specifikke problemer datoer gav i migreringsopgaven ... som altid er jeres artikler en anelse tynde i forklaringen af de specifikke tekniske problemer)

Jon Bendtsen

Løn hænger nøje sammen med datoer, fordi de afgør de beløb, der er optjent og skal udbetales, og det har da også været netop datoer, der har givet problemer for Lønmodtagernes Garantifond.

De taler kun om datoer, det er vel kun dage?

http://ordnet.dk/ddo/ordbog?query=dato

Betydninger

bestemt dag i en bestemt måned (og et bestemt år), angivet ved tal og ord eller tal alene fx 27. december 1968 eller 27.12.1968

Eksempler dato og klokkeslæt

Jep, det må være dag alene, og så burde ISO da være tilstrækkeligt.

ISO standarden er faktisk ikke særlig brugbar når det kommer til stykket. For at undgå at jokke på nogen nationale ligtorne var man nødt til at specificere et format som overhovedet ingen brugte, med det resulatat at overhovedet ingen bruger det, fordi det i bund og grund er ulæseligt.


Er der behov for mere end YYYYMMDD eller evt. YYYY-MM-DD når det handler om løn? Mere præcist end dage er det vel ikke relevant at være? Artiklen nævner kun datoer.

Den bedste løsning jeg kender, er astronomernes MJD format, som dog stadig har en lille krølle med skudsekunder.


Så præcist behøver løn vel ikke at være? Men nu vi taler om rummet, gad vide hvordan en astronaut ville blive aflønnet? deres og vores tid er jo ikke helt identisk.

Jesper Lund Stocholm

Du kan ikke nøjes med at skrive dette. Du må uddybe eller tie stille. (det sidste er nok sværest) :-)


Ok :o)

Det er en fejlslutning at tro, at bare man bruger "et heltal", så bliver der færre fejl. Specielt når man snakker migrering/integration imellem heterogene systemer, så er det en vigtig ting, at man på systemniveau/grænseflade/interface kan erklære, hvad man udstiller. Her giver "xsd:datetime" (evt med et reg-exp) langt mere brugbar information end xsd:double ifht at angive, at en givet datastump indeholder en dato. Ifht drift og fejlsøgning af slutsystemet er ISO-datoer også at foretrække for de fleste ... jeg synes i hvert fald at "1973-09-05T12:03:11Z" er langt lettere at læse end 116082191 .

... jeg må også sige, at jeg da savnede Pascals besyv i debatterne, dengang Jorden var ved at gå under fordi OOXML i regneark angav tidspunkter/datoer som netop tal (Julian numbers) og ikke ISO-datoer. Vi lavede det jo om i OOXML, men reelt synes jeg, at det var spild af tid ud fra et teknisk synspunkt (men vi blev jo desværre trumfet af politikken).

:-)

Jeg tvivler på, at tidszoner har været en del af problemet som angivet ovenfor (selvom man jo aldrig skal sige aldrig), men dise UNIX-datoer umuliggør jo også overførsel af information om den tidszone tidspunktet "tilhører".

Thomas Knudsen

@Jesper: du har nu i flere omgange spyttet efter ISO8601 i Version2-debatten. I første omgang ifbm. dokumentformatdebatter, hvor jeg mest havde indtryk af at sarkasmen skulle på banen for at forsvare en halvdårlig implementering i et af dine favoritdokumentformater, så den gang undlod jeg at kommentere.

Nu fremturer du imidlertid igen sarkastisk over standarden, så måske din afsky stikker dybere?

Jeg mener nu ikke der er nogen grund til at afsky ISO8601-standarden i den grad du lægger op til. Den er faktisk såre fornuftig og ikke mere kompliceret end at den ret korte Wikipediaside om emnet giver et meget fint overblik.

For en menneskelig bruger er det fx ganske nyttigt at ISO8601 får leksikografisk orden til at falde sammen med numerisk orden (tænk fx på sortering efter vilkårlig søjle i et databaseudtræk som inkluderer både dato og tekstfelter).

Men, som Poul-Henning kommenterer, så lider standarden også under det kulturbetingede fænomen at man var nødt til at producere et format der endnu ikke var i brug nogen steder.

Det har så på den anden side den fordel at man kan SE når der er tale om en ISOformateret dato.

Og så benytter ISO8601 den meget fornuftige konvention at den mest betydende enhed kommer først: 2013-02-12, i modsætning til den skandinaviske konvention 12/2-2013, hvor informationen kommer i omvendt rækkefølge, og den USAnske, 2/12/13, hvor rækkefølgen er helt ude af trit med graden af betydning.

Det er da rigtigt, som Poul Henning kommenterer, at MJD er betragteligt nemmere at regne på, men for en menneskelig bruger er MJD nu endnu mere ulæseligt end ISOformatet, som retteligt ikke er så fa’ens vanskeligt at forstå: Hvis man bare bruger det ind i mellem så er der ikke store problemer med at aflæse hvilken årstid vi befinder os i ved et hastigt kastet blik.

MJD, derimod, kræver en noget mere veludviklet sans for hovedregning, hvis man vil vide bare nogenlunde hvilken årstid man befinder sig på.

Selv i perioder hvor jeg har beskæftiget mig intenst og dagligt med jordobservationssatellitdata, som typisk er tidsfæstet i MJD, har jeg måttet bede computeren om hjælp når jeg skal bruge årstiden for et givent tidsstempel (et cirka-år kan man hurtigt sjusse sig til ved at dividere med 400, lægge 10% til og så lægge udgangsåret 1858 til resultatet - men det er ikke noget som ligger klar på rygmarven i perioder hvor jeg ikke er involveret i satellitbårne jordobservationsdata).

Så selv om ISO arbejdsgruppen måtte anvende et “kulturneutralt” format, så er det på mange måder yderst anvendeligt for mennesker i deres dagligdag.

Faktisk tror jeg de fleste mennesker, med brug af en smule kontekstuelt overblik, er i stand til at aflæse at 2013-02-12 refererer til dagen i dag, hvis de finder det skrevet et sted hvor de normalt ville forvente at finde en dato.

Jeg er knapt så sikker på at det samme vil være tilfældet hvis der det samme sted står MJD-værdien 56335.

Det er oplagt at MJD er kolossalt meget nemmere at regne på, når det handler om at måle tidsrum op - men datamater er glimrende både til at regne, og til at regne om fra dit til dat.

Og en omregningsrutine er der under alle omstændigheder brug for, når slutresultatet skal præsenteres for en menneskelig bruger. At have et internationalt, kulturneutralt format til at definere en laveste fællesnævner for den slags omregninger ER altså ikke verdens mest idiotiske ide.

Jesper Lund Stocholm

Nu fremturer du imidlertid igen sarkastisk over standarden, så måske din afsky stikker dybere?


Jeg afskyr da bestemt ikke ISO8601 - jeg bruger den dagligt og den er fabelagtig til de ting den er lavet til.

Jeg sagde dengang, at udskiftning af "numeriske datoer" med "ISO-datoer" i OOXML var uden reel teknisk værdi og det fastholder jeg stadig. Specielt i kontekst af dokumentformater som ODF, så skal datoer jo alligevel håndteres numerisk af alle funktioner, så det er svært at retfærdiggøre at datoer skal konverteres og persisteres dybt inde i maven af dokumentformater som ODF - bare for at konvertere tilbage, når værdien skal bruges. Det er et unødvendigt overhead.

Dokumentformater er ikke "integrationsformater" - det er persisteringsformater og derfor er der andre krav til hvordan ting persisteres i dem.¨'

Jeg kan i øvrigt ikke se, at jeg udtaler mig kritisk om ISO8601 ovenfor - misforstår du mig ikke?

Thomas Knudsen

Så er vi mere enige end jeg opfattede det.

Men jeg havde svært ved at opfatte din kommentar: "Nej, hvorfor dog bruge en ISO-standard, når vi nu har én, der løser problemet til fortræffelighed. (sarkasme kan forekomme i ovenstående)", som andet end en sarakastisk antydning af at ISO8601 netop IKKE løser problemet.

Jesper Lund Stocholm

Men jeg havde svært ved at opfatte din kommentar: "Nej, hvorfor dog bruge en ISO-standard, når vi nu har én, der løser problemet til fortræffelighed. (sarkasme kan forekomme i ovenstående)", som andet end en sarakastisk antydning af at ISO8601 netop IKKE løser problemet.


Måske manglede der et "ikke" et sted i det jeg skrev?

Anyways - jeg synes at det er helt hul i hovedet at begynde at bruge UNIX-datoer til detvi snakker om her (desuagtet at vi jo ikke ved så meget om selve systemerne), ISO8601 er umiddelbart en oplagt kandidat.

I ODF og OOXML arbejder vi jo med noget lignende UNIX-datoer - hos os hedder de blot "epocs" og er ikke 1970-01-01 UTC men fx 1899-12-31 23:59:59 og vi regner i dage og ikke i sekunder. Men hvor det giver fin mening i en beregningsmæssig kontekst at gemme datoer som tal (og det er ret svært at se bort fra den beregningsmæssige kontekst, når vi snakker om regneark), så er det tosset at begynde at bruge dem, når vi snakker migrering/integration imellem heterogene systemer.

:o)

Poul-Henning Kamp

Det er da rigtigt, som Poul Henning kommenterer, at MJD er betragteligt nemmere at regne på, men for en menneskelig bruger er MJD nu endnu mere ulæseligt end ISOformatet,

Her afslører du en meget tydelig misforståelse:

Det er specielt vigtigt med datoer og tid at man klart adskiller repræsentation og præsentation fra hinanden, for næsten hele balladen handler om præsentation.

Hvor mange timer arbejdede jeg f.eks på min døgnvagt imellem 2012-10-02 12:00 og 2012-10-03 12:00 ?

Nåh-ja, der var noget med sommertid, var der ikke ? Eller var det en anden dato ?

Når tidspunkter, uanset præcision, udveksles imellem computersystemer, bør det altid ske i en utvetydig representation, hvorefter det enkelte system kan præsentere tidspunktet hvordan faen det har lyst til.

ISO standarden fatter ikke dette, ligelidt gør de fleste andre standarder når det kommer til stykket.

Så nej: ISO8601 ville ikke "bare" have løst problemet.

En repræsentation der er klart forskellig fra en præsentation, f.eks MJD, er meget bedre, den er der ingen der misfortolker.

Jesper Stein Sandal

(V2: og så kunne det da være interessant at høre om de specifikke problemer datoer gav i migreringsopgaven ... som altid er jeres artikler en anelse tynde i forklaringen af de specifikke tekniske problemer)

Der er problemet desværre ofte, at de kilder, der må udtale sig, ikke kender de præcise tekniske detaljer. Skal vi have dem med, er vi med andre ord nødt til at få kilden til at blive briefet af én, der kender detaljerne (og kan forklare dem til en chef), hvorefter chefen skal vende tilbage til os.

Det her er en rigtig fin og relevant diskussion, men vil den blive meget bedre af at kende det præcise problem, ATP havde? I så fald skal jeg gerne forsøge at følge op.

I dette tilfælde vurderede jeg dog, at den nuværende detaljegrad var tilstrækkelig, så længe forklaringen ikke var noget i stil med "version xy.zz af SAP Generisk System laver kage i alle datoer".

Pascal d'Hermilly

@jesper
Mht til direkte menneske-læsbarhed har du ret. Hvis jeg endelig skulle få brug for at læse en dato_kolonne i et sql udtræk tilføjer jeg to_timestamp(min_kolonne). Men det er sjældent nødvendigt ;-)
Tidszoner: Tidspunktet er i UTC. Jeg synes det er noget pjat at notere at hvilken tidszone programmet kørte i - det skal omdannes til universel tid ved kørsel.

Jesper Lund Stocholm

Tidszoner: Tidspunktet er i UTC. Jeg synes det er noget pjat at notere at hvilken tidszone programmet kørte i - det skal omdannes til universel tid ved kørsel.


Det kommer dælme an på det system du arbejder med - eller hvad "kørsel" betyder for dig. Jeg sidder pt og arbejder på et system, hvor kunderne er spredt geografisk over flere tidszoner, og her er det bydende nødvendigt, at vi kan fortælle den konkrete bruger det lokale tidspunkt, hvor en UTC-tid i vores system stammede fra. Denne information er tabt, hvis du "kun" gemmer som YYYYMMDDThhmmssZ. Her er du nødt til at have en eller anden form for tidszoneangivelse med for at brugeren præsenteres for det rigtige lokale tidspunkt.

Jesper Lund Stocholm

Mht til direkte menneske-læsbarhed har du ret. Hvis jeg endelig skulle få brug for at læse en dato_kolonne i et sql udtræk tilføjer jeg to_timestamp(min_kolonne). Men det er sjældent nødvendigt ;-)


Du har helt ret - men ifht integration imellem systemer, så vil du jo så skulle overføre både en ISO-dato og en "numerisk dato", og sådan en redundans får det til at klø over hele kroppen på mig :o)

Pascal d'Hermilly

Her er du nødt til at have en eller anden form for tidszoneangivelse med for at brugeren præsenteres for det rigtige lokale tidspunkt.


Du har tidspunktet i UTC. Du kan lave det om til Tokelau-tid om du vil.
:-)
Hvis det er vigtigt for dig at kunden brugte Redmond-tid på det loggede tidspunkt så vil jeg foreslå at du bruger et andet felt til det frem for at blande tingene sammen.

Pascal d'Hermilly
Jesper Lund Stocholm

Du har tidspunktet i UTC. Du kan lave det om til Tokelau-tid om du vil.


Ja, hvis du ved hvor brugeren er. Det er ikke altid trivielt at fastslå.

Hvis det er vigtigt for dig at kunden brugte Redmond-tid på det loggede tidspunkt så vil jeg foreslå at du bruger et andet felt til det frem for at blande tingene sammen.


Principielt set er "2013-02-13T14:26:00Z" jo nøjagtig det samme som "2013-02-13T15:26:00 +01:00", hvis vi taler om tidspunkter i Danmark.

:o)

Bjarke Walling

Jeg har aldrig forstået hvordan datoer uden tidszone-angivelse giver mening i en global kontekst: En dato angiver vidt forskellige tidsintervaller rundt omkring i verden. Derfor giver det i bund og grund kun mening at gemme tidspunkter, hvis man skal kommunikere globalt... eller man kan kommunikere en dato samt sted (a la “bla bla dato, dansk lokaltid”). Det er godt gammeldags træls når API'er, som f.eks. Podio, glemmer denne vigtige detalje: Hvordan skal jeg præsentere “2012-02-12” for brugeren, når jeg ikke ved i hvilken tidszone eller sted det oprindeligt blev indtastet.

Pascal d'Hermilly

Jeg har aldrig forstået hvordan datoer uden tidszone-angivelse giver mening i en global kontekst: En dato angiver vidt forskellige tidsintervaller rundt omkring i verden.


Ja hvorfor skal det være så kompliceret? Brugte de unix time er tidszonen altid er UTC. Selvom der ikke er givet nogen explicit tidszone på "1360705764" kan du alligevel regne ud at det er 12/2-2013 kl 22:49 dansk tid.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Programming in HTML5 with Javascript and CSS3 [20480]

Hvornår: 2015-10-01 Hvor: Østjylland Pris: kr. 19975.00

PowerPoint course experienced (conducted in English)

Hvornår: 2015-12-22 Hvor: Storkøbenhavn Pris: kr. 2950.00

Projektledelse

Hvornår: 2015-10-06 Hvor: Fyn Pris: kr. 18400.00

Modeldrevet. komponentbaseret udvikling af indlejret software

Hvornår: 2015-08-21 Hvor: Nordjylland Pris: kr. 18000.00

SharePoint 2013 Power User [55028]

Hvornår: 2015-10-01 Hvor: Østjylland Pris: kr. 7975.00