Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.12 skal alltid POS levere bonger i POSLog versjon 81.
Modul | Beskrivelse |
|---|---|
| Kasserer | Antall siffer for kasserernummer (RTC-34270) Kasserernummer kan ha inntil 9 siffer i Chain Classic. |
| Nettleser | Nettleser i Chain Classic (RTC-35855) Knapper som åpner nettleseren i Chain Classic vil alltid benytte Microsoft Edge. |
Når varetransaksjoner på reseptvarer registrert i POS eller i InStore App og resultatet oppdateres fra POSLog til Chain Classic, lagres disse på råvarene som ingrediensene i reseptvarene er skapt fra.
Samtidig logges det også en transaksjon på selve reseptvaren for oppfølging i rapporten "Varetransaksjonsliste".
|
Ved registrering av varetransaksjoner på reseptvarer i POS eller i InStore App, kan man følge opp transaksjonene på reseptvarene ved å velge avkryssingsboks for "Reseptvarer" i rapporten "Varetransaksjonsliste".

|
Det kan være behov for å kunne se varesalg fordelt på råvarene som ingrediensene i reseptvarer består av.
Rapporten "Salgsstatistikk" er tilpasset å vise dette dersom man velger avkryssingsboks for "Ingredienser".
Resultatet vil vise salget pr råvare med inntil 3 desimaler i antallskolonnene.
|
Ved utskrift av etikett fra InStore App er det mulig å parameterstyre om kriterier for varesalg, lagerbeholdning eller bestilling skal benyttes for å begrense antall etiketter som lages.
|
Når bestillinger/varemottak er skapt via programmet "Bestillingsfordeling Excel", vil dette vises i vedlikeholdsprogrammet for "Bestilling".


Via programmet "Utlegg av RIGAL statistikk" er det mulig å legge ut summen av varetransaksjoner pr. transaksjonstype og årsakskode til RIGAL F-fil (finansfil) totalt pr dag.
RIGAL-kode for disse postene er IVtnnnn, der t = transaksjonstype og nnnn er årsaksnummer inkl. ledende nuller (hentet fra Systemalternativ 1000).
Dette er parameterstyrt tilleggsfunksjonalitet.
|
I servicehandel modulen kan det finnes behov for å kunne se salg registrert på reseptvarer. Normalt lagres slike salgstransaksjoner på selve råvarene, men for reseptvarer lagres dette i egen tabell "resepttrans", som kun fungerer som logg og som grunnlag for rapport.
I servicehandel modulen kan det finnes behov for å kunne se salg registrert på ingredienser i reseptvarer. Normalt lagres slike salgstransaksjoner på selve reseptvaren, men for ingredienser lagres dette i egen tabell "ingredsalg", som kun fungerer som logg og som grunnlag for rapport.
|
Det kan være behov å kunne se både salg og svinn for ingrediensene som er benyttet i reseptvarer.
Tabellen "ingredsalg" oppdateres fortløpende med salg på råvarene som ingrediensene er skapt fra.
Dette salget lagres totalt pr råvare pr dag pr butikk.
|
Når funksjonalitet for veid kostpris er i bruk og denne er > 0, er det alltid denne som skal brukes som nettopris i POS for alle priser, både aktive og fremtidige.
Ved endring av veid kostpris i forbindelse med et varemottak, vil det skapes et utlegg til POS for alle aktive og fremtidige priser med den nye veid kostprisen i nettprisfeltet.
|
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.11 skal alltid POS levere bonger i POSLog versjon 81.
Modul | Beskrivelse |
|---|---|
| Bestilling | Lagring av varelinje i vedlikehold av Bestilling (RTC-35375) Lagring av ny/endret varelinje er optimalisert for forbedret ytelse når mange brukere jobber med dette samtidig |
| Bestilling/Varemottak | Antall varelinjer i bestilling og varemottak (RTC-35812) Det er mulig å bruke 5 sifret antall varelinjer i både bestilling og varemottak. Dette betyr at det kan være > 1000 varelinjer i en og samme ordre når neste tildelte radnr økes med 10. |
| Kampanjegruppe | Melding på skjerm når importerte varer sammenfaller i ulike kampanjegrupper (RTC-35734) Når to kampanjegrupper har samme start dato/tid eller slutt dato/tid og inneholder samme varer, avvises varene i den andre kampanjegruppen fordi de er sammenfallende. Meldinger om dette vil vises på skjermen. Dette gjelder også ved bruk av knappen "Hent nye varer". |
| Lager | Oppdatering av lager etter retur av samme vare på flere varelinjer i samme bong (RTC-34933) Dersom samme vare skal returneres flere ganger, tastes vanligvis antall inn på eksisterende varelinje. Lager vil da oppdateres med samlet antall. |
Rapporten "Sortimentliste Excel" tilbyr tre forskjellige, parameterstyrte, alternativer med 39, 53 eller 58 kolonner/felt i Excel rapporten.
De samme formatene kan også brukes til oppdatering/nyopplegg av varer ved import av VPI fra Excel.
|
I rapporten "Prisendring med etikettsimulering" vises strekkode for PLU/EAN med 1-13 siffer.
|
Dersom det ikke skal være mulig å skape manuelle varetransaksjoner i Chain Classic, kan knappene i verktøylinjen for nyopplegg og kopiering fjernes.
Med dette vil det kun være mulig å utføre motposteringer.

|
Generelt skal reseptvarer aldri være lagerstyrte. Det er råvarene som ingrediensene i reseptvaren er skapt fra, som skal være lagerstyrte.
Ved oppdatering av varetransaksjoner fra POSLog som er registrert på en reseptvare, vil det skapes varetransaksjoner i databasen på råvarene som ingrediensene i reseptvaren er bygd opp av.
Samtidig vil også lager oppdateres på de samme råvarene.
Det er også mulig å registrere varetransaksjoner i POSLog på en pakkevare. Da vil det skapes varetransaksjoner i databasen på innholdsvarene. Likeledes vil lager oppdateres på disse innholdsvarene.
Ved salg av en reseptvare (fra Tokheim POS eller EG POS) vil salget registreres på reseptvaren, mens lager også oppdateres på råvarene via de samme ingrediensene.
|
Normalt vil Chain Classic avrunde salgsbeløp fra bongen. Unntaket fra dette er når kredittsalg oppdateres til kundesalgstatistikken (grunnlag for utlegg av kredittsalg til Cash Settlement).
Da benyttes ferdig avrundede beløp fra bongen.
|
Ulike oppsett av Priskontroll medfører at det kan være praktisk å parameterstyre hvilken av de fem fanene som skal være vises når programmet startes.
|
Bruk av Excel og Word i Chain Classic fungerer kun dersom det finne en lokal installasjon av Office-programmene på arbeidsstasjonen.
Mangler dette, vil meldingen under forklare årsaken.
Disse meldingene vil også vises dersom det kun finnes en onlineløsning av Office. Chain Classic vil da ikke få kontakt med disse Office-programmene.

I aktiv varetelling der talte varer skal godkjennes og lager skal oppdateres, er det mulig å se hvilke varelinjer som allerede er oppdatert og hvilke som ikke er oppdatert.
Det er tre utvalgsalternativer for "Vis varer":

Knappen for "Lagerinformasjon" er ikke alltid aktiv i Vare- og Prisvedlikehold. Denne er inaktiv ved i følgende tre tilfeller:

Det er forskjeller mellom feltoppsett i Item Master og Chain Classic.
Vareoppdatering uten prisinformasjon er standard i Item Master men i utgangspunktet ikke tillatt i Chain Classic.
Det er derfor viktig med et riktig parameteroppsett for alle kunder.
|
Det anbefales å slå på full støtte for å søke frem eksisterende vare via tandemnummer når EAN for hovedvare i RIGAL VPI er ukjent i Chain Classic.
Dette vil forhindre at det skapes dubletter av samme vare. Eksempler på dette er:
I disse tilfellene vil det utføres et EAN/PLU-nr bytte der eksisterende hovedEAN i Chain Classic endres til tandemnummer og nytt hovedEAN fra RIGAL-VPI overtar.
|
Det kan parameterstyres om en profilprisendring via RIGAL VPI, skal fjerne evt. tilhørende lokale butikkpriser.
Dette gjelder ikke dersom butikkprisene har en aktiv eller framtidige kampanjepris, medlemstilbud eller en butikklokal mixmatch der varen inngår.
|
Endringer som fører til utlegg av bestillinger til RIGAL, logges for enklere oppfølging.
|
I "Lagerinformasjon" som åpnes via en knapp i verktøylinjen fra Vare-/Prisvedlikehold, og i andre program som viser lagerposter for flere butikker, vil kun lager for aktive og lagerstyrte butikker vises.
|
Mixmatchtype 35 er en gruppemix hvor det kan parameterstyres om prispost for gruppe 1 skal legges ut til Tokheim POS.
|
Beregning av nettopris på bestillingsrad, ved bruk av "Bestillingsfordeling Excel", utføres på samme måte som ved manuell registrering av bestilling eller ved bestilling opprettet fra POSLog.
Hvordan nettoprisen beregnes, er parameterstyrt og fungerer for varer som ikke er suppleringsvarer.
Antall gjenstående dager i aktiv kampanjeperiode eller antall dager til fremtidig kampanjeperiode kan også påvirke resultatet.
|
Generell ytelse i Chain Classic er framfor alt avhengig av serveroppsett og serverkonfigurasjon.
Optimalisert indeksbruk forbedrer denne ytelsen og gir brukerne en enda bedre brukeropplevelse.
|
Hjelpeprogram til bruk for EG personell.
|
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.10 skal alltid POS levere bonger i POSLog versjon 81.
Modul | Beskrivelse |
|---|---|
Bestilling | Behandling av varer merket "Ikke bestilling" i Bestillingsmodulen (RTC-31342)
|
Lager | Se lager for andre butikker (RTC-32343) Med funksjonsknappen "Lagerinformasjon" i Vare- og Pris-vedlikehold vises lagerbeholdning for butikkbruker dersom butikken har lagerpost på varen. Uten lagerpost på varen er knappen deaktivert. Med adgang til andre butikkers lagerbeholdning kan butikkbruker også se lagerbeholdning til disse andre butikkene i tillegg til egen lagerstatus. Dersom egen butikk ikke har lagerpost på en vare, kan butikkbruker likevel se lagerbeholdning til de andre butikkene. |
Utlegg til POS | Riktig bruk av punktum som desimaltegn ved eksport av mixmatch til POS (RTC-32523) Når butikklokal mixmatch eller kampanjegruppe lages i Chain Classic etter import av RIGAL X/J-fil og det evt. skapes nye butikkpriser som mangler, vil det alltid brukes punktum som desimaltegn i utlegg til POS. |
VPI-Sync | VPI-Sync og flere ubehandlede ordinære prisendringer i varekø (RTC-31186) Det hender at Chain Classic og POS "ikke er enige" om hva som er gjeldende ordinære pris. For at VPI-Sync ikke skal vise unødige avvik, vil siste "godkjente" pris i Chain Classic sendes til POS og benyttes for sammenligning mot tilsvarende pris der. |
Funksjonalitet for utskrift av små rabattprislapper finnes i "Butikkrutiner", "Varevedlikehold" og "Prisvedlikehold". Knappen vises alltid i "Butikkrutiner" men må spesifikt velges for bruk i de andre to vedlikeholdsprogrammene.
![]()
Det kan parameterstyres om det kun skal være mulig å angi prosentrabatt eller om det i tillegg skal være mulig å velge mellom kronerabatt eller rabattert pris.
Det er uansett kun mulig å angi to siffer. Angitt verdi skrives da ut under strekkoden i markert felt nedenfor (2 siffer).

|
Chain Classic har mange funksjoner som trenger en lokal installasjon av Excel på arbeidsstasjonen.
Microsoft tilbyr også en "online Excel-løsning" som ikke fungerer i Chain Classic, men det laget en løsning som forenkler åpning av Excel rapportene.
|
Det er mulig å legge ut alle data for en ny butikk til POS. Dette innebærer at utlegget normalt legges i katalogen "Sendes" for overføring til POS med mulighet for ekstra kopi av filene til en spesifisert katalog.
Men det kan også spesifiseres at utlegget kun skal legges ut til denne ekstra katalogen og ikke til POS.
|
Dersom e-post adressen skal benyttes som brukernavn for kasserer i andre løsninger, er det anbefalt å slå på krav om at e-post adresse må angis ved endring eller oppretting av ny kasserer.
|
Ved sletting av tandem legges alltid tandemen ut til filen tandem.butnr til POS. I tillegg kan det også legges ut slettepost via RIGAL V-fil.
|
Det er standard å avvise RIGAL-poster når de mangler EAN.
Men det finnes en parameterstyrt funksjonalitet for å søke fram varen via eksisterende profilpris.
|
Det er parameterstyrt om endringer i en godkjent bestilling skal eksporteres til ERP i RIGAL format.
Endringene logges også med brukerID og tidspunkt når man godkjenner eller fjerner godkjenning.
Dersom bekreftelse er i bruk, vil dette eller fjerning av bekreftelse også logges, både i bestillingshode og på bestillingsradene.
Dersom bekreftelse ikke benyttes, kan knappene for Bekreft/Fjerne bekreftelse skjules for brukeren.
|
Det er mulig å "simulere en "kampanjepris" via oppdatering av to ordinære prisendringer fra RIGAL VPI.
Dette kan være aktuelt for varer med Fastpris der det ikke er tillatt å benytte en vanlig kampanjepris i POS.
Man oppdaterer først en fremtidig "startpost" med ønsket prisendring og deretter en sluttpost der ordinær pris gjerne endres tilbake til opprinnelig pris.
Disse postene kan gjerne sendes inn i samme RIGAL V-fil.
Dette bør kun brukes i spesielle tilfeller og skal ikke erstatte bruk av standard kampanjegrupper med alle de fordeler det gir.
Dersom kredittkunder betaler inn for mye, kan kundesaldo bli negativ. Også negative beløp legge ut til Tokheim POS når oppdateringen kommer fra Chain Web via Chain Classic.
Når Chain Web er master for kunder, oppdateres alle endringer i Chain Classic.
Det er mulig å fjerne muligheten til å tilbakestille avviste prisendringsposter via en parameter.
Dette anbefales siden det kan oppleves forvirrende at man ikke får utført tilbakestillingen som forventet fordi postene i varekøen er ferdigbehandlet og fjernet.
I tillegg kan man velge å utsette godkjenning av manuelt endrede poster (utsalgsprisen er endret) for analyse av konsekvensene av endringen før prisendringene godkjennes samlet.
|
Bruk av standard Priskontroll kan via systemparameter tilpasses forskjellige behov, der priser som skal kontrolleres er tilgjengelige på aktive faner.
Dette oppsettet styrer om de fem fanene "Nye priser", "Ordinære prisendringer", "Kampanjepriser", "Mixmatch" og "Kampanjegruppe" skal være aktive eller ikke
Det er også mulig å velge hva som skal skje med en endret utsalgpris. Vanligvis vil endringen godkjennes umiddelbart, og da fjernes posten direkte.
Alternativt kan lagring og godkjenning utsettes slik at man kan analysere effekten av en prisendring. Posten vil da ligge igjen og fjernes først når den godkjennes.
Det er også mulig å fjerne funksjonalitet for "Tilbakestilling" av en avvist profilprisendring. Dette anbefales siden disse varekøpostene kun er tilgjengelig i et kort tidsrom inntil de er ferdigbehandlet.
Risikoen er at man ikke "rekker" å tilbakestille postene i den korte tiden mellom at man trykker på knappen "Avvis" og neste varekøbehandling.
I praksis varer dette "tidsvinduet" kun mellom 0-120 sekunder, deretter er det ikke mulig å bruke funksjonaliteten.
For de fleste vil det derfor være mindre forvirrende om denne funksjonaliteten fjernes helt.
|
Programmet "VPI maler" gir mulighet til å differensiere mellom forskjellige typer/behov av RIGAL V-fil import.
På den 1. fanen "VPImal" vises navn og nummer. På fanen "Felter i mal" vises alle poster i den aktuelle VPI malen.
|
For valg av hvilke mixmatchtyper en kjede benytter og tilpassing av disse, brukes nå programmet "Mixmatchtyper" på menyen Register - Generelle.
Dette menypunktet er i utgangspunktet tilgjengelig for alle, men systemadministrator kan endre på oppsett og hvilke mixmatchtyper som skal benyttes og vises for vanlige brukere.
Dette nye menyvalget er kun tilgjengelig i Chain Classic versjon 2.2 . |
Dersom parameter for dette er påslått, vil det ved oppdatering av lager skapes et automatisk lagerutlegg i JSON format.
|
I rapportene "Butikkoppgjør" og "Butikkoppgjør pr. kasserer" er det støtte for bruk av inntil 9-sifret kasserernummer.
Når Item Master skaper en ny vare, skal denne normalt sendes som to poster (en VAR post og en PRI post) via RIGAL V-formatet til Chain Classic.
VAR posten må alltid sendes først, og i denne oppdateres også noen felt (f.eks. sortimentskode) som egentlig ligger på pris i Chain Classic.
Ved oppdatering av påfølgende PRI post, vil disse feltene beholde sine originale verdier fra VAR posten.
|
|
Det er mulig å slette både en kampanjepris og et medlemstilbud med samme start/slutt dato via samme RIGAL V-fil. Dette gjelder både aktive og fremtidige tilbud.
I tillegg kan fremtidige ordinære prisendringer slettes.
|
Ved sletting av tandem via post i RIGAL V-fil dette logges:
|
Ved behov for eksport av varehierarkiet til "Cloud", benyttes rapporten "Varehierarki Excel" under menyen Rapporter - Vare. Rapporten lages kun til Excel.
Merk at i siste kolonne kombineres varegruppe og undergruppe med 4 siffer (inkl. ledende nuller) for hver feltverdi (til sammen 8 siffer).
Varegruppe 1 med undergruppe 10 vil dermed få verdien "00010010" i dette kombinerte feltet.
Utvikling av generelle oppdateringer, fra InStore App, sikrer god dataflyt.
|
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.09 skal alltid POS levere bonger i POSLog versjon 81.
Ved endring av EAN/PLU blir nå følgende lagt ut til Lexmark:
|
Når et tandemnummer er angitt på en vare i RIGAL vare-fil, og dette nummer allerede er knyttet til en annen hovedvare, blir tandemnummeret "flyttet" fra gammelt til nytt hovedvarenummer forutsatt at systemparameter 632 er satt.
Ved denne operasjonen har det tidligere ikke kommet noe utlegg til Lexmark, mens det nå blir lagt ut filer både til totalbutikk (libitemlex) og øvrige butikker (priceitemlex).
|
Ved sletting av tandemnummer på en vare legges det nå ut Lexmark-melding både til totalbutikk (libitemlex) og øvrige butikker (priceitemlex).
|
Omsetningskrav for etikettutskrift i Lexmark kan settes for alle etikettskapende endringer. Det vil si at det må ha vært omsetning innenfor et gitt antall dager tilbake i tid for at etikett skal skrives ut.
Systemparameter 878 har to verdier, én for kampanjepris/medlemstilbud og én for alle øvrige endringer. Settes parameterverdi til 0 vil det ikke være noe krav om omsetning på varen for at etikett skal skrives.
Disse parameterverdiene settes i utgangspunktet på kjedenivå (System parameter), men vil kunne overstyres for enkeltbutikker. Butikkbrukere vil kunne endre disse verdiene via fanen "Butikkparametere" i program for vedlikehold av butikkregistret.
|
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.08 skal alltid POS levere bonger i POSLog versjon 81.
Modul | Beskrivelse |
|---|---|
Kampanjegruppe | Sletting av hel mixmatch i kampanjegruppe (RTC-32186) Det er mulig å slette en komplett mixmatch i kampanjegruppe. Det blir da gjort et utlegg til POS av kun en post for sletting av mixhode. |
Rapporter | "Spørring på pris" i rapport (RTC-31806) I mange omsetningsrapporter for kasserer er det mulig å se antall spørringer på pris som er utført i kassen. Det er totalt fire varianter av dette som kan medføre at telleren øker:
|
Varevedlikehold | Lagerinformasjon i vare- og prisvedlikehold (RTC-30139) Ved å bruke knappen "Lagerinformasjon" i "Vare- og Prisvedlikehold" vises lager for varen som er i fokus i en søkeliste for alle butikker som brukeren har tilgang til og som har lagerpost.
|
Ved bruk av papiretiketter vil det ved avslutning av "Priskontroll" eller "Manuelt varemottak" komme opp en dialog for etikettutskrift med valg av etikettype og skriver.
Skal standard etiketttype og skriver benyttes, beholdes standardinnstillingene som vist under. Etikettype og skriver velges da automatisk.

Dersom dette skal overstyres, kan andre alternativer velges i dette skjermbildet.
|
Det er mulig å parameterstyre om resept-/ingrediensinformasjon skal legges ut til Tokheim POS.
Standard er at informasjonen legges ut, men dersom dette ikke er ønskelig kan dette endres via en systemparameter.
|
Det er mulig å parameterstyre oppdatering av varemottak av D-pakk varer via RIGAL slik at antall av D-pakk varen blir multiplisert med antall i pakning (småpakning).
Dette gjelder kun for utvalgte leverandører.
|
I rapporten "Grunnlag bestilling" er det på fanen "Alternativer" nå mulig å benytte utvalg for "Min." og "Maks." disponibelt antall.
Standardverdier er fra 0 til 99999. Ved bruk av minimumsverdi = 0 vil også varer med negativt disponibelt antall tas med i rapporten.
Angir man en verdi større enn 0 i dette feltet, vil kun varer med disponibelt antall større eller lik denne verdien bli tatt med.
Fremtidige ordinære prisendringer kan slettes via RIGAL V-fil ved å sette verdien C i felt 7.1.5 Kode.
Prisendringene vi da slettes i Chain Classic og nødvendige utlegg sendes til POS.
Ved oppdatering av bestillingskriterier via Excel fra 3. part, finnes det 2 parameterstyrte alternativer.
Innholdet i Excel filen skal bestå av følgende felt, hvorav de i blått kan endres:
Ny butikkpost kan opprettes eller en eksisterende post kan slettes. Antall kan endres (0 er gyldig).
|
Det er mulig å parameterstyre oppdatering av prisendringer fra RIGAL V-formatet der EAN = 0.
Forutsetning for dette er krav til unik kombinasjon av varenr og salgsenhet (vektkode) i RIGAL-postene.
Dersom dette er oppfylt, skal kjent vare i Chain Classic kunne søkes fram via kombinasjonen av varenr og salgsenhet.
Dersom poster med EAN = 0 ikke finnes via en unik kombinasjon av varenr og vektkode, vil postene avvises med en feilmelding i VPI feilloggene.
PRI-post med ukjent EAN, i Chain Classic, vil bli avvist. |
|
Varemottak for pakkevare fra InStore App spesialbehandles ved oppdatering fra POSLog.
Ved mottak av pakkevaren vil det bli opprettet varetransaksjoner for varen(e) som inngår i pakkevaren,
Lager vil også bli oppdatert for disse varene.
|
Det kan parameterstyres om en RIGAL varemottaksfil (I-formatet) der alle vareradene har mottatt antall = 0, også skal behandles. Da vil ordren få status "Mottatt".
Det skapes en RIGAL "kvitteringsfil" som kopi av de opprinnelige RIGAL postene.
|
Kun for bruk med Tokheim POS. Om det finnes en "L15-verdi", vil dette eksporteres til Reporting.
Dersom en slik verdi ikke finnes, vil feltet "Mengde" legges ut.
|
I datoutvalg er årstall standardisert til to siffer for alle rapportutvalg med en hjelpeknapp for kalenderoppslag.

Når ItemMaster (IM) kun sender vareinformasjon via RIGAL V-formatet til Chain Classic, blir ikke postene oppdatert før prisinformasjonen er på plass.
Det er innført et parameterstyrt unntak fra dette. Når denne parameteren slås på, vil VPI-poster uten pris bli oppdatert. Pris beholdes da uendret.
|
Ved nyopplegg av kampanje- og medlemstilbud er det parameterstyrt om det er tillatt med delvis overlapping.
Dersom dette ikke er tillatt eller det er lagt inn en ugyldig verdi med samme start-/sluttid, forklares dette med informative feilmeldinger i brukergrensesnittet dersom varene avvises.
Dette gjelder både i Kampanjegruppe og for manuelle kampanjer (skapt i Prisendring) uansett metode for innhenting av data.
I tillegg til feilmeldingen i brukergrensesnittet, kan loggpostene hentes opp via knappen "Avviste varer i kampanjegruppe".

Den samme knappen finnes også i programmet for "Mixmatch".
Tandemnummer som også finnes som hovedvare, er noe som må korrigeres.
Et hjelpeprogram kan korrigere dette ved å fjerne tandemnummeret i Chain Classic og legge ut sletting av tandem til POS.
|
Forhindre at feilposter i dette JSON-formatet blir liggende ubehandlet
|
På fanen "Feltverdier i butikk" i "Varevedlikehold" og "Prisvedlikehold" kan man velge hvilke felt som butikkene i en kjede skal kunne se og endre.
Uinteressante felt skjules. Dette er parameterstyrt.
|
Ved sletting av bruker i Chain Classic slettes alle brukerrelaterte data.
|
Når en butikkpris skal slettes, sjekkes det nå om det finnes noen aktive eller fremtidige lokale butikkmix'er der denne varen inngår.
Om det er tilfelle, vil det legges ut slettepost for disse postene til POS.
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.07 skal alltid POS levere bonger i POSLog versjon 81.
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. |
| RIGAL | DUN-nummer i RIGAL VPI (RTC-30127) 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. |
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.
|
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.
|
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.

|
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".
|
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.
|
Denne funksjonaliteten brukes når en butikk kun skal ha profilpriser, og aktive lokale butikkpriser skal derfor fjernes.
|
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.
Loggfilen mottawebmmdd.butnr legges daglig ut på loggkatalogen via standard utlegg.
|
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.
|
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.
Utlegg av info for servicehandels-varer kan parameterstyres for å forhindre varer fjernes utilsiktet fra en resept i Tokheim POS.
|
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.06 skal alltid POS levere bonger i POSLog versjon 81.
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. |
| Varemottak | Utskrift av prislapper i varemottak (RTC-28791) 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.
|
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.
|
Hvis gavekort og/eller tilgodelapp brukes for å betale et nytt gavekort lages en egen finanstransaksjon for dette.
|
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.
|
Det er tre mulige parameterstyrte alternativer for hvordan nettopris skal oppdateres via RIGAL/POSLog.
|
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.
|
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".
|
I programmet "Varetransaksjoner" vises alle transaksjoner uavhengig av transtype.
Det er kun mulig å legge opp/kopiere/motpostere følgende transaksjonstyper:
Alternativ:
Følgende transaksjonstyper kan ikke registreres, kopieres eller motposteres:
Knapp for "Kopiering" og "Motpostering" (= sletteknapp) er deaktivert for de transaksjonstyper det ikke er tillatt å registrere.
|
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".
|
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.
|
Som følge av begrensninger i 3. partssystemet Tokheim POS er antall tegn i varenavn, ved eksport, nå begrenset til 20 tegn.
|
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.
|
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.
|
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:
1: "Etikettekster"
2: "Vektdeklarasjon"
3: "Vareinformasjon"
4: "Teknisk informasjon"
|
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.
|
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:
På fanen "Vare":
- hgr
- ugr
- prodnr
- sgr
- fgr
- mvagr
- bransje og agr dersom bransje > 0
- enva
- varetype
- lager
- bestill
- enhet
- aktiv
- opris
- krabatt
- fabrikatnr
- chgmva
- lokalstyrt
På fanen "Tillegg vare":
- modellnr/modellnr2
- fargenr
- storrnr
- fabrikatnr
- matrialkode
- sesongnr
- garantikl
- individtype
- idkrav
- trykkbilde
- opprinnelse
- alarmvare
- anbrekk
- kunlot
|
Dokument status:
Dato:
Med oppgradering til Chain Classic versjon 2.2.0.0.05 anbefales det at POS leverer bong-format i POSLog versjon 81.
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). |
| Vareinformasjon | Vareinformasjonstekst (RTC-27650) Når det gjelder beskrivelse av vare i vareinformasjonstekst, er det ingen begrensning i tekstlengde. |
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.
|
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.
|
|
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".
|
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).
Dokument status:
Dato:
Ved oppgradering til Chain Classic versjon 2.2.0.0.04 anbefales det at POS leverer bong-format i POSLog versjon 81.
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. |
| Lager | Utlegg av lagerfil til Chain Web (RTC-27548) 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. RIGAL V-fil og kampanjegruppedata (RTC-27899) 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.
|
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*.*)
|
Det er mulig å unngå oppdatering på varer, ved endring via RIGAL V-/J-filer, hvis det gjelder parameterstyrte varegrupper og/eller produsenter.
Avvisninger logges i noen av filene VPI-err*.* eller err*.*
|
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.

|
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.
|
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:
Vedlikehold av Tankstatus:
Loggrapport loggtype 80:
|
Ved bruk av 3. partssystemet Tokheim kan manuell oppdatering, generelt vedlikehold eller sletting av registrert tankstatus gjøres i drivstoffprogrammet "Manuell tankstatus".
Resultat legges ut til "Reporting".
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.
|
Dokument status:
Dato:
Ved oppgradering til Chain Classic versjon 2.2.0.0.03 anbefales det at POS leverer bong-format i POSLog versjon 81.
Modul | Beskrivelse |
|---|---|
| Bestilling | Butikk uten "Bestilling" (RTC-19163) 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. |
| Lexmark integrasjon | Utlegg av tilbudsposter til Lexmark (RTC-26601) 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. |
| RIGAL | RIGAL-oppdatering av "Fastpris" (RTC-26656) 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". |
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.

|
Automatisering av mottak av varer i butikk fører til at "Mottak av webordre" i Chain Classic ikke brukes, men at statusfelt fortsatt oppdateres.
|
Hvis kundeendringer skal logges er det mulig å sette opp hvilke kundeposter som skal logges ved endring.
Endringslogg med én post pr. endret feltverdi skrives til filen "chgkunde<mmåååå>.txt" på "LRS"/"logg-katalogen".
Ny rapport "Kundeendringslogg" som viser denne loggen ligger under "Rapport"/"Logger".
|
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.
|
Ved bruk av programmet "Slette/fjerne fra kasse" vil leverandørnr og leverandørnavn også vises i alle rapporter som lages, uansett utvalg.
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:
|
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".
|
Rapporten "Sortimentsliste Excel" kan lages med standard 39 kolonner eller via parameterstyring med utvidet format, alle 53 kolonnene.
|
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.
|
Dokument status:
Dato:
Ved oppgradering til Chain Classic versjon 2.2.0.0.02 anbefales det at POS leverer bong-format i POSLog versjon 81.
Modul | Beskrivelse |
|---|---|
| Wet Stock | Wet Stock mengder (RTC-24636) 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.
|
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.
|
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.
|
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.
|
Ved innlesing av JSON-fil fra StoreMaster inngår også disse feltene:
|
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.
|
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.
|
"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.
|
Temperaturkompensert mengde "L15" vises i eget felt i program for "Tankstatus".
Hvis denne verdien = 0 vises ikke feltet og nivåverdien legges ut til "Reporting" i stedet.
|
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.
Dokument status:
Dato:
Ved oppgradering til Chain Classic versjon 2.2.0.0.01 anbefales det at POS leverer bong-format i POSLog versjon 81.
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. |
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.

Det er mulig å begrense utlegg til el. etiketter og ferskvarevekter til kun de faktiske endringer som gjelder disse løsningene.
|
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".
|
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.
|
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.
|
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.
|
Det er mulighet å angi butikk som Debio-godkjent, dette fører til at økologisk merke alltid legges ut til vektformatet XML.
|
Sletting av pris, og vare hvis det kun finnes én pris, utføres ved å sette funksjonskode "S" i felt 5 i RIGAL V-fil. Sletting utføres da umiddelbart.
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.
|
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.