Kunders landefelt skal ikke være fri-tekst

Question

Problemstilling
Vi er stødt på en problemstilling med den nuværende måde at håndtere kunder på, i forbindelse med en integration til e-conomic via REST-API. Eftersom at e-conomic er gået over til at påskrive DK/DE etc. foran cvr nr. automatisk på faktura osv. - såfremt er landet er stavet korrekt - kan vi gennem REST-API ikke længere verificere om en kunde eksistere i e-conomic basseret på deres cvr-nr. Dette skyldes at flere lande i EU har samme syntaks for cvr-nr. Derfor vil 2 kunder fra 2 forskellige lande kunne have samme cvr-nr i e-conomic.

Fordi at lande-feltet er et fritekst felt, kan dette ikke bruges til validering/søgning, da det ikke vides hvordan landet er skrevet ind. Tyskland kan i teorien indskrives som Tyskland, Germany, Deutschland, Deutchland. Alle vil være gyldige, inkl. den med stavefejl, men jeg kan ikke bruge det, da jeg reelt set ikke ved hvad sprog der kommer retur fra e-conomic eller om der er stavefejl. 

Tag fx dette eksempel:

Tysk kunde i e-conomic	Dansk kunde i e-conomic	Kunde i webshop
CVR: 240240240 Land: Deutschland	CVR: 240240240 Land: Denmark	CVR: 240240240 Land: Danmark

Hvis jeg slår op i kunde kartoteket vil både den danske og tyske kunde komme retur, men jeg kan ikke lave en validering da kundens land i e-conomic står på engelsk mens den i webshoppen står på dansk. Dette vil resultere i at der blev oprettet en duplikat af den pågældende kunde.

Et andet eksempel er dette:

Tysk kunde i e-conomic	Kunde i webshop
CVR: 240240240 Land: Deutchland	CVR: 240240240 Land: Deutschland

Her kommer der selvfølgelig kun en kunde retur, men fordi at feltet er frit-tekst, så kan jeg igen ikke validere at det er samme kunde, da kunden i e-conomic har en stavefejl i landetnavn. I begge eksempler vil det i realiteten betyde at der bliver oprette duplikater af kunderne, hvilket ikke er en holdbar løsning i længden.

Dette er reelt et så stort issue, at det reelt set er en dealbreak i forhold til at kunne integrere eksterne systemer som webshops etc., som har kunder fra flere lande af, op til e-conomic da vi ikke længere kan verificere om kunden eksistere i e-conomic. Vi har fx en kunde, som nu er nødt til at gå igennem alle deres kunder og fjerne fx DE foran cvr-nr. Helt generelt virker denne idé med automatisk lande-kode foran cvr-nr helt malplaceret, som fx også bliver nævnt af thomas.knudstrup i denne tråd: ØV - CVR nummer ændring lavet uden omtanke ... ønske: Lav landekode og nummer konfigurerbart

Løsningsforslag
Den bedste løsning vil være at tilbagerulle det automatisk landekode, og istedet lade brugerne/integrationen have styr på det. Hvis det ikke er muligt så er det i min optik 3 andre løsningsmuligheder

1. Fordi at lande-feltet er blevet styrende i forhold til hvad der skrives foran cvr-nr på fakturaen fx, er landefeltet nødt til at være standardiseret. Det er derfor mit forslag at lande-feltet ændres til en dropdown, og i REST-api skal der selvfølgelig returnes både landenavn + iso-kode for landet. Og her det især iso-koden som er vigtigt, for landenavn kan igen være på al verdens sprog, men iso-koden for lande er ikke afhængig af sprog.
2. Hvis det ikke er muligt at ændre det til en dropdown, skal der enten være en anden måde at definere landet der skal sættes foran cvr nr, så man får en iso-kode retur i REST-api fx, 
3. Eller også skal der laves en mulighed for at disable den automatiske påfyldning af DK/DE etc. foran cvr-nr på faktura etc. For så kan cvr-nr defineres med DK/DE foran i integrationen, hvorved at de igen bliver unikke. Det vil selvfølgelg stadig give problemer hvis kunden er skrevet ind uden DK/DE foran.

Answer 1

cmelgaard har ganske ret. I min optik er den enkleste, hurtigste og bedste måde at løse problemet her og nu, helt af fjerne den der automatiske tilføjelse af landekode til CVR/VAT nummer. Rent kodemæssigt er det vel noget med at udkommentere nogle få linjer.

Først derefter bør man overveje hvordan sådan en funktionalitet eventuelt skal indføres, og det er ikke noget der skal diskutteres på et internt udviklermøde. Det er noget der skal diskutteres med brugerne, og det skal være brugere der har forstand på eksport.

I det hele taget kunne jeg godt tænke mig at når der implementeres "smarte funktioner" som hurtigt viser sig at føre til direkte fejl, så blev disse "smarte funktioner" fjernet med det samme. Den her med CVR/VAT nummer problematikken er et klart eksempel på sådan en "smart funktion" som ganske enkelt ikke er god nok.

Answer 2

Vedr. landefelt som fritekst eller ej, så er min holdning: Jo, det må gerne være fritekst. Og e-conomic systemet skal hverken validere eller formattere det. Det skal skrives præcis som jeg vælger at skrive det, med stavefejl, på dansk, på engelsk, med store og små bogstaver osv.

Der må derimod gerne være en dropdown ved siden af til valg af (ISO-) landekode, naturligvis med mulighed for at vælge "blank".

Answer 3

En fjerde løsning kunne være at inden systemet indsætter landekoden foran, så laves der et tjek for om der allerede er skrevet en landekode ind.

Answer 4

Hej med jer begge to! 

Mange tak for jeres forslag. 

I forhold til en implementering, så er der lidt forskellige veje at gå, som i også selv beskriver. Jeg har brugt lidt tid på at undersøge tingene og finde ud af, hvilke af de forslag, der skaber mest værdi for størstedelen af vores brugere og som jeg ser det er drop down menuen klart den, der rammer flest. Det kan nemlig bruges i flere sammenhængen. 
Der er dog i forhold til, hvordan en evt. implementering af dette skal gennemføres. Både i forhold til sprog og i forhold til alle de kunder vi har i dag, som allerede nu har skrevet fritekst i feltet. Jeg vil ikke love noget og ej heller udelukke de andre ideer. Men jeg vil tage det med videre i processen. Derfor vil jeg lægge det i puljen vi kalder ønskebrønden, som er det sted, hvor vi gemmer forslag, der potentielt set kan gennemføres i fremtiden. 

Jeg vender tilbage, hvis der sker noget nyt i sagen. 

Rigtig god dag 

Comments

Hej,

Tak for svaret. Må indrømme at jeg er lidt skuffet over svaret - føler ikke i forstår hvor stort problematik denne automatiske landekode har indført for eksterne integrationer - som det er pt. vil vi ikke kunne integrere fx webshops som har kunder fra flere lande over i e-conomic, da vi ikke vil kunne verificere om det er en rigtige kunde i e-conomic vi har fat i. Hvis vi gør, så skal alle fakturaer/tilbud/ordre manuelt verificere i e-conomic = ikke holdbart!!!

Det er jo ikke blot en forbedring - fordi i har indført denne automatisk landekode er jeres REST-api på nuværende tidspunkt totalt ubrugeligt hvis man har kunder fra flere lande, og ønsker at integrere udefra. Alt problematikken vil kunne løses hvis i enten gør det muligt at slå den automatisk landekode fra eller laver et tjek om der allerede eksistere en landekode (hvilket er mig en gåde, hvorfor systemet ikke gør det i dag) - virker helt forrykt at kunde som har udenlandske kunder skal ind og ændre i deres CVR-nr på alle de kunder som allerede har landekode foran. Hvis der laves et tjek inden faktura/ordre/tilbud oprettes, vil REST-api til en hvis grad være brugbart.

---

Hej Jesper,

Hvornår kan vi forvente at sagen kommer videre ?

Nu har vi levet med den defekte funktionalitet i et års tid eller så'n. Det er egentlig ikke i orden...

Så helt præcis hvornår ruller i denne funktion tilbage, alternativt gør det helt simpelt og giver os mulighed for selv at bestemme ?