Chain Classic versjon 2.2.0.0.06

Dokument status: 

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.2.0.0.06 anbefales det at POS leverer bong-format i POSLog versjon 81. sjekker forutsetninger

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.  

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.

Prisendring av utmeldt vare via RIGAL

(RTC-29117)

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.

Teknisk informasjon
I systemparameter 101 angis antall dagers forsinkelse ved sletteposter fra leverandør.

Oppdatering av mixmatcher i POS ved endring av gjeldende unntaksvaregrupper

(RTC-28210)

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.

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

(RTC-27954

Hvis gavekort og/eller tilgodelapp brukes for å betale et nytt gavekort lages en egen finanstransaksjon for dette. 

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.

Integrasjon med Q-bank (bildebank)

(RTC-26841)

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. 

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.
  • Videre brukes https-kall til kunde sitt bildearkiv:
    For eksempel:  https://media."kunde".no/butikkflater/pos_button/

Nettoprisendring ved oppdatering av varemottak

(RTC-28738)

Det er tre mulige parameterstyrte alternativer for hvordan nettopris skal oppdateres via RIGAL/POSLog.

Teknisk informasjon
Systemparameter 977 styrer hvordan nettoprisendringer skal oppdateres via RIGAL/POSLog.

Rulle tilbake tellesvinntransaksjoner ved nullstilling av salgsdag

(RTC-28665)

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. 

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. 

Endre nettopris direkte i elektronisk varemottak

(RTC-28547)

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".

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.

Ny parameter kan ikke brukes sammen med systemparameter 799, som er en spesialinnstilling for Coop Svalbard der engrospris kan endres direkte i samme skjermbilde.

Vedlikehold av poster i "Varetransaksjoner"

(RTC-28638)

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.

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.

Oppdater klientfiler i bakgrunn

(RTC-28374)

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".

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"

(RTC-29240)

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.

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. 

Trunkering av varenavn ved eksport Tokheim POS

(RTC-28646)

Som følge av begrensninger i 3. partssystemet Tokheim POS er antall tegn i varenavn, ved eksport, nå begrenset til 20 tegn.

Teknisk informasjon
Alle "NAM"- poster, uansett type, vil trunkeres etter 20 tegn hvis varenavn i Chain Classic inneholder flere enn disse 20 tegn.

Feil butikknummer i POSLog

(RTC-28614)

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. 

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.

Overgang til kampanjegruppeutlegg

(RTC-28386)

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.  

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å

(RTC-27990)

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"

Teknisk informasjon

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

(RTC-28298)

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.

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.

Blanke felt eller standardverdier for ny vare

(RTC-28978)

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

Teknisk informasjon
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: 

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon  2.2.0.0.05 anbefales 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).   

Vareinformasjon

Vareinformasjonstekst (RTC-27650)

Når det gjelder beskrivelse av vare i vareinformasjonstekst, er det ingen begrensning i tekstlengde.

Logging av endringer i kundeordrer

(RTC-27035)

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.

Teknisk informasjon

Systemparameter 973 kontrollerer hva av endringer i kundeordre som skal logges.

Merk! Det finnes allerede en annen standardlogg for prisendringer i kundeordre som logger alle prisendringer som utføres uavhengig av beløp og størrelse på prisreduksjon til loggfil "kordMMDD.butnr".

Logging av internoverføring

(RTC-28535)   

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. 

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

(RTC-28230)

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

(RTC-27713)

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". 

Teknisk informasjon

Dokumentasjon for RIGAL I-fil er oppdatert på portalen: 

  • "Melding til leverandør" legges ut i feltnummer 30.56
  • "Referansetekst" legges ut i feltnummer 30.57

Varetransaksjonsliste Excel

(RTC-26927)

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). 


Chain Classic versjon 2.2.0.0.04

Dokument status: 

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.   Sjekk at dette er riktig forusetninger!

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. 

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.

Oppdatering av ordinærpris i kampanjegruppe

(RTC-27852)  

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.

Teknisk informasjon
Systemparameter 838 åpner for denne funksjonaliteten

Angi fast bruttofortjeneste på RIGAL-oppdaterte varegrupper

(RTC-26674)

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. 

Logging av endringer på utvalgte varefelt

(RTC-27142)

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.

Teknisk informasjon
Valg av VPI-mal gjøres i systemparameter 741. 

Logging av RIGAL X-filer i VPI-logg

(RTC-27143)

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*.*) 

Teknisk informasjon
Systemparameter 969 = 1 slår på denne funksjonaliteten.

Spesifiserte varegrupper/produsenter skal ikke oppdateres via RIGAL VPI

(RTC-26673)    

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*.*

Teknisk informasjon

Denne funksjonaliteten er en kundespesifikk løsing! Øvrige kunder skal ikke bruke disse parameterne.

Utvalgte varegrupper og produsenter settes opp i systemparameter 967 og 968.

Systemparameter 707 = 1 fører til at avvisning logges i filen VPI-err*.* og hvis systemparameter 707 = 0 logges det i filen err*.*

Ved avvisning skrives følgende til loggene:

  • Avvisning pga varegruppe - "Varegruppe er sperret for vpi-mottak:"" + varegruppe og varegruppetekst
  • Avvisning pga produsent - "Produsent er sperret for vpi-mottak:" + produsentnr og navn

Strekkoder i lagerrapport "Feilliste"

(RTC-27037)

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.

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":

Avskriv uleverte rader ved første varemottak

(RTC-26858)

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.

Teknisk informasjon

For denne funksjonalitet gjelder:

  • Systemparameter 477 = 1
  • Systemparameter 860 = 1 (utlegg ved mottak i POSLog)

L15 funksjonalitet pr. butikk

(RTC-26923)

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:

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:

  1. Legg opp butikkene manuelt.
  2. 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.

Manuell tankstatusregistrering 

(RTC-26929)

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".

JSON til Inventory Module 

(RTC-27043)

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. 

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. 


Prisendring av utmeldt vare via RIGAL

(RTC-29117)

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.

Teknisk informasjon
I systemparameter 101 angis antall dagers forsinkelse ved sletteposter fra leverandør.

Oppdatering av mixmatcher i POS ved endring av gjeldende unntaksvaregrupper

(RTC-28210)

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.

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

(RTC-27954

Hvis gavekort og/eller tilgodelapp brukes for å betale et nytt gavekort lages en egen finanstransaksjon for dette. 

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.

Integrasjon med Q-bank (bildebank)

(RTC-26841)

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. 

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.
  • Videre brukes https-kall til kunde sitt bildearkiv:
    For eksempel:  https://media."kunde".no/butikkflater/pos_button/

Nettoprisendring ved oppdatering av varemottak

(RTC-28738)

Det er tre mulige parameterstyrte alternativer for hvordan nettopris skal oppdateres via RIGAL/POSLog.

Teknisk informasjon
Systemparameter 977 styrer hvordan nettoprisendringer skal oppdateres via RIGAL/POSLog.

Rulle tilbake tellesvinntransaksjoner ved nullstilling av salgsdag

(RTC-28665)

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. 

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. 

Endre nettopris direkte i elektronisk varemottak

(RTC-28547)

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".

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.

Ny parameter kan ikke brukes sammen med systemparameter 799, som er en spesialinnstilling for Coop Svalbard der engrospris kan endres direkte i samme skjermbilde.

Vedlikehold av poster i "Varetransaksjoner"

(RTC-28638)

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.

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.

Oppdater klientfiler i bakgrunn

(RTC-28374)

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".

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"

(RTC-29240)

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.

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. 

Trunkering av varenavn ved eksport Tokheim POS

(RTC-28646)

Som følge av begrensninger i 3. partssystemet Tokheim POS er antall tegn i varenavn, ved eksport, nå begrenset til 20 tegn.

Teknisk informasjon
Alle "NAM"- poster, uansett type, vil trunkeres etter 20 tegn hvis varenavn i Chain Classic inneholder flere enn disse 20 tegn.

Feil butikknummer i POSLog

(RTC-28614)

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. 

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.

Overgang til kampanjegruppeutlegg

(RTC-28386)

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.  

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.  

Övergång till kampanjgruppsutlägg  

(RTC-28386)   Svensk oversetting av saken over, da denne ikke var en del av 2.1.1. patch 36 releasen,  for resten av de svenske sakene se den svenske teksten av releasen

Användning av kampanjgruppsutlägg rekommenderas då det betyder mycket för felsökning vid avvikelse, men viktigast är säkerhet och prestanda som är betydligt bättre. Funktionaliteten kan aktiveras manuellt via systemparameter, men det rekommenderas att använda särskilt program för detta för snabbare och säkrare resultat vid konvertering av existerande kampanjgrupper till nytt utlägg i kampanjgruppsformatet.

Teknisk information

Programmet som ska användas är: "LRS"/"Parameter"/"Aktivera kampgrutlägg till POS"

Funktionaliteten kan aktiveras manuellt genom att sätta systemparameter 750 = 1, men då måste kampanjerna konverteras manuellt genom att kopiera, avsluta och godkänna de kopierade kampanjgrupperna. Genom att använda anpassat program för detta inkluderas kontroll av varuköposter och borttagning i POS, kampanjgrupperna startas också om innan nytt utlägg i kampanjgruppsformatet.

Begrense mulighet å lage informasjonstekst under HK-nivå

(RTC-27990)

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"

Teknisk informasjon

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

(RTC-28298)

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.

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.

Blanke felt eller standardverdier for ny vare

(RTC-28978)

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

Teknisk informasjon
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: 

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon  2.2.0.0.05 anbefales 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).   

Vareinformasjon

Vareinformasjonstekst (RTC-27650)

Når det gjelder beskrivelse av vare i vareinformasjonstekst, er det ingen begrensning i tekstlengde.

Logging av endringer i kundeordrer

(RTC-27035)

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.

Teknisk informasjon

Systemparameter 973 kontrollerer hva av endringer i kundeordre som skal logges.

Merk! Det finnes allerede en annen standardlogg for prisendringer i kundeordre som logger alle prisendringer som utføres uavhengig av beløp og størrelse på prisreduksjon til loggfil "kordMMDD.butnr".

Logging av internoverføring

(RTC-28535)   

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. 

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

(RTC-28230)

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

(RTC-27713)

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". 

Teknisk informasjon

Dokumentasjon for RIGAL I-fil er oppdatert på portalen: 

  • "Melding til leverandør" legges ut i feltnummer 30.56
  • "Referansetekst" legges ut i feltnummer 30.57

Varetransaksjonsliste Excel

(RTC-26927)

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). 


Chain Classic versjon 2.2.0.0.04

Dokument status: 

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.   Sjekk at dette er riktig forusetninger!

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. 

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.

Oppdatering av ordinærpris i kampanjegruppe

(RTC-27852)  

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.

Teknisk informasjon
Systemparameter 838 åpner for denne funksjonaliteten

Angi fast bruttofortjeneste på RIGAL-oppdaterte varegrupper

(RTC-26674)

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. 

Logging av endringer på utvalgte varefelt

(RTC-27142)

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.

Teknisk informasjon
Valg av VPI-mal gjøres i systemparameter 741. 

Logging av RIGAL X-filer i VPI-logg

(RTC-27143)

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*.*) 

Teknisk informasjon
Systemparameter 969 = 1 slår på denne funksjonaliteten.

Spesifiserte varegrupper/produsenter skal ikke oppdateres via RIGAL VPI

(RTC-26673)    

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*.*

Teknisk informasjon

Denne funksjonaliteten er en kundespesifikk løsing! Øvrige kunder skal ikke bruke disse parameterne.

Utvalgte varegrupper og produsenter settes opp i systemparameter 967 og 968.

Systemparameter 707 = 1 fører til at avvisning logges i filen VPI-err*.* og hvis systemparameter 707 = 0 logges det i filen err*.*

Ved avvisning skrives følgende til loggene:

  • Avvisning pga varegruppe - "Varegruppe er sperret for vpi-mottak:"" + varegruppe og varegruppetekst
  • Avvisning pga produsent - "Produsent er sperret for vpi-mottak:" + produsentnr og navn

Strekkoder i lagerrapport "Feilliste"

(RTC-27037)

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.

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":

Avskriv uleverte rader ved første varemottak

(RTC-26858)

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.

Teknisk informasjon

For denne funksjonalitet gjelder:

  • Systemparameter 477 = 1
  • Systemparameter 860 = 1 (utlegg ved mottak i POSLog)

L15 funksjonalitet pr. butikk

(RTC-26923)

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:

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:

  1. Legg opp butikkene manuelt.
  2. 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.

Manuell tankstatusregistrering 

(RTC-26929)

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".

JSON til Inventory Module 

(RTC-27043)

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. 

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: 

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.   Sjekk at dette er riktig forusetninger!

Forbedringer

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". 

Ekskludere varegruppe fra hurtigprising i mixmatch

(RTC-26094)

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.

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

(RTC-25897)

Automatisering av mottak av varer i butikk fører til at "Mottak av webordre" i Chain Classic ikke brukes, men at statusfelt fortsatt oppdateres.

Teknisk informasjon
Funksjonalitet brukes kun for webshop type, med oppsett: systemparameter 610 = 1.

Logging av kundeendringer

(RTC-26092)

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".

Teknisk informasjon
Systemalternativer 1093 inneholder de kundefelter som kan aktiveres for logging. For logging MÅ logisk hukes av på hver post det ønskes oppfølging på.

Provisjonssalg - butikk i butikk

(RTC-26096)

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.

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 

(RTC-26095)

Ved bruk av programmet "Slette/fjerne fra kasse" vil leverandørnr og leverandørnavn også vises i alle rapporter som lages, uansett utvalg.

Forhindre mixmatchkonflikt

(RTC-25910)

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:

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.

Forventet dato i "Bestillingsfordeling Excel"

(RTC-26399)

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".

Teknisk informasjon
Denne funksjonaliteten gjelder ved bruk av "Bestillingsfordeling Excel", og både systemparameter 843 og 818 må være aktive.

Sortimentsliste Excel

(RTC-25218)

Rapporten "Sortimentsliste Excel" kan lages med standard 39 kolonner eller via parameterstyring med utvidet format, alle 53 kolonnene.

Teknisk informasjon
Systemparameter 964 = 1 slår på utvidet format i rapporten "Sortimentsliste Excel".

Hvem er "sjef" for mixmatch 

(RTC-25909)  

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.  

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: 

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.    Legg inn riktig forusetninger

Forbedring

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".

Mixmatch med varer som mangler i vareregisteret

(RTC-24623)

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.

Teknisk informasjon

Denne funksjonaliteten aktiviseres med systemparameter 960.

Oppsett for inkluderte mixtyper skjer pr. mixtype via systemalternativer 132 hvor verdien "Integer" > 0.

Ved avvik logges dette i loggtabell loggtype 15.

Alternativ sletting av mixmatch

(RTC-24624)

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. 

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

(RTC-23534)

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.

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

(RTC-24960)

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. 

Teknisk informasjon
Denne funksjonalitet gjelder kun hvis systemparameter 839 er i bruk.

Innlesing av JSON-fil fra StoreMaster

(RTC-25721)

Ved innlesing av JSON-fil fra StoreMaster inngår også disse feltene:


Teknisk informasjon

Innholdet i det siste feltet (andre butikker med lager for som denne butikken kan se) er resultat av oppsett i Systemalternativer for butikk - 2. 

Bruk av laveste nettopris i "Bestillingsfordeling Excel"

(RTC-25219)

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.

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

(RTC-25221)

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.

Teknisk informasjon
Utvidet kontroll av nettopris ved "Manuelt varemottak" og bruk av "Bestillingsfordeling Excel" slåes på med systemparameter 962.

Wet Stock - justering av tanknivå

(RTC-24621)

"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.

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"

(RTC-25555)

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.

Teknisk informasjon
For å legge ut L15-verdien til "Reporting" må systemalternativer 800 settes med "Integer" = 11 for et nytt 11. felt i utlegg for tankstatus.

Oppdatering av tankstruktur til Tokheim

( RTC-24058)

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:  

Dato:  fyll inn riktig 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.    Legg inn riktig forusetninger

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

(RTC-23527)

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

(RTC-23517)

Det er mulig å begrense utlegg til el. etiketter og ferskvarevekter til kun de faktiske endringer som gjelder disse løsningene.

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).     

Skap lokal kampanje fra InStore App

(RTC-18658)

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".

Ikke legg ut slettede varer til POS 

(RTC-23707)

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".

Teknisk informasjon
Systemparameter 906 må være riktig satt opp for "Sletting av varer" fra spesialliste 100000002. 

Importere EAN/PLU fra CSV-fil til vareliste

(RTC-23728)

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".

Montering som linkvare

(RTC-23520)

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.

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.

Vektutlegg ved sletting av post i næringsinnhold

(RTC-24257)

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.

Næringsinnhold i vektutlegg til Finnvacum

(RTC-24372)

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.

Gjenopprett manglende varekøposter

(RTC-24400)

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.  

Eksternt MixID i kampanjegruppe

(RTC-24514)

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.

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

(RTC-24697)

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.

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.

Utlegg av økologisk-merke i vektformatet XML

(RTC-24625)

Det er mulighet å angi butikk som Debio-godkjent, dette fører til at økologisk merke alltid legges ut til vektformatet XML.

Teknisk informasjon

Systemparameter 958 = 1

I tillegg, butikk som skal legge ut økologisk merknad til vektformat XML, MÅ settes opp for dette ved å huke av for "Debio" i butikkregisteret.

Sletting av pris via RIGAL

(RTC-24622)

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. 

Aktivt varekønr i "Vare- og Prisvedlikehold"

(RTC-24541)

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.

Innlesing av data fra Store Manager (JSON)

(RTC-25314)

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.

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.

Kampanje-ID til Tokheim POS 

(RTC-25331)

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.