Inspirationsesvent i torsdags

Question

Hej e-cononomic - Martin Lysholt Nielsen

Tak for et flot event i Langebrogade i torsdags.
Et godt lokale, god lyd og fint udsyn til foredragsholderne. Og så en god kage til.

Det var interessante emner, som I bragte til torvs.
Til autobank, som jeg bruger dagligt anvender, fik jeg lige et par fif, men autobank kan dog stadig forbedres. I kan se hvordan her:

http://forum.e-conomic.dk/18211/guf-for-webshoppere-abonniner-og-udviklere

http://forum.e-conomic.dk/20228/dynamisk-felt-pa-betalingsbetingelser

Men det var nu e-learning og e-invoicing, der havde min største interesse.
Det er ganske rigtigt, at finnerne, men især svenskerne, er længere fremme end os for så vidt angår
e-invoicing. Det skyldes, at Volvo var den første virksomhed i verden, der introducerede EDI, som et led i deres strategi om "just-in-time production" tilbage i firserne. Det vil sige den rette reservedel til den rette bil på det rigtige tidspunkt, når bilen skulle bygges.
Herhjemme var det primært Dansk Supermarked, der var lokomotivet med stregkoder på alle varer, elektronisk fakturering og lagerstyring.

Det er jo fantastisk, at e-conomic nu her tredive år efter også tager del i udviklingen. Der er bare lige et lille problem i Jeres tilgang til det.
For at e-invoicing skal fungere korrekt er det selvfølgelig en nødvendighed, at de data man sender afsted elektronisk, også er de korrekte.
Første side i grundbogen for programmører omhandler validering af data. E-conomics programmører har tydeligvis let og elegant sprunget denne side over. Når vi taler om kreditorer og varer, så mangler der validering på GLN, CVR, P-nr, CPR, bankkontonumre, FIK-koder, kreditornumre, GTIN-14, GTIN-13 og sikkert mange flere.
Det er simpelthen et must, at disse data bliver sendt rigtigt afsted i e-invoicing. Er der ikke validering på, bliver data afvist enten under afsendelsen eller hos modtageren. Supporten forklarer den manglende validering med, at nogle kunder bruger felterne til noget andet, og så kan man jo ikke validere!? Det er selvfølgelig noget sludder. Felterne skal indeholde de informationer, som de er ment til.
I faktureringen opererer man med minus-penge, så Nemhandel kløjs i det, og i projektstyringen kan man indtaste daglige 1.000.000 timer, skønt alle ved, at der kun er 24 i døgnet.
Tænk, hvis Volvo havde forsøgt, at få presset 10 eller 100 førersæder ind i Volvo 142.

Når vi kan modtage fakturaer elektronisk, vil det være helt oplagt, at give lagerstyringen en ordentlig overhaling ved samme lejighed, så både afdelinger og lokationer bliver en del af produktet, så
håndværksmestre med mange svende/biler, detailhandlere med flere butikker mv kan få et fantastisk produkt til styring af lager med stregkoder. Samtlige store leverandører til disse brancher er allerede kørende med e-invoicing, og mange af vore andre leverandører er jo også e-conomic brugere.

Den samme problematik gælder for automatiske betalinger. Når I nu får styr på udligningen af kreditorfakturaer med -kreditnotaer, vil det jo helt oplagt, at man kun betaler restbeløbet på den
oprindelige faktura. Jf supporten er dette en helt umulig opgave, men hvis I strammer Jer lidt op, går det nok alligevel. Vi skulle jo nødig betale for meget for vores varer.

Der ligger et kæmpe projekt foran Jer, hvis jeres e-invoicing strategi skal give mening.

Jeg håber inderligt, det lykkes.

Men endnu en gang tak for eventen.

Mvh

Finn
e-consultic

Comments

Hej Finn :)

Jeg skriver bare lige for at følge op.
I forhold til de ting du har skrevet, så vil jeg starte med at fremhæve de ting, som er blevet forbedret:
Der er validering på GLN og P-nummer nu.
CVR vil der ikke komme validering på, da dette felt bruge som momsregistreringsnummer ved salg til EU, når man trækker rapporten 'Salg til EU'.

De andre punkter i forhold til validering er jeg nødt til at tjekke op på, så dem afventer lige, men der er stadig ikke validering på disse.

Vi kigger løbende på vores lagermodul, og der er planlagt forbedringer. Det er dog ikke en ordenligt overhaling, som du beskriver, men mere enkelte punkter vi udbedrer på nuværende tidspunkt.

I forhold til at modregne kreditnota i betalinger, så kan godt gøre dette nu ved Bankoverførsel og IBAN. Så den den skulle også meget gerne være klaret :)

Hilsen Jesper Mieritz

---

Hej Jesper
Tak, det er da dejligt, der sker noget.
Med hensyn til validering, vil jeg endnu en gang forespørge på validering af FIK ved indtastning af leverandørfaktura. Det er jo ganske væsentligt, hvis bankconnect skal fungere korrekt.
Mvh
Finn
e-consultic.dk

---

Hej Finn :)

Jeg vil gerne prøve at kigge på valideringen af det felt. For at jeg kan præsentere det bedst muligt for vores udviklere, hvordan skal sådan en validering fungere? Jeg tænker på, hvor henne kan man hente oplysninger, som bekræfter, at det er det korrekte FIK-nummer.

Jeg håber det giver mening og du er frisk på at hjælpe mig lidt :)

---

Hej Jesper
Det s valideres efter fuldstændig samme regler, som I anvender, når I danner FIK-linien på debitorfakturaer (modulus 10)
Mvh
Finn
e-consultic

---

Mange tak for svaret. Jeg præsenterer det for vores udviklere til vores næste møde :)

---

Hej Finn :)

Jeg har nu snakket med vores udviklere herinde.
Der vil på nuværende tidspunkt ikke komme validering på FIK koder. Det ville selvfølgelig være en lækker funktion, hvis dette var muligt, men vi har valgt at lægge vores fokus på andre områder :)

Hilsen Jesper Mieritz

Answer 1

Hej Finn
Det er dejligt, at deltog på vores event. Tak for de rosende ord – det lyder til, at du har fundet det interessant og god kage hører der til sådan et event 

Der er rigtig mange gode og spændende punkter du nævner her i indlægget – de fleste af dem som også har været nævnt her på vores forum tidligere.

Jeg har videregivet dit indlæg fyldt med inputs til min kollega Martin som vi tage et lille kig på nogle af de forskellige ting du nævner i forhold til data validering – Så vi efterfølgende kan give dig et lidt bedre overblik over de forskellige ting uden det bliver en større projektskrivning.

I forhold til lagerstyring så er der en række andre steder i modulet der kræver en overhaling før det vil være specifikt på afdelinger og lokationer.
Det er på nuværende tidspunkt planlagt på vores roadmap, at skulle arbejde nærmere med lagermodulet i 4. kvartal 2017 (det kan ændres sig)
Her er det fokus, at forbedre de alm. arbejdsgange og derved mindske fejl. Der er tale om de simple funktioner i lagermodulet og derfor ikke imødekommer det ønske med styring af lager ud fra stregkoder.

Der ligger en klar udfordring i eksport af betalinger og håndteringen af kreditnotaer – Jeg er helt enig i, at det kunne være fordelagtigt hvis der kunne automatisk modregnes i forhold til kreditnotaen.
Det er en opgave som ikke er umulig men lidt kringlet i forhold til hvordan denne kreditnota skal modregne betalingen. Det er ikke et punkt som ligger prioriteret lige for nuværende men et, vi er opmærksomme på udfordringen.

Vi kommer med en separat kommentar i forhold til data validering. Forhåbentlig en gang i næste uge.
Tusinde tak for dine inputs og for dit store engagement for vores program.  

Comments

Jeg er bekymret for, om e-conomic kører på en så tidssvarende platform, at de kan udvikle alt det, som de hele tiden antyder, at de gerne vil!

---

Vi er i gang med, at gøre e-conomic klar til, at komme over på en fremtidssikret platform.
Det er lige den opgave der arbejdes på i vores servicevindue - Som jeg kan se du også har kommenteret på -> http://blog.e-conomic.dk/kommende-servicearbejde-e-conomic-skal-fremtidssikres/

Så jeg forstår din bekymring - Derfor er arbejdet med, at flytte over på en fremtidssikret platform også allerede godt i gang.