ASPECT4 Logistik Præsentation af release 9.0

Transkript

1 ASPECT4 Logistik Præsentation af release 9.0 Release 9.0 er første skridt mod at kunne erstatte ASPECT4 Handel. Den fokuserer på at gøre brug af den kendte teknologi og tilføre ny funktionalitet, der tilfører mere værdi i løsningerne med ASPECT4 Logistik. Både på den grafiske brugergrænseflade exposer og på anvendelsen af ASPECT4 BusinessConnector, hvor der er sket markante funktionsløft specielt med lanceringen af et Cockpit til exposer, som styrker anvendelsen af den grafiske brugergrænseflade. Release 9.0 indeholder også en række generelle større funktionalitetsforbedringer.

2 .

3 Indhold Generelt om ASPECT4 Logistik release Cockpit... 6 Funktionalitet... 6 Hvad er med i release Fremtidige forretningsgange... 8 Editering i liste... 8 Styring af farver og tekstattributer... 9 Opsætning Produktionsordresplit Rammeordrer Hvad er en rammeaftale Kundeaftalte minimumslagre Den enkelte rammeaftalelinje kan periodiseres Disponering ved afledte ordrer Disponering ved intern samhandel Forbedret afkaldsstyring Bedre opfølgningsmuligheder på ordrehierarkier Integration til salgsbudget Hurtig ordreregistrering Eksempel på hurtig ordreregistrering EDI via ASPECT4 BusinessConnector Den tekniske konfiguration Diverse funktionalitetsforbedringer Ændring i konteringsbeskrivelser Supplerende tekster i sprog DocManager og samlefaktura Defaults ved ordreoprettelse Synkrone adaptere Forespørgsel på finansposter Nye/ændrede funktioner Databaseændringer Implementeringsvejledning Forberedelse Modtagelse og installatio af pakker Miljøopsætning Opgradering af testmiljø Opgradering af driftsmiljø Opgradering af test-/driftsmiljø Bemærkninger

4

5 Generelt om ASPECT4 Logistik Release 9 Som varslet i efteråret 2004 skifter ASPECT4 Industri i forbindelse med frigivelse af release 9.0 navn til ASPECT4 Logistik. Navneskiftet skal markere en milepæl for produktet. ASPECT4 Logistik nu får en endnu større kundeportefølje end hidtil, da ASPECT4 Handel-kunderne for manges vedkommende allerede er i gang med en proces med at blive migreret over på ASPECT4 Logistik-løsningen. Ud over flere brugere på ASPECT4 Logistik vil der systemudviklingsmæssigt også ske positive ændringer, idet migreringsprojekterne vil tilføre ASPECT4 Logistik ny funktionalitet til glæde for eksisterende kunder på både ASPECT4 Industri og ASPECT4 Handel. Indholdet af release 9.0 er naturligvis præget af ovenstående, og ud fra en erkendelse af at migreringsprojekterne er en løbende proces, er release 9.0 da også tiltænkt som første skridt i forhold til fuldstændigt at kunne erstatte ASPECT4 Handel. Releasen fokuserer på at gøre brug af den kendte teknologi, og benytte teknologierne til at give kunderne endnu mere værdi i løsningerne med ASPECT4 Logistik. Her tænkes både på den grafiske brugergrænseflade exposer og på anvendelsen af ASPECT4 BusinessConnector, hvor der i indeværende release er sket markante funktionsløft. Specielt igennem lancering af et Cockpit til exposer er der nu endnu flere gode grunde til at anvende den grafiske brugergrænseflade. Release 9.0 indeholder også en række generelle større funktionalitetsforbedringer. Specielt er styringen af rammeordrer udvidet og forbedret væsentligt, men også en ny funktionalitet omkring hurtig ordreregistrering frigives. Funktionaliteter til at lave en opsplitning af produktionsordrer i flere delprocesser samt en række mindre funktionsforbedringer er også indeholdt i ASPECT4 Logistik release 9.0. De foreløbige installationer af release 9 hos forskellige kunder har alle vist, at de tiltag, der er gjort for til stadighed at højne kvalitetsniveuaet i ASPECT4 Logistik, har givet de forventede resultater. Implementeringen af releasen har vist sig at kunnne foretages effektivt og med et godt resultat. God fornøjelse med ASPECT4 Logistik relase 9. 5

6 Cockpit Et for ASPECT4 Logistik nyt begreb er skabt i forbindelse med release 9 - Cockpittet. Begrebet er anvendt for at give associationer til pilotens komplekse verden, hvor en hel række meget forskelligartede informationer skal kunne fremfindes hurtigt og fleksibelt. Cockpit-applikationer anvendes til at samle applikationer i et overblikscockpit i exposer. Herved opnås, at flere applikationer kommer til at fremstå som én applikation. Det giver dels brugeren en oplevelse af et dynamisk skærmbillede med hensigtsmæssig præsentation af forskelligartede data og dels en enestående fleksibilitet, idet der kan udvikles enkeltstående, uafhængige applikationer, som gennem cockpittet kan indgå i en kompleks sammenhæng. Et eksempel på et ordrecockpit er vist herunder, hvor der er sammenstykket et cockpit ud fra en række forskellige applikationer. Der er sammenhæng imellem de respektive applikationer - i eksemplet er der en salgsordre med tilhørende ordrelinjer i sydvest-applikationen. I sydøstapplikationen er der lavet en opsætning, der tillader, at varebilledet bliver vist i sammenhæng med ordrelinjen. Funktionalitet I applikationsafhængige data til cockpittet angives, hvilke applikationer der skal være i hvilke dele af skærmen. Der anvendes forbogstaver i de engelske verdenshjørnebetegnelser til at angive placeringen på skærmen - dvs. N(orth), E(ast), S(outh) og W(est). Den første angivelse deler skærmen i 2 dele horisontalt eller vertikalt. Denne opdeling kaldes efterfølgende frames. De enkelte frames kan også opdeles i nye frames enten nord-syd eller øst-vest. Nogle eksempler på opdelinger vises på næste side. øst-vest. Begge dimensioner kan ikke forekomme samtidigt (dvs. der kan kun angives skillelinjer og ikke krydser). Skillelinjernes placering inden for det frame, de deler, kan bestemmes af den enkelte bruger ved at trække i skillelinjerne. Hvis flere applikationer angives til at ligge i samme frame, vil de enkelte applikationer komme som faner inden for framet. I tillæg til hver enkelt applikation og dennes placering angives Master, Slave og Reaktivitet. Der kan benyttes op til 5 verdenshjørneangivelser. Hver angivelse deler den foregående angivelse i nord-syd eller Applikationer med en given Slave-kode vil blive synkroniseret med applikationer, der har den samme kode som 6

7 De enkelte frames kan opdeles i nye frames enten nord-syd eller øst-vest. Som en særlig kode kan angives en *. Hvis den står som Master, betyder det, at alle øvrige frames bliver opfrisket, hver gang der sker en handling i den aktuelle applikation. Hvis den står som Slave, betyder det, at framen bliver opfrisket, hver gang der sker en handling i hvilken som helst af de øvrige applikationer. Blank i Master eller Slave opfattes som ingen kode. Dvs. applikationer med blank Slave-kode opfriskes kun af applikationen selv. Mens applikationer med blank Master-kode ikke foranlediger, at andre applikationer opdateres. I enkelte situationer kan det være nødvendigt, at flere applikationer med samme Slave-kode opfriskes i en bestemt rækkefølge. Det kan styres ved at angive applikationerne i den ønskede rækkefølge i applikation 0128 parametrene. Applikationerne startes og opfriskes i denne rækkefølge. En anden og mere sikker metode er at give applikationerne forskellige koder, idet en opfriskning af en applikation efterfølgende giver afledte opfriskninger ud fra applikationens Master-kode. Det skal bemærkes, at den initielle visning ikke tager hensyn til Master- og Slave-koderne, idet alle applikationerne da kaldes i den rækkefølge, de angives i applikation Rækkefølgen af applikationer i faner i samme frame styres ligeledes af den rækkefølge, de angives i applikation Det er de 3 koder, der betyder, at sammenstillingen af forskellige applikationer i frames kommer til at virke som en samlet enhed for brugeren. Det skal her understreges, at afledte opfriskninger tager tid/performance. Der bør derfor kun angives de nødvendige koder. De enkelte applikationer kan ikke afsluttes. De vil således altid blive stående på øverste niveau, indtil cockpittet lukkes. Hvis en batchapplikation angives som en del af cockpittet, vil opstartsbilledet vises igen, efter at applikationen er udført. Tilsvarende vil Afslut (F3) i en underapplikation ikke afslutte det øverste niveau. Master. Det betyder, at hvis der ændres i Master-applikationen, vil Slave-applikationers frame blive opfrisket. Opfriskningen sker som udgangspunkt først, når kontrollen kommer tilbage til cockpittet, dvs. det er efter, at handlingen er udført, og eventuelle vinduer er lukket. Det kan ændres ved at angive 5 som Reaktivitet. Et 5-tal betyder, at opfriskningen sker, så snart en linje i et listebillede er selected dvs. har fokus. Der kan godt være flere applikationer, der har samme Master-kode, ligesom en given applikation kan have samme Master- og Slave-kode. Hvis fx 3 applikationer alle har Z som både Master og Slave, vil de 2 øvrige applikationer blive opdateret, uanset hvilken af de 3 applikationer der ændres i. Hvad er med i release 9 Det skal her understreges, at cockpit-funktionaliteten er et udviklingsværktøj. De fleste applikationer vil umiddelbart kunne afvikles i et cockpit, og cockpits er derfor velegnede til prototyping. Det kan forventes, at det ved nærmere analyse typisk vil være nødvendigt med nogle justeringer af applikationer, for at de helt rammer målet i cockpittet. Disse justeringer vil langt hen ad vejen være af opsætningsmæssig karakter, men der kan også være behov for noget målretttet applikationsudvikling. Det betyder også, at EDB Gruppen ikke garanterer, at alle applikationer eller alle funktioner i en given applikation, vil virke i et cockpit. Det betyder, at der ikke accepteres fejlmeddelelser på en applikation, såfremt den ikke virker ved afvikling i et cockpit. På nuværende tidspunkt er der ikke lavet nogen standardapplikationer, som er cockpits. Dette vil formodentligt ske i kommende releases, og såfremt disse er fejlbehæftede, kan de selvfølgelig fejlmeldes. 7

8 For at kunne afvikle cockpits kræves et modul, hvor der er et kampagnetilbud, som inkluderer dette modul uden beregning, såfremt kunden inden den 31. august 2005 har indgået aftale om releaseløft til rel. 9. Release 9 behøver ikke at være i drift inden denne dato, men der skal blot være indgået aftale om releaseløft inden. anvendte vare (fundet ved LDA-nøglefeltet). Det er præcis den applikation, der er i det ovenfor viste eksempel. Det er hensigten, at der med cockpit-tankegangen åbnes for en nytænkning i applikationsudviklingen. Sammen med faciliteter med direkte opdatering af enkeltfelter og inddatering i lister skabes der baggrund for ny arkitektur. Fremtidige forretningsgange Cockpit-funktionaliteten vil fremover kunne foranledige, at der udvikles endnu simplere applikationer, som selvstændigt har begrænset eller ingen værdi, men som vil være målrettet til anvendelse i et cockpit. Et simpelt eksempel herpå er en applikation, der viser et billede af den senest Der er mange muligheder i Cockpittets overbliksskabende funktionalitet: samling af flere applikationer, såsom vareoprettelse i ét skærmbillede, overvågning i produktionen ved sammenstilling af et antal relevante applikationer, et varecockpit med billeder og links til leverandørens produktspecifikation og mange andre muligheder. Det er faktisk fantasien, der hurtigt kan blive den begrænsende faktor, og ikke som hidtil teknologien. Editering i liste I exposer er der nu åbnet en generel mulighed for, at felter kan editeres direkte i listebilledet. Hvorvidt det er muligt, kan sættes op via applikation 9169, hvor der i forvejen er opsat, hvilke felter der kan inddateres i feltbilledet. I release 9 er muligheden kun i begrænset omfang anvendt i applikationer, men det forventes udbygget i senere releases. I nogle tilfælde vil man bare kunne åbne for editeringen, men når det ikke er gjort generelt, skyldes det, at den i en del tilfælde er sådan, at et felt ikke altid er åbent for indtastning. Fx vil felter på en ordre typisk kun være åbne for indtastning, hvis ordren ikke er lukket. Denne logik vil ikke umiddelbart slå igennem i listebillederne. Dog kan man ved hjælp af faciliteterne omkring Styring af farver og tekstattributter lave en tilsvarende logik uden at skulle rette i programmerne. Kode 2 medfører således, at recorden opdateres, så snart feltet forlades, og ikke først når rækken forlades. Det giver mulighed for at styre betinget åbning/lukning af felter samt fremfinding af defaultværdier afhængig af skift af koder m.m. I releasepunktet Hurtig ordreregistrering bliver Editering i lister anvendt for derigennem at opnå en lettere tilgængelig ordreregistrering, når man kan taste de primære oplysninger direkte i listebilledet. Felter, der er editerbare i lister, fremstår typisk med hvid baggrund, mens de ikke editerbare typisk fremstår i nuancer af grå. Generelt bliver en record opdateret, når fokus flyttes væk fra den linje, man taster i. Det betyder, at hvis der fx er 3 åbne felter i en række, så kan man taste i alle 3 felter, før recorden opdateres. Koden for editering i lister kan imidlertid sættes til 3 værdier: 0: Ikke editerbar 1: Editerbar 2: Editerbar og straks opdatering Det nu er muligt at inddatere umiddelbart fra listebilledet. Det gør inddateringen af fx nye priser væsentlig hurtigere. 8

9 Styring af farver og tekstattributter Der er åbnet for en styring af farver og forskellige attributter på felter i exposer. Det gør det muligt at opsætte skærmbillederne, så man som bruger hurtigt kan danne sig et intuitivt overblik. Forskellige farvemarkeringer giver i højere grad mulighed for at fokusere på det væsentlige. Man vil ofte her anvende farverne fra trafiklys til at indikere godt/dårligt/fare/advarsel, da farverne grøn, gul og rød umiddelbart opfattes sådan af de fleste. Markering af felter med ikoner Der findes et standardudvalg af ikoner, der kan anvendes til at sætte foran feltværdier. Styringen kan i de fleste tilfælde ske uden programmering. Kun i de tilfælde, hvor markeringerne ikke kan dannes på baggrund af data fra den record, det vedrører, kan det blive nødvendigt med kald til nogle programlogikker, men det sker i givet fald uden at ændre standardprogrammet. Styringerne kan dels lægges på recordniveau og dels på feltniveau. Styringer på recordniveau vil dække alle felter på recorden. Man kan på denne måde fx farve en hel række grøn. Ud over styring af visuelle indtryk kan feltstyringerne også anvendes til en logisk styring i applikationerne. Man kan lukke for editering af et felt eller helt skjule det, afhængigt af værdier af andre felter. Man kan ændre default-placering af fokus, så cursor ikke står i første indtastningsfelt, når feltbilledet vises, og man kan få vist et billede eller en webside i stedet for et felt. I det følgende gennemgås, hvad der kan styres. Farver Der kan dels angives tekstfarver, og dels angives baggrundsfarver. Skriftstørrelse På feltbilleder kan man ændre skriftstørrelsen. I eksemplet er der samtidig anvendt en anden skriftfarve. Editering og skjul felter Typisk betinget af værdier af andre felter kan man lukke for editering eller evt. helt skjule felter. Typisk vil statusværdier være anvendt i betingelser. Fokus Som udgangspunkt sættes fokus i det første indtastningsfelt, men det kan man overstyre, så det bedre passer den optimale arbejdsgang. Billeder I stedet for værdien af et felt kan man få vist et billede. I overstyringen angiver man stien til billedet. Stien kan være sammensat af fast del og feltværdier (fx et varenummer). Som en del af stien kan man referere til en fast stiangivelse fra Arbejd med pc-stier (9187). Her skal man være opmærksom på, at det ikke er en god ide at anvende rød baggrundsfarve, da den bruges systemmæssigt til at indikere fejl. Skriftform Man kan angive, at skriften skal være fed og/eller kursiv. Websider På samme måde som ved billeder kan man i stedet for værdien af et felt få vist en webside. Det sker ved, at man i overstyringen angiver en URL. URL en kan være direkte fra et felt eller være delvist sammenstykket med en fast del. 9

10 Opsætning På record- eller feltniveau angives en feltstyringsident. Opsætning af indholdet af feltstyringsidenten sker direkte i F4 fra det pågældende felt i applikation Følgende muligheder findes: Ident Beskrivelse Gyldigt beregningsudtryk *BCOLOR Angiver baggrundsfarve, som Navnet skal findes på indholdet skal vises med. systemparameter COLOR (ny) *BOLD Angiver om indholdet vises med yes; no fed skrift. *CASE Styrer om der kan tastes store upper; lower; mixed og/eller små bogstaver i feltet. F4-applikationen viser kun feltstyringsidenter, der kan anvendes på den pågældende fil. Hvis der er referencer til felter, som ikke er i fildefinitionen, kan den således ikke anvendes her. Tilsvarende vil man ved specifikationen af feltstyringsidenten ikke kunne referere til felter, der ikke findes i den pågældende fildefinition. Til den enkelte overstyring angives en anvendelseskode, som angiver, om overstyringen skal gælde lister, feltbilleder eller alle steder. Attributterne *HIDDEN og *EDIT tager dog ikke hensyn til anvendelseskoden de vil altid gælde alle steder. Desuden vil de ikke kunne gøres lempeligere, end programmet har sat dem til. Dvs. der kan ikke åbnes felter, som programmet har lukket (gælder jo bl.a. visning og key-felter ved redigering). Et felt kan ligeledes heller ikke gøres synligt, hvis programmet har skjult det. Desuden angives en prioritet, som har betydning, hvis den samme attribut bliver angivet flere gange fx både på recordniveau og på et felt. *EDIT Åbent for editering. yes; no *EXEC Angiver at en anden feltstyrings- Skal findes i FSIDREG ident skal udføres. Det giver mulighed for at kæde flere styringer sammen. *FOCUS Sætter fokus i et givet felt. yes; no *ICON Angiver navnet på en ikon, som skal Navnet skal findes på vises sammen med værdien. systemparameter ICON (ny) På feltbilleder kommer ikonen til at stå efter indtastningsfeltet. *ICONRPL Angiver navnet på en ikon, som skal Navnet skal findes på vises i stedet for værdien. systemparameter ICON (ny) Hvis feltværdien indeholder en URL, vil man på feltbilleder kunne trykke på ikonen og få udført URL en. *IMAGE Angiver sti til billede, som skal Sti. Funktionen vises i stedet for værdien. PATH(<path>) kan anvendes til at sætte en del af stien. *GOTO Angiver at logikken skal fortsætte Linjenummer med det linjenummer, der er større end eller lig med linjenummeret angivet som resultat *HIDDEN Angiver om feltet skal vises. yes; no *ITALIC Angiver om indholdet vises med kursiv. yes; no I betingelsen kan 2 værdier sammenlignes. Som sammenligningsoperator kan anvendes >, <, =, >=, <= og <>. Der kan angives sammensatte udtryk med anvendelse af AND og OR, men der kan ikke anvendes parenteser. Som sammenligningsværdier kan angives variable, felter fra recorden eller konstanter. Alfanumeriske konstanter angives med omkring (fx ABC ). Felter fra recorden refereres med feltets feltnavn. Der skal være mindst 1 blank mellem hvert felt og operator (fx 1<2 er ikke lovligt, mens 1 < 2 er). *LINK Angiver URL, der skal udføres. URL. Funktionen PATH(<path>) kan evt. anvendes til at sætte en del af stien. *ONEXIT Angiver, at en editering skal sende yes; no data tilbage til programmet, så snart feltet forlades. *SIZE Angiver fontstørrelse. Der kan Absolut eller relativ angives relative værdier (fx +2 ), værdi hvilket anbefales, da brugerne har forskellig default fontstørrelse. Ændring af size supporteres ikke p.t. i tabeller.. *TCOLOR Angiver tekstfarve, som indholdet Navnet skal findes på skal vises med. systemparameter COLOR (ny) &vvvvvvvv Navnet på en hjælpevariabel Variablens værdi. (variablen skal ikke defineres Hvis værdien er numerisk, andre steder). bliver variablen numerisk, og ellers alfanumerisk. 10

11 Funktionen SUBSTR kan anvendes til at referere til dele af en streng på formen SUBSTR (<ident>,<start>,<længde>), hvor <ident> skal være en variabel eller et feltnavn. Funktionen CHAR kan anvendes til at omdanne et tal til en alfanumerisk streng. Syntaksen er CHAR (<ident>,<længde>), hvor <ident> kan være en numerisk variabel eller feltnavn. I beregningsudtrykket kan anvendes de samme funktioner, som ved betingelser. Karakterværdier kan sammensættes med + imellem. Herudover kan der som beregning i stedet angives et programkald med funktionen CALLPGM, som skal returnere den ønskede værdi. Dette kan anvendes, hvor ovennævnte funktionalitet ikke er tilstrækkelig. Programkaldet angives på følgende form: CALLPGM(<program>,<parm1>,...,<parm9>) hvor <parm>-værdierne dog kan udelades. Dvs. der kan overføres fra 0 til 9 parametre. Som parameterværdier kan angives konstanter, felter og variable. Der findes en rammesource ZCPRAMME til COBOL, der er et simpelt eksempel på et sådant program. Der findes en standardvariabel med navnet $FIELD. Den indeholder navnet på det felt, som det skal gælde for. Hvis det kommer fra STFRATTRID, vil variablen indeholde værdien *ALL. Værdien af LDA-nøglefelter kan refereres med de navne, der fremgår af fildefinitionen til WLDANGL Disse feltnavne begynder altid med *LDA. Anvendelse af LDAnøglefelter i stedet for de egentlige feltnavne gør det lettere at anvende den samme feltstyringsident for flere fildefinitioner. I feltnavne kan indgå wildcards i form af spørgsmålstegn. Man kan fx referere til????recsts for recordstatus på den aktuelle record. Produktionsordresplit Funktionen operationssplit anvendes til at skabe et parallelt slutforløb på en produktionsordre, således at man kan opdele en produktionsordre i flere parallelle forløb, der kan planlægges uafhængigt af hinanden. Et praktisk eksempel, hvor dette kan anvendes, er til hurtigt at færdiggøre en del af produktionen til en kunde, hvis denne pludselig har fået behov for hurtigt at få leveret en del af ordren. Split af en ordre medfører således, at der bliver 2 (eller flere) udgående lagervarer med beordringsvaren. Et eksempel er vist nedenfor til illustration af funktionalitetens formål. Situation før split: 11

12 Der foretages split på proces 0020 ordreforløbet ser herefter således ud: Løsning Funktionen implementeres i følgende applikationer: Arbejd med produktionsordrer (8102) Arbejd med produktionsordreforslag (8103) Arbejd med serviceordrer (8114) Arbejd med serviceordreforslag (8115) Tilføjelsen sker i form af tilføjelse af nyt valg Split proces (22). Operationsnummer: Visning af processens operationsnummer Planlagt procesresultat (M1): Visning af planlagt procesresultat Tilbagemeldt procesresultat: Visning af evt. allerede tilbagemeldt resultat (gode) på processen Procesresultat ny proces (M2): Her indtastes den mængde, som det parallelle forløb skal starte med. Defaultes med planlagt tilbagemeldt. Det valideres, at indtastet mængde > 0 og <= M1. Følgende krav skal være opfyldt, for at der kan foretages split på en operation: Det må ikke være den første proces på ordren Der må ikke være tilgange til forløbet fra operationer, der ligger parallelt til den operation, som man splitter på. Med andre ord processer, der ligger efter splitprocessen, må kun have en indgående flowvare Opfyldes ovenstående krav, vil brugeren blive præsenteret for et skærmbillede med følgende felter: Angiver brugeren en splitmængde, vil der fra og med den aktuelle operation blive dannet et parallelforløb indeholdende alle de resterende processer som kopi af eksisterende forløb. Produktionsordretekster, alternative procesenheder, materialereferencer kopieres, og evt. underleverandørindkøbsordrelinje(r) oprettes for nye underleverandørprocesser. Efter kopiering af forløbet korrigeres automatisk både det nye og det gamle forløb, således at mængder på processerne passer med det anfordrede. Denne korrektion svarer 12

13 til korrektion foretaget ved Korriger (13), hvor det planlagte procesresultat for den eksisterende proces er = M1-M2 og planlagt procesresultat for den nye proces er = M2. Der foretages også kopiering og efterfølgende justering af udgående flowvarer fra foregående proces(ser). Kalk.fordelingsprocent, Variabel mængde og Disponeret mængde korrigeres med forholdet mellem Disponeret procesmængde i alt før opsplitning og Disponeret procesmængde i alt efter opsplitning på den proces, som den udgående flowvare peger på. Har processen, der splittes, tilgang fra flere foregående operationer, håndteres dette ved, at der dannes flere flowvaresæt (et sæt pr. foregående operation). Færdigmeldinger på udgående flowvarer fra foregående proces(ser) flyttes over på nye udgående flowvarer ved samme faktor som ovennævnte (M2/M1). Dette sker ved tilbagemeldingskorrektioner af oprindelige tilbagemeldinger og oprettelse af nye tilbagemeldinger på ny(e) flowvarer. Disse tilbagemeldinger oprettes på nye tilbagemeldingsjournaler, der automatisk rekvireres til opdatering, når applikationen forlades. Øvrige tilbagemeldinger flyttes ikke over på det nye procesforløb. Proceslinjenumre for det nye procesforløb nummereres ved reglen: Største proceslinjenummer på ordren inden opsplitning + proceslinjenummer på den proces, der splittes. For såvel det oprindelige procesforløb som det nye procesforløb ændres udskrift af diverse produktionspapirer til Ja, såfremt disse papirer allerede er udskrevet. (Fx Jobkort antal = 1). På det nye procesforløb nulstilles endvidere Antal og Dato for disse produktionspapirer. (Fx Jobkort dato = ). Som udgangspunkt oprettes nyt procesforløb med samme status som oprindelige, dog således at status på det nye procesforløb aldrig bliver større end Igangsat (30). Processer på det nye procesforløb tilføjes oplysning om reference til den proceslinje, som processen er splittet fra. Denne oplysning er nødvendig af hensyn til, at underleverandørindkøbsordrer på det nye procesforløb skal tilføjes som ny linje på oprindelig underleverandørindkøbs-ordrer, i stedet for at der oprettes en ny indkøbsordre. Efter at split er gennemført, foretages efter behov manuel datering og evt. øvrige justeringer af det nye procesforløb. Evt. materialeallokeringer flyttes ikke automatisk over på nyt procesforløb. Efter behov skal der således foretages en manuel efterbehandling af disse. Efter at der er foretaget split, er det ikke muligt at slette det dannede parallelforløb automatisk. Manuelt kan forløbet slettes, og det oprindelige forløb kan korrigeres tilbage til den oprindelige mængde. Rammeordrer Indgåelse af kundeaftaler med en vis tidsmæssig udstrækning er grundlaget for oprettelse af en rammeordre. Rammeordrebegrebet har eksisteret igennem mange versioner af ASPECT4 Logistik, men i nærværende release er det valgt at ændre og udvide begrebet. Der er således foretaget væsentlige ændringer på en række nøgleområder: Hvad er en rammeaftale Kundeaftalte minimumslagre Den enkelte rammeaftalelinje kan periodiseres Disponering ved afledte ordrer Forbedret afkaldsstyring Bedre opfølgningsmuligheder på ordrehierarkier Integration til salgsbudget. Ændringerne er beskrevet i det efterfølgende. Det er muligt at bibeholde eksisterende funktionalitet igennem parametopsætning af systemparameter Modul 3 - Salgsstyring(MODUL-3). Tilsvarende vil den nye funktionalitet kunne aktiveres igennem systemparameter Modul 3 - Salgsstyring(MODUL-3). Hvad er en rammeaftale? I forbindelse med oprettelse af rammeordrer er det hensigtsmæssigt at kunne styre en række informationer, der ikke normalt hører til på en bestemt rammeordre. Denne type af informationer er samlet under rammeaftaler i applikation 6137 Arbejd med rammeordre aftaler. Ved hjælp af aftalen får man mulighed for at specificere, hvornår der skal advares (dage til udløb eller udnyttelsesgraden af aftalen), om der skal udskrives ny ordrebekræftelse i tilfælde af regulering, planlægningskalender til fordeling over tid af det forventede aftræk, hvor lang tid aftalen gælder, afkaldsmængder, pris/rabat-kode og overførselsoplysninger. Ved overførselsoplysninger forstås regler for, i hvilket omfang informationer skal overføres fra rammeordre til den ordretype, man har valgt at overføre til. En rammeordreaftale oprettes altid pr. kunde. På vareniveau man vælge, om reglen skal gælde pr. vare, varegruppe eller for alle varer 13

14 Kundeaftalte minimumslagre I forbindelse med oprettelse af rammeordreaftaler med kunderne har man mulighed for at oprette minimumsbeholdninger. Det er tanken, at man her kan dokumentere, hvis man har en aftale med kunden om altid at have mindst et bestemt antal på lager. Nogle virksomheder ønsker, at de kundebestemte minimumslagre skal tillægges varens minimumslager ved den almindelige disponering, hvorimod andre virksomheder ønsker, at de kundebestemte minimumslagre er en mere informativ information, der ikke skal disponeres efter. Hvorvidt kundeaftalte minimumslagre skal medregnes i disponeringen, bestemmes af systemparameter Produktions- og lagerstyringsparametre (STYKLIST). Den enkelte rammeaftalelinje kan periodiseres I en ny applikation (6137 Arbejd med Rammeordreaftaler ) kan der pr. kundenummer beskrives en række basisbetingelser, som kan anvendes ved oprettelse af rammeordrer. Oplysningerne, som kan angives på varenummer, varegruppe eller på generelt niveau, omfatter bl.a.: Afkaldsmængde (evt. overstyring af enhedsordrestørrelse fra varesalgsoplysninger) Advarsel - dage (advarsel når der er maks. et givet antal dage til aftalen udløber) Advarsel - periode/pct (advarsel når der er maks. en given procentdel af gyldighedsperioden tilbage) Advarsel - restmgd (advarsel når der er maks. en given restmængde tilbage) Advarsel - restmgd/pct (advarsel når der er maks. en given procentdel af aftalemængden tilbage) Planlægningskalender (til disponering: uge/månedsopdeling) Pris-/rabatkode (skal rammeordrens pris-/rabatbetingelser nedarves til afkaldsordren) 0: afkaldskundens pris-/rabatbetingelser anvendes altid (dvs. rammeordren vedrører kun styring af mængder) 1: betingelser nedarves, hvis kundenummer eller debitornummer svarer til rammeordrens kundenummer 9: betingelser nedarves altid Må ordrepriser efterreguleres Ny ordrebekræftelse ved regulering Ved oprettelse af en rammeordrelinje angives bl.a. leveringstermin, sluttermin og samlet kvantum. Ved oprettelse af ny linje sættes sluttermin lig med udløbsdato for aftalen. Leveringstermin tolkes som dato for første planlagte leverance, mens sluttermin tolkes som slutdato for sidste periode i leverancen. En dato på ordrehovedet angiver udløbsdato for hele rammeordren (alle linjer). Ved oprettelse af linjer valideres det, at sluttermin ikke ligger efter denne udløbsdato. Leveringstermin og sluttermin anvendes til at periodisere disponeringer. Der foretages ingen automatisk lukning af aftaler, selv om slutterminen overskrides. En sådan lukning kan evt. udføres ifm. udskrift af advarselsliste. Ved registrering/redigering ombrydes linjen i et antal periodiserede disponeringer. Dette sker iht. oplysning i aftalekartoteket. Hvis leveringstermin eksempelvis er , og sluttermin er , og planlægningskalenderen angiver månedsopdeling, vil der blive disponeret 1/12 af ordrelinjens kvantum til levering ved starten af hver kalendermåned i løbet af året. Ved Nedbryd afsætningsplan (8211) planlægges der iht. disse deldisponeringer. Som et næste niveau til rammeordrelinjen er det muligt at se og redigere de periodiserede disponeringer. Ordrebehandleren kan her disponere mængder og tidspunkter, men tidspunkterne skal ligge inden for den på ordrelinjen angivne periode. Når niveauet forlades, kontrolleres om totalmængden passer med ordrelinjemængden. Er dette ikke tilfældet, justeres de enkelte periodetal forholdsvist (dvs. det er altså tilstrækkeligt i første omgang blot at angive mængder som forholdstal). Ved evt. efterfølgende redigering af mængden på ordrelinjeniveau bevares den relative periodefordeling. Hvis perioden indskrænkes, flyttes de udenfor liggende disponeringer til periodens start- eller sluttermin. Hvis alle disponeringer slettes, foretages genberegning af disse (som ved nyoprettelse af ordrelinje). Disponering ved afledte ordrer Det er muligt at foretage produktions- og indkøbsmæssige disponeringer på grundlag af salgsrammeordrer. Selvom slutproduktion (fx montage) først gennemføres i forbindelse med, at en terminsordre planlægges (ved afkald på rammeordren), er det allerede ved oprettelse af rammesalgsordren muligt eksempelvis at indkøbe råmaterialer eller gennemføre indledende produktioner på mellemvareniveau. Dette illustreres med nedenstående eksempel. En deldisponering på 100 stk. af vare A på en rammeordrelinje (på i alt 1200 stk.) medfører automatisk oprettelse af et produktionsordreforslag på 100 stk. af samme vare. Dette forslag giver igen anledning til oprettelse af 2 afledte produktionsordreforslag på mellemvare B og C på hhv. 100 og 200 stk. Det ene produktionsordreforslag afleder et indkøbsordreforslag på vare D på 400 stk. (Der oprettes et sådant sæt af ordrer for hver deldisponering på rammeordrelinjen.) Oprettelse Det er herefter muligt at få igangsat indkøb og produktionsordrer på mellemvareniveau - PF02, PF03 og IF01 er alle blevet godkendt og gennemført. 14

15 Nedenfor illustreres situationen efter, at der er foretaget et afkald på 25 stk. Produktionsordreforslaget PF01 reduceres til restmængden på 75 stk. Afledte produktionsordrer ændres ikke, da disse i mellemtiden er gennemført. Der oprettes automatisk en egentlig produktionsordre på 25 stk. tilknyttet afkaldsordren (terminsordren). Der er her valgt en opsætning, som gør, at denne produktionsordre ikke danner afledte ordrer. Det forventes med andre ord, at mellemvarer nu er til rådighed (men andre ordrepolitikker kunne medføre, at der blev dannet afledte ordrer). Afkald rammeordrelinjer. Dette er for at imødekomme situationen, hvor man på den ene side gerne vil opbygge lidt mellemvarelager til dækning af senere leveringer på den konkrete rammeordre, men på den anden side ikke ønsker at overproducere, da mellemvarerne ikke vil kunne bruges til andet formål. Dette håndteres på følgende måde: Applikationerne 6241/6242 afvikles med en opsætning, der gør, at der for rammeordrer kun dannes afledte ordrer på det aktuelle behov (ingen lageropbygning). Der ses med andre ord her bort fra vareoplysningernes ordrestørrelsesangivelser. Når PO06 er færdigproduceret, kan TO02 overføres til fakturering. I dette eksempel kasseres 5 stk. ekstraordinært, hvilket medfører, at kun 20 stk. kan faktureres, mens de sidste 5 stk. resterer på terminsordren. Bemærk: Hvis terminsordremængden ændres, så den svarer til den faktisk producerede mængde, kan rammeordren tilbagejusteres (parameteropsætning), således at den afspejler den faktiske restlevering (80 stk.). Levering Trimning af, hvornår der skal dannes afledte ordrer, styres ved hjælp af den enkelte vares ordrepolitikkode samt opsætning og afvikling af Gennemføre afledte ordretransaktioner (6241/6242). Ordrepolitikkode kan eksempelvis være PO, som betyder, at der altid dannes en afledt produktionsordre, eller PD som betyder, at denne kun dannes, hvis der ikke er tilstrækkelig fri disponibel beholdning. Ved forskellige kald og opsætninger af 6241/6242 (og evt. anvendelse af kopiapplikationer) kan det sikres, at fx rammeordrer altid giver anledning til, at afledte produktionsordrer dannes som forslag, og at disse igen afleder forslag. En anden opsætning kan fx sikre, at terminsordrer giver anledning til oprettelse af egentlige produktionsordrer, og at disse ikke afleder yderligere ordrer. Med Sammenlægge produktionsordrer (ny applikation 8210) samles produktionsordrer. Ordrer på samme beordringsvarenummer samles her inden for afgrænsede perioder (uanset om disse er afledt af samme rammeordre). Det angives, om der pr. varenummer kun skal samles, indtil minimumsordrestørrelsen er opfyldt (flere ordrer inden for afgrænsningsperioden), eller om der skal samles til en ordre. I eksemplet ovenfor blev der disponeret 200 stk. af vare C (PF03) til dækning af behovet ved produktion af 100 stk. vare A (PF01). Der skal med andre ord bruges 2 stk. vare C til at producere 1 stk. vare A. Som beskrevet vil der hvis minimumsordrestørrelse og enhedsordrestørrelse på vare A er 1 blive planlagt i alt 12 produktionsordrer på vare A (En ordre pr. kalendermåned). Det samlede behov for vare C er altså stk. Når applikationerne 6241/6242 afvikles som ovenfor beskrevet, vil der derfor umiddelbart blive dannet 12 ordrer på vare C på hver 200 stk. (forudsat at der ikke er nogen fri disponibel beholdning). Efter afvikling af den nye applikation vil disse hvis varens minimumsordrestørrelse fx er 2000, og der skal dannes flere ordrer blive samlet til en ordre på stk. pr og 400 stk. pr Disponering ved intern samhandel Den i forrige afsnit beskrevne disponering kan også foretages, selvom produktion sker via et søsterfirma. Nedenstående eksempel illustrerer dette. I det ovenfor beskrevne eksempel dannes de afledte ordrer på netop den mængde, der skal til for at dække moderordren (minimumsordrestørrelse og enhedsordrestørrelse på varestamoplysninger er lig 1). Hvis varestamoplysningen tilsiger, at der skal dannes ordrer på en større mængde, vil dette umiddelbart ske. Der opbygges med andre ord evt. en fri disponibel lagerbeholdning på den mængde, der overstiger det umiddelbare behov. Når salgsrammeordren oprettes i Firma1, dannes der her automatisk en indkøbsrammeordre i samme firma. Denne spejles i en salgsrammeordre i Firma2, hvor den indledende produktionsforberedelse kan foretages som beskrevet i forrige afsnit. Oprettelse Når ordrer er afledt (direkte eller indirekte) fra en rammeordre, er der mulighed for at styre, at ordremængder på den afledte ordre ikke overstiger det samlede behov på 15

16 Der foretages nu et afkald på 25 stk., idet terminsordre TO02 oprettes. Dette medfører automatisk oprettelse af indkøbsordre IO02 i Firma1 og af terminsordre TO12 og produktionsordre PO12 i Firma2. Samtidig reduceres restmængden på RO01 og de heraf afledte ordrer i Firma1 og Firma2. Bemærk, at disse afledte ordrer altid kun vil afspejle ændringer i RO01 - der vil aldrig kunne overføres direkte fra disse til andre ordretyper. Afkald Hvis afkaldet overstiger restmængden på rammeordren, informeres ordrebehandleren Hvis priser/rabatter skal nedarves, overføres disse. Hvis prislistekode på rammeordren er 1, og kundenummer afviger fra rammeordrens kundenummer, sættes denne kode på afkaldsorden til en særlig værdi ( T ) Udvalgte ordrehovedoplysninger overføres evt. fra rammeordre til afkaldsordre (iht. systemparameter Rammeordrer overførselsparametre(soovfopl). Hvis en given ordre oprettes som afkald fra flere forskellige rammeordrer, vil det være ordrehovedoplysningerne fra den senest tilknyttede rammeordre, der er gældende. Som i forrige afsnit færdigmeldes kun 20 stk. fra produktionen. Dette medfører, at der dannes en fakturaordre FO13 i Firma2 (kunden er her Firma1, mens leveringsadressen er slutkundens). I Firma1 registreres denne fakturering automatisk (via applikation 7261), og der dannes ligeledes automatisk en fakturaordre FO03 til slutkunden. Levering Rammeordrelinjer, som er under nedskrivning, kan ikke slettes, og centrale oplysninger (varenummer, variantspecifikation mv.) kan ikke ændres. Linjer kan altid afsluttes (lukkes), selv om ordremængder ikke er fuldt leveret. Ved gennemførelse af afkald på en rammeordrelinje reduceres linjens deldisponeringer automatisk. Dette vil altid ske ved, at den/de kalendermæssigt tidligst placerede reduceres/slettes. Bedre opfølgningsmuligheder på ordrehierarkier Forbedret afkaldsstyring Afkaldsordrer oprettes manuelt. Dette kan enten ske ved: at der med udgangspunkt i en rammeordre overføres afkaldte mængder til en ordre af anden ordretype (typisk terminsordre), eller ved at der i forbindelse med oprettelse af ordrer med anden ordretype automatisk foretages nedskrivning af relevant rammeordre. Ved overførsel fra rammeordre (applikation 6106) er afkaldsordrens ordrehovedoplysninger (herunder kundenummer) identiske med rammeordens (svarende til gældende release). Nedskrivning af rammeordre kan ske automatisk ifm. med oprettelse af ordre af anden type på følgende måde: For hver ordrelinje kontrolleres om der er en rammeordrelinje, der opfylder gældende betingelser (vareoplysninger, kundeoplysninger, systemparametre mv.) for sammenføjning Til dokumentation af bl.a. status på afledte ordrer ( halvfabrikata ) er der udarbejdet en ny ordreoversigt, Udskriv disponeringsliste (6420). Denne tager udgangspunkt i salgsordrer og viser oplysninger fra disse samt afledte ordrer. Pr. salgsordrelinje vises alle afledte ordrer op til ønsket niveau. Hvis der er mere end en afledt ordre pr. salgsordrelinje, skrives oplysninger for disse på efterfølgende linjer. Resultatet af evt. materialetjek udskrives under den kontrollerede produktionsordre. Man kan vælge at udskrive en linje for alle komponenter eller kun linjer med kritiske komponenter. Integration til salgsbudget Blandt de nye funktionaliteter i rammeordrestyringen er også muligheden for at overføre rammeordrer til budget. Hvis man har længerevarende aftaler med sine kunder, og disse er dokumenteret som rammeordrer i ASPECT4 Logistik, vil det være oplagt at overføre dem til budget. Herved vil man få endnu en mulighed for at følge op på rammeaftalerne med kunderne. Er dette tilfældet, nedskrives rammeorden, og ordrereference dannes. Afhængig af opsætning i applikationsafhængige data kan man vælge, at ordrebehandleren først skal bekræfte, at den fremfundne ordre nedskrives. Ordrebehandleren kan i så fald vælge at acceptere nedskrivningen, at der søges videre efter evt. anden ordre, eller at nedskrivning helt undlades 16

17 Hurtig ordreregistrering Hos kunder med eksempelvis massesalg af dagligvarer er ordreregistrering ofte så krævende, at denne i første omgang noteres på papir, og efterfølgende indtastes i ASPECT4 Logistik. Dette skyldes ofte, at kunden kommer med ufuldstændige oplysninger, som først skal bearbejdes, og først herefter kan den systemmæssige ordreregistrering foretages. 1) Manuelt oprettede skabeloner I Arbejd med skabelonvarelister (6122) kan man ud fra falde igennem -princippet (også kendt som OGI-princippet) via kundeident enten kundenummer, kundegruppe eller generelt oprette manuelle skabeloner. Skabelonerne oprettes i systemparameteren skabelon(skabelon) med skabelontype 1, og også med koden for OGI-princippet. Til at afhjælpe ovenstående problematikker er der med inspiration fra ASPECT4 Handel udviklet en løsning, der har følgende formål: 1. At kunne registrere/redigere centrale ordrelinjeoplysninger i et listebillede 2. Ved ordreoprettelse at kunne inddatere i et antal blanke linjer 3. Oprettelse af nye linjer kan tage sit udgangspunkt i en foruddefineret skabelon 4. At forsyne ordrelinjer med nye informative oplysninger. Helt generelt er løsningen designet, udviklet og systemtestet imod den grafiske brugergrænseflade (exposer), og derfor ligger der en afgrænsning imod anvendelse af løsningen i 5250-emulering. Der er som sådan ikke gjort noget i udviklingsmæssig henseende for at hindre anvendelsen af 5250-emulering, men på den anden side er der ikke foretaget test imod 5250-emulering, hvorfor EDB Gruppen ikke anerkender eventuelle fejl i ASPECT4 Logistik med relation til hurtig ordreregistrering opstået som følge af brug af 5250-emulering. Ad 1 Muligheden for at redigere centrale oplysninger i et listebillede er beskrevet i afsnittet om editering i liste, og er derfor ikke beskrevet yderligere i nærværende afsnit. Ad 2 Til hurtigt at kunne inddatere ekstra ordrelinjer er der mulighed for at tilføje et antal foruddefinerede blanke linjer. De blanke linjer er knyttet til den skabelon, som man ønsker at arbejde i. Nedenfor er vist, hvordan opsætning af antal blanke linjer foretages. 2) Udvælg fakturaordre Idet man står i ordrelinjebilledet, kan man danne en skabelon fra tidligere fakturaordrer til kunden. Dette gøres ved at vælge den skabelon, der er oprettet som skabelontype 2 (vælg fakturaordre), hvorefter der fremkommer en oversigt over kundens fakturaordrer. Man kan så udvælge den, der skal anvendes som skabelon. Det er nok blot at oprette en skabelon i systemparametrene med denne skabelontype, da skabelonen kan benyttes til alle kunder. 3) Via sumkørsler Afvikling af Dan vareliste pr. kunde (E205) danner varelister pr. kunde. Denne kørsel kan eksempelvis sættes til at køre hver nat, således at varelisterne hele tiden er opdaterede. Ud fra filen er det muligt at danne følgende skabeloner pr. kunde: Senest købte varer (købsdato) skabelontype 3 Mest solgte varer (mængde) skabelontype 4 Mest solgte varer (beløb) skabelontype 5 Disse skabeloner dannes, idet man vælger at benytte dem i ordrelinjebilledet. Ad 4 Ordrelinjer forsynes med nye informative oplysninger: Fri disponibel beholdning Dato for fri disponibel beholdning (d.d. eller fremtidig dato) Eksempel på hurtig ordreregistrering For at give et samlet indtryk af mulighederne ved hurtig ordreregistrering er der nedenfor gennemgået et eksempel, som viser, hvordan typiske arbejdsgange kunne være i forbindelse med en hurtig ordreregistrering ud fra en manuelt oprettet skabelon. Stamdata Før hurtig ordreregistrering kan anvendes, er der følgende stamdata, der skal være på plads: Ad 3 Oprettelse af nye linjer skal kunne tage sit udgangspunkt i en foruddefineret skabelon. Der er mulighed for at danne skabeloner på tre måder: 1) Systemparameteren skabelon(skabelon) skal være udfyldt. Jf. tidligere beskrevet skal denne systemparameter være udfyldt. På systemparameteren skal det også angives, hvilken skabelontype der er tale om. I nærværende eksempel er det en manuelt oprettet skabelon. 17

18 2) Skabelonen skal tilknyttes den ønskede kunde. På stamdata til kundeoplysninger er der tilføjet en mulighed for at knytte en skabelon til kunden. Denne skabelon vil være default i forbindelse med ordreoprettelse. 3) Skabelonen skal være oprettet i Arbejd med skabelonvarelinjer (6122) På den manuelle skabelon tilknyttes varenumrene som illustreret i nedenstående skærmbillede. I eksemplet er der lavet et Cognac vinkatalog, hvortil der er tilknyttet tre forskellige cognacer. På grundlag af ovenstående er det muligt at lave hurtig ordreregistrering - et eksempel vises nedenfor. På den manuelle skabelon tilknyttes varenumrene Ordreregistreringen Til højre er vist et eksempel på skærmbilledet til hurtig ordreregistrering. Skabelonen hentes fra stamdata, og ordreregistreringen med åbne felter i listebilledet kan begynde. Som princip er det valgt, at der skal tages stilling til mængdefelter, således at der ikke af vanvare bliver udfyldt en ordrelinje. Det er muligt at inddatere i de tomme linjer på listebilledet, hvor også vanlig hentefunktionalitet (F4) kan benyttes. Efter endt inddatering ligger ordrelinjerne som kladdelinjer, hvilket kan ses ud fra recordtypen (kolonnen RT i skærmbilledet) på den enkelte ordrelinje. Efter endt inddatering skal de tomme linjer fjernes, hvilket gøres fra Selektionsskærmbilledet, hvor behandlingskoden angiver, at de tomme linjer skal fjernes. Efter at denne funktion er udført, vil kladdelinjerne være at betragte som almindelige ordrelinjer. Ønskes der tilføjelser til ordrer, eksempelvis gennem en anden skabelon, kan der hentes flere skabeloner ind via Selektion (F17), hvor der kan hentes flere skabeloner som kladdelinjer. Dette er ikke vist i skærmbilledet her til højre. 18

19 EDI via ASPECT4 BusinessConnector I forhold til den eksisterende EDI-løsning i ASPECT4 Logistik er der konceptuelt set sket en væsentlig udvikling. Hidtil har EDI-løsningen været baseret på AKS-moduler, hvilket har givet nogle begrænsninger. Fremadrettet vil EDIløsningen være baseret på ASPECT4 Business Connector, og de EDI-dokumenter, der ikke er omlagt fra AKS EDI til ASPECT4 BusinessConnector i indeværende release, forventes at blive omlagt i en kommende release. Dokumenterne, der er lagt om i forbindelse med release 9.0, er: Modtag ordre (ORDERS) Sende pakkeliste (DESADV-niveau 3) Sende faktura (INVOIC) Sende ordrebekræftelse (ORDRSP) Sende ordre (ORDERS) Modtage ordrebekræftelse (ORDSP) Modtag leverandørfaktura (INVOIC) Den tekniske konfiguration Figurerne herunder beskriver den overordnede tekniske løsning, der anvendes ved afsendelse af EDI-dokumenter. ASPECT4 Logistik føder informationen igennem relevante applikationer, og via supplerende EDI-informationer ( Arbejd med supplerende EDIinformationer (6198)) sendes EDI-meddelelsen ud til en logistikadapter. Denne adapter konverterer filen til XML ved anvendelse af felttabeller. Her giver felttabellerne, som er et generelt værktøj, mulighed for på fleksibel vis at opsætte den XML, der sendes ud i ASPECT4 BusinessConnector. Den yderligere h=åndtering er beskrevet i særskilte dokumenter omkring ASPECT4 BusinessConnector, hvorfor der henvises til disse dokumenter for yderligere information. Af ovenstående EDI-dokumenter fremgår det, at der er tale om et nyt dokument, og resten er omlægninger fra den eksisterende AKS EDI. Pakkelisten er udviklet, således at der kan afsendes en niveau 3 pakkeliste altså en pakkeliste i 3 niveauer, eksempelvis: Bil Palle Pakke De 3 niveauer er nødvendige for at kunne understøtte beskrivelse af anbrudte paller, og pakkelisten skal genereres gennem anvendelse af pakkelisten. For yderligere beskrivelse af pakkelisten henvises til releasebeskrivelse for ASPECT4 Industri Release 8.1. Den tekniske konfiguration ved modtagelse af EDI-dokumenter Overordnet set er det den norske DEBIB2 standard, der ligger til grund for dokumenterne, men DEBIB2 er et subset af den internationale standard EANCOM. I tillæg til ovenstående dokumenter er der også lavet en række databaseudvidelser i ordrekartotekerne, interfacefilerne samt EDI mellemfilerne, således at der kan bæres flere af de oplysninger, der er beskrevet i EANCOM 96 standarden. Oplysningerne er udelukkende tilføjet i forhold til EDI, hvormed der ikke er foretaget udvidelser af statistikfilerne. Blandt mulighederne kan nævnes muligheden for at overføre rentesats i forbindelse med fakturering. Den tekniske konfiguration ved afsendelse af EDI-dokumenter Modtagelsen af EDI-dokumenter følger nogenlunde samme skabelon, som den ovenfor beskrevne afsendelse. Modtagelsen af EDI-meddelelser beskrives ikke her; der henvises til beskrivelsen under afsendelse af EDI. 19

20 Diverse funktionalitetsforbedringer I release 9 er der en række mindre funktionalitetsforbedringer, der er beskrevet nedenstående. Ændring i konteringsbeskrivelser Konteringsbeskrivelser (applikation 9381 Vis konteringsbeskrivelser ) var lavet i Office Vision og kunne derfor ikke længere vedligeholdes. Det var derfor blevet nødvendigt med en mere tidssvarende løsning, hvorfor konteringsbeskrivelser er omlagt til HTML-dokumenter, der kan vises i en browser. Synkrone adaptere Som modul til ASPECT4 Logistik er der udviklet synkrone adaptere. De synkrone adaptere har til hensigt at kunne give et onlinesvar på en forespørgsel, der sker uden for ASPECT4 Logistik eksempelvis fra en butik på internettet. De tre synkrone adaptere, der er udviklet til ASPECT4 Logistik release 9, er følgende: 1. Tjek på disponibel beholdning for en kunde på én til flere varer. 2. Tjek på salgsprisen for en kunde på én til flere varer. Supplerende tekster i sprog I forbindelse med etablering af sprogstyring i ASPECT4 Logistik blev der taget højde for, at beskrivelser til stamdata kunne dannes på et valgfrit antal sprog. Dette gøres ved at oprette beskrivelseslinjen i forskellige sprog og kopiere linjen med angivelse af et alternativt sprog. I release 9 er der mulighed for at angive supplerende tekster på de samme sprog, som der er opbygget beskrivelser i. Dette er illustreret i billedet nedenfor. DocManager og samlefaktura I ASPECT4 Industri release 8 blev der påbegyndt en formularløsning, der baserer sig på DocManager. Dette arbejde er under fortsat udvikling, og i release 9 er samlefakturaen nu også understøttet gennem DocManager. For yderligere beskrivelse af DocManager-faciliteter henvises dels til releasebeskrivelsen for ASPECT/4 Industri release 8.1 og dels til særskilt materiale for DocManager. Defaults ved ordreoprettelse I forbindelse med ordreoprettelse har det hidtil været sådan, at en række værdier på ordren har været defaultet (foreslået) fra kundestamdata. Ved hjælp af systemparameter Ordreoprettelse defaultoplysninger(sodefopl) har man nu mulighed for at tage udgangspunkt i værdierne fra debitoren i stedet for værdierne fra kunden. 3. Tjek og evt. oprettelse af salgsordretransaktion for en kunde på én til flere varer. Ad 1 Til leveringstjekket er der oprettet et nyt modul kaldet EA6P01RA. Modulet er et business-modul, der indeholder funktionen STOCKCHECK. Funktionen i modulet kaldes med angivelse af en kunde samt en række varer og returnerer oplysninger om disponibel beholdning m.m. Ad 2 Til salgspristjekket er der oprettet et nyt modul kaldet EA6P01RA. Modulet er et business-modul, der indeholder funktionen PRICECHECK. Funktionen kaldes med angivelse af en kunde samt en række varer, og den returnerer salgspriskomponenter fra salgsprislisterne Ad 3 Til simulering og evt. oprettelse af en salgsordretransaktion er der oprettet et nyt modul kaldet EA6P01RA. Modulet er et business-modul, der indeholder funktionerne ORDERCHECK og ORDER. Funktionerne i modulet kaldes med angivelse af en kunde samt en række varer, og de returnerer oplysninger vedr. oprettet salgsordretransaktionsjournal, disponibel beholdning, salgspris samt koder for, om salgsordretransaktionerne kan oprettes korrekt. Ved funktionen ORDER vil der blive oprettet en salgsordretransaktionsjournal med den ønskede ordre. Supplerende tekster i sprog I release 9 er der mulighed for at angive supplerende tekster på de samme sprog, som der er opbygget beskrivelser i 20