Kontospecifikationer, udskriv over flere regnskabsperioder

Question

Jeg vil foreslå, at systemet kan udskrive kontospecifikationer fra finansbogholderiet over flere regnskabsperioder i én omgang. Eks. der er regnskabsafslutning pr. 31/12 2017 og man vil se posteringer fra eks. 30/9 2016 til 31/3 2017. Som det er nu skal man både ind i år 2016 og 2017, altså to udskrifter - det er meget "bøvlet". Til orientering kan det oplyses, at i debitor- og kreditormodulerne kan man godt udskrive henover flere regnskabsår. I andre bogføringssystemer kan man også, bare til orientering.

Answer 1

Hej og tak for dit forslag :)

Jeg vil lige opsummere for at være sikker på, hvad du ønsker. Du vil kort og godt kunne trække rapporter på tværs af regnskabsperioder. Hvis jeg har misforstået det, så ret mig endelig.

Jeg vil som udgangspunkt gerne gå videre med denne forespørgsel. For at have de bedste argumenter for dette forslag, kan jeg så lokke dig til at uddybe, hvornår og i hvilken situation du ønsker at trække dette? Oven i det vil jeg høre, hvilke rapporter fra finans du ønsker at have denne mulighed på.

Forslaget bliver sat som overvejes og jeg vil tage det med videre. Jeg håber du/I er frisk på at argumentere ydeligere. Det vil helt sikkert hjælpe når jeg senere skal arbejde videre med forslaget.

Answer 2

Hej igen :)

Jeg har nu vendt din forespørgsel med vores udviklere.

Grunden til, at det er bygget på denne er, at der er udfordring med den primopostering, som indgår i rapporten når man går på tværs af et regnskabsår. Det er også derfor de andre rapporter godt kan gå på tværs.

I tilfælde, hvor du går på tværs af året, så vil en evt. primo gøre, at beløbene bliver lagt sammen dobbelt, da alle posteringer i året vil lægge sig over som primo den første dag i den nye periode. Der skulle derfor laves en primo i minus, hvis man kan kalde det, det. Ellers vil en rapport på tværs ikke give mening i sin visning. I hvert ikke på den måde det er lavet i dag. Hvis dette skulle ændres skal vi derfor ind og ændre på den måde primo bliver dannet og vist, hvilket gør det en meget større opgave. Der må jeg være ærlig at sige, at det input, der skal lægges i det ikke svare til den værdi, der kommer ud af det igen. Ikke sammenlignet med andre forslag vi har liggende. Derfor vil vi afvise forslaget og jeg sætter derfor status til implementeres ikke.