Dynamiske felter og layout på bestillinger

Question

Felterne [MomsBeloeb] og [TotalBeloebBrutto] virker ikke i design og layout -> bestilling

Jeg har priser på mine bestillinger, men moms er altid 0

Answer 1

Jeg kan se at der flere steder efterlyses begrundelser for, at den ene eller den anden feature ønskes, sådan at e-conomics folkene kan bedømme om det er noget der skal arbejdes videre med. Her mine bud på, hvorfor der skal være en fungerende moms på indkøbsordrer:

<ul>Indkøbsordren er grundlaget for den aftale man laver med leverandøren. Der skal således være klarhed over alle de beløb man kan finde i ordren.

Hvis man bestiller fra udlandet kan det faktureres på flere måder. Det kan være momsfrit, det kan være med den udenlandske moms eller det kan være med dansk moms hvis selskabet har en afdeling i Danmark der står for faktureringen, sådan i grove træk.

Når bogholderiet skal betale regningen, altså indkøbsfakturere, skal beløbet stemme overens med den indkøbsordre som indkøberen har produceret. Ellers skal der spildes tid på at få verificeret, at beløbene er korrekte.</ul>

Er der andre bud, måske formuleret på en bedre måde ?

Answer 2

Hej Thomas,

Fedt med uddybet info! Det giver os nogle eksempler/arbejdsgange på hvornår man bruger dette, og det er jo super relevant. Både så vi kan forstå konteksten(er der måske en måde hvor på man kan komme i mål (ikke så relevant i dette tilfælde)) - og til at forstå hvor mange som har denne arbejdsgang, og derfor også hvor mange der har dette ønske.

Smukt - og som Thomas skriver, hvis der er er andre med samme problemstilling, giv gerne jeres mening tilkende.

Jeg vil også lige henvise til mit tidligere indlæg i dette emne, da det som sagt er noget der vil kræve meget omplanlægning af lagerstyringen.

mvh

Answer 3

Hej Steffen,

så er brokkehovedet (mig!) på banen igen

De der forklaringer med uha, det er sørme meget svært at (gøre et-eller-andet), de duer ikke rigtig. Det er -undskyld- at tale ned til folk. Hvis man ønsker at brugerne deltager aktivt og bidrager konstruktivt, så må man komme med seriøse forklaringer som brugerne kan forholde sig til. Der er -indrømmet- en snært af det i ovenstående, men helt generelt er der for meget af den slags.

I det her eksempel kan der -efter mit bedste skøn, når der ikke er kommet flere detaljer på bordet- laves en simpel work-around løsning. Man kan jo nøjes med at beregne momsen og vise den, direkte i den kode der genererer siden (og PDFen), den behøver ikke at blive gemt. Det er først nødvendigt at gemme momsbeløbet når der indkøbsfaktureres og bogføres. Ind til da er det helt fint bare at beregne og vise den. Gør man det på den måde, vil det ikke have den ringeste indflydelse på resten af systemet og det vil være muligt at sende/udskrive indkøbsordrer med alle nødvendige beløb.

Nu kan i jo så vælge at acceptere dette og lave ændringen uden videre vrøvl. Det skal selvfølgelig også testes, det gør jeg gerne i mit testsystem, og så er den potte ude.

I kan også vælge at affærdige ideen, men så vil jeg -igen- gerne bede om en ordentlig forklaring, ikke bare sorry, no can do. Det er vel ikke helt urimeligt ?

Answer 4

Hej brokkehoved (dig)   

Godt at se du er på banen igen!

Som du kan se i det andet indlæg om ca. det samme - http://forum.e-conomic.dk/forbedringsforslag-til-conomic/nummerserie-til-bestillinger-t1010-10.html#p3779 så er vi som sagt ikke teknikere, hvorfor en længere udregning ikke er helt at have med at gøre.

Vedr. dine næste afsnit vil jeg henvise til det andet indlæg, da det går på det samme

Skulle der være andet, så siger du jo bare til.

mvh

Answer 5

Ja ja, tak... Mon ikke jeg finder et eller andet ?

mvh
Brok E. Hoved

Answer 6

Helt sikkert.

Mvh