ASPECT4 Logistik Præsentation af release 9.1

Transkript

1 ASPECT4 Logistik Præsentation af release 9.1 Release 9.1 indeholder mange funktionelle forbedringer på handelssiden af ASPECT4 Logistik. Udviklingsprojekterne sikrer en meget smidig overgang til ASPECT4 Logistik fra ASPECT4 Handel. De fleste nyskabelser findes for den udgående logistik fx store områder som pris- og rabattilsætning, dynamisk redisponering samt transportstyring samt på forbedringer for den indgående logistik fx et cockpit til modtagelse af leverandørfakturaer. Af generelle forbedringer kan nævnes, mulighed for at implementere alternative kostpriser samt for at kunne designe skærmbilledet anderledes i exposer.

2 Indhold Generelt om ASPECT4 Logistik release Udgående logistik Dynamisk redisponering 4 Opsætning af den dynamiske redisponering 6 Simulering af mulighederne for levering 6 Dynamisk redisponering og ordrebehandling 6 Log over redisponeringer 7 Manuel omprioritering af ordrer 8 Dynamisk redisponering og tid 8 Salgspriser og rabatter 8 Definitioner 8 Stamdata 9 Firmaparametre 9 Øvrigt 12 Stamdatavedligeholdelse 12 Regler og begrænsninger 15 Funktioner 15 Transportstyring 17 Hvorledes opstår et transportbehov? 18 Planlægning af en transport 19 Gennemførelse af en transport 20 Rammeordrer 23 Hvad er en rammeaftale? 23 Sammenhæng mellem rammeaftaler og rammeordrer 24 Kundeaftalte minimumslagre 24 Den enkelte rammeaftalelinje kan periodiseres 25 Disponering ved afledte ordrer 26 Disponering ved intern samhandel 27 Forbedret afkaldsstyring 27 Bedre opfølgningsmuligheder på ordrehierarkier 27 Integration til salgsbudget 27 e-export 27 Modtagelse af leveringsforslag vha. adaptor DELFOR28 Forudsætninger og afgrænsninger ved anvendelse af DELFOR 28 Diverse småting udgående logistik 29 Kopiering af ordrelinjer 29 Indtastning af et numerisk kundenummer 29 EAN nummer som kundens varenummer 29 Selektion på status 29 Forhandlernummer 29 Prissætningskunde 29 Allokering af paller og kolli 30 Udvidet kontrolkode scanning 30 Toldposition på proformafakturaer 30 KID-nummer på faktura 30 Indgående logistik Cockpit på fakturamodtagelse 31 Cockpit på kapacitetsoverblik. 32 Tjek mod akkumuleret kapacitet 33 Ændret styring af Nedbryd afsætningsplan 33 Materialetjek i forbindelse med finplanlægning 34 Baglæns datering i forbindelse med finplanlægning 34 Selektion på produktionsmodelgrupper. 34 Manglende udfyldelse af POPX-TS 34 Maks. størrelse på datakøer 35 Brug af funktionsgrupper i forbindelse med firmaparameter A9145 og A Workflow til godkendelse af leverandørfakturaer 35 Tværgående forbedringer Nye kostprismetoder 37 Produktkonfigurering ved salgsordreregistrering 37 Konfigurering af varesæt 38 Varenummer og navn 38 Kopiering i forbindelse med varedimensioner 40 Listeændring Kalkuler kostpriser indkøbsvarer'(9231) 40 Omlægning af Økointerface 40 Tekniske forbedringer STFE behandling under exposer 41 Brug af shortcut F4 42 Eksterne dokumenter i DocManager 42 Kald af pc-applikationer vha. shortcut 42 Implementering Implementeringsvejledning 43 Forberedelse 43 Modtagelse og installation af pakker 43 Miljøopsætning 44 Opgradering af testmiljø 44 Opgradering af driftsmiljø 45 Opgradering af test-/driftsmiljø 46 Bemærkninger 46 Triggere 46 2

3 Generelt om ASPECT4 Logistik Release 9.1 Denne nye release af ASPECT4 Logistik indeholder mange funktionelle forbedringer på handelssiden af ASPECT4 Logistik. Mange af de gennemførte udviklingsprojekter er gennemført for at sikre en meget smidig overgang til AS- PECT4 Logistik for de kunder, der tidligere havde ASPECT4 Handel. De fleste nyskabelser findes for den udgående logistik. Dette gælder eksempelvis store områder som pris- og rabattilsætning, dynamisk redisponering samt transportstyring. Der findes dog også en del forbedringer for den indgående logistik. Eksempelvis er der udviklet et cockpit til modtagelse af leverandørfakturaer. Af generelle forbedringer kan det nævnes, at det nu bliver muligt at implementere alternative kostpriser. Desuden er der kommet en række muligheder for at designe skærmbilledet anderledes i exposer. Læs mere om comboxe, feltgrupper og radiogroups under afsnittet om feltvisningsmetode. Vi er desuden meget stolte over, at de første cockpits nu leveres til standard. Vi håber, at I alle får meget glæde af dette. Denne releasebeskrivelse udgives kun elektronisk. Hvis I har behov for en papirudgave, bedes I selv udskrive denne. Den engelske udgave af releasebeskrivelsen vil foreligge i maj Hvis I ikke allerede har opgraderet til release 9.0, vil det være en god ide at opgradere direkte til release 9.1. For de mange kunder, der allerede har opgraderet til release 9.0 kan det anbefales at lave et lille releaseløft til release 9.1, hvis I finder nogle interessante punkter i denne releasebeskrivelse, hvilket vi naturligvis håber, I gør. 3

4 UDGÅENDE LOGISTIK Dynamisk redisponering Formålet med den dynamiske redisponering i ASPECT4 Logistik er at sikre, at kunderne serviceres bedst muligt med varer i prioriteret rækkefølge. Eventuelle ændringer i virksomhedens forsyningssituation vil også direkte blive afspejlet på salgsordrerne, ved at leveringsterminerne automatisk ændres på disse ud fra det givne regelsæt. Den dynamiske redisponering disponerer salgsordrer ud fra en given forsyningssituation, dvs. er baseret på lagerbeholdninger og planlagte tilgange i form af indkøb og produktion. Den dynamiske redisponering varetager ingen opgaver i forbindelse med forbedring af virksomhedens forsyningssituation. Den dynamiske redisponering i ASPECT4 Logistik er implementeret for normale salgsordrer, dvs. terminsordrer. Den dynamiske redisponering fungerer inden for et lagersted, og ikke på tværs af lagersteder. Den dynamiske redisponering består af følgende nye applikationer i ASPECT4 Logistik: 6360 Vis disponering 6260 Løbende redisponering 6263 Stop løbende redisponering 6264 Redisponer alle varer 6190 Arbejd med ordreprioriteter Opsætning af den dynamiske redisponering Hvis kunderne skal prioriteres udelukkende efter "først til mølle"-princippet, skal man kun anvende tidsstempel som prioritet. Som det fremgår af parameteren, kan man desuden styre det maksimale antal split, en ordrelinje kan resultere i (svarende til antal delleveringer). Desuden kan man styre, at mindst en procentdel af en ordrelinje skal kunne leveres, før leverance i det hele taget er interessant. Det anbefales desuden at anvende en speciel udformning til styring af hvilke ordrer, der skal medtages i disponeringen. En typisk opsætning kunne følge den her viste for redisponering: Opsætning af den dynamiske redisponering er ret omfattende. For at anvende den dynamiske redisponering er der en række opsætninger, der skal gennemføres. Det drejer sig om følgende: Opsætning af systemparametre Opsætning af triggere Applikationsopsæt på ordrebehandling Opstart af nødvendige applikationer for at kunne anvende den dynamiske redisponering Systemparametre til den dynamiske redisponering Systemparameter REDISP er ny i ASPECT4 Logistik og oprettet med det formål at kunne styre den dynamiske redisponering. Som det fremgår af denne systemparameter har man mulighed for at anvende 3 forskellige elementer i prioriteringen af kundeordrerne. De tre elementer er en kundegruppering, en prioritet eller er tidspunkt for ordreregistrering. Hvis man anvender en kundegruppering til prioritering mellem kunderne (eksempelvis A/B/C kunder), skal man desuden angive, i hvilken kundegruppe denne klassifikation findes. For indkøbs- og produktionsordrer vil man normalt medtage bekræftede indkøbsordrer og produktionsordrer (evt. statussyret). På lagersiden bør alle lokationer og alle partier markeres som medtagne. 4

5 Følgende systemparametre er tillige nye som følge af implementering af den dynamiske redisponering: DISPBASE: Disponering baseret på (systemværdier) REDIAARS: Redisponeringsårsag (systemværdier) REDILBGR: Log begrænsning til redisponering (undtager årsager fra loggen). Opsætning af triggere Den dynamiske redisponering er baseret på triggere på følgende filer: Lagerbeholdninger (LABEREG) Salgsordrelinjer (ORDLREGS) Indkøbsordrelinjer (ORDLREGI) Produktionsordrelinjer (PROLREG) Triggerne sættes op vha. applikation 'Arbejd med eventbeskrivelser' (9188) og applikation 'Arbejd med supplerende handlinger' (9189). Her følger en typisk opsætning af disse applikationer. Fra de supplerende handlinger ser opsætning eksempelvis således ud: Den samlede oversigt over, hvilke triggere der er tilføjet de enkelte filer, styres vha. applikation 'Arbejd med eventbeskrivelser' (9188). Den specifikke opsætning for eksempelvis filen LABEREG ser eksempelvis således ud: Aktivering af redisponering i ordrebehandling For at anvende den dynamiske redisponering i ordrebehandlingen skal følgende parameter på eksempelvis applikation 6524 'Arbejd med terminsordrelinier' opsættes således: Check af fri disponibel beholdning sættes til 3. Hidtil har kun mulighederne 0 og 1 været tilgængelige. Hvis man vælger at sætte koden til 3, vises disponeringsbilledet, hvis ordren enten ikke kan leveres direkte fra lager, eller hvis ordrelinjers leveringstid ligger længere fremme i tid end varens leveringstid. Varer med en disponeringskode mindre end 7 medtages ikke i disponeringen. 5

6 Applikationsopstart til den dynamiske disponering Applikation 'Gennemfør supplerende handlinger' (9272) skal være aktiv. Det samme skal applikation 'Løbende redisponering' (6260). Det anbefales at styre dette vha. applikation 'Arbejd med jobdefinitioner' (9176). Simulering af mulighederne for levering Mulighederne for levering vises vha. applikation 'Vis disponering' (6360). Et disponeringsbillede kaldes med varenummer, kundenummer og lagersted. Hvis man kun anvender registreringstidspunkt som prioritet i disponeringen, har det ingen betydning, hvilken kunde man spørger for. Hvis kunderne er prioriteret enten via en kundegruppe eller via deres prioritet, er leveringssituationen afhængig af kundens prioriteter. en vare er bekræftet på et senere tidspunkt, end det burde være muligt i henhold til varens leveringstid, forlænger den dynamiske redisponering automatisk leveringstiden for denne vare, svarende til det tidspunkt hvor den sidste tilgang er planlagt. Dynamisk redisponering og ordrebehandling Hvis en ordrelinje ikke kan leveres fuldt ud fra lager, og ikke skal leveres på et senere tidspunkt end varens leveringstid, anvendes samme disponeringsbillede som vist ovenfor under simulering af disponering. For at synliggøre leveringssituationen for en ordrelinje er der indført en ny statuskode, nemlig 25 for disponeret. En ordrelinje kan få status 25, hvis den enten er disponeret mod lager eller med en tilgang (indkøb eller produktion). Et disponeringsbillede kunne eksempelvis se således ud: Ordrebehandleren har en række muligheder, når et sådant disponeringsbillede fremkommer: 1. Bedst muligt. Hvis ordrebehandleren vælger dette i denne situation, vil ordrelinjen blive splittet i 3 ordrelinjer svarende til leveringssituationen. Alle ordrelinjer får 3.11 som ønsket leveringsdato. Hvis dette valg tages, og det bliver muligt at levere varerne tidligere, end det fremgår af dette disponeringsbillede, flyttes ordrelinjerne automatisk frem i tid. 2. Det aftales med kunden, at alle 500 skal leveres den Dette gøres ved at markere levering ud for datoen den Der oprettes en ordrelinje med den som leveringsdato og som ønsket leveringsdato (en ordrelinje forsøges aldrig leveret før ønsket leveringsdato). Det fremgår af billedet, at leveringstiden for varen er 14 dage, samt at der er spurgt på et antal på 500. Det vises, at de 76 kan leveres fra lager. De næste 200 kan leveres, når der modtages varer fra indkøb d De sidste kan leveres i henhold til standard leveringstid for varen på 14 dage, dvs. d Styring af planlagte tilgange Som det altid har været tilfældet i ASPECT4 Logistik, har en præcis styring af datoerne for de forventede tilgange stor betydning for, hvor troværdige disponeringsbillederne er. Dette bliver endnu mere betydningsfuldt ved ibrugtagning af den dynamiske redisponering. 3. Det aftales med kunden, at der skal leveres 50 nu og resten den Dette gøres ved at taste 50 ud for den 3.11 og markere den for resten. Disponeringsbilledet vil så se ud som vist nedenfor. Dette resulterer i 2 ordrelinjer med leveringsdato henholdsvis den 3.11 og den Ønsket leveringsdato sættes til samme dato som leveringsdatoen. 4. Mange andre kombinationer kan aftales med kunden. Blot må det maksimale antal split ikke overskrides, og en levering skal mindst tilfredsstille procentsatsen fra systemparameter REDISP (undtaget er sidste levering). En planlagt tilgang ligger altid mindst 1 dag frem i tiden. Herved sikres, at der er tid til at ekspedere varerne. Styring af leveringstider En vares genanskaffelsestid findes på varens indkøbsoplysninger. Hvis sådanne ikke findes, tages standard leveringstider fra varens salgsoplysninger. Erfaringsmæssigt kan det være svært at få opdateret leveringstiderne fra en leverandør, selv om dette let kan vedligeholdes i ASPECT4 Logistik. Hvis en indkøbsordre for 6

7 Hvad sker der med ordren, hvis noget ændrer sig? Det antages, at ovenstående eksempel er blevet oprettet som en ordre. Hvis der nu forekommer en lagerregulering på -50, vil følgende hændelser indtræde: Ordreindgang via EDI eller Business Connector Hvis ordrer modtages elektronisk, behandles de svarende til, at ordrebehandleren havde anvendt "bedst mulig" levering. 1. Ordrelinjen med levering den 3.11 kan ikke længere leveres. Denne bliver derfor splittet i 2 ordrelinjer. Den oprindelige ordrelinje reduceres til 26, og der oprettes en ny ordrelinje på 24 den Dette er forårsaget af, at de 50 er aftalt med kunden, at de ønskes leveret den 3.11 og først mulige dato efter denne dato er den Ordrelinjen d bevares uændret. Man kan tænke sig mange scenarier for hvilke hændelser, der kan forekomme. Det kan tilrådes selv at simulere diverse scenarier, således at man får fuld klarhed over, hvorledes disponeringen reagerer i specielle situationer. Grundlæggende gælder følgende regler: En ordre vil aldrig blive forsøgt leveret før ønsket leveringsdato. En ordrelinje vil aldrig blive splittet i et større antal, end der fremgår af systemparameter REDISP. Hvis en ordrelinje er splittet manuelt vha. disponeringsbilledet, kan de her splittede linjer splittes igen, svarende til det antal gange det er tilladt, jf. systemparameter REDISP. En ordrelinje vil aldrig tillade leverancer, der går under procentsatsen for mindste leverancer, jf. systemparameter REDISP (undtaget for denne regel er sidste leverance). Skaffevarer og direkte leverancer Skaffevarer og direkte leverancer medtages ikke på normal vis i redisponeringen. Det gælder for følgende ordrepolitikker: IS, IO, PO, IG, at ordrelinjer på disse automatisk oprettes i status 30, svarende til prioriteret i forhold til den dynamiske redisponering. Dette betyder, at disse i praksis ikke medtages i redisponeringen, og dermed ikke risikerer at blive splittet. Log over redisponeringer De ændringer, der er foretaget af den dynamiske redisponering logges naturligvis. Man kan arbejde med denne log vha. applikation 'Arbejd med redisponeringslog' (6135). Af loggen fremgår, hvorledes ændringer på ordrelinjerne er gennemført - se nedenstående billede. På basis af loggen kan man vælge at markere, eksempelvis at kunden skal have en ny bekræftelse. Log over redisponeringer - af loggen fremgår, hvorledes ændringer på ordrelinjerne er gennemført. 7

8 Manuel omprioritering af ordrer Hvis man er kommet i en situation, hvor man har behov for at overstyre den automatiske tildeling af varer, kan dette gøres vha. applikation 'Arbejd med ordreprioriteter' (6190). Ved at markere en ordrelinje i applikationen hæves ordrelinjens status til 30. Dette er en prioriteret status, i forhold til det bedste som den dynamiske redisponering kan tildele, nemlig 25. Den dynamiske redisponering kan ødelægges af anvendelsen af reservationer og allokeringer i ordrebehandlingen. Det kan derfor tilrådes at fjerne disse muligheder fra ordrebehandlingsapplikationerne, og først allokere varer når disse skal plukkes fra lager. Samtidigt tilrådes det at begrænse adgangen til applikation 'Arbejd med ordreprioriteter' (6190). Dynamisk redisponering og tid Det forhold, at tiden går, er ikke en hændelse, der kan opfattes af triggeropsættet på filerne. Det er derfor nødvendigt en gang dagligt at redisponere alle varer. Dette gøres vha. applikation 'Redisponer alle varer' (6294). Salgspriser og rabatter For at give et godt overblik over salgspris- og rabattilsætningen i ASPECT4 Logistik har vi valgt her at udarbejde en total beskrivelse af mulighederne for styring af priser og rabatter. Det er således ikke kun nye muligheder, der er beskrevet her. Styring af salgspriser og rabatter omfatter: Administration af prisoplysninger og prisbetingelser Formidling af prisoplysninger og prisbetingelser Fremfinding af gældende priser og prisbetingelser ved oprettelse af ordrer Dokumentation af eventuelle afvigelsessituationer Blandt faciliteterne til ovennævnte opgaver kan bl.a. nævnes: En vare kan optræde på flere forskellige prislister En prisliste kan findes i flere forskellige valutaer Prislister kan tidsbegrænses Kunder kan tilknyttes en bestemt prisliste En prisliste kan begrænses til en enkelt kunde Der kan opereres med såvel priser som rabatter Der kan opereres med kvantumsafhængige priser og rabatter Der kan opereres med variantafhængige priser Særskilt finanskontering af de enkelte priselementer Definitioner I ASPECT4 Logistik opererer vi med flere begreber under den overskrift, der hedder Salgspriser og rabatter. Der er grundlæggende tale om følgende: Pris: Priser (basispriser) anvendes til beskrivelse af udgangspunkt for bestemmelse af salgspris. Dette udgangspunkt kan modificeres af tillæg/fradrag (korrektioner) på prissiden og/eller af afgivne rabatter. Rabat: Prisrabatter anvendes til beskrivelse af rabatter, der fratrækkes salgsprisen ved bestemmelse af nettopris. Rabatter specificeres altid selvstændigt og fremgår specificeret på tilbud, ordrebekræftelse og faktura. Prisrabatter i valuta adskiller sig fra prisrabatter i procent ved at beskrive rabatter som absolutte størrelser frem for relative procentsatser. Korrektion: Priskorrektioner anvendes til beskrivelse af eventuelle tillæg eller fradrag, der kan korrigere basisprisen. Det betyder, at korrektionen ikke fremtræder særskilt tilbud, ordrebekræftelse og faktura. Priskorrektioner i valuta adskiller sig fra priskorrektionerne i procent ved at beskrive tillæg eller fradrag som absolutte prisstørrelser frem for relative procentsatser. Totalrabat: En rabat, som gives for hele ordren. Denne angives på salgsordrehovedet og vil initieres med værdien fra kundens stamoplysninger. Den vil blive beregnet som en procent af ordrens total, dog reguleret for de priser, rabatter, korrek- 8

9 tioner og ordrelinjer, der er markeret, for at denne ikke medtages ved udregning af totalrabat. Kæderabat: At kunne håndtere rabatter, der ydes i flere niveauer. Rabataftaler kan beskrives i et vilkårligt antal niveauer. Det er således muligt at beskrive, hvornår en aftale "erstatter" en anden aftale, og hvornår den fundne aftale er "tillæg" til øvrige aftaler. Rabatberegning kan beskrives i flere detaljer, herunder hvilket "niveau" af nettobeløb rabatten skal beregnes af. F.eks. en rabataftale, der giver 10 % rabat, og en rabataftale der giver yderligere 5 %. I dette tilfælde ydes rabatten af det allerede rabatberegnede nettobeløb. Firmaparametre Følgende firmaparametre har indflydelse på salgspriser og rabatter. Rabataftale (RABATAFT) Stamdata Kundekartotek På en kundes stamdata er der følgende felter, der danner grundlaget for salgsprissætning og rabatgivning: Prissætningskundenummer er et nummer, der angives på kundeoplysningerne. Prissætningskundenummeret giver mulighed for at lade pris- og rabattildelingen være styret heraf. Herved bliver det fleksibelt, hvorledes man vil styre pristilsætningen for en kunde (ikke bundet til kunde eller debitor). Dette kundenummer kan evt. anvendes, hvis det f.eks. er en indkøbskæde, der er prisgivende. Niveau: Hvilket niveau rabataftalen er på. 0 er højeste niveau, og 9 er laveste. Rabataftale-ID: Grundlag for kontering - Rabataftale-ID anvendes til kontering af kæderabat Prislistenummer, der anvendes til at bestemme, hvilken pris kunden skal betale ved køb. Hvis feltet er 0 (nul), køber kunden til grundsalgspriser, og hvis det er 1 (et), køber kunden til prislistepriser. Normalsituationen er 1. Prisrabatkode angiver, om kunden må få prisrabat. Rabatgrundlag: Rabat, som tildeles manuelt på en given ordrelinje, overstyrer altid al anden rabatberegning. Dvs. at der f.eks. ikke samtidig tildeles linjen samlerabat. Dog er der mulighed for, at linjens kvantum kan indgå i det samlede kvantumsgrundlag, som anvendes ved fastlæggelse af samlerabatsatser for hele aftalen. Mængderabatkode angiver, om kunden må få mængderabat. Rabatgruppe: Kundens pris- og rabatgruppe. Kan sammenknytte kunder på en fælles prisliste. Blev anvendt, før prissætningskunde blev introduceret som begreb. Totalrabatprocent for kunde. Varekartotek På varens stamdata er der følgende felter, der danner grundlaget for salgsprissætning og rabatgivning: Rabatgruppe for varen ved salg. Gruppen på salgsvarens basisoplysninger anvendes ifm. tilsætning af korrektioner og rabatter. Herudover er der mulighed for at tilknytte varen et antal supplerende varerabatgrupper. Disse indgår kun ved rabatberegning (og altså ikke ved korrektionsberegning). Beregningsrækkefølge angives på systemparameter RABATVAR. Prisrabatkode angiver, om der ydes prisrabat på varen. Samlerabat: Angiver ved beregning af rabatter på gruppeniveau, om rabatten kun gælder for den enkelte ordrelinje, eller om denne omfatter alle ordrelinjer på ordren med den aktuelle varerabatgruppe og rabataftale. Enhedstype: Enhedstypen angiver, om enheden på den aktuelle aftale er en kvantumsenhed eller en beløbsenhed (valutakode). Hvis enheden er en kvantumsenhed, omregnes ordremængde til den angivne enhed ifm. rabatberegningen. Hvis enheden er en valutakode, er det ordrelinjens BRUTTOBELØB, der anvendes ved søgning efter evt. beløbsgrænser. Hvis der ikke er oprettet en aftale i ordrens valuta, kan en aftale i systemvaluta evt. anvendes. Se systemparameter SALGPRIS. Enhed: Den enhed (alternative enhed), som kvantumsgrænser angives i, i forbindelse med rabatter på den pågældende aftale. Hvis enheden er en valutakode, er grænserne beløbsgrænser i den pågældende valuta. Bemærk, at det er en ordrelinjes BRUTTOBELØB, der i så fald anvendes ved søgning efter beløbsgrænser. Mængderabatkode angiver, om der ydes mængderabat på varen. Info om næste kvantumsgrænse: Procentangivelse vedrørende information om yderligere rabatmulighed. Hvis der er mulighed for yderligere rabat, og det aktuelle kvantums- 9

10 grundlag er mindre end den angivne procent fra næste kvantumsgrænse, informeres ordrebehandleren. Dette sker i så fald, når linjebehandlingen afsluttes eller evt. på anfordring. Er værdien 0, gives ikke automatisk information. Manuel rabat: Rabat, som tildeles manuelt på en given ordrelinje, overstyrer altid al anden rabatberegning. Dvs. at der f.eks. ikke samtidig tildeles linjen samlerabat. Dog er der mulighed for, at linjens kvantum kan indgå i det samlede kvantumsgrundlag, som anvendes ved fastlæggelse af samlerabatsatser for hele aftalen. Håndteringskode: Alternativ prisgruppe anvendes ved opslag i prislisten, hvis søgning via den primære kundeprisog rabatgruppe ikke gav resultat. Håndteringskode der angiver hvorledes rabatten gives. Rabatten kan gives uafhængigt af andre rabatmuligheder inden for det aktuelle rabatniveau, eller kan alternativt erstatte andre grupper, som resulterer i en lavere sats. Endvidere kan man angive, om rabatten skal gives, hvis der er angivet en manuel pris på ordrelinjen. Rabatgrupper for varer (RABATVAR) Sekvensnummer: Angiver beregningssekvensnummer for rabataftalen. Ved beregning af salgsrabatter gennemløbes de enkelte rabataftaler i den her angivne rækkefølge. Næste sekvensnummer: Hvis der er givet rabat på den aktuelle rabataftale, kan rabat på en eller flere efterfølgende rabataftaler undertrykkes. Hvis næste sekvensnummer er større end nul (og større end aktuel beregningssekvensnummer), fortsætter efterfølgende rabatgivning fra det her angivne sekvensnummer. Pris- og rabatgrupper for kunder (RABATKUN) Totalrabat på varer i gruppen: Angivelse af, om der ved beregning af totalrabat (fakturarabat) skal medregnes linjer på varer i denne gruppe. EDI rabatkode: Den tilhørende rabatkode, der sendes via EDI. Salgsprissætning (SALGPRIS) Evt. alternativ prisgruppe: Alternativ prisgruppe anvendes ved opslag i prislisten, hvis søgning via den primære kundepris- og rabatgruppe ikke gav resultat. Det er herved muligt at anvende forskellige grupper til hhv. prissøgning og rabatsøgning. Dette er relevant, hvor der f.eks. arbejdes med relativt mange rabatmuligheder, men kun få prislister. Hvis alternativ prisgruppe er blank, søges ikke via denne gruppe. Rabatniveauoplysninger (RABATNIV) Her angives først, hvilke kombinationer der anvendes i salgsprissætningen: S-pris via kundenr.-varenr.: Angivelse af, om den aktuelle kombination anvendes i salgsprissætningen. S-pris via kundegrp.-varenr.: Angivelse af, om den aktuelle kombination anvendes i salgsprissætningen. S-pris via blank-varenr.: Angivelse af, om den aktuelle kombination anvendes i salgsprissætningen. Fuld variantspecifikation: Angivelse af, om salgsprissætning af variantvarer sker med fuld variantspecifikation. Tillæg/fradrag varianter: Angivelse af, om salgsprissætning af variantvarer sker med tillæg/fradrag for prisbestemmende dimension. 10

11 Salgspriskorrektion i valuta: Kode, som angiver, om - og i givet fald hvordan - salgspriskorrektion i valuta anvendes: 0: Salgspriskorrektion i valuta anvendes ikke 1: Salgspriskorrektion i valuta anvendes 2: Salgspriskorrektion i valuta anvendes, såfremt salgspriskorrektion i procent ikke findes Rabatsøgning i systemvaluta: Ved søgning efter salgsrabatter, hvor rabatgivningen er betinget af angivne beløbsgrænser, søges der primært efter rabatgrænser angivet i ordrens valuta. Hvis sådanne ikke findes, kan det her specificeres, at der alternativt skal søges efter grænser angivet i systemvaluta. Salgspriskorrektion i pct.: Kode, som angiver, om - og i givet fald hvordan - salgspriskorrektion i procent anvendes: 0: Salgspriskorrektion i procent anvendes ikke 1: Salgspriskorrektion i procent anvendes 2: Salgspriskorrektion i procent anvendes, såfremt salgspriskorrektion i valuta ikke findes Bemærk: For at undgå at der i dette tilfælde tildeles rabatter ud fra både aftaler i ordrevaluta og i systemvaluta, bør rabatreglerne opsættes sådan, at aftalen i systemvaluta gøres betinget af, at der ikke er fundet en aftale i ordrevaluta. Dette kan ske ved at anvende feltet 'Næste sekvensnummer' på systemparameter RABATVAR. Salgsrabat i valuta: Kode, som angiver, om - og i givet fald hvordan - salgsrabat i valuta anvendes: 0:Salgsrabat i valuta anvendes ikke 1: Salgsrabat i valuta anvendes 2: Salgsrabat i valuta anvendes, såfremt salgsrabat i procent ikke findes Bemærk endvidere, at omregning mellem valutaer altid sker til gældende kurs, og at rabatgrænser omregnet til ordrevaluta dermed indirekte kan variere fra gang til gang. Salgsstyring (MODUL-3) Salgsrabat i procent: Kode som angiver, om - og i givet fald hvordan - salgsrabat i procent anvendes: 0:Salgsrabat i procent anvendes ikke 1: Salgsrabat i procent anvendes 2: Salgsrabat i procent anvendes, såfremt salgsrabat i valuta ikke findes Basiskorrektionsnummer: Angivelse af eventuelt korrektionsnummer, som benyttes, såfremt der ikke findes salgspriskorrektion for pågældende salgsordrehovedprioritet. Prislisteanvendelse: Om prislistesystemet anvendes. Her angives, hvilke kombinationer der anvendes ved søgning efter salgspriskorrektioner og -rabatter. Kundeobjekttype: Om rekvirentkunde eller betalingskunde er bestemmende for prissætning. Såfremt der anvendes prissætningskunde, skal der angives rekvirentkunde. Prissætningsdato: Om ordreindgangsdato eller leveringstermin fungerer som default for prissætningsdato. Anvendes samlerabat: Om der anvendes samlerabat på varerabatgruppeniveau. 11

12 Øvrigt I dimensionskartoteket angives, om dimensionen og udfaldet er bestemmende for salgspris (J/N). Der er i denne struktur 3 typer af vareidentifikation: - Prissætning uden hensyn til variant (felter for variant lig blank). Stamdatavedligeholdelse Salgsbasispriser - Prissætning med fuld variantspecifikation. (Udfald for prisbestemmende variantdimension i relevante felter for variant, resterende lig blank). - Prissætning med tillæg/fradrag pr. variantdimension. (For hver prisbestemmende variantdimension angives hhv. dimension og udfald i de 2 første felter for variant, resterende lig blank). Fra dato: Dato, der angiver, hvorfra prislisten gælder. Gør det muligt at operere med flere udgaver af "samme" prisliste på samme tidspunkt. Ved prissætning er enten leveringsdato eller optagelsesdato afgørende for valg af prisliste. Denne prissætningsdato gemmes og vedligeholdes på ordrelinjen. Disse oplysninger anvendes til beskrivelse af udgangspunkt for bestemmelse af salgspris. Dette udgangspunkt kan modificeres af tillæg/fradrag på prissiden og/eller af afgivne rabatter. Prislisteidentifikation: Herved forstås den "pegepind" til prisliste, der kan skabes fra en kunde/ordre. I prislisteidentifikationen indgår: Kundeidenttype Kundeidentifikation Vareidentifikation Prisvarianttype Valuta Kundeidenttype anvendes til definition af, hvilken form for kundeidentifikation der anvendes: O = Objekt (Kundenummer) G = Gruppe (Kundepris- og rabatgruppe) I = Ingen kundeidentifikation (blank) Kundeidentifikation kan være: Kundenummer Kundepris- og rabatgruppe Blank Til dato:dato, der angiver, hvornår prislisten ikke længere er gyldig. En prisliste er gyldig, indtil en ny prisliste træder i kraft, eller indtil prislisten udløber. Udløbne prislister fungerer altså som om, de ikke eksisterer, uanset deres fra dato. Enhedspris: Pris pr. salgsenhed (pr. salgsprisangivelse). Kan evt. blive korrigeret med tillæg eller fradrag. Tilsvarende kan forskellige former for rabatter indvirke på den endelige nettopris. Mulighed for priskorrektion: Angiver, om den fundne salgspris må korrigeres af eventuelle tillæg/fradrag. Mulighed for salgsprisrabat: Angiver, om der må ydes salgsprisrabat i forhold til den fundne salgspris. En salgsprisrabat er en rabat beskrevet med kvantumsgrænse lig nul. Mulighed for mængderabat: Angiver, om der må ydes kvantumsrabat i forhold til den fundne salgspris. En kvantumsrabat er en rabat beskrevet med kvantumsgrænse forskellig fra nul. Mulighed for totalrabat: Angiver, om ordrelinjen må medregnes ved beregning af grundlag for en eventuel totalrabat. Vareidentifikation: Det er en grundlæggende forudsætning, at salgspriserne altid kan beskrives pr. varenummer. Der kan endog være behov for yderligere specifikation, såfremt virksomheden afsætter variantvarer. I vareidentifikationen indgår derfor: Varenummer Prisvarianttype (1, 2 eller 3) Variant (5 felter á 5 tegn) 12

13 Priskorrektion i valuta Vareidentifikationstype anvendes til definition af, hvilken form for vareidentifikation der anvendes. Følgende definitioner benyttes: O = Objekt (Varenummer) G = Gruppe (Rabatgruppe for varen ved salg) I = Ingen vareidentifikation (blank) Vareidentifikationen kan være: Varenummer Rabatgruppe for varen ved salg Blank Kvantumsgrænse: De angivne korrektioner gælder for køb fra og med denne kvantumsgrænse (bestilte salgsenheder). Ved køb af antal salgsenheder mindre end nederste kvantumsgrænse anvendes kvantumskorrektion ikke. Oplysningerne i dette kartotek anvendes til beskrivelse af eventuelle tillæg eller fradrag, der kan korrigere basissalgsprisen. Tillæg eller fradrag er generelt udtryk for afvigelsessituationer, som altid beskrives i forhold til og gælder for et helt salgsordrebilag. Tillæg eller fradrag kan være kommercielt betingede eller udtryk for en opnået kundeservice, f.eks. tillæg for særlig hurtig levering. Priskorrektioner i valuta adskiller sig fra priskorrektioner i procent ved at beskrive tillæg eller fradrag som absolutte prisstørrelser frem for relative procentsatser. Korrektionsnummer: Angivelse af, hvilket tillæg eller fradrag der skal beregnes i den pågældende situation. Ved beregning anvendes ordreprioritet på salgsordrehovedet. Prislisteidentifikation: Herved forstås den "pegepind" til prisliste, der kan skabes fra en kunde/ordre. I prislisteidentifikationen indgår: Kundeidenttype Kundeidentifikation Vareidentifikation Prisvarianttype Valuta Kundeidenttype anvendes til definition af, hvilken form for kundeidentifikation der anvendes: O = Objekt (Kundenummer) G = Gruppe (Kundepris- og rabatgruppe) I = Ingen kundeidentifikation (blank) Gyldig fra dato: Dato, der angiver, hvorfra prislisten gælder. Gør det muligt at operere med flere udgaver af "samme" prisliste på samme tidspunkt. Ved prissætning er enten leveringsdato eller optagelsesdato afgørende for valg af prisliste. Denne prissætningsdato gemmes og vedligeholdes på ordrelinjen. Udløbsdato: Dato, der angiver, hvornår prislisten ikke længere er gyldig. En prisliste er gyldig, indtil en ny prisliste træder i kraft, eller indtil prislisten udløber. Udløbne prislister fungerer altså som om, de ikke eksisterer, uanset deres fra dato. Priskorrektion: Tillæg (positiv) eller fradrag (negativ) pr. salgsenhed. Såfremt vareidentifikationstypen er varenummer, er korrektionerne pr. salgsprisangivelse ellers for 1 salgsenhed. Korrektionerne foretages for den fundne basissalgspris. Mulighed for salgsprisrabat: Angiver, om der må ydes salgsprisrabat i forhold til den fundne salgspris. En salgsprisrabat er en rabat beskrevet med kvantumsgrænse lig nul. Mulighed for mængderabat: Angiver, om der må ydes kvantumsrabat i forhold til den fundne salgspris. En kvantumsrabat er en rabat beskrevet med kvantumsgrænse forskellig fra nul. Mulighed for totalrabat: Angiver, om ordrelinjen må medregnes ved beregning af grundlag for en eventuel totalrabat. Kundeidentifikation kan være: Kundenummer Kundepris- og rabatgruppe Blank Vareidentifikation: I vareidentifikationen indgår: Vareidentifikationstype Vareidentifikationen 13

14 Priskorrektion i procent Datastrukturen følger den beskrevne i afsnit om prislister med følgende afvigelser: Rabataftale er tilføjet på recorden. Korrektionsnummer indgår ikke i recorden. Priskorrektion erstattes af Enhedsrabat. Mulighed for salgsprisrabat indgår ikke i recorden. Mulighed for mængderabat indgår ikke i recorden. Prisrabatter i procent Oplysningerne i dette kartotek tjener samme formål som priskorrektioner i valuta, blot opereres med procentsatser til beskrivelse af tillæg og fradrag. Datastrukturen følger den beskrevne i afsnit om prislister med følgende afvigelser: Valuta indgår ikke i recorden. Priskorrektion erstattes af Procentkorrektion. Prisrabatter i valuta Oplysningerne i dette kartotek tjener samme formål som salgsprisrabatter i valuta, blot opereres med procentsatser til beskrivelse af rabatten. Datastrukturen følger den beskrevne i afsnit om priskorrektioner med følgende afvigelser: Valuta indgår ikke i recorden. Enhedsrabat erstattes af Rabatprocent. Oplysningerne i dette kartotek anvendes til beskrivelse af eventuelle rabatter, der fratrækkes (tillægges) salgsprisen ved bestemmelse af nettopris. Rabatter specificeres altid selvstændigt og fremgår specificeret på tilbud, ordrebekræftelse og faktura. Rabatter i valuta adskiller sig fra rabatter i procent ved at beskrive rabatfradrag som absolutte prisstørrelser frem for relative procentsatser. 14

15 Regler og begrænsninger Nedenfor beskrives præcedens inden for de pris- og rabatelementer, der er introduceret i ovenstående afsnit. Beregningsrækkefølge Beregninger foregår selvstændigt og uafhængigt af hinanden i følgende trin: 1. Basispriser - salg 2. Priskorrektion i valuta/priskorrektion i procent 3. Prisrabatter i valuta/prisrabatter i procent I firmakartoteket (SALGPRIS) angives, hvorvidt Priskorrektion i valuta, Priskorrektion i procent, Prisrabatter i valuta og Prisrabatter i procent anvendes. Såfremt priskorrektion og/eller prisrabatter anvendes i såvel valuta som procent, angives endvidere søgerækkefølgen for disse. Reglen er så, at den "først fundne" anvendes til prisberegningen. Søgerækkefølge I hvert af ovenstående trin anvendes oplysninger fra kun én record. Den generelle rækkefølge for søgning er: 1. Kundenummer - Varenummer 2. Kundenummer - Varerabatgruppe 3. Kundenummer - SPACE 4. Kundepris- og rabatgruppe - Varenummer 5. Kundepris- og rabatgruppe - Varerabatgruppe 6. Kundepris- og rabatgruppe - Blank 7. Blank - Varenummer 8. Blank - Varerabatgruppe 9. Blank - Blank Ved varevarianter søges først efter en fuld variantspecifikation, derefter søges tillæg/fradrag pr. variantdimension. Ved hjælp af firmaparameter SALGPRIS kan søgerækkefølgen indskrænkes i forhold til ovenstående. Gyldighed Inden for ovennævnte 9 søgetrin findes gyldige oplysninger i forhold til en prissætningsdato. Den gældende (gyldige) record er karakteriseret ved, at der er tale om den seneste 'Gyldig fra dato', der dog ikke er senere end prissætningsdato - og samtidig må til dato ikke være tidligere end prissætningsdatoen. Begrænsninger i salgspriskorrektioner og rabatter I de enkelte beregningstrin kan der forekomme begrænsning af efterfølgende beregning af tillæg, fradrag eller rabatter. Et nej (N) har i denne forbindelse altid præcedens for et eventuelt efterfølgende ja (J) ved senere beregningstrin. Desuden skal der gøres opmærksom på følgende forhold: Hvis der på prisaftalen er sagt 'N' til linjerabatter, gælder dette for alle rabatgrupper Hvis der er angivet rabat på varenummerniveau, fremfindes ingen rabatter på varegruppeniveau Hvis blot en af evt. flere rabatmuligheder på varegruppeniveau angiver 'N' til totalrabat, overstyrer dette evt. andre rabatgruppers totalrabatangivelse Funktioner Arbejd med prislister Der vælges mellem basispriser, priskorrektioner og prisrabatter. Som forespørgsel er der også mulighed for at vise "komplette" prislister, hvor bruttopris, bruttopris efter priskorrektion og nettopris fremgår efter inddatering af kundenummer, varenummer, variantudfald, mængde, prissætningsdato og evt. korrektionsnummer. Der er mulighed for at kopiere. Der kan kopieres til anden gyldighedsdato eller prislisteidentifikation. Der kan foretages regulering af priser ved brug af angivet indeks. Der er endvidere mulighed for regulering af salgspriser med udgangspunkt i standardkostpris, simulationspris eller grundsalgspris. Ved udgangspunkt i standardkostpris eller grundsalgspris kan desuden vælges mellem nye eller gældende priser. Ved reguleringer kan varens avanceprocent, indeks og konstant tillæg anvendes. Endvidere angives regler for øreafrundinger. Udskriv prislister Der er mulighed for ved hjælp af en række parametre at få udskrevet prislister med en brugerbestemt udformning. Denne prisliste kan dels udskrives, dels dannes som en datafil, der kan videresendes til f.eks. dannelse af cdromkatalog, trykkeri eller anden viderebearbejdning. Arbejd med salgsordrer Prislisterne anvendes til at foreslå en enhedspris for den enkelte varelinje ved oprettelse af ordre, såfremt der ikke findes en specialaftale for vare-/kundekombinationen. Prissætningen foretages efter følgende regler for præcedens: Manuelt indtastet pris og rabat Specialaftalepris og rabat Prislistepris, korrektioner og rabat Grundsalgspris I ordrebehandlingen er det muligt at korrigere kundeprisog rabatgruppe samt prissætningsdato for en ordrelinje. Ordrebehandlingen har funktion til fremfinding af prisliste, salgspriskorrektion og salgsprisrabat på grundlag af evt. korrigerede ordrelinjeoplysninger som f.eks. prissætningsdato, bestilt antal mv. Ordrebehandlingen har endvidere en funktion til genbestemmelse af prislistepris, salgskorrektion og salgsprisrabat. Funktionen fungerer analogt til default ordrelinje, dvs. prissætningsdato ændres til oprettelsesdato/leveringstermin og kundepris-/rabatgruppe ændres til kundens stamoplysning herfor. Ordrebehandlingen har desuden en funktion til genstart af prissætning. Funktionen fungerer som ved ny ordrelinje, dvs. prissætningen udføres ud fra præcedensreglerne, der er anført ovenfor. 15

16 Fra den enkelte ordrelinje er det desuden muligt at arbejde med rabatlinjer. Det er som udgangspunkt de rabatlinjer, som er fundet i forbindelse med prissætning, der dokumenteres her, men det er muligt at redigere disse. For hver realiseret rabatmulighed vises en linje med sats og rabatgrundlag. Rabatlinjer kan evt. korrigeres. Der kan endvidere oprettes helt nye rabatlinjer. VIGTIGT: Beregning af nettorabatgrundlag sker efter linjenummerorden. Hvis mindst en linje ændres manuelt, sættes prisrabatkoden på salgsordrelinjen til 'R' (manuelt redigeret på rabatlinjeniveau). Rabatlinjer vil herefter ikke blive opdateret automatisk, selvom salgsordrelinjeoplysninger korrigeres. Økonomirapportering Økonomirapportering af varesalg omfatter varesalgsposteringerne: Varesalg til grundpris Salgspriskorrektion Totalrabat Linjerabat (delrabatter) Salgsprisdifference (forskellen mellem basispris og grundsalgspris) Vis kundeaftaler Som et 'Næste niveau' på kundestamoplysninger (applikation 6128) vises liste over kundeaftaleelementer. Listen omfatter records af følgende typer: Basissalgspris Korrektion i procent Korrektion i valuta Rabatter i procent Rabatter i valuta Totalrabat Bonus Pr. type kan man via 'Faste selektioner' vælge, hvilke aftaletyper der skal vises (O/G/I), eller om der evt. slet ikke skal vises records for typen. Endvidere kan der her angives en pr.-dato. Det bliver herved muligt at skelne mellem historiske, gældende og fremtidige aftaler. Denne parameter sættes altid til dags dato ved programstart. Vis kundeaftaler 16

17 Transportstyring Formålet med transportløsningen i ASPECT4 Logistik er at løse den interne styringsopgave, der er forbundet med planlægning af transport, gennemførelse af afsendelse samt opfølgning på, om transporten forløb som planlagt. Transportplanlægning Overvågning af transportbehov Transportløsningen i ASPECT4 Logistik retter sig udelukkende mod transport af terminsordrer (normale salgs- og lagerflytningsordrer). Transportløsningen i ASPECT4 Logistik indeholder ikke nogen egentlig rutestyring eller chartequeregnskab for en transportopgave. Hvis denne opgave skal være en del af løsningen, skal der integreres mod ASPECT4 Transport. Denne transportløsning indeholder ej heller nogle fornyede styringsmuligheder for returgods. Behov for omfordeling ja Flyt behovet til anden rute/dato nej Denne beskrivelse indeholder som følge af dette følgende afsnit: Bookning af transportør Bookingliste Hvorledes opstår et transportbehov? Automatisk oprettelse Manuel oprettelse Planlægning af en transport Ombookning Kommunikation med transportør om transportbehov vha. bookingliste Udtagelse af turnumre Gennemførelse af en transport Tilbagemelding af hvad der skal transporteres Dannelse af fragtbreve og pakkeetiketter Udskrift af fragtbreve Udskrift af pakkeetiketter Dannelse af transportindkøbsordrer Tilbageførsel af fragtindkøb Opfølgning på transport Fragtstatistik Fragtafvigelser Dialog med kunde Registrering af specialomkostnin - ger for transporten Behov for ombookning? nej Klargøring af afsendelsesdok. Lastning Følgeseddel Pakkeetiketter EDI fragtbrev + papir til bil Fragtbrevsoversigt En transportproces i en virksomhed kan typisk følge forløbet i det her viste flowchart. Færdigmelding af transporten Transportindkøbsordre Der kan forekomme afvigelser fra dette procesdiagram, uden at den grundlæggende funktionalitet ændres. Eksempelvis kan elementerne "Klargøring af afsendelsesdokumenter" og "Lastning" optræde som parallelle processer. Plukningen af varerne fremgår ikke af det viste procesdiagram, men forventes at forløbe parallelt med de første processer frem til "Klargøring af afsendelsesdokumenter". Forsendesesjournaler Fakturaregistrering Match på beløb? nej Godkendelse af faktura ja Slut 17

18 Hvorledes opstår et transportbehov? Et transportbehov kan i princippet opstå på mange måder. Grundlæggende opstår der et transportbehov, når en eller flere varer skal transporteres fra vores lager frem til en modtager. Det næste spørgsmål er så, hvornår kendes det præcise transportbehov, dvs. den mængde der skal transporteres til kunden, samt hvornår transporten skal finde sted. Svarene på disse spørgsmål kan være mangeartede og er helt sikkert forskellige fra virksomhed til virksomhed. Vel vidende at et præcist transportbehov kan opstå på mange forskellige tidspunkter i forskellige virksomheder, er EG også bevidst om, et der vil være en række kunder, der efterspørger c-løsninger inden for dette område. Automatisk oprettelse af transportbehov Vi har i ASPECT4 Logistik valgt, at et transportbehov kan opstå, når der dannes en forsendelsesjournal. Forsendelsesjournalen er det job, der styrer plukningen af varerne fra lageret. Hvis man i virksomheden kun udtager de beholdninger til pluk, der er allokeret, er der stor sikkerhed for, at det planlagte transportbehov også skal gennemføres. Det forudsættes, at der plukkes mod ordre eller mod kunde (samme kundenummer og leveringsadresse). Det automatiske transportbehov opstår, hvis man sætter triggerprogrammet ZTRGTRAL på filen RUTHREG. Triggerprogrammet styrer, at der oprettes et transportbehov svarende til forsendelsesjournalen (plukkejobbet). Transportbehovet dannes på datoen for forsendelsen, hvorfor det tilrådes at være rimelig præcis i valg af metodik, når datoen fastlægges på forsendelsesjournalen. Transportbehovet er ydermere adskilt på rutenummer, lagersted og leveringsmåde fra ordren. Som det fremgår af ovenstående, kan man forestille sig mange andre varianter af, hvorledes et transportbehov opstår. For nogle af disses vedkommende kan der indgås udviklingssamarbejder, for andres vedkommende vil det kræve c-løsninger. Et transportbehov tager naturligvis også sit udgangspunkt i salgsordrerne. Salgsordrerne har fået tilføjet en række nye felter for bedst muligt at kunne understøtte transportstyringen. Det drejer sig om: Transportkrav (eksempelvis behov for kran, størrelse af bil og lign.) Leveringstidspunkt Turnummer Hertil kommer, at forsendelsesplanlægningen i forvejen bygger på de afsendelsesmønstre, der fremgår af rutekalenderne i applikation 'Arbejd med rutekalender' (9174). Fremkomsttidspunktet hos kunden beregnes dels på basis af antal forsendelsesdage til kunden og leveringsmådens rutekalender. Valg af transportør styres udelukkende af transportplanlægningen, hvilket betyder, at evt. valg af transportør på terminsordren ikke tages i betragtning. Et automatisk oprettet transportbehov indeholder eksempelvis følgende informationer: Kundenummer og leveringsadresse Forsendelsesjournalnummer Antal paller, kolli, rumfang, bruttovægt og nettovægt Transportkrav, kundekrav samt leveringsklokkeslæt Længde, bredde og højde (den største fra varerne) Statuskode (følger statuskode fra forsendelsesjournalen) Hertil kommer at et transportbehov i dets levetid tilføjes oplysninger som: Antal forsendelsesenheder der er plukket Hensat fragt Styring af om der er udskrevet bookingliste til transportør De forskellige transportbehov grupperes i en række transportheadere. Disse oprettes automatisk, når der oprettes et nyt transportbehov. Nøglen til en samling af transportbehov (hoveder) er dato, rute, lagersted og leveringsmåde. Hovedet indeholder information, som f. eks: Antal ordrer, ordrelinjer Summerede transportantal (forsendelsesenheder) Lagersted (afgangssted) (defaultes ud fra systemparameter Rute) Klokkeslæt afgang (defaultes ud fra systemparameter Rute) Fragtleverandør/transportansvarlig (defaultes ud fra systemparameter Rute) Summeret antal paller, kolli, rumfang, bruttovægt og nettovægt Status 00 = oprettet 30 = plukning påbegyndt 60 = plukning fuldendt 80 = følgesedler, fragtbreve og pakkeetiketter udskrevet Manuel oprettelse af et transportbehov De virksomheder, der anvender transportplanlægning, vil typisk fra tid til anden have et behov for at kunne oprette et manuelt transportbehov. Dette vil typisk være på noget, som ikke plukkes fra lager. Der er mulighed for manuelt at oprette et transportbehov. Når man har dette behov, åbnes en række felter, der normalt ikke er åbne for redigering, således at man kan registrere de præcise transportoplysninger. 18

19 Planlægning af en transport Planlægningsopgaven for transportplanlægningen består dels i at optimere transporterne, dels i at kommunikere med transportørerne og slutteligt i at udtage turnumre (vil ikke blive anvendt i alle virksomheder). Ombookning I forbindelse med dannelse af forsendelsesjournaler dannes der, jf. ovenstående afsnit, et transportbehov. Hvis man i forbindelse med planlægning af transport har en række yderligere krav, der skal tilfredsstilles, som eksempelvis at bilerne i videst mulig omfang skal køre med fulde læs, vil der typisk være en opgave forbundet med at ombooke transportbehovene. Modsvarende kan man have et ønske om, at der kun må være en bil pr. transport. I sidstnævnte tilfælde vil man skulle flytte nogle af transportbehovene til andre dato-/ rutekombinationer. Der er ikke noget krav om, at ruterne skal være oprettet som stamdata. Dette giver planlæggeren den frihed, at han/hun eksempelvis kan flytte en række transportbehov til en helt ny og ukendt rute, der kun opstår den ene gang, grundet et specielt transportbehov. Denne arbejdsmetodik vil desuden typisk blive anvendt, hvis man har flere transporter til samme område, og disse eksempelvis skal fordeles på en række biler. Generelt gælder det, at har man flyttet et transportbehov til eksempelvis en anden rute, vil et yderligere matchende transportbehov (samme ordre) blive planlagt på same rute. I applikationen 'Arbejd med transportplanlægning' (6191) kendes ombookningsfunktionaliteten under begrebet 'Flyt linje'. Bookingliste Kommunikationen med transportørerne foretages vha. en bookingliste. Bookinglisten er tænkt til at dække det behov for information, som transportøren har for at kunne fremskaffe et passende antal biler (transportenheder) til løsning af transportopgaven. Bookinglisten kan udskrives vha. applikation 'Udskriv bookingliste' (6293). Det bemærkes, at denne ikke kan udskrives på papir, medmindre DocManager anvendes. Bookinglisten indeholder informationer om hvilke transporter, der er booket på en tur. Ud for hvert enkelt transportbehov fremgår leveringsadressen samt den forventede bruttovægt og det forventede volumen for transporten. Disse data er beregnet på basis af fragtinformationerne på varens salgsinformationer. Yderligere fremgår leveringsklokkeslæt, specielle transportkrav og kundekrav til transporten. Se eksemplet på næste side. Turnumre En række virksomheder ønsker at samle turene på turnumre. Der kan udtages et fælles turnummer for de transportbehov, der er samlet på en tur (kombination af dato/rute/lagersted/leveringsmåde). Turnummeret opdateres også på den tilhørende fakturaordre. Her kan det bl.a. anvendes til en samlet udskrift af de følgesedler, der måtte høre til turen. Turnummeret kan tillige anvendes i forbindelse med opfølgning på de faktiske fragtomkostninger. Turnummer tildeles ud fra bilagsnummerserie TU. Der er ikke noget krav om, at der skal udtages turnumre for at anvende transportplanlægningen i ASPECT4 Logistik. Turnummer skal dog udtages, hvis man ønsker en samlet udskrift af følgesedler til turen. Gennemførelse af en transport 19

20 Bookinglisten indeholder informationer om, hvilke transporter der er booket på en tur. Gennemførelsen af en transport består i at få registreret, hvad der er pakket til transporten, samt i at få kommunikeret til de forskellige interessenter i form af fragtbreve, pakkeetiketter, fragtbrevsoversigt og følgesedler. Hertil kommer, at transportindkøbet skal dannes. Tilbagemelding af hvad, der skal transporteres Da et transportbehov er direkte forbundet med plukkeopgaven et transportbehov pr. forsendelsesjournal - er det naturligt at registrere antallet af forsendelsesenheder pr. transportbehov. Formålet med denne type af registrering er at få et korrekt antal forsendelsesenheder (paller, kolli, bundt eller lignende) til fragtbrev og til dannelse af pakker og dermed udskrift af pakkeetiketter. Til styring af de forskellige forsendelsesenheder er der oprettet en ny systemparameter Pakketyper antalsfelter (FRTPANT). På denne systemparameter kan man oprette op til 10 forskellige forsendelsesenheder. Typiske forsendelsesenheder vil være palle, kolli, bundt eller lignende. Når man har afsluttet plukning af en forsendelsesjournal, vil man i forbindelse med gennemførelsen af journalen få et skærmbillede, i hvilket man kan registrere antallet af forsendelsesenheder, jf. de der er oprettet under systemparameteren Pakketyper antalsfelter (FRTPANT). antallet af pakkede forsendelsesenheder direkte i transportplanlægningen 'Arbejd med transportplanlægning' (6191). På systemparameteren Pakketyper antalsfelter (FRTPANT) kan man endvidere angive et varenummer, der skal faktureres kunden sammen med registrering af forsendelsesenheden (eksempelvis fakturering af EURpaller ved registrering af antal EUR-paller). Den her omtalte registrering af antallet af forsendelsesenheder må ikke forveksles med den "pluk og pak" funktionalitet, der i øvrigt findes i ASPECT4 Logistik. Den her form for registrering er overordnet og holder ikke styr på hvilke varer/beholdninger, der findes i de enkelte pakker. Modsvarende er registreringsopgaven ved denne type af overordnede tilbagemeldinger langt mindre ressourcekrævende end den tilsvarende registrering af hvilke beholdninger, der er i de enkelte pakker. Dannelse af fragtbreve og pakkeetiketter I forbindelse med afsendelse af de plukkede varer skal der normalt dannes fragtbreve og evt. pakker. Princippet bag dannelse af fragtbreve er, at der dannes et fragtbrev pr. leveringsadresse pr. kunde. Herved sikres, at flere ordrer leveret til samme kunde på samme leveringsadresse kommer til at optræde på et og samme fragtbrev. Herved sikres det, at de faktiske fragtomkostninger minimeres. Via referencestrukturen kan man finde vej enten fra ordren til fragtbrevet eller omvendt. Fragtbreve tildeles et fragtbrevsnummer ud fra systemparameter Fragtbrevsnumre opbygning (FRAGTMSK). Denne parameter styrer dels længden på fragtbrevsnummeret, dels nummertildelingen for fragtbrevsnummerets variable del. Der kan være forskellig opbygning af fragtbrevsnumre pr. transportør. Alternativet til at registrere antallet af pakker i forbindelse med afslutning af en forsendelsesjournal er at registrere Samtidig med at der dannes fragtbreve, dannes der pakker. Der dannes i princippet et pakkenummer pr. forsendelsesenhed, der er tilbagemeldt på de transportjobs, der samles på fragtbrevet. Hvis fragtleverandøren har mulighed for at 20