FaVa 1.0.20240815.4 og Delogue 1.0.20240814.2 er frigivet på AppSource
Om denne release
Frigivet – 15. august 2024
Versionen er bygget på:
- Microsoft Dynamics 365 Business Central, 24.4 (min. release 24.0)
- LS Central, 24.1 (min. release 24.0)
FaVa
Indhold
FaVa rapport til udskrift af salgsreturvareordre:
Der er nu lavet funktionalitet til udskrift af salgsreturvareordrer i FaVa med samme layout som de øvrige FaVa rapporter. Udskriften er ofte efterspurgt af B2B kunder, som derved kan få en bekræftelse på, hvad de skal sende retur.
Info! Rapporten med nummer 71170605 skal tilføjes til rapporttypen ”Returvareordre” under ”Rapportvalg – salg”!
Overmodtagelseskode påføres automatisk fra dimensionsmatrix:
Hvis man har ønsket at køre med overmodtagelseskoder i FaVa, har det hidtil været sådan, at logikken har fulgt standardlogikken i BC, og at man dermed manuelt har skullet tilføje overmodtagelseskoden på købsordrelinjen. Ellers har man fået den fejlbesked, at man ikke kan modtage det indtastede antal i feltet ”Modtag (antal)”, hvis det er større end det, der er angivet i feltet ”Antal”.
Brugen af overmodtagelseskoder i FaVa er nu væsentligt forbedret, så oprettelsen af overmodtagelseskoder nu foregår automatisk ved oprettelse af købsordrelinjerne efter afslutning og lukning af dimensionsmatrix.
Scenarie 1
Hvis overmodtagelseskoden har markering i feltet ”Standard”, og overmodtagelseskoden ikke er påsat hverken leverandør eller vare, så sker følgende, når der i dimensionsmatrix kaldt fra feltet ”Modtag (antal)” indtastes en værdi, som er større end ”Antal”, og som ligger indenfor tolerancen på overmodtagelseskoden:
- Det indtastede antal tillades
- Hvis der dog indtastes et antal, som ligger over tolerancen på overmodtagelseskoden, fremkommer en fejlmeddelelse
Når matrix forlades, vil FaVa pr. celle i dimensionsmatrix holde styr på, hvilke købsordrelinjer der automatisk skal have udfyldt overmodtagelseskoden, og samme felter som i standard BC vil blive udfyldt med info om overmodtagelse
Scenarie 2
Hvis overmodtagelseskoden ikke har markering i feltet ”Standard”, og overmodtagelseskoden ikke er påsat hverken leverandør eller vare, så sker følgende, når der i dimensionsmatrix kaldt fra feltet ”Modtag (antal)” indtastes en værdi, som er større end ”Antal”, og som ligger indenfor tolerancen på overmodtagelseskoden:
- Der fremkommer en fejlmeddelelse, om at kode for overmodtagelse mangler
Scenarie 3
Hvis overmodtagelseskoden ikke har markering i feltet ”Standard”, og overmodtagelseskoden er påsat enten leverandør eller vare, så sker følgende, når der i dimensionsmatrix kaldt fra feltet ”Modtag (antal)” indtastes en værdi, som er større end ”Antal”, og som ligger indenfor tolerancen på overmodtagelseskoden:
- Det indtastede antal tillades
- Hvis der dog indtastes et antal, som ligger over tolerancen på overmodtagelseskoden, fremkommer en fejlmeddelelse
Når matrix forlades, vil FaVa pr. celle i dimensionsmatrix holde styr på, hvilke købsordrelinjer der automatisk skal have udfyldt overmodtagelseskoden, og samme felter som i standard BC vil blive udfyldt med info om overmodtagelse.
Scenarie 4
Hvis overmodtagelseskoden ikke har markering i feltet ”Standard”, og overmodtagelseskoden er påsat både leverandør og vare, så sker følgende, når der i dimensionsmatrix kaldt fra feltet ”Modtag (antal)” indtastes en værdi, som er større end ”Antal”, og som ligger indenfor tolerancen på overmodtagelseskoden:
- Det indtastede antal tillades
- Hvis der dog indtastes et antal, som ligger over tolerancen på varens overmodtagelseskode, fremkommer en fejlmeddelelse
Når matrix forlades, vil FaVa pr. celle i dimensionsmatrix holde styr på, hvilke købsordrelinjer der automatisk skal have udfyldt overmodtagelseskoden, og samme felter som i standard BC vil blive udfyldt med info om overmodtagelse.
Bemærk! Overmodtagelse fungerer også, hvis opdatering af købsordren kommer fra et lagermodtagelsesdokument!
FaVa felter og matrix håndtering på bogførte dokumenter:
Det er på de nedenfor nævnte bogførte dokumenter nu lavet sådan, at relevante FaVa felter overføres dertil, og at linjerne bliver opdelt i matrixlinjer og varelinjer. Derudover er det muligt at tilgå oplysningerne i dimensionsmatrix og/eller sortimentsmatrix, og det er ligeledes muligt at vise/skjule dokumentets varelinjer.
Det betyder med andre ord, at der i henhold til ovennævnte dermed er implementeret samme logik på de bogførte dokumenter, som på de ikke bogførte dokumenter.
Køb:
- Bogførte købsmodtagelser
- Bogførte købsfakturaer
- Bogførte købsreturleveringer
- Bogførte købskreditnotaer
Salg:
- Bogførte salgsleverancer
- Bogførte salgsfakturaer
- Bogførte returvaremodtagelser
- Bogførte salgskreditnotaer
Derudover er tilsvarende lavet på følgende ikke bogførte dokumenter:
Køb:
- Købsfakturaer
- Købskreditnotaer
Salg:
- Salgsfakturaer
- Salgskreditnotaer
Bemærk!I forbindelse hermed har det været nødvendigt at strømline felter på henholdsvis salgs- og købsdokumentlinjer, så felt id’er nu er identiske og feltrækkefølgen den samme på tværs af dokumenter og på tværs af køb og salg!
Dette har resulteret i, at de nedenfor nævnte felter er ”obsoleted” (markeret til at skulle slettes)!
- XTEFVBrand
- XTEFVAssortment
- XTEFVSalesperson Code (kun på salg)
- XTEFV Shelf No. (kun på køb)
Fixes
Ingen tjek på ”Salgssæson for lager” på salgsreturvareordrer:
Udfordring: Der har indtil nu været tjek på, at ”Salgssæson for lager” skal være tilknyttet varen ved indtastning af salgsreturvareordrelinjer.
Løsning: Dette tjek er nu fjernet.
Oprydning ved slet af farve/størrelse (variant):
Udfordring: Ved sletning af varianter har der hidtil været den udfordring, at systemet ikke automatisk fik ”ryddet op” og slettet oprettede (tilknyttede) sæsonvarianter, hvilket resulterede i, at sæsonvarianterne manglede hægtning til selve varianten. Denne oprydning har dermed skullet forgå manuelt indtil nu.
Løsning: Dette er nu fixet.
FaVa Delogue
Indhold
Udvidelse med feltet ”Enhedskode” under ”Delogue pristype mappinger”:
!!! Breaking Change !!!
Det har hidtil været sådan, at salgs- og købspriser på varer fra Delogue automatisk oprettes med varens enhedskode. Dette er nu ændret, så det nu er det nye felt ”Enhedskode” på siden ”Delogue pristype mappinger”, der afgør hvilken enhedskode, der påføres priserne i FaVa.
Ændringen er primært lavet af hensyn til dem, der anvender sortimenter i FaVa, for logikken i FaVa er sådan, at sortimentsprisen beregnes ved, at systemet finder prisen med blank enhedskode og selv beregner sortimentsprisen ved at gange enhedsprisen med antallet af varer i sortimentet. Hvis man derimod har oprettet prisen med sortimentets enhedskode og/eller med sortimentets variantkode, vil den pris dog blive anvendt i stedet for den beregnede pris.
Bemærk! Feltet sættes default til blank værdi, hvilket dermed resulterer i, at både salgspriser og købspriser fremadrettet vil blive oprettet med blank enhedskode!
Bemærk! Hvis man derimod fortsat ønsker, at varer fra Delogue får salgs- og købspriser i FaVa oprettet med en anden enhedskode end blank, skal man umiddelbart efter opdateringen til denne release manuelt påføre den i feltet ”Enhedskode” på linjer med pristypen ”Leverandørens købspris” og ”Salgspris”!
Fixes
Overførsel af priser fra Delogue ved brug af prislister (ny salgsprisoplevelse) i FaVa:
Udfordring: Der er tidligere lavet funktionalitet til dynamisk at kunne håndtere overgang fra nuværende prisstruktur til prislister i takt med, at man måtte vælge at aktivere ”Ny salgsprisoplevelse” under ”Styring af funktioner”. Der kunne dog opstå situationer, hvor priserne fra Delogue ikke blev oprettet korrekt i FaVa.
Løsning: Oprettelsen af priserne fra Delogue i FaVa udføres nu korrekt og med udgangspunkt i, at hvis enten enhedsprisen eller den vejledende salgspris ændrer sig i Delogue, vil det medføre en opdatering af begge priser i FaVa. Hvis der er markering i feltet “Brug start-/slutdato på priser”, bliver der sat en slutdato på de gamle priser. Både enhedsprisen og den vejledende salgspris sammenlignes, og hvis bare én af disse priser er forskellige fra den eksisterende, bliver den gamle pris lukket og en ny pris bliver oprettet. Hvis der ikke er markering i feltet “Brug start-/slutdato på priser”, bliver der ikke sat en startdato på prislinjen. Eftersom Delogue ikke understøtter variantspecifikke priser, er det kun prislinjer med en blank variantkode, der bliver oprettet og opdateret i FaVa.
Info! Tilsvarende er lavet i forhold til den nuværende prisstruktur i FaVa!
Forbedret validering af mandatory custom fields fra Delogue:
Udfordring: Tidligere har det været sådan, at man kunne komme afsted med at importere styles med blanke værdier i custom fields, som var markeret som ”Obligatorisk” på siden ”Delogue feltmapning”. Hvis feltet fra Delogue ikke havde en værdi, så blev det bare importeret uden værdi til ”Delogue Style kladde”, og dette ville så resultere i en fejlmeddelelse ved oprettelsen/opdateringen af varen.
Løsning: Dette er nu fixet, så importen til ”Delogue Style kladde” nu validerer på, at feltet skal have en værdi, hvis det er markeret til ”Obligatorisk”.
Oprettelse af BC vareattributter ved import fra Delogue:
Udfordring: Det har indtil nu været sådan, at man i forbindelse med oprettelse af BC vareattributter ved import fra Delogue kunne få en meddelelse om, hvorvidt man ønskede at omdøbe.
Løsning: Dette er nu fixet.
Vigtige links med info om nye og planlagte opdateringer:
BC
https://learn.microsoft.com/en-us/dynamics365/business-central/product-news
LS
https://help.lscentral.lsretail.com/Content/Release-Notes-LS-Central/Release-Notes-LS-Central.htm
Continia
- Document Capture:
https://docs.continia.com/en-us/continia-document-capture/new-and-planned/overview - Document Output:
https://docs.continia.com/en-us/continia-document-output/new-and-planned/overview - Expense Management:
https://docs.continia.com/en-us/continia-expense-management/new-and-planned/overview - Payment Management:
https://docs.continia.com/en-us/continia-payment-management/new-and-planned/overview - Collection Management:
https://docs.continia.com/en-us/continia-collection-management/new-and-planned/overview