Version 13 (1+2) Finans nyheder

Transkript

1 Version 13 (1+2) Finans nyheder samt andre områder også interessante for finansfolk M3UG præsentation 19. marts 2015

2 Præsentationen Den giver et overblik over udvalgte funktioner Det er ikke live (men der er screen dumps ). Der henvises iøvrigt til Infor NC rapporter for en mere detaljeret gennemgang på hvert enkelt område. Disse er iøvrigt særdeles omfangsrige og uddybende (der har nok aldrig være givet så meget og så god produkt dokumentation som i V13 )

3 Agenda Debitor Forbedret kreditkontrol + AR Credit Manager Toolbox af eksterne dokumenter Forudbetaling med og uden forud fakturering Kreditor Forudbetaling 2 varianter Nyt BatchFakturaInterface modul Fragt Afregning med indkøbsordrer og self-billing Beløbsstyret fakturagodkendelse afhængig af type køb Finans Små gode forbedringer GLS850 kan kaldes via API

4 Agenda Internt regnskab Afstemningsrapporter Omkostningselementer i indkøbskalkuler efter operator 99 Pris og afgifter henføres til batchet ved actual cost Historisk Actual Cost Andre tekniske funktioner Event Trigger Drill down

5 Forbedret kreditkontrol Parametre kreditkontrol: Styring af hvilke ordrer/fakturaer der skal indgå via betalingsbetingelserne:

6 CRS315 - Kreditkontrol Kan også kaldes via CRS610 option 25

7 Credit Manager Toolbox

8 eksterne dokumenter Følgende print/programmer kan nu mailes: 1. ARS149PF Statement of Account 2. ARS159PF Payment Reminder 3. ARS169PF Interest Invoice 4. ARS189PF Payment Advice 5. ARS116PF AR Standard Letter 6. ARS121PF Manual Customer Invoice 7. MFS109PF Internal Invoice 8. APS056PF AP Batch Invoice 9. APS162PF Giro Remittance Advice

9 eksterne dokumenter I CRS111 kan faste modtagere af de forskellige dokumenter sættes op: Det kan igen overstyres via dokument modtagere i CRS945, hvor disse dokumenter også er oprettet. Så en relativt fleksibel løsning Kun 1 modtager, men man kan selvfølgelig fylde hele feltet ud (eller lave en mail-gruppe på sin mail-server).

10 Forudbetaling debitorer Der opereres med 2 metoder: Brutto og Netto Brutto er ny og udtrykker at man sender en betalingsanmodning til kunden, men den bogføres ikke som en faktura. Den skal betales før man sender varerne. Fakturaen sendes derefter og den lyder på ordrens totale beløb (brutto). Netto minder lidt om-aconto delen som vi kender den, blot udvidet med flere parametre for udvælgelse til aconto fakturering samt en specification på aconto fakturaen af, hvad som betales. Der opsamles anmodninger i en ny funktion OIS125, som faktureres. Når leverancen sker, slutfaktureres kunden. Denne faktura lyder på ordretotal aconto faktureringer (netto).

11 Forudbetaling - debitorer Bruttometoden (Til dårlige betalere, betalingsstandsninger etc): - der udskrives en proforma faktura direkte som en integreret del af ordre registreringen, fakturaen bogføres ikke leveringen er spærret indtil betaling (OIS150 har fået flere værdier)

12 Forudbetaling - debitorer Når fakturaen betales registreres den som en speciel aconto indbetaling (option 19 i ARS110, men ABS har også fået et scenarie for fremsøgning af denne), hvorefter leveringen frigives (ifølge dok.) Når forsendelsen faktureres udligner den aconto indbetalingen.

13 Forudbetaling - debitorer Betalingsmetoden styrer flowet sammen med et par parametre på ordretypen. Begge dele bør være stamdata på den slags kunder. (Jeg kan dog ikke få den til at danne forudbetalingsreferencen, så betalingen kan ikke foretages ) Det fungerer som en integreret del af ordreflowet - styret af kundeservice så der er ikke noget med at ændre spærrekoder, kreditgrænser osv. Det er enkelt at slette ordren, hvis kunden alligevel ikke betaler sin aconto.

14 Forudbetaling - debitorer Nettometoden (normal kunde, hvor man ønsker forudbetaling): - flowet på ordresiden er det samme, men forudbetalingen bogføres som en normal faktura, der skal betales. Der er kommet en mængde nye parametre og muligheder for beregning af aconto-fakturering i OIS121 og OIS122. Leveringen er spærret med en speciel statuskode indtil betaling Når forsendelsen faktureres fratrækkes forudbetalingsfakturaen på den endelige faktura (deraf netto). Betalingsmetoden styrer flowet sammen med et par parametre på ordretypen. Integreret del af ordreflowet styret af kundeservice.

15 Forudbetaling kreditorer Også her 2 mulighed med brutto og netto. Ved bruttometoden registreres forudbetalingen med udgangspunkt i en amnodning (altså ikke en faktura) i en ny funktion (APS106). Disse betales og står som aconto udbetalinger. Når varefakturaen modtages udtrykker den det totale beløb (brutto) Ved netto fremsendes aconto fakturaer, som betales som normale fakturaer. Varefakturaen udtrykker varebeløbet aconto faktureringer (netto). Værdien af denne + aconto anvendes for matchning af indkøbsodre Evt. betaling af netto udestående Afstemning i speciel APS120 funktion.

16 Forudbetaling kreditorer - brutto Ved bruttometoden registreres forudbetalingen med udgangspunkt i en amnodning (altså ikke en faktura) i en ny funktion (APS106). I APS106 står posten som en anmodning om udbetaling. Der kan via APS905 parametre styres om denne anmodning skal godkendes af en ansvarlig person og om der kræves reference (til indkøbsaftale). Derfra går den over i normale udbetalingsrutiner (manuelt eller betalingsforslag) og dermed registreres den som en åben udbetaling. Indkøbsordren registreres og refereres typisk til aftalen Fakturaen modtages og den udtrykker fakturabeløbet på de leverede varer (altså ikke fratrukket noget forudbetaling). For at udligne fakturaen mod forudbetalingen skal man udligne forudbetalingen og fakturaen(rne) i APS120, hvor parametre på økofunktionen giver et specielt view.

17 APS106 Anmodning 3

18 APS130 Betalingforslag

19 APS120 Man. Betal. (option 19)

20 APS200 Kreditor

21 CRS405 AP10 Nye opsæt

22 APS100 Leverandørfaktura

23 APS120 Spec. Afstemning Herefter går betalingsanmodningen i status 9

24 Forudbetaling kreditorer - netto Ved netto metoden registreres betalingsanmodningen som en leverandørfaktura (forudbetaling type 2). Der kan registreres flere af disse fakturaer. Fakturaen godkendes og bogføres og betales som en normal leverandør faktura. Der modtages en vare-faktura, som nettobeløbet der udestår (forudbetalingstype 4) Når denne faktura skal matches mod indkøbsordren(rne) skal summen af betalingsanmodningsfakturaerne indgå, disse vælges i et program PPS117, som popper op mellem APS100 og APS360.. Den endelige leverandørfaktura (fratrukket aconto betalinger) betales normalt. Udligning via APS120 som under brutto...

25 APS117 - eksempel

26 Netting mod prepaid 220

27 APS450(MI) for batchfakturaer Helt nyt modul skrevet fra bunden af. Flere nye fakturatyper 05 = Prepayment invoice 10 = Self-billing 20 = Supplier invoice 30 = Debit note 40 = Debit note request 50 = Supplier claim 51 = Supplier claim request Kan også modtage ordrelinie afgifter Fungerer ellers med samme funktionalitet som APS050

28 APS450(MI) for batchfaktuaer

29 Selfbilling nu også fragt

30 Fragtindkøb via IO

31 Fragt indkøb via IO

32 Fragt indkøb via IO

33 Fragt indkøb via IO

34 Fragt indkøb via IO

35 Fragt indkøb via IO

36 Fragt indkøb via IO De dannede indkøbsordrer kan fakturamatches som almindelige indkøbsordrer De kan også kobles op på en selfbilling aftale, så selfbilling kørslen sørger for fakturering:

37 Forbedret godkendelse (DOA) Man kan nu styre godkendelses niveauet afhængig af hvad en person køber. Dvs. indkøbschefen på godt godkende for 2 mio. Varekøb, men kun for kurser Man kan desuden sætte op, at på specielle omkostningtyper skal der en ekstra godkendelse til (eks alt PC-udstyr skal godkendes af IT funktionen).

38 Finans gode forbedringer Bloker konto for manuelle posteringer i CRS630: Tekst på bilagsheader... Brugerdefinerede views i GLS120

39 Finans GLS850 via API

40 IR Sikre konsistent bogføring CAS950 Transaktioner uden for dato interval får første interval dato parameter på øko-funktion CA02: (men stadig ingen kontrol i føde-modulerne ). Bogføringsdatoen skrives nu tilbage i fødetransaktionerne (og ikke bare ned i CINACC). Hvis man retter i GLS037, så skrives disse rettelser tilbage i CINACC

41 IR: CAS535 Afstemning Ny rapport der har til formål at dokumentere sammenhængen mellem GLS210, CAS300 og MWS070 (som nok er det område, hvor der er flest afstemningsproblemstillinger) Rapporten kan kaldes med udgangspunkt i GLS210 (finans): På denne måde giver den en oversigt over, hvor transaktionerne kommer fra, som er bogført på givne konti.

42 IR: CAS535 Afstemning Den kan også kaldes modsat i lagertransaktioner pr et givet lager i et transaktionsdato interval og så vise hvilke finanskonti der er bogført på.

43 IR: Indkøbspris kalkuler Det er nu blevet muligt at tilføje omkostningselementer efter element type 99 (lager kostprisen) Dette kan anvendes til at styre forskellige kostpriser i virksomheden, hvor f.eks fradrag af bonushensættelser kan være med til at udtrykke en reelle kostpris, men det ønskes ikke at denne vises direkte i sytemet (tidligere skulle man operere med flere modeller og tilpasninger for at få det bogført). Styres via parameter 085 i CAS900. Bogføres ved varemodtagelse på normale 225 men ny modpostering 982 (ikke lagerførte omkostninger) Nye konteringshændelser på både PP10 (tilgang lager) og PP35 (retur reklamationer) Men ingen fordeling senere...

44 IR: Actual Cost Fakturamodtagelse Via parameter i APS905 kan man nu opdatere actual cost ved fakturamodtagelsen bedre end tidligere. Der beregnes nu en ny actual cost (MAHEAD) = oprindelig +/- difference (incl MACOPU og MAELEM). Afgifter opdatere til reelle omkostninger og afgifter fra fatkuramatchningen.

45 IR: Actual Cost Genberegn historisk kostpris Primært tænkt hvis man anvender periodisk lagervurdering (type 2 i CAS900),men kan også anvendes af andre dog uden opdatering. Ny funktion CAS400 for at få genberegnet nye/historiske actual cost priser. Sættes igang via et datointerval og gælder alle transaktioner i dato intervallet. Output er et overblik over korrektioner, der måske ikke er henført til faktiske omkostninger: Efterfølgende kan disse opdateres via PCS450 (opdaterer MITTRA)

46 Event Subscription Mulighed for at følge op på ændringer i tabeller/data og få notificationer, når et givet felt ændrer værdi. Kan anvendes ved - nyoprettelser kunder (opdater kreditgrænse) - nyoprettelser leverandør (bankkonto skal oprettes) - hvis en parti bliver kasseret - hvis en ordre ikke motages komplet osv. Når ændringen sker sendes en besked til en mail-modtager, og selve transaktionen kan også gemmes senere for analyseformål (Er måske lidt teknisk i sin opsætninge, men en ganske effektiv måde at lave et mini-workflow ).

47 Opsætning hvilken tabel

48 Hvilke felter

49 Hvad skal ske??

50 Dynamisk modtager

51 Kriterier

52 Drill down ved summeringer

53 CRS610 Vis kunder

54 CRS610 Retur til højere niv.

55 Tak!