Problemer med lagerstyring

Question

Hej e-conomic, hej Jesper

Jeg har tilmeldt lagermodulet og startet lagerstyring op af punktafgiftspligtigt oplag af varer med EU-harmoniserede afgifter. Det er primært varer i segmentet vin og spiritus.
I Danmark skal der afregnes punktafgifter og emballage(flaske-)afgifter til SKAT løbende måned+15 dage af solgte varer.
Snyder man e-conomic hist og her, så kan det godt lade sige gøre fornuftigt.
Men jeg har nogle generelle udfordringer.

ENHEDER
Punkt- og flaskeafgifter afregnes efter alkoholprocent, bobler/ikke bobler, indhold og flaskestørrelser. For spiritus gælder det, at alkoholprocenten varierer ganske betydeligt. Der skal derfor oprettes enheder, der er klart overskuelige og sigende.
Whisky findes for eksempel i et hav af forskellige alkoholprocenter 46,4 - 46,5 - 46,8 osv osv. Når en enhed oprettes, tager e-conomic blot den næste ledige nøgle. Det betyder, at ny enhed 46,7 ikke kommer naturligt i rækkefølgen. Skal man bruge en enhed for en anden flaskestørrelse, går det helt galt.
Systemet kan snydes, men kun med et kæmpearbejde og fuldstændig uoverskuelighed til følge.
Jeg opfordrer e-conomic til at gøre det muligt selv at vælge nøglen, når der oprettes enheder. Og selvfølgelig skal nøglen kunne rettes/slettes som i alle andre kartoteker.

AFGIFTSKONTI
I e-conomic opererer man kun med de afgifter, som afregnes via momsafregningen. Det er ikke muligt at tilføje yderligere afgiftsformer med tilhørende finanskonti, hvilket er helt essentielt i forbindelse med oprettelsen af enheder. Er der ikke denne kobling, kommer afgiftsmuligheder ikke ind på varekortet.
Igen må man ud og snyde systemet for at få en fornuftig løsning.
Jeg opfordrer e-conomic til at gøre det muligt at oprette andre relevante afgiftsformer.

VARELEVERANDØRFAKTURA
Når der skal oprettes en ny fakturalinje på en vareleverøndørfaktura skal kostprisen indtastes. Når der købes i EUR, sker det ofte, at kostprisen på en vare er en pris med mere end 2 decimaler. Det betyder, at en fakturalinje med måske tusinde enheder går fuldstændig galt. Derfor må man snyde og for eksempel lave en gebyrkonto til at justere fakturatotalen med. Det er ikke hensigtsmæssigt.

Det samme gør sig gældende ved "kostpristillæg i %". Her er det også kun muligt at anvende to decimaler. I øvrigt har jeg også efterfølgende behov for at se, hvilket kostpristillæg, der er anvendt på bogførte varelinjer.

Disse åbenlyse fejl gør afstemning/udligning af finanskonti efterfølgende til noget rigtigt "ØV"

Jeg opfordrer e-conomic til at ændre antal decimaler på kostprisen til minimum fire.

Når vareleverandørfakturaen er bogført er det ikke muligt, at se den anvendte kurs, hverken på det interne bilag eller posteringen.
Jeg opfordrer e-conomic til at angive den anvendte kurs.

BILAG
Når man køber varer i EU, så følger der en mængde forskellige bilag med. Ordreseddel, følgeseddel, transportdokumenter, EMCS-dokumenter, leverandørfaktura, transportfaktura mm.
Alle disse dokumenter kommer nødvendigvis ikke samtidig. Nogle med snail-post, andre med mail og nogle om nogle uger.
Når SKAT kommer på kontrolbesøg skal alle disse dokumenter præsenteres med tilhørende rapporter med varebevægelser.
Problemet er, at man efter bogføringen af fakturaen ikke efterfølgende kan knytte bilag til fakturaposteringen.
Man har nu bilag flydende rundt i hele universet istedet for samlet på posteringen.
Jeg opfordrer e-conomic til at arbejde for, at der kan tilknyttes yderligere bilag til en bogført faktura.
Dette gælder i øvrigt også, når der faktureret til kunder. Det kunne være tegninger, opgørelser, anden brevveksling mm.

BETALING
Når betalingen af leverandørfakturaen skal bogføres sker det oftest efter et bilag fra banken, fordi bogføring i valuta via bankafstemning giver for store fejlmuligheder.
På dette bilag er hverken kurs eller det modsvarende DKK-beløb angivet.
Den kurs, som e-conomic foreslår er naturligvis forkert, fordi man i den virkelige verden anvender både køber- og sælgerkurs +/- bankens margin.
Den foreslåede kurs angives med seks decimaler, men den skal jo rettes til den rigtige kurs. Det er nemt at regne i feltet - =beløb i danske kroner/beløb i EUR*100 - men nu er feltet kun med to decimaler. Det betyder diff i banken.
Jeg opfordrer e-conomic til at angive det korrekte antal decimaler (seks) ved udregning i kursfeltet.
Det hedder også "validering af felter"!!

AFDELINGER
Og så min kæphest gennem mere end 10 år.
Det giver jo absolut ingen mening, at man kan sælge varer fra afdelinger, men ikke købe de samme varer til afdelinger.
En opfriskning af API'et tillige, ville give fantastiske muligheder - læs e-fakturering.

Ingen er jo perfekt, generelt er jeg tilfreds med brugen af lagerstyring, når blot man har vænnet sig til finurlighederne. Men det ville absolut være fantastisk, hvis e-conomic kunne løse nogle af mine ønsker. Jeg tror, der er et stort kundepotentiale i lagermodulet, hvis det blev fikset lidt op.

mvh

Finn
e-consultic.dk

Answer 1

Hej Finn og mange tak for det lidt lange, men meget relevante indlæg.

Da det er så langt og med så mange punkter, så vil jeg punkt for punkt besvare det herunder:

Enheder:

Jeg kan huske du før har bragt dette op og jeg har i sidste uge fået dette med vores udviklere.

Jeg kom med forslaget omkring ændring af nummer på omkostninger, enhed og abonnement. I første omgang ville de ’kun’ godkende en. Her valgte vi i fællesskab, at abonnement var den, som skabte mest værdi, da man bruge nummeret til en kørsel, hvor det giver mening at kunne lave en form for gruppering.

Derfor vil jeg også sige, at enheder ikke bliver i denne omgang.

Afgiftskonti:

Her er jeg lidt i tvivl om, hvordan det skal bruges. Derfor vil jeg spørge lidt ind.

Som jeg læser det bruger du enhederne til at bestemme, hvordan en afgift posteres ved at have de relevante afgiftskonti på. Oven i det har du satsen, så det hele passer sammen.

Er det i den forbindelse du ønsker flere konti, så du kan tilføje endnu flere forskellige afgiftskonti?

Hvis det er dette, skal den så bruges til andet end at bogføre beløbet over på en bestemt konto? De andre er fx brugbare i forhold til rapporten. Du må meget gerne uddybe, hvis de skal have anden funktionalitet end at fungere som en posteringsmulighed for afgift ud fra en sats.

Vareleverandørfaktura:

Decimaler er en evig problemstilling. Jeg erkender det giver udfordringer i systemet, hvis dette er tilfældet. Omvendt må jeg også bare sige, at jeg har bragt dette op en del gange og som tingene er nu, så vil det ikke komme.

Synliggørelse er kursen er dog en sag. Du kan godt manuelt regne den ud ved at finde posteringen og så beregne forholdet mellem de to beløb. Det vil dog kræve manuelt arbejde.

Jeg kan ikke love noget her, men hvis vi skal vise den, hvor ville det så hensigtsmæssigt at gøre det?

Bilag:

Her vil jeg gøre dig opmærksom på, at du godt kan vedhæfte bilag løbende til en vareleverandørfaktura. Hvis du går ind via inboxen og vælger ’vedhæft til postering’ -> skriver bilagsnummeret og det korrekte regnskabsår, så vil du kunne få det med.

Jeg har ikke fundet en løsning på salgsfakturaen. Jeg vil lige grave i, hvorfor det ikke virker her.

Betaling:

Jeg har før undersøgt problemstillingen med regnefeltet. Det er nemlig sådan at feltet til kursen tillader flere decimaler. Selve regne funktionen er dog den samme som findes alle andre steder i e-conomic, hvor der kun arbejdes med to decimaler. Derfor vil en ændring betyde, at det slår gennem alle steder i e-conomic, hvor du ikke kan arbejde med flere decimaler. På den baggrund fik jeg sidste gang afvist, at vi ville arbejde med dette.

Jeg kan dog sagtens se din pointe her.

Afdelinger:

Du har jo ret i det du siger her. Det ville selvfølgelig være naturligt, at man også kan købe hjem til afdelinger. Jeg vil gerne prøve at tage dit forslag her med videre. I første omgang kan jeg ikke sige noget om, hvordan vores udviklere vil se på det.

 

I forhold til hele lagermodulet, så er jeg rigtig glad for, at du overordnet set er tilfreds. Jeg kan sagtens følge dig i, at der lige mangler lidt opmærksomhed før vi kan ramme en endnu bredere gruppe af kunder. Der er må jeg bare sige, at jeg er enig.

Dermed ikke sagt, at der ikke findes brugere, som vil kunne få et produkt, der opfylder deres behov, men der findes helt sikkert potentielle kunder, som har valgt vores lagermodul fra og tilvalgt en partner eller lignende til deres e-conomic aftale.

For at slutte af, så har du rigtig mange gode tanker her. Decimaler er evig snak og i forhold til din problemstilling, så vil bedre arbejde med decimaler løse to af dine punkter. Det bliver dog ikke noget vi vil kigge på her og nu.

Afgiftsdelen afventer jeg dit svar. Løsningen her ser jeg som ikke-udvikler ikke være så kompleks, hvis jeg har fanget den rigtigt. Det vil dog ikke løse overblikket over enheder.

Når vi kommer til vedhæftning af bilag, så ligner det løsningen på vareleverandørsiden allerede findes. Salgssiden kan jeg dog ikke helt finde ud af endnu.

Jeg tror jeg har fået svaret på det hele og jeg vil lige grave videre. Det er helt ikke det svar du ønskede dig hele vejen rundt, men hvis der er noget jeg direkte ikke har svaret på, eller der er noget, som ikke giver mening, så må du endelig gøre mig opmærksom på det.

Mange tak for en dybdegående og faglig relevant gennemgang af vores lagermodul. Der er ingen tvivl om, at du ved, hvad du snakker om her. Jeg ser frem til at høre fra dig.