Med oppgradering til Chain Classic versjon2.2.0.0.07skal alltid POS levere bonger i POSLog versjon 81.
Forbedringer
Modul
Beskrivelse
Lexmark
Lexmark oppdatering når tilbud = ordinærpris (RTC-29650)
I situasjonen der kampanjepris/medlemstilbud = normalpris og normalpris økes i tilbudsperioden vil dette ikke trigge etikett. Hvis kampanjeprisen deretter økes slik at denne igjen blir lik normalpris vil dette gi etikett til Lexmark merket som prisendring i stedet for kampanje/medlemstilbud. Det er kun utprisendring til tilbud lavere enn ordinærpris som vil gi etikett merket kampanjepris/medlemstilbud.
Oppdatering og endring av DUN-nummer kan kommuniseres via, felt 7.1.56, i RIGAL V-fil.
Varetelling
Utlegg til 3. part av talte varer med resultat = 0 (RTC-30681)
Ved utlegg av svinnposter til 3. part etter varetelling kan det være tilfeller hvor talte varer med 0 som resultat også skal legges ut. Når dette er i bruk legges disse 0-postene ut ved alle typer at varetelling.
Bruk av kampanjegruppeutlegg anbefales da det har mye å si for feilsøking ved avvik, men viktigst er sikkerhet og ytelse som er vesentlig bedre. Funksjonalitet kan slåes på manuelt via systemparameter, men det anbefales å bruke eget program for dette for kjappere og sikrere resultat ved konvertering av eksisterende kampanjegrupper til nytt utlegg i kampanjegruppeformatet.
Expand
title
Konfigurasjon
Teknisk informasjon
Programmet som skal brukes er: "LRS"/"Parameter"/"Slå på kampgrutlegg til POS" Funksjonalitet kan slåes på manuelt ved å sette systemparameter 750 = 1, men da må kampanjene konverters manuelt ved å kopiere, avslutte og godkjenne de kopierte kampanjegruppene. Ved å bruke tilpasset program for dette inkluderes kontroll av varekøposter og sletting i POS. Kampanjegruppene restartes også før nytt utlegg i kampanjegruppeformatet.
For 3. part-systemet Lexmark benyttes egen VPI-mal for etiketter. Menypunkt for denne etikettmalen er: "Register"/"Generelle"/"Vilkår for Lexmarkutlegg", som åpner programmet "Etikettmaler".
I kolonne"Filutlegg"(samme som "Oppdatere" i VPI-mal) , betyr "Ja" at endring av aktuelt felt medfører utlegg av Lexmark-fil. I kolonne "Etikettutskrift"(samme som "nullstille" i VPI-mal), betyr "Ja" at endring i dette felt aktiverer etikettkrav i Lexmark-utlegg. Standard er at kun endringer av utpris (ordinærpris, kampanje- og medlemstilbud) skal gi etikett i Lexmark. Det er mulig å skrive ut etikett i Lexmark også ved endring av andre felter. Merk at dette kun gjelder felter i "Pris" (Lexmark vareendringer går kun til totalbutikk) slik som leverandør, bestnr, etikettnr og sortiment.
Expand
title
Konfigurasjon
Teknisk informasjon
VPI-maler har fra nå av nummer 1-99, mens etikettmaler har nummer fra 100 og oppover. Dette fører til at når denne funksjonaliteten blir tatt i bruk og VPI-mal for Lexmark har et nummer lavere enn 100,MÅskriptet "flyttetimal.p" i katalogen "Help" kjøres. Da vil nummerserien oppdateres og ny etikettmal lages med dette nummeret. I tillegg oppdateres tilsvarende verdi i systemparameter 876, hvor nummer for Lexmark etikettmal er angitt, fra "X" til 100. Avvik i denne parameteren vil forhindre etikett. I kolonnen "Filutlegg" betyr "Ja" at endring av aktuelt felt medfører utlegg til Lexmark-fil. For å sjekke hvilke felt som fører til/ikke fører til utlegg, trykk på kolonneoverskrift for å sortere på innhold, I kolonnen "Etikettutskrift" betyr "Ja" at endring i dette felt aktiviserer etikett, ved å sette felt 7 (Etikett) i Lexmark-utlegget til "Yes". Standardverdi er "Ja" for endring på Utpris, Kampanjepris og Medlemspris. I dette programmet kan dette enkelt endres eller kompletteres med andre alternativer.
Når gammelt butikknummer beholdes, ved bytte av butikknummer, sikres det mot problemer i bongoppdatering fra 3. part (for eksempel webbutikk). Dette vil kunne skje hvis butikknummer ikke endres i alle systemer samtidig. I programmet "Endring av butikknr" på fanen "Alternativer" er derfor dette forvalgt, men kan overstyres hvis det er full kontroll på at butikknummerbytte skjer samtidig i alle løsninger.
Expand
title
Konfigurasjon
Teknisk informasjon
Ved butikknummerbytte endres det i gammel butikkpost i butikkregisteret til nytt butikknummer. Dersom gammelt butikknummer skal beholdes, lages en ny post med gammelt butikknummer, profilnummer er beholdt, kommunikasjonstype settes = 1 og butikknavn blir satt til: "Old store no. for store xxxx (nytt butikknr). Ellers er oppsettsdata blanke.
Automatisk opplegg av varemottak ved internoverføring
Uansett hvilken RIGAL-kode som brukes for faktura eller bestilling/bekreftelse, vil det alltid lages et automatisk varemottak ved internoverføring mellom butikker.
For Eksport av alle kunder i Chain Classic via JSONL-formatet, til Customer Service (Chain Web) brukes programmet: "System"/"Administrative rutiner"/"Utlegg av data"/"Kunder til customer service".
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 982 må settes opp med sti (path) til katalog for kunderelaterte JSONL-filer, for eksempel: json_cust\ , denne må også skapes manuelt i LRS-katalogen.
Dette er en første utgave som sannsynligvis må endres videre sammen med løsningene som skal motta dette formatet.
Eksporter alle kundegrupper til Customer Service i JSON-formatet
Via programmet "System"/"Administrative rutiner"/"Utlegg av data"/"Kunder til Cust. Serv." kan kundegrupper legges ut i JSONL-format til Customer Service i Chain Web.
Expand
title
Konfigurasjon
Teknisk informasjon
Det må manuelt lages en katalog, under LRS-katalogen, med samme navn som er brukt i feltet "Verdi" i systemparameter 982.
Denne funksjonaliteten brukes når en butikk kun skal ha profilpriser, og aktive lokale butikkpriser skal derfor fjernes.
Ytelse er vesentlig forbedret.
Det kan velges å skrive en rapport, men kun dersom antall forventes å være under 200.000 lokale prisposter.
Mulighet å lage utvalg på varegruppeliste er lagt til
Antall poster vises direkte i jobblisten, rapport trenger ikke å lages for dette
Expand
title
Konfigurasjon
Teknisk informasjon
Grunnet begrensning i 3. part programmet "vsView", er rapport genereringen begrenset til maks 200.000 lokale prisposter. Dersom antall er større enn dette, er risikoen for heng i programeksekveringen stor. Nå er det vel uansett ikke aktuelt å lese en rapport med så mange varelinjer.
Systemparameter 997 finnes for å angi maks antall poster varer som kan skrives ut i rapport. Maksimalt 200.000 og 0 = ikke i bruk.
"Ikke lag rapport" er et valg på fanen "Alternativer" som unngår å lage rapport uansett antall varer i utvalg. Dette bør brukes når det er kjent at det er mange lokale butikkpriser som skal slettes og/eller at rapport er unødvendig.
Dersom funnet antall poster overgår verdi i systemparameter 997 eller 200.000 stk., vil det heller ikke lages rapport.
Hvis rapport ikke skrives, vises dette som: "Ingen rapport" først i kolonnen "Resultat" i rapportlisten for antall varer.
Om "Mottak av webordre" er i bruk finnes behov for å logge alle aktiviteter knyttet til lagring av endret lagersted. Dersom webservice (WS) ikke fungerer vil klient gå i heng og kan også terminere. Loggfilenmottawebmmdd.butnrlegges daglig ut på loggkatalogen via standard utlegg.
Expand
title
Konfigurasjon
Teknisk informasjon
Loggfilen har følgende innhold:
- Beskrivende tekst - Butikknr - Ordrenr - Ordretype - Sendstatus - Dato/tid for når mottaket ble registrert - Kollinr - Lagersted
Hva som trigger logging:
- Ingen kontakt med webservice - Webordre mottatt i butikk - Overføring via webservice feilet - Webordre IKKE mottatt komplett i butikk
Utover standardformat finnes et parameterstyrt fullformat av "Sortimentliste Excel". Dette fullformat tilsvarer det Excel dokument som lages i rapporten "Sortimentliste Excel". Det innebærer også at VPI-import kun har støtte for akkurat dette formatet.
Expand
title
Konfigurasjon
Teknisk informasjon
Fullformat Sortimentliste Excel aktiveres ved å sette systemparameter 964 = 1.
Laget Excel-rapport representerer det fullformat som skal brukes for VPI-import via excelvpi.csv.
Det erKUNfelt fra standardformatet som oppdateres, ikke de nye feltene.
Forbedret oppdatering i søkefunksjon i lagerprogrammer for drivstoff
På toppen av den oppdaterbare delen i programmet "Manuell tankstatus" kan HK-bruker søke etter aktive butikker med minst en tilkoblet tank. For butikkbrukere vises kun egen butikk dersom det finnes minst en tank registrert på butikken. I tillegg vil det nå i det vanlige registreringsprogrammet, "Tankstatus", alltid vise korrekt produktnavn dersom man endrer tanknr/tankgr.
Alternativ for utlegg av reseptvare til Tokheim POS
Utlegg av info for servicehandels-varer kan parameterstyres for å forhindre varer fjernes utilsiktet fra en resept i Tokheim POS.
Expand
title
Konfigurasjon
Teknisk informasjon
Aktiv systemparameter 983 medfører at feltet COMP_TYPE i utlegg av reseptvare til Tokheim POS skal ha verdien "3" i stedet for "2".
Chain Classic versjon 2.2.0.0.06
Dokument status:
Status
colour
Green
title
released
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon2.2.0.0.06skal alltid POS levere bonger i POSLog versjon 81.
Forbedringer
Modul
Beskrivelse
Etikett
Etikett skrives ikke uten endring av utpris (RTC-29332)
Hvis ny kampanjepris er lik utpris eller hvis kampanjenettopris, men ikke utpris, endres på aktiv kampanje da skrives det ikke etikett ved noen av disse tilfellene.
Kampanjegruppe
Sletting av mixmatch fra ikke godkjent kampanjegruppe (RTC-29477)
Ved opplegg av ny kampanjegruppe med flere mixmatcher kan bruker slette både en og flere mixmatcher før selve kampanjegruppen godkjennes.
Samme vare i multiple michmatcher i samme kampanjegruppe (RTC-27651)
Det er mulig å ha flere mixmatcher, med samme vare, i en kampanjegruppe, uten risiko for komplikasjoner grunnet identisk start- og/eller sluttdato.
Mixmatch
Innhenting av nye varer i allerede godkjent mixmatch (RTC-29815)
I manuell mixmatch eller mixmatch i kampanjegruppe kan innhenting av nye varer gjøres på flere måter. Uansett metode vil både automatisk og manuell godkjenning/lagring lage varekøposter med samme butikknummer som er gjeldende i nevnte tilbudstyper.
Rapporter
Antall solgte varer i grafisk varegruppesalgsrapport (RTC-29486)
Ved bruk av grafisk varegruppesalgsrapport kan det åpnes et vindu for "Fordeling pr. butikk". Generelt vil denne "pop-up" ha en kolonne for antall, men i tabeller for varegruppe- og undergruppesalg gir det ikke mening å lagre antall (av uidentifiserte varer). For å unnvike misforståelse ekskluderer disse salgsrapportene kolonne "Antall", i stedet for å vise verdi 0 for alle poster.
Ved bruk av parameterstyrt spesialløsning for varemottak (ikke standardløsningen el. varemottak), er det mulig å skrive ut etiketter via knappene "Prislapp" og "Prislapp lager". Funksjonen gir prislapper for nye varer og i programmet utførte prisendringer på både eksisterende og nye varer.
Oppdatering av nettopris i eksisterende el. varemottak ved manuelt varemottak (RTC-28081)
Hvis det oppdages en vare med feil nettopris i elektronisk varemottak, kan dette korrigeres ved å lage et manuelt varemottak og sette riktig kostpris på varen der. Det lages da en varetransaksjonspost som har riktig verdi og lager oppdateres. Hvis man, som riktig er i dette tilfelle, velger å oppdatere mot eksisterende ordre da blir tilsvarende ordrelinje i elektronisk varemottak oppdater med ny verdi på nettopris og også data i ordrehode blir rekalkulert i forhold til ny verdi fra manuelt varemottak.
Utmeldt vare (fra leverandør) innebærer at varen har en fremtidig slettepost for når varen skal fjernes fra systemet. Hvor mange dager frem i tid denne slettedatoen settes er parameterstyrt. Når det kommer en RIGAL-fil med beskjed om utmeldt vare, "U", vil en slettepost lages. Slettedato blir en fremtidig dato tilsvarende i dag pluss parameterstyrt antall dager.
Utmeldt vare betyr at varen ikke lenger kan bestilles, bestillingsnummer fjernes derfor fra etikett og elektroniske hylleforkanter
Hvis beskjed om utmeldt vare kommer sammen med en eller flere fremtidige prisendringer lages det flere prisendringsposter. Den første med dagens dato for å sikre gjeldende pris, at varen oppdateres med sortimentskode "U" og at bestillingsnummer derfor fjernes fra papir- og el.etikett. Det lages også en post per fremtidig prisendring, hvor dato for den siste prisendringen legges sammen med parameterstyrt antall dager frem i tid for å sette slettedato for varen sin slettepost.
Expand
title
Konfigurasjon
Teknisk informasjon
I systemparameter 101 angis antall dagers forsinkelse ved sletteposter fra leverandør.
Oppdatering av mixmatcher i POS ved endring av gjeldende unntaksvaregrupper
Ved vedlikehold av programmet "Spesiell varegruppeliste", en liste med varer som ikke skal gi prisreduksjon på utvalgte mixmatchtyper, legges all mixmatchinformasjon (kun mixhode) ut på nytt. Slik at alle mixmatcher dette berører i POS, oppdateres med korrigeringer av gjeldende unntaksvaregrupper.
Expand
title
Konfigurasjon
Teknisk informasjon
Mixmatchtyper som skal hensynta unntakslisten med varegrupper er angitt i systemalternativer 132 Den "Spesielle varegruppelisten", unntakslisten, har listenr: 100000001
Under LRS-menyen ligger programmet "Kampanjegr og mix til POS" kan kjøre denne oppdatering manuelt. Her kan angis om alle aktive og fremtidige kampanjegrupper og/eller mixmatcher skal legges ut til POS. I tillegg kan bestemmes om kun kampanjegruppehode eller mixhode skal legges ut.
Dette er samme program som kjøres rett etter at vedlikehold av "Spesielle varegrupper" er lagret, men da er det kun berørte mixhode-poster som legges ut, for mixtyper angitt for å hensynta unntaksvaregrupper.
Betale gavekort med annet gavekort og/eller tilgodelapp
Hvis gavekort og/eller tilgodelapp brukes for å betale et nytt gavekort lages en egen finanstransaksjon for dette.
Expand
title
Konfigurasjon
Teknisk informasjon
Finanstransaksjon med transtype 891 fanger opp beløp som representerer kjøp av gavekort, betalt med gavekort og/eller tilgodelapp. Feltet antall telles opp med 1 for hver bong der denne kombinasjonen finnes.
Utlegg av RIGAL finansfil (F-fil) er utvidet med ny transaksjonskode IGG som inneholder data beskrevet ovenfor.
Dette er en cloud-tilpasset bildebankløsning. I stedet for å hente bilder fra lokal server hentes de via URL og bildenavn er identisk med EAN for hovedvare eller koblet tandemnummer.
Expand
title
Konfigurasjon
Teknisk informasjon
Standardløsning med bildebank på lokal server, med oppsett i systemparameter 68: for eksempel "\lrs\bilder", kan fortsatt brukes som alternativ. Men systemparameter 68 skal ikke være i bruk hvis kunde tiltrer annen bildebankløsning.
Ved overgang til bildebankversjon "Q-bank":
Systemparameter 972 aktiviseres.
I tillegg må skriptet "Nullstillbilde.p" i hjelp-katalogen kjøres for å fjerne alle gamle bildekoblinger.
Det forutsettes initialt at det er "png-filer" som brukes. Med EAN = filnavn blir det "EAN.png". Det er dog mulig å åpne for bruk av andre bildeformat.
Hvis salgsdag, alle salgsdata, må slettes for en hel dag, for så å leses inn på nytt. Det betyr alle bonger som er levert til Chain Classic innenfor angitt datointervall. Dette inkluderer varetransaksjoner for tellesvinn, hvis de er levert via POSLog.
Expand
title
Konfigurasjon
Teknisk informasjon
Det er programmet "Nullstilling av salgsdag", som utfører dette. Varetransaksjoner, innenfor datointervall, merket "Kasse" fjernes og lagerantall telles ned med tilsvarende transaksjonen sin verdi. Dette fordi at det ikke skal bli dobbel registrering på lager. Svinnposter, i varetransaksjoner, laget i Chain Classic påvirkes ikke av dette.
I "Elektronisk varemottak" er det som standard ikke mulig å endre nettopris, slik det er i det spesialtilpassede programmet "Varemottak". Men det er mulig å parameterstyre "El. varemottak" slik at nettopris kan redigeres direkte i programmet uten å bruke "Manuelt varemottak".
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 980 slår på denne funksjonaliteten, og nettoprisfeltet vil åpnes for redigering. Dette er et kalkulert felt (ikke lagret i basen) og kan ikke oppdateres direkte. Ved nettoprisendring skjer derfor følgende:
Ny skjermverdi legges inn i engros-feltet.
Ev. kalkylerabatter settes til 0.
Det betyr at hvis opprinnelig engros er 100 og rabatt 1 = 10 %, vil nettopris vises som 90. Ved å bruke denne mulighet å endre nettopris, overskriver brukeren opprinnelig kalkulert verdi, med for eksempel 95. Resultatet blir engros = 95 og alle rabatter = 0.
Info
title
Merk!
Ny parameter kanikke brukes sammen med systemparameter 799, som er en spesialinnstilling for Coop Svalbard der engrospris kan endres direkte i samme skjermbilde.
I programmet "Varetransaksjoner" vises alle transaksjoner uavhengig av transtype.
Det er kun mulig å legge opp/kopiere/motpostere følgende transaksjonstyper:
1 Synlig svinn" (1)
2 Intern forbruk" (2)
6 Lagerjustering" (6)
11 Nedpakking
Alternativ:
7 Varetelling - kan parameterstyres til om dette skal tillates eller ikke
Følgende transaksjonstyper kan ikke registreres, kopieres eller motposteres:
3 Retur
4 Reklamasjon fra kunde, utføres i POS (Transaksjonstekst inneholder "kasse")
5 Varemottak
8 Tellsvinn
9 Internoverføring
Knapp for "Kopiering" og "Motpostering" (= sletteknapp) er deaktivert for de transaksjonstyper det ikke er tillatt å registrere.
Expand
title
Konfigurasjon
Teknisk informasjon
Med aktivering av systemparameter 810 tillates det at også varetelling blir med blant de transaksjonstypene som kan legges opp/kopieres/motposteres i Chain Classic.
Det anbefales ikke slå på denne parameteren for lagerstyrte butikker, da en del av funksjonaliteten laget for modellvare ikke er optimal i denne sammenheng, samt at det finnes et dedikert program for registrering av disse.
Systemparameter 394 angir om "reklamasjon til leverandør" er i bruk i Chain Classic, ingen pengetransaksjon, kun varer ut av lager. Dersom <> "", er reklamasjon til leverandør tillatt.
Av sikkerhets grunner kan det være en fordel med å installere client-filene ved oppdatering av patch i bakgrunnen. For dette trenges minst én AD-bruker med "Single Sign On" (SSO). Da denne logger seg på automatisk utføres klientoppdatering uten "forstyrrelser".
Expand
title
Konfigurasjon
Teknisk informasjon
SSO for AD-brukere aktiviseres ved å legge inn aktuell domene i systemparameter 90, og vil da bli gjeldende for alle brukere som logger seg på med denne domene. Dette parametervalget åpner også for å legge inn en "ukjent" domene i parameter 90 som da kan brukes også i domenefeltet for enkelte brukere, hvis ikke alle skal ha denne funksjonaliteten.
For "silent upgrade modus" ved oppdatering av klientfiler er det to alternativer å velge mellom. Verdien "CUOnly" legges inn i filen "client_update.xml", i "FIX-katalogen", på noen av følgende måter.
Datobegrenset nyregistrering av poster i "Drivstoff"
Ved nyregistrering av poster i serviceprogrammene "Levering". "Manuell tankstatus" og "Tankstatus" under "Drivstoff", er det mulig å parameterstyre hvor langt tilbake i tid det er mulig å nyregistrere en post. Feilmelding kommer da opp hvis for gammel dato velges og lagring er ikke mulig.
Expand
title
Konfigurasjon
Teknisk informasjon
Denne funksjonaliteten forutsetter bruk av systemparameter 9003.
Systemparameter 981 kan da benyttes for å angi de antall dager tilbake i tid det er lov å angi ved oppretting av ny post i drivstoffprogrammene
Med standardvalget, systemparameter 981=0, er det ikke noen begrensning.
I tilfelle butikknummer skal byttes i Chain Classic og dette ikke utføres samtidig på andre steder, for eksempel i webshop, får dette store konsekvenser i systemet. For å unngå at det kommer in salg på manglende butikk i Chain Classic, avvises disse bongene og logges slik at de kan identifiseres og sendes inn på nytt med riktig butikknummer.
Expand
title
Konfigurasjon
Teknisk informasjon
Dersom StoreIDToCreateCustomerOrdersIn > 0 men butikk mangler i Chain Classic, logges feilmelding i standard LRS\logg\"POSLog*.butnr"
Bonger som logges må behandles manuelt i etterkant.
Bruk av kampanjegruppeutlegg anbefales da det har mye å si for feilsøking ved avvik, men viktigst er sikkerhet og ytelse som er vesentlig bedre. Funksjonalitet kan slåes på manuelt via systemparameter, men det anbefales å bruke eget program for dette for kjappere og sikrere resultat ved konvertering av eksisterende kampanjegrupper til nytt utlegg i kampanjegruppeformatet.
Expand
title
Konfigurasjon
Teknisk informasjon
Programmet som skal brukes er: "LRS"/"Parameter"/"Slå på kampgrutlegg til POS"
Funksjonalitet kan slåes på manuelt ved å sette systemparameter 750 = 1, men da må kampanjene konverters manuelt ved å kopiere, avslutte og godkjenne de kopierte kampanjegruppene. Ved å bruke tilpasset program for dette inkluderes kontroll av varekøposter og sletting i POS, kampanjegruppene restartes også før nytt utlegg i kampanjegruppeformatet.
Begrense mulighet å lage informasjonstekst under HK-nivå
For programmet "Varevedlikehold"/"Vareinformasjon" finnes en parameterstyrt begrensning som forhindrer at det lages informasjonstekster på lavere nivå enn HK-nivå (profil 0/putikk 0). De informasjonstypene dette gjelder er følgende:
For type 3 og 4 skjer KUN HK-utlegg, det er felles informasjon. Det bør derfor vurderes om disse skal begrenses som standard, hvis utlegg er det som ønskes. Informasjonstekster som lages av butikkbruker kan kun brukes som infokilde i dette program i Chain Classic.
Systemparameter 974 = 0,0,1,1 viser oppsett for at nye varenotat av typene 3 og 4 i "Vareinformasjon", kun kan opprettes som felles informasjonstekster for HK-utlegg (profil 0/butikk 0).
Eksport av ikke mottatte bestillinger til Chain Web
For eksport, av ikke mottatte bestillinger, fra Chain Classic til Chain Web i format J-SON, benyttes programmet "Bestillinger til Procurement".
Programmet ligger under "System"/"Administrative rutiner"/"Utlegg av data. Samlet utlegg legges på parameterstyrt plass. Hvis ønskelig kan også sendes/backup brukes for backup.
Expand
title
Konfigurasjon
Teknisk informasjon
Plass for eksport av disse JSON filene settes opp i systemparamater 978. Standardforslag er "json_proc", uansett katalognavn må katalogen lages manuelt under LRS-katalogen.
Hvis systemparameter 312 er aktiv, lages også backup-filer i katalogen LRS\sendes\backup.
Hvis parameterstyring til VPI-mal for standardverdier ikke brukes, blir alle feltene blanke når "Ny vare" opprettes. Dette er standard.
Når ny vare lages manuelt i programmet "Varevedlikehold" i Chain Classic kan det være ønskelig at noen felter alltid oppdateres med samme standardverdier. Dette kontrolleres ved parameterstyring i en tilpasset VPI-mal med standardverdier for "Ny vare". Det er følgende felt som kan settes opp med standardverdier:
I systemparameter 206 - angis nummeret på den VPI-malen inn som representerer ny vare og de standardverdiene som skal brukes. Ved ukjent VPI-malnummer, vil alle felt bli blanke når "Ny vare" opprettes.
Chain Classic versjon 2.2.0.0.05
Dokument status:
Status
colour
Green
title
released
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon2.2.0.0.05anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul
Beskrivelse
Etiketter fra varekø
Skrive varekøetiketter fra InStore App (RTC-26686)
Det er støtte for å skrive ut etiketter, fra varekø i Chain Classic, direktete fra InStore App. De som kan skrives ut vises også i "Varekøliste" med etikettflagg = "Nei", og betyr at det ikke er skrevet ut.
RIGAL
Mixmatch og kampanjegruppe sendes alltid med referanse via RIGAL (RTC-28418)
Kampanjehode og mixmatchhode må ha referanse til tilbudsvarene. Kundespesifikke oppsett gir forskjellige løsninger på dette. På den ene siden kan kampanjegruppnr og/eller mixmatchnr brukes, hvis disse numrene ikke er i bruk gjelder "Kampanje-ID" og "ekstern mix ID".
Utleggene skjer i RIGAL-filer for kampanjegruppe (J) og mixmatch (X).
Sletting av ordrerad og ordrehode logges i "Sletting kundeordre" under "Rapporter"/"Logger".
Også nedprising vil logges hvis endring av salgspris som overgår parameterstyrte referanseverdier. Det er to verdier som må oppfylles den første angir min. linjesum (salgspris før endring) for en rad, og andre verdi angir min. total prisreduksjon som er foretatt på denne raden.
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 973 kontrollerer hva av endringer i kundeordre som skal logges.
Info
Merk! Det finnes allerede en annen standardlogg for prisendringer i kundeordre som logger alle prisendringer som utføresuavhengigav beløp og størrelse på prisreduksjon til loggfil "kordMMDD.butnr".
Ved internoverføring logges dette i loggfil: internlogg_DD-MM-YY.butnr.
Logging gjelder både hvis det er gjort via InStore App og direkte i Chain Classic.Ved tilfelle hvor det gjøres i Chain Classic skrives det "CC CLIENT" slik at det fremgår hvor denne transaksjon er skapt.
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 776 slår på denne funksjonaliteten. Denne parameteren bør være satt som standard, da logging kun gjelder for internoverføringer, små mengder data.
For beste logging ved bruk av denne funksjonaliteten, anbefales et oppsett med systemparameter 289= IBK. Det er ikke sannsynlig at noen kunde bruker IFA i disse dager, derfor bør IBK bør være standardoppsett til alle.
Begrens valgmuligheter for butikkbruker i kampanjegruppe
Det kan velges om butikkbrukere eller alle brukere, unntatt utviklingsbrukere, skal ha begrenset adgang til funksjonalitet ved vedlikehold av kampanjegruppe. Fanene "Kampanjepris", "Medlemstilbud" og "Mixmatch" kan alle deaktiveres, enten for kun butikkbrukere eller for alle brukere, unntatt utviklingsbrukere som alltid har adgang til alle fanene.
Det er også mulig å sperre for manuelle valg av kampanje-ID når butikklokal kampanjegruppe opprettes, dette gjelder uansett brukertype. Denne funksjon forutsetter et ønske om at alle butikklokale kampanjegrupper alltid skal ha samme kampanje-ID. Denne verdien for kampanje-ID parameterstyres.
Expand
title
Konfigurasjon
Teknisk informasjon
For begrensning av kampanjegruppefunksjoner:
Systemparameter 975 har fire verdier som kan kombineres.
Viktig! Etter satt verdi må appserver asLRS restartes.
Samme kampanje-ID for alle butikklokale kampanjer:
I systemparameter 976 angis ønsket kampanje-ID, noe som kan være både numerisk og alfanumerisk.
Ved denne funksjonaliteten kan IKKE systemparameter 496 og systemparameter 685 være i bruk.
Utlegg av informasjonstekst i bestilling til leverandør, via RIGAL
For informasjon til eksterne løsninger legges informasjonstekst ut via RIGAL I-fil, hvis det er angitt i bestillingsfeltene "Melding til leverandør" og "Referansetekst".
Expand
title
Konfigurasjon
Teknisk informasjon
Dokumentasjon for RIGAL I-fil er oppdatert på portalen:
"Melding til leverandør" legges ut i feltnummer 30.56
Ved å avgrense utvalg på transaksjonstype, periode og butikk(er), gir rapporten "Varetransaksjonsliste Excel" en overblikk over periodens på akkumulerte verdier, hvor kostpris er summert pr butikk pr undergruppe (til forskjell fra ordinær varetransaksjonsliste).
Hvis kostpris mangler i varetransaksjon hentes dette fra ordinærpris.
Det skrives en fane for hver butikk i Excel-rapporten, med butikknr som fanenavn.
Det skapes også en PDF rapport med samme opplysninger.
Chain Classic versjon 2.2.0.0.04
Dokument status:
Status
colour
Green
title
released
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.04 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul
Beskrivelse
Etikett
Bestill etikettutskrift med forskjellige etikettyper (RTC-27262)
Det er mulig å bestille og skrive ut etiketter med forskjellige etikettyper i samme etikettbestilling fra InStore App.
Ved utlegg av lagerfil til Chain Web fra Chain Classic vil alltid tidligere eksportert fil, "StockBasis.butnr", skrives over, hvis den ikke er hentet opp.
Optimalisering av utlegg ved lagerendring (RTC-27423)
Generelt legges ikke lagerendringer ut til POS, dette skal kun skje ved endring av pris eller veidkost. Varemottak er derfor eneste grunn for filutlegg, med lagerendringer, til POS og evt. annen 3.part.
Rapporter
Leveringsdato i rapporten "Grunnlag bestilling" (RTC-27033)
Når spesialfunksjonalitet for å vise leveringsdato i "Bestilling" er i bruk, viser dette leveringsdato på ordre linje i rapporten "Grunnlag bestilling".
RIGAL
Utlegg av leverandørordre-ID etter varemottak (RTC-27182)
Leverandørordre-ID er et felt som ikke vises i Chain Classic men som kan benyttes når leverandør sender inn varemottak via RIGAL I-fil. Når varemottak er godkjent legges leverandør-ID ut i RIGAL I-formatet, dette gjelder uansett om varemottak gjøres i InStore App eller i Chain Classic.
Ved utlegg av RIGAL V-fil, fra "Klargjøre vare", legges det ut kampanjegruppeinfo for kampanjegruppenummer, kampanje-ID, navn på kampanjegruppe tilhørende formatene "K" (kampanjevare) og "M" (Medlemstilbud). I tillegg legges det ut RIGAL J-fil med tilsvarende informasjon.
I kampanjegruppe finnes mulighet for å bruke funksjonalitet for å angi fast kr- eller %rabatt på varelinje i både kampanje eller medlemstilbud. Ved endring av ordinærpris i "Priskalkyl", rekalkuleres tilbudspris også i kampanjegruppe og endring til POS legges ut via det utleggsalternativ som brukes, kampgr eller prisfil.
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 838 åpner for denne funksjonaliteten
Angi fast bruttofortjeneste på RIGAL-oppdaterte varegrupper
Det er mulig å angi fast bruttofortjeneste for ordinære priser for varer på gitte varegrupper. Ny utsalgspris vil da rekalkuleres og avrundes i henhold til dette, når de oppdateres via RIGAL VPI.
Vedlikehold skjer i registerprogrammet "Bruttofortjeneste i RIGAL" hvor det er mulig å legge inn fast bruttofortjeneste for varer i nye varegrupper og endre for eksisterende.
Det er mulig å velge om logging skal skje, ved endring på alle varefelt merket med "Oppdatering" = "Ja", i en utvalgt VPI-mal. Dette gjelder da kun for én utvalgt VPI-mal, og da ved manuell endring direkte i Chain Classic eller oppdatering via RIGAL VPI.
Endringene logges i loggkatalogen med filnavn "chgvareddmmyyyy.txt". Både ny og opprinnelig verdi vises, og akkumuleres i denne månedsfilen.
Det er mulig å logge opplegg og oppdatering av mixmatch via RIGAL- X-filer i VPI-logger. Meldingsteksten er formattert på samme måte som ved logging fra oppdatering av RIGAL V-formatet og J-formatet (utvidet J-format = V-fil i innhold).
Alle meldinger skrives i standard VPI-logger (vpierr*., vpierrtot.* og VPIins*.*) Det skrives ingenting i standard feillogg/oppdateringslogger (err*.* errtot*.* eller ins*.*)
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 969 = 1 slår på denne funksjonaliteten.
Spesifiserte varegrupper/produsenter skal ikke oppdateres via RIGAL VPI
Det er mulig å skrive ut strekkode på varene i lagerrapporten "Feilliste". Dette gjøres som standard kun for varer med negative lagerantall, men det er også mulig å sette opp "Skriv strekkode" som standard. Noe som må til hvis man tar ut denne rapporten ved EOD.
Expand
title
Konfigurasjon
Teknisk informasjon
For å sette opp "Skriv strekkode" som standard må systemalternativer 1072, kode 1 - "xfeillip", tilpasses dette, ved å sette "yes" som 2. verdi i feltet "Verdi2":
Hvis funksjonalitet for å lukke ordre ved første varemottak og da avskrive uleverte rader er i bruk, skal alle rader kvitteres ved utlegg av RIGAL I-fil, også de ikke mottatte.
Expand
title
Konfigurasjon
Teknisk informasjon
For denne funksjonalitet gjelder:
Systemparameter 477 = 1
Systemparameter 860 = 1 (utlegg ved mottak i POSLog)
Det er mulig å velge om butikk skal ha mulighet til å bruke funksjonalitet for L15 kompenserte verdier. Dette gjelder for 3. partssystemet Tokheim.
Utlegg til Reporting:
Kun for butikk med denne funksjonaliteten aktiv.
Mengdefeltet til Reporting oppdateres dersom "komplestmengde" > 0.
Vedlikehold av Tankstatus:
Feltet for "L15 kompensert" mengde vises kun for butikk med denne funksjonalitet aktiv og "komplestmengde" > 0.
Loggrapport loggtype 80:
I loggtype 80 logges endringer av "komplestmengde".
Rapporten takler også loggposter med kun 7 felt, uten "komplestmengde", da vises feltet "L15 kompensert" = 0.
Expand
title
Konfigurasjon
Teknisk informasjon
Butikker som skal bruke denne funksjonalitet må ligge opplagt med en post i systemalternativer for butikk 2003.
For å legge opp disse finnes to muligheter:
Legg opp butikkene manuelt.
Bruke skript "lagchliste2003.p", i help-katalogen. Alle butikker med kommunikasjonstype = 11 (aktive butikker), legges da opp i systemalternativer 2003.
Fjern deretter de butikkene som ikke skal benytte L15 kompenserte verdier.
Ved bruk av 3. partssystemet Tokheim kan manuell oppdatering, generelt vedlikehold eller sletting av registrert tankstatus gjøres i drivstoffprogrammet "Manuell tankstatus".
Inventory Module er en cloud modul som er lager-master. Chain Classic legger ut komplett lager-fil i JSON-format til egen katalog for videre bruk i Inventory Module.
Expand
title
Konfigurasjon
Teknisk informasjon
Egen eksportkatalog må lages under %%:\LRS\. Denne stien må i tillegg spesifiseres i systemparameter 970.
Det lages også backup av denne JSON-fil, i %%:\LRS\Sendes\Backup hvis systemparameter 312 er aktiv.
Chain Classic versjon 2.2.0.0.03
Dokument status:
Status
colour
Green
title
released
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.03 anbefales det at POS leverer bong-format i POSLog versjon 81.
Det anbefales at alle butikker har "Bestilling" påslått i butikkregisteret. Men fra patch 32 bør det sjekkes at butikker som ikke har bestilling, da faktisk ikke har "Bestilling" valgt i butikkregisteret. Dette for å sikre at bestillinger ikke lages, på disse butikkene, via automatikk ved for eksempel Kundeordre og Varemottak fra POS eller InStore App.
Utlegg av kampanje- og medlemstilbudsposter til 3. partssystemet Lexmark er begrenset til kun de de som er nødvendige for Lexmark sin funksjonalitet, der finnes ikke samme behov som ved tilsvarende utlegg til POS.
Rapporter
Utvalg i rapporten "Nonsalerapport pr. nonsaletype" (RTC-26418)
Ved bestilling av rapporten "Nonsalerapport pr. nonsaletype" er det mulig å sette opp forskjellige utvalg, for eksempel varegruppe.
Flagget "Fastpris" oppdateres via RIGAL-fil. Verdiene F, "P eller Y setter fastprisflagget aktivt. Alle andre bokstaver deaktiviserer fastpris. Hvis verdi mangler, skjer ingen forandring av "Fastpris".
Ekskludere varegruppe fra hurtigprising i mixmatch
Det er mulig å sette opp varegrupper for å ikke bli med i mixmatch via hurtigprising (Hent varer via utvalg), inn i mixmatch. Hvilke mixmatchtyper dette skal gjelde for må settes opp. Det er dog fortsatt mulig å legge inn enkeltvarer fra ekskludert varegruppe, da det forventes at den som gjør jobben har kontroll på dette. Kun for mixmatchtyper satt opp med denne funksjonalitet vises knappen "Ingen nedprising". Bak denne knapp vises den/de varegrupper som ekskluderes ved hurtigprising i aktuell mixmatchtype.
Expand
title
Konfigursjon
Teknisk informasjon
I listevedlikehold finnes programmet "Spesielle varegrupper" med listenr 100000001, angitte varegrupper i denne listen vil ekskluderes ved hurtigprising (Hent varer via utvalg) inn i mixmatch. Det er kun innholdet i denne liste som skal vedlikeholdes fra dette menypunktet.
Forutsetninger
Systemalternativer 121:
Kode 3 for mixmatch skal ha "Integer" = 48, for utlegg av nytt felt som inneholder varegruppenr som skal ekskluderes, i mix.butnr-utlegg til.
Kode 34 for kampanjegruppe skal ha "Integer" = 64, for utlegg av nytt felt som inneholder varegruppenr som skal ekskluderes, i kampgr.butnr-utlegg til.
I systemalternativer 132 må de mixmatcher som denne regel skal gjelde for velges ved å huke av for "Benyttes unntaksvaregrupper".
E-handel: Oppdater varemottaksbong i Chain Classic
Provisjonssalg etter provisjonsvareliste, i eget vedlikeholdsprogram, legges ut til EG Cash Settlement etter hver EOD. Det er kun mulig å legge opp og bruke én provisjonsvareliste pr. butikk.
Expand
title
Konfigurasjon
Teknisk informasjon
Transaksjonstype "IPE" i RIGAL F-fil til EG Cash Settlement inneholder totalsum og sammenlagt MVA for solgte varer i provisjonsvarelisten.
Intervall for nummerserie for provisjonsvarelisten er satt opp i systemparameter 965 og bør ikke forandres, hvis ikke kjeden har mer enn 1000 butikker.
"Slette/fjerne fra kasse" logger leverandør i rapport
Hvis en vare allerede finnes i en mixmatch og den samme varen leges opp i ny mixmatch vil det sjekkes på startdato/-tid og sluttdato/-tid. Hvis disse sammenfaller vil den nye mixvaren bli forkastet. Det kan nemlig ikke håndteres to slike køposter med samme start/slutt-dato/tid. Denne avvisning vil enten vises med melding og eller logges i loggrapport for loggutskrifter.
Dette gjelder for:
Manuell innlegging
Hent nye varer
Hent varer via utvalg
Hent varer via varegr
Expand
title
Konfigurasjon
Teknisk informasjon
Hvis det ikke kommer meldinger logges dette i loggrapport under loggutskrifter. Loggtyper som skal brukes må være aktive i systemalternativer 1034 for eksempel 9, 25 og 26 som brukes for mixmatch/kampanjegruppe.
Ved bruk av "Bestillingsfordeling Excel" kan bruker velge å opprette enten bestillinger eller varemottak. I begge disse tilfellene settes forventet leveringsdato uten verdi i programmet "Bestilling".
Expand
title
Konfigurasjon
Teknisk informasjon
Denne funksjonaliteten gjelder ved bruk av "Bestillingsfordeling Excel", og både systemparameter 843 og 818 må være aktive.
Varer i mixmatch som overlapper er ikke noe problem hvis det er forskjell på både start- og sluttdato/tid. Men det er ikke mulig for Chain Classic å ha to poster på samme mixvare, på samme nivå (butikk eller profil), med samme start- eller sluttid. Hvis dette skjer fører det alltid til at den ene posten forkastes. Dette er samme regler som gjelder for kampanjepris og medlemstilbud. Det anbefales derfor å ta en beslutning om hva som faktisk skal prioriteres.
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 963 = 0 - Prioriterer gjeldende mixvare når tilsvarende vare kommer i mixmatch via RIGAL, med samme start- eller sluttdato/tid oppdatering.
Systemparameter 963 = 1 - Prioriterer mixvare via RIGAL. Dette gjelder likevel KUN for de mixtyper som har verdi "Integer" = 1 i systemalternativer 132. For mixtyper med "Integer" = 0 vil fortsatt konflikter via RIGAL forkastes.
Tilsvarende funksjonalitet for kampanjepris/medlemspris settes opp i systemparameter 877.
Chain Classic versjon 2.2.0.0.02
Dokument status:
Status
colour
Green
title
released
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.02 anbefales det at POS leverer bong-format i POSLog versjon 81.
For å gjøre det lettere å forstå at de mengder som brukes i Wet Stock prosjektet kan være utført i både liter eller kilo, vises disse med enhet "Liter/Kilo".
Det er standard å avvise hel mixmatch når det finnes en eller flere ukjente varer. Det er mulig å velge de mixmatchtyper, hvor det skal være mulig å se bort fra standard og i stedet lage en mixmatch med kun de resterende kjente varene i RIGAL-filen.
Expand
title
Konfigurasjon
Teknisk informasjon
Denne funksjonaliteten aktiviseres med systemparameter 960.
Oppsett for inkluderte mixtyper skjer pr. mixtype via systemalternativer 132 hvor verdien "Integer" > 0.
Standard for sletting av varelinje i mixmatch, fra ERP via RIGAL-utlegg, er å legge ut komplett mixmatch til Chain Classic med alle varelinjer, og med aktiv slettemelding på hver mix-varelinje som skal slettes. Det finnes også et oppsettsalternativ hvor det blir mulig ved å kun legge ut de varelinjer som skal være igjen i mixmatchen, resterende varelinjer fjernes da fra aktiv mixmatch. Hvis utleg mangler varelinjer fører det til at hele mixmatchen avsluttes/fjernes.
Expand
title
Konfigurajson
Teknisk informasjon
Systemparameter 961 slår på denne funksjonaliteten.
I tillegg er det krav på systemparameter 684 = 1
Alle butikkpriser skal ha samme verdi på vektkode og fastpris
Det er mulig å alltid ha samme verdi på vektkode og fastpris på profilpris og alle butikkpriser på samme profil, også når endringer skjer via RIGAL-oppdatering.
Expand
title
Konfigurasjon
Teknisk informasjon
Denne funksjonaliteten krever at systemparameter 640 = 1
I tillegg må feltene "Fastpris" og "Vekt", i systemalternativer 1091, ha logisk-flagg slått på. Eller kun for den ene verdien av "Fastpris" eller "Vekt" som skal være lik på alle butikker.
Behandling av Coopay reserveløsning i finansoppgjør
I tilfeller når Coopay betalinger ikke blir gjennomført før EOD, behandles dette med reserveløsning og totalbeløp vises i begge butikkoppgjørsrapportene. I tillegg sendes informasjon om dette via finansutlegg til EG Cash Settlement.
Expand
title
Konfigurasjon
Teknisk informasjon
Denne funksjonalitet gjelder kun hvis systemparameter 839 er i bruk.
Standard funksjonalitet i programmet "Bestillingsfordeling Excel" er at nettopris ALLTID oppdateres fra regnearket hvis denne har en verdi > 0.
For valget "Bestillingsforslag":
Dersom nettopris i regnearket er 0 kopieres dette fra priskalkyle og da velges laveste tilgjengelig nettopris på aktivt ordinær- eller kampanjepris (ved ønsket leveringsdato), og settes over til bestillingsrad. Det sjekkes dog ikke på nettopris for evt. aktivt medlemstilbud.
For valget "Varemottak":
Ved standard oppsett sjekkes det ikke på laveste nettopris i priskalkyle.
Utvidet funksjonalitet:
Det er også mulig å parameterstyre slik at også medlemstilbud inkluderes når laveste nettopris i priskalkyle skal finnes frem. Dette gjelder da komplett kontroll av ordinær-, kampanje- og medlemstilbud for både "Bestillingsforslag" og "Varemottak" i programmet.
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 962 slår på valg av laveste nettopris i priskalkyle for både "Bestillingsforslag" og "Varemottak" i programmet "Bestillingsfordeling Excel", når nettopris = 0 i regnearket.
Bestillingsfordeling Excel og laveste nettopris fra priskalkyle, ved manuelt varemottak
Ved bruk av "Manuelt varemottak" og "Bestillingsfordeling Excel" finnes mulighet for å hente laveste nettopris funnet på ordinær-, kampanjepris eller medlemstilbud i priskalkyle (hvis aktive for valgt dato), hvis nettopris = 0 i Excel regneark. Hvis nettopris i regneark > 0 brukes dog ALLTID beløp i regneark.
Standard blir nettopris KUN kontrollert mot ordinær- og kampanjepris for "Bestillingsforslag". For varemottak blir det ikke gjort noen kontroll.
Expand
title
Konfigurasjon
Teknisk informasjon
Utvidet kontroll av nettopris ved "Manuelt varemottak" og bruk av "Bestillingsfordeling Excel" slåes på med systemparameter 962.
"Justering av tanknivå" velges ved manuell justering av tanknivå i programmet "Levering". Justerte poster vises i egen kolonne i programmet. Informasjon om at justering av tankstatus legges ut til "Reporting". Funksjonen er kun tilgjengelig når ny post opprettes. Leveringsnummerserien for dette er paramaterstyrt og oppdateres automatisk ved valg av "Justering av tanknivå". Dersom bruker angrer valg av "Justering av tanknivå" og fjerner merknad eller kansellerer hele registreringen, vil teller for leveringsnummer telles tilbake igjen for å unngå at det skapes "ubrukte" hull i nummerserien.
Expand
title
Konfigurasjon
Teknisk informasjon
Ved utlegg til Reporting "MÅ" systemalternativer 800 oppdateres, "Fylling" skal ha verdi "Integer" = 11.
Startnummer for leveringsnummerserie må settes i systemparameter 995.
Leveringsnummer i systemparameter 995 brukes første gang manuell justering av tanknivå utføres for butikk. Samtidig lages automatisk ny butikkpost for nestkommende leveringsnummer i systemalternativer for butikk 2002. I disse postene oppdateres så leveringsnummer, pr. butikk, med + 1 for hver ny post som lages.
Wet Stock og temperaturkompensert mengde i "Tankstatus"
Når tankstruktur oppdateres til 3. partssystemet Tokheim POS og det kommer endring i kapasitet på en tankgruppe, vil dette oppdateres på tankgruppe uansett om tank er tilknyttet eller ikke. Ved manglende tankinfo lages en ny tankgruppeinfo og oppdateringen blir eksportert til Tokheim POS.
Chain Classic versjon 2.2.0.0.01
Dokument status:
Status
colour
Green
title
released
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.01 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedring
Modul
Beskrivelse
Rapporter
Bestillingsnummer i rapporten "Selvbetjente varer" (RTC-23516)
Rapporten "Selvbetjente varer" er utvidet med kolonne for "Bestillingsnummer", her er det støtte for alfanumeriske eller numeriske bestillingsnummer.
Rapport for sletting og makulering i selvbetjent kasse
Rapporten "Kassererstatistikk - Selvutsjekking viser antall bonger som er makulerte og/eller har rader som er slettet fra selvbetjent kasse. I tillegg viser den hvilken kasserer som utførte dette.
Begrense utlegg til ferskvarevekt og el. etiketter
Det er mulig å begrense utlegg til el. etiketter og ferskvarevekter til kun de faktiske endringer som gjelder disse løsningene.
Expand
title
Konfigurasjon
Teknisk informasjon
Det er mulig å begrense utlegg til el. etiketter og ferskvarevekter til kun de faktiske endringedr som gjelder disse løsningene.
VPI-mal må lages, en for vekt og en for Breece/Pricer. Disse VPI-malene settes deretter opp for å akkurat oppdatere de felt som finnes i respektive utlegg.
Det er forskjell på Pricer og Breece, ved bruk av begge må det også bli tatt høyde for de felt som avviker slik at begge oppdateres i dette tilfelle. Alle andre felt skal være satt til "Nei".
For å aktivere funksjonalitet angis verdier i systemparameter 957, som er todelt og første verdi er VPI-malnummer for vekt og andre verdi VPI-malnummer for el. etikett (Breece/Pricer).
Det er mulig å velge en vare i InStore App for å så lage en lokal kampanje (ikke kampanjegruppe) i Chain Classic. Deretter legges kampanjen ut til POS. Gjeldende regler for kampanje, i forhold til parameteroppsett, må følges og ved ugyldige data avvises oppdateringen. Avvik logges i loggutskrifter - post 28 "Avviste butikkprisendringer fra ISA".
Ved bruk av sletting av varer i parameterstyrt spesialliste for sletting, er det mulig å velge hvis informasjon om denne sletting skal legges ut til POS. Standard ved bruk av denne funksjonalitet er at varene i varelisten slettes i Chain Classic og deretter legges ut for sletting i POS/CW. Men det kan være tilfelle når det er bedre å kun slette i Chain Classic, for å deretter slette, manuelt, direkte i POS. Dette er et manuelt valg i programmet "Sletting av varer".
Expand
title
Konfigurasjon
Teknisk informasjon
Systemparameter 906 må være riktig satt opp for "Sletting av varer" fra spesialliste 100000002.
Når vareliste lages er Excel-formatet ofte brukt for å importere EAN/PLU til ny vareliste. For å fortsatt ha denne mulighet uten programmet Excel til stede er det laget en ny funksjonalitet for å gjøre samme sak med tekstfil i CSV-format. Det forventes å være kun én EAN/PLU på hver rad, og siste raden blank.
Dette gjelder også for "Spesielle varelister", forskjellen ligger i at her oppdateres en eksisterende vareliste, i "Vareliste " skapes alltid ny vareliste - akkurat som når man trykker på knappen for "Importer fra Excel".
Det er ikke bare pant som kan brukes som linkvare. Også "Montering" kan brukes til dette. For eksempel til varmepumpe, velg linkvaren "Montering" og linktype 2, da påvirkes ikke panteregnskap. Det er også gjort spesialtilpasninger for det elektroniske hylleforkant systemet Breece. Summen av hovedvare og linkvare (f.eks. varmepumpe og montering) blir slått sammen og teksten inkl. montering (eller hva navn denne varen har) vises på Breece-displayet.
Expand
title
Konfigurasjon
Teknisk informasjon
Systemalternativer 125, kode 17: "priceitemlex" - må settes til Integer = 52.
Systemalternativer 125, kode 21: "priceitemlex" - må settes til Integer = 48.
Dette for utlegg til 3. partsystemet Lexmark.
I tillegg er ny post laget i VPI-mal, post 1007 i standardmal.
RIGAL-dok og systemdok er oppdatert når de gjelder linktype 2.
Hvis en post slettes på butikk, i næringsinnhold, men det fortsatt finnes verdi på profil da vil denne legges ut som erstattingsverdi for butikk. Kun hvis det ikke finnes profilverdi vil det legges ut sletting av post til vekt i butikk.
Til 3. partssystemet "Finnvacum" legges næringsinnholdstypene: 11 Kostfiber, 12 Protein og 13 Salt ut på en og samme linje Dette gjelder for Finnvacum vektetikett, ferskvarevekt, i format: atte2.butnr.
Hvis en butikk mangler køposter for en vare med kampanjepris, medlemstilbud eller mixmatch (inkluderer også fremtidige prisendringer). kampanjeposter kan disse gjenopprettes. Dette kan gjøres på manglende vare i "Prisvedlikehold" av enten HK-bruker, butikkbruker eller teambruker. Gjeldende køposter vises under fanen "Køposter i butikk". Ved å trykke på knappen "Kontroller kø" gjenopprettes manglende køposter, som beskrevet ovenfor. For HK-bruker sjekkes valgt vare for alle butikker, for teambruker for alle butikker på gjeldende team og for butikkbruker kun på gjeldende butikk.
I kampanjegruppe vises "Eksternt MixID" i egen kolonne allerede på siden over alle inngående mixmatcher i kampanjegruppen. Dette under forutsetning at ikke "Kupongkode" er ikke i bruk.
Expand
title
Konfigurasjon
Teknisk informasjon
For denne funksjonalitet kreves at systemparameter 536 = 0, dvs. "Kupongkode er ikke i bruk".
Sletting av siste pris sletter også vare i Lexmark
Ved sletting av pris fjernes dette fra 3. partsløsningen Lexmark. Hvis prisen er den eneste gjenværende, da fjernes også selve varen fra Lexmark.
Expand
title
Konfigurasjon
Teknisk informasjon
Ved sletting av pris skapes det alltid utlegg til Lexmark itemprice-fil. Når den siste prisen, eneste gjenværende, på varen slettes, skal også selve varen fjernes fra Lexmark. For dette skapes utlegg til Lexmark item-fil.
Det blir stadig viktigere, spesielt for EG personell som må finne ut hvilken, av flere kampanjepriser, som er den som er aktiv i POS. Dette vises i både "Vare- og Prisvedlikehold" for ordinærpris, kampanjepris, medlemspris og tidsstyrt pris.
Det er laget mulighet for å bruke prefiks, som angir hvilken tabell som skal oppdateres, ved innlesing av JSON-filer i Chain Classic. Men inntil videre er ikke dette standard, derfor leses samtlige data på input-katalogen inn.
Expand
title
Konfigurasjon
Teknisk informasjon
For innlesing av JSON-filer må dedikert katalog for disse filene være angitt i systemparameter 946.
Ikke alle JSON-filer har prefiks som angir hvilken tabell som skal oppdateres (angis i systemalternativer 216). Inntil videre må derfor denne prefiks verdien fjernes: "Verdi1" = blank, slik at samtlige data på input-katalogen leses inn.
Hvis profil oppgitt på ny butikk mangler, opprettes denne i Chain Classic.
Profil kan ikke endres på eksisterende butikk.
RIGALnr og postnr sjekkes mot lovlig format i Chain Classic.
Alle punkter her logges til ny logg lrs\logg\jsonerr.txt.
Vare som ligger i flere aktive mixmatcher i samme eller forskjellige kampanjegrupper, legges til 3.-partsystemet Tokheim POS med hvert og en av de forskjellige kampanje-ID'ene som er i bruk i Chain Classic. Dette sørger for et korrekt grunnlag, når Tokheim POS skal velge beste tilbud for kunde.
