You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 111 Next »

Chain Classic versjon 2.1.1.0.45

RELEASED   

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.1.1.0.45 skal POS alltid levere bonger i POSLog versjon 81.




Chain Classic versjon 2.1.1.0.44

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.1.1.0.44 skal POS alltid levere bonger i POSLog versjon 81

Forbedringer

Modul

Beskrivelse 

Elektroniske etiketter

Utlegg til elektroniske etiketter ved forlengelse av tilbudspriser (RTC-39381)

Ved forlengelse av en tilbudspris (kampanjepriser eller medlemstilbud), ny sluttdato på aktivt tilbud, skal det alltid legges ut oppdaterte poster med tilbudspriser til Lexmark.

Elektroniske etikettløsninger derimot behøver ikke denne oppdatering da disse får egne utlegg når tilbudsprisen avsluttes.

Kampanjegruppe

Kopiering av kampanjegruppe for "Team" (RTC-39969)

Når en team-kampanjegruppe kopieres, er det mulig å kopiere denne til en kampanjegruppe for butikk eller profil.

RIGAL 


Framtidig prisendring og utmeldt vare (RTC-39744)

Dersom en vare meldes ut via RIGAL, settes sortimentkode til "Utmeldt" og bestillingsnummer nullstilles på pris. 

Det lages også en slettepost med parameterstyrt slettedato X dager fram i tid.

Dersom det etter dette kommer nye eller framtidige prisendringer for samme vare, vil dato for slettepost flyttes fram i tid i forhold til den nye prisendringsdatoen, mens sortimentskode "Utmeldt" og nullstilt bestillingsnummer beholdes.

Tankstatus

Registrering av flere tankstatus poster på samme dag (RTC-39257)

Det er mulig å registrere flere tankstatuser på dagens dato, så lenge de registrerte målingene har et unikt tidspunkt. 

Forhindre tilbudspriser på "fastpris" varer

(RTC-39428)

Det er mulig å forhindre opplegg av tilbudspriser (kampanjepris og medlemstilbud) på varer med fastpris. 

Manuell prisendring:
Valg for å skape tilbudspris vil ikke være mulig for brukere som normalt har denne rettigheten. 

Kampanjegruppe:
Det tillates ikke opplegg av varer med fastpris ved manuelt valg av vare, ved "Hurtigprising", ved "Hent nye varer" eller ved innlesing via "Excel" (csv-/xlsx-format).
Melding om dette vises i kampanjegruppe loggen.

Hurtigprising:
Også i Hurtigprising avvises tilbudspriser for disse varene, og i tillegg logges dette i "Loggutskrift" for loggtype 6: "Avvist i hurtigprising". Melding 12 vises: "Varen har fastpris".  

Butikkrutiner:
For butikkbruker som kun kan skape tilbudspris, vil knappen "Endre pris på vare" være deaktivert.
For bruker som også kan endre ordinær pris, vil valg for Kampanjepris og Medlemstilbud være deaktivert i prisdialogen.

Melding ": IP 557 "Denne varen har "Fastpris" og kampanjepris/medlemstilbud kan derfor ikke benyttes", vises i de tilfelle når man EAN/PLU kan skrives i EAN-felt og forlater dette eller trykker på lagreknappen.

Teknisk informasjon
Når Systemparameter 1012 = 1 stoppes opplegg av tilbudspriser på varer med fastpris.

Kontroll mot SAP om slettepost for vare skal kjøres eller ikke

(RTC-34179)

Det kan settes opp en jobb som hver natt kontrollerer, mot SAP, om aktive sletteposter i varekø skal behandles eller ikke.
Dersom SAP har informasjon om at vare fortsatt finnes i lager, vil slettedatoen flyttes X antall dager fram i tid, for ny kontroll senere.

Teknisk informasjon

Profilbutikker i Chain Classic, 99901, 99902 osv., kan ikke brukes til dette, da disse ikke eksisterer i SAP.
I stedet må unike "VPI-profilbutikker", brukes for dette.

Systemparameter 991:
Angir antall dager fram i tid for sletteposter i varekø som skal kontrolleres og hvor mange dager fram i tid en slettepost skal flyttes, dersom SAP ikke godkjenner sletting.

Systemparameter 1011:
Angir adresse til web service i POS Server som utfører oppslaget i SAP.

Systemparameter 1014:
Det anbefales å slå på logging av webservice for en planlagt periode, når denne funksjonalitet blir tatt i bruk.

Priskanal og utlegg til elektroniske etiketter

(RTC-39745)

Ved bruk av priskanal i kampanjegruppe er det parameterstyrt hvordan utlegg skal skje til Breece/Pricer. 
Utlegg kan utføres uansett valg av priskanal (standard) eller kun når det er valgt priskanal "Alle".
Dersom valgt priskanal er "Alle", vil det ikke bli utført utlegg dersom priskanal for eksempel = "Shop express".

Teknisk informasjon
Denne funksjonalitet styres av: Systemparameter 948.

Administration av kasserer og kunde kun i Chain Classic

(RTC-39482)

Når kunde eller kasserer skapes/endres er det normalt å legge ut dette til POS. Men benyttes 3.parts POS-løsning (f.eks. Tokheim POS), kan det være ønskelig at dette ikke skjer.
Da er det mulig å parameterstyre dette slik at unødvendige køposter fjernes automatisk.

Teknisk informasjon

 Systemalternativer 185: "Tokheim"
   - For "Kunde" gjelder - Kode: 4
   - For "Kasserer" gjelder - Kode: 11  

For begge gjelder at når felt "Verdi1" = "Blank", skal ny-/endringsposter ikke legges ut.
Programmet som tømmer filko sørger for at disse postene fjernes uten at de legges ut.

Oppdatering av ny vare fra Item Master

(RTC-39334)

Ved oppdatering av ny vare i Chain Classic fra RIGAL er det nødvendig at både vare- og prisinformasjonen er levert fra Item Master.
Når begge postene er på plass i "VPI Vedlikehold" slås de sammen og en ny vare med pris skapes i Chain Classic.
Også rekkefølgen er viktig, for ny vare må, varepost komme inn før prispost. Kommer prispost først, vil prisposten forkastes da det ikke finnes noen vare å koble den til.
I dette tilfelle vil en etterfølgende varepost bli liggende til en ny prispost kommer slik at ny vare kan skapes.

Oppdatering av veidkost ved varemottak av ny vare på eksisterende profilkampanje

(RTC-40022)

Ny vare mangler lokal butikkpris og lagerpost. Når ny vare aktiveres via Varemottak, skapes butikkpris med kopi av kampanjeposter fra profilpris.
I tillegg skapes en prisendring for butikkpris med prisdata hentet fra Varemottak. Dette gjelder ved: 

  • RIGAL-import til varemottak, endring av pris og/eller antall for mottatte varer og etterfølgende oppdatering av lager.
  • RIGAL-import til varemottak og direkte valg av lageroppdatering uten forutgående endring av varemottaksposten.
  • Manuelt skapt post i varemottak, lagring av pris og antall av mottatt vare og etterfølgende oppdatering av lager. 

Når varen kommer inn i Varemottak, vil varen aktiveres med profilpris inkl. aktiv profilkampanje for butikken. 
Når lager oppdateres, vil lagerpost med veidkost bli skapt og det lages samtidig ny butikkpris med kopi av profilkampanjen. 
Ved utlegg til POS vil alltid veidkost benyttes som nettopris for alle pristyper.

Teknisk informasjon
Gjelder kun ved bruk av " Varemottak" (ikke ved bruk av "Elektronisk varemottak"):
Systemparameter 528 = elmottakw

Logging av webservice

(RTC-40216)

Logging av hva som blir sendt til POS Services og hva som ble sendt tilbake via en webservice er normalt slått av.
Men det kan slås på ved behov i test av en ny web service eller ved feilsøking.
P.t. er denne funksjonaliteten innført i webservice som benyttes i RTC-34179.

Teknisk informasjon

Det er laget mulighet for å innføre generell logging av et webservicekall fra Chain Classic, men foreløpig er dette kun innført i ny webservice for sjekk av om sletting av en vare/pris skal utsettes eller ikke (ref. RTC-34179).

Systemparameter 1014 slår på logging av webservicekall mot POS Services. Det er anbefalt å slå på denne logging i en planlagt periode når nye webservicekall blir tatt i bruk (ikke permanent).
Når logging er påslått, vil loggingen skje i forbindelse med at EOD-jobben kjøres i Chain Classic. Dette gir da en loggfil pr dag.
Det er loggtype 46 i System Alternativ 124 som benyttes, navn på nye loggfiler er: ws<mmdd>.txt.

Logging av sletting av ordrerader og komplette ordrer 

(RTC-37992)

Under "Rapporter - Logger" ligger muligheten å skrive ut loggrapporter. For å følge opp sletting av ordrer og/eller ordrerader for bestilling/varemottak, benyttes: Loggutskrift "Slettet ordre/ordrerad". 

Følgende sletteaktiviteter logges: 

  • Bestilling: Ordrerader og komplette bestillinger 
  • Elektronisk varemottak: Ordrerader og komplette varemottak
  • Varemottak: Ordrerader og komplette varemottak
  • Sletting av åpne bestillinger 
  • Bestillingsrader fra RIGAL

Logging av lagerbevegelser

(RTC-38346)

Når Chain Classic ikke er master for lagerstyring, vil ERP sende lageroppdateringer via RIGAL.
Det betyr at det kan dukke opp endringer i lagerbeholdningen som ikke vil vises som registrerte aktiviteter i Chain Classic.
Chain Classic kan kun holde styr på lagerbeholdning mellom oppdateringene fra ERP. 
Derfor vil alle endringer av lagerbeholdning lagres i lagerdag tabellen med en registrering pr endring.

Teknisk informasjon

Hver transaksjon som endrer lagerbeholdning, logges i feltet lagerdag.fritekst med en rad med oppdaterte verdier adskilt med semikolon for:

  • tidspunkt
  • brukerID (for aut. kjøring av batchjobber - programnavn)
  • programnavn (ved bruk av persistent program for lagerendring, inneholder dette også navnet på kallende program)
  • lagant
  • korrlagant
  • bestant
  • resant
  • veid kost
  • CHR(13) (CR - Carrige Return)

Avslutte gamle bestillinger/kundeordrer

(RTC-39498)

Det finnes to hjelpeprogram, under LRS-menyen, for å avslutte gamle bestillinger og kundeordrer som aldri vil bli ferdigstilt på annet vis: 

  • "Ferdigstill bestillinger" - Endrer alle ikke mottatte bestillingsrader/-hoder, før gitt dato, til status mottatt.
  • "Ferdigstill kundeordrer" - Endrer alle ikke betalte eller ikke leverte ordrerader, samt ikke leverte ordrehoder, før gitt dato, til status betalt og levert.

I begge programmene rekalkuleres verdier i lagerpost for vare i alle endrede rader.

Standard antall dager er parameterstyrt og kan overstyres ved programkjøring fra menyen.

Teknisk informasjon

Programmene må ha en verdi >0 i systemparameter 1013 for å fungere.
Her settes antall dager tilbake som skal brukes i respektive program, disse kan derfor være forskjellige. 

 - Alle bestillinger/kundeordrer som er eldre enn angitt antall dager vil bli avsluttet.

Programmene ligger under "LRS- Korrigere/endre data"
 - Ferdigstill bestillinger 
 - Ferdigstill kundeordrer

Nullstilling av bongnr

(RTC-40699)

I Chain Classic lagres de 10 sist innleste bongnumrene per butikk. Dersom support av noen årsak må lese inn en bong med et bongnummer i denne listen, vil bongen avvises med beskjed om at bongnummer allerede er brukt.
Den lagrede nummerserien må derfor slettes. Hjelpeprogram for dette finnes under "LRS- Korrigere/endre data".
Med "Nullstilling av bongnr" fjernes alle de 10 lagrede bongnumrene for butikk(ene). Deretter kan den manglende bongen kan leses inn på nytt.

Teknisk informasjon
Programmet "Nullstilling av bongnr" sletter alle lagrede bongnummer for angitt(e) butikk(er) i systemalternativer for butikk 1022.

Vedlikehold av bestillingsrader i elektronisk varemottak

(RTC-39437)

Det er mange muligheter å tilpasse elektronisk varemottak. For eksempel:

  • Skal det være mulig å legge inn ny bestillingsrad i eksisterende varemottak?
  • Skal det være lov å slette en bestillingsrad som ikke er mottatt?
  • Skal det være lov å endre nettopris?
Teknisk informasjon

Oppsett for vedlikehold av bestillingsrader i varemottak program:

  • Systemparameter 398=1: Tillatt ny-opplegg av rader
  • Systemparameter 547=1:  Tillatt sletting av rader
  • Systemparameter 980 =1: Tillatt endring av nettopris på vare 

Kontroller oppsett av slettedager for "Sletting av statistikk"

(RTC-40102)

Regler for visning av "Laveste pris siste X dager" fører til endringer når det gjelder sletting av prislogg poster.
Disse må beholdes når en vare slettes siden samme EAN/PLU kan bli opprettet på nytt innenfor angitte tidsintervall for laveste pris.
Prisloggposter vil derfor ikke slettes via varekøbehandling eller via batchprogrammet "Sletting av varer". 

Dette medfører at innholdet i prislogg tabellen vil vokse raskere dersom den ikke er satt opp med en fornuftig slettefrekvens i den automatiske jobben for "Sletting av statistikk" som kjøres hver EOD. 
Dette gjelder ikke bare prislogg tabellen, det er også viktig at mengden data i alle statistikktabeller holdes innenfor fornuftige mengder, at man kun tar vare på det man har bruk for. 

Teknisk informasjon

I vedlikeholdsprogrammet "Oppsett slette statistikk" under System menyen angis "Dager før sletting".
Dette settes pr. tabell og data eldre enn angitt dato, slettes fra respektive tabell ved kjøring av ryddejobben hver EOD.

I EOD brukes programmet "Sletting gammel statistikk" (ip\drift\deletep.r). Programmet må være lagt opp i systemalternativer 1001: "EOD jobber".
Dersom #-tegn er lagt inn før teksten i "Verdi1", må dette fjernes.

Dersom sletting av en tabell ikke har vært i bruk, bør man starte slettingen gradvis ved å angi en slettedato som favner en begrenset mengde data slik at man unngår at for store datamengder slettes på en gang. 



Chain Classic versjon 2.1.1.0.43

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.1.1.0.43 skal POS alltid levere bonger i POSLog versjon 81

Forbedringer

Modul 

Beskrivelse 

Elektronisk varemottak

Varesøk i elektronisk varemottak (RTC-38982)

Dersom det oppleves problemer med standard varesøk i ordre i elektronisk varemottak, prøv da følgende rutine:

  1. Sorterer først bestillingsrader på EAN/PLU, (trykk på kolonneoverskrift), slik at laveste nummer er i topp.
  2. Åpne standard søkeprogrammet "Finn vare", enten ved å trykke på "Kikkerten" eller bare skriv EAN/PLU-nummer direkte.
    • Angi EAN/PLU-nr for søk i felt "Fra-kolonne" og trykk "Enter". 
  1. Funnet EAN/PLU hentes inn på første ordrerad, med etterfølgende EAN/PLU nedenfor.
  2. For å fjerne filter som skjuler ovenforliggende ordrelinjer: 
    • Tast 1, søkeprogrammet åpnes, trykk "Enter" og alt er tilbake igjen.
    • Det er også mulig å legge inn et nytt søkekriterum umiddelbart uten å måtte nullstille noe
EOD-rapport

Melding når E-post feiler i EOD-Rapport (RTC-36556)

Dersom melding ikke kan leveres når EOD-rapport (som også skal sendes som E-post) skapes (nettverksproblemer eller annet problem), vil dette logges direkte i Status feltet i Rapportlisten.

  • Når E-post er sendt, vil det stå: "E-post sendt".
  • Når E-post ikke kan sendes, vil det stå: "Ferdig - E-post feilet".
RIGAL

Varetype til RIGAL og logging av oppdatering fra RIGAL VPI (RTC-36476)

Chain Classic legger alltid ut "Varetype" i RIGAL V-fil.
Ved import av endret varetype fra RIGAL VPI, logges dette i VPI feillogg. 

Vare

Fjern "Stopp salg av vare" i POS (RTC-38072)

I Chain Classic kan en vare som har blitt sperret, senere åpnes for salg på kassene igjen. Dette skjer enten ved å bruke knappen "Friskmeld vare" i "Varevedlikehold eller ved å velge "Friskmeld vare" ved utlegg av varen fra "Klargjøre vare".

Vare-/kundegrupperabatt

Bruk av varelister i "Vare-/kundegrupperabatt" (RTC-34434)

Ved opplegg og vedlikehold av varerabattposter i "Vare-/kundegrupperabatt" kan varelister med varelistenummer opp til 8 siffer benyttes.

Varetransaksjoner

Bongnummer og kundeordrenr/radnr i "Varetransaksjoner" (RTC-36528)

For økt sporbarhet og enklere oppfølging oppdateres "Bongnummer" alltid når "Varetransaksjoner" oppdateres fra POSLog, og kundeordrenr/rad oppdateres også når dette er tilgjengelig.

Vise laveste pris de siste 30 dagene før kampanjestart

(RTC-38287,RTC-38447RTC-38451

Ifølge markedsføringsloven skal referansepris, dersom den vises på elektroniske etiketter (Pricer og Breece) og papirbaserte etiketter eller plakater fra Lexmark, være den laveste prisen som har vært brukt i butikken de siste 30 dagene.

Kontrollperioden begynner dagen før tilbudsstart og strekker seg angitt antall dager tilbake i tid (minst 30 dager). Verdiene kan derfor bli forskjellige, i forhold til startdato, når det lages framtidige tilbud på samme vare.

I laveste pris inkluderes tidligere ordinære prisendringer, kampanjepriser og medlemstilbud som har vært lavere enn gjeldende ordinærpris. Gjeldende ordinære pris vil derfor kun benyttes som laveste pris dersom denne faktisk er den laveste prisen i perioden.

I program for Kampanjegruppe og manuell Prisvedlikehold vil verdi for laveste pris vises i eget felt, når kampanjepris eller medlemstilbud legges opp.

Teknisk informasjon

Systemparameter:

  • 1006: Antall dager tilbake i tid for perioden som skal kontrolleres fra startdato til kampanjepris/medlemstilbud.
  • 1007: Angir hvilke av formatene til Lexmark, Pricer og Breece som skal ha dette utlegget av laveste pris.
  • 1008: Maks antall minutter ved "forlengelse" av sentral kampanje. Tiden fra den sentrale profilkampanjen (S-lag) avsluttes til den kopierte, lokale kampanjen starter ("forlengelse"), for å unngå at den avsluttede sentrale profilkampanjen inngår i sjekk på laveste pris for lokal kampanje. 

Systemalternativer:

For utlegg av felt for "laveste pris" må dette settes opp:

  • 125 rad 4 "Pricer": Integer" = 28
  • 125 rad 9 "Breece": Integer" = 59
  • 125 rad 17 "Lexmark": Integer" = 53

Bruk av Excel online i Chain Classic

(RTC-37084)

Dersom Microsoft "online Excel-løsning" benyttes, kan ikke rapporter i XML-format brukes. Det vil derfor lages en CSV-versjon av denne rapporten som kopieres til katalogen Chain_Print. 

  1. Velg ønsket rapport i rapportlisten og trykk på "Excel-knappen".
    • Excel rapporten flyttes til katalogen Chain_Print. Dette bekreftes med en melding.
    • Dersom rapporten er i XML-format (formattert Excel) vil det i tillegg lagres en CSV-versjon av rapporten på samme katalog. Meldingen vil nå henvise til at begge rapporter er kopiert.
  2. Åpne katalogen "Chain_Print" under katalogen "Dokumenter". Her vil de lagrede Excel rapportene ligge, både i XML og CSV format dersom rapporten er formattert.

Alle rapportfiler i .csv format, kan åpnes direkte i den Excel-løsningen som er tilgjengelig for bruker. 

Teknisk informasjon

Systemparameter 992 = 1 åpner for bruk av forenklet løsning av "Excel online".

Merk at dersom OneDrive er i bruk, vil "Dokumenter" katalogen under denne benyttes.

Brukere som fortsatt har Excel lokalt på PC vil ikke merke noen forskjell om den nye parameteren er påslått.

Oppdatering av RIGAL VPI med VAR- og PRI-poster fra Item Master 

(RTC-38435)

Når Item Master blir tatt i bruk, er det viktig Chain Classic er oppdatert til nyeste patch og at systemparameterne er satt opp korrekt.

Generell funksjon er som følger:

  1. RIGAL VPI med VAR-post på eksisterende vare i Chain Classic blir oppdatert dersom det er endret vareinformasjon i importen.
  2. RIGAL VPI med VAR-post på ny vare blir liggende igjen i VPI-vedlikehold inntil tilhørende PRI-post oppdateres. Dette innebærer at en komplett ny vare kan oppdateres til Chain Classic.
  3. RIGAL VPI med PRI-post for ny vare blir avvist dersom det ikke finnes en ventende VAR-post i VPI-vedlikehold.
  4. For ny vare må derfor alltid VAR-post oppdateres før PRI-post
  5. RIGAL VPI med PRI-post på kjent vare i Chain Classic, oppdateres dersom det finnes endret prisinformasjon.
Teknisk informasjon

Når Item Master (IM) tas i bruk, vil vare- og prisinformasjon leveres i to adskilte poster (en VAR post og en PRI post) og ikke i samme post som er standard i VPI-oppdateringen i Chain Classic. Det er derfor viktig å teste dette grundig med riktig parameteroppsett. I tillegg er det nødvendig det en egen VPI-mal for PRI-poster som sikrer korrekt oppdatering av alle felt, også de som lagres ulikt mellom vare og pris i Chain Classic og Item Master. 

Følgende systemparameter må være riktig:

  • Systemparameter 987 = 1
  • Systemparameter 669 = 0
  • Systemparameter 425 = 2
  • Systemparameter 782 = (VPI-malnummer for "Pris"

Utlegg av omsetning til Nielsen IQ

(RTC-38850)

Utlegg av "Omsetning til Nielsen IQ" kan legges opp som en automatisk jobb i forbindelse med EOD, men programmet kan også brukes manuelt.
Standardverdi for ukenummer går ut fra dagens dato og 6 dager tilbake i tid, og kan endres etter ønske ved manuelle utlegg.
Omsetning legges ut pr solgt EAN/PLU med egne poster for salg på tandemnummer. 

Teknisk informasjon

Katalog for utlegg  være opprettet  (Nielsen\ i systemparameter 64 under hjemmekatalogen angitt i systemparameter 60).

Systemparameter 1009 bestemmer filnavn for utlegget (weeksales = prefix)  
Ved utlegg tilføyes årstall og ukenummer, slik at komplett filnavn blir:  weeksales_<yyyywwww>.csv.

For regelmessig rapport legges denne jobben opp som parameterstyrt EOD-jobb og startes da automatisk i forbindelse med EOD.

Manuell kjøring fra menyen: "System > Administrative rutiner >Utlegg av data > Omsetning til Nielsen IQ".

Mixtype 46: "Betal med Coopay og få x kr/% ekstra kjøpeutbytte" 

(RTC-36758

Når ny mixmatch med mixtype 46 opprettes, hentes korttype for Coopay inn automatisk. Korttypen kan ikke endres.
Verdi for Rabattkr eller Rabatt% må angis. Selvskanning kan i tillegg velges.
Denne mixtypen fungerer uavhengig av varene i handlekurven, derfor skapes kun 1 mixrad med en angitt "Dummy-vare" som sørger for mix utlegget til POS via varekø.

Teknisk informasjon

Systemalternativ 132 - Mixtype 46 være oppsatt med:
    - "Logisk" påslått
    - "Desimal" = "PLU-nr for dummy-vare" 

Systemalternativer 80 - Korttype for Coopay må opprettes.
    - Verdi1 = XXXX (Tekstkode for korttype)
    - "Desimal" = 1

Systemparameter 1005 - Nummer for Coopay korttype (fra systemalternativer 80).

Bruk av modellvarer i mixmatch

(RTC-37236)

Noen mixmatchtyper kan brukes med modellvarer. Dette er noe som forenkler å legge inn et utvalg varer der kun en variant representerer alle varer i modellen.

For å få denne funksjonaliteten i POS, må valg av Modellvarer hukes av.
For å unngå problemer i POS kan ikke denne funksjonaliteten endres etter godkjenning av mixmatchen.
Flere slike kritiske valg er deaktivert slik at verdien beholdes uendret i hele mixmatchen "levetid".

Bruk av nettopris fra ordinær priskalkyle i rapporten "Lagerliste Excel"

(RTC-39048)

  1. Rapporten "Lagerliste Excel" er i utgangspunktet laget for å vise kostpris for butikkenes varer der veid kostpris > 0. For varer uten veid kostpris, skrives 0 i denne kolonnen.
  2. Dersom parameter for å vise nettopris fra ordinær priskalkyle slås på, vil disse verdiene vises og bli brukt til å beregne kostpris for varer som ikke har en gyldig veid kostpris.

Dersom nevnte parameter slås på, vil denne rapporten vise samme verdier som alt rapport "Lagerliste".

Teknisk informasjon
Dersom systemparameter 1010 = 1, vil kostpris beregnes for alle varer med bruk av nettopris fra ordinær priskalkyle dersom varen mangler veid kostpris.

Prisimport via resultat-fil fra "Sortimentliste Excel"

(RTC-37853)

Ved innlesing av VPI fra Excel kan det oppdateres prisendringer for profilpriser fra ulike profiler og butikkpriser. Hvordan prisendring skal oppdateres, bestemmes av om "RIGAL/Excel VPI pr butikk" er avkrysset (prisendringer på butikkpris) eller ikke (prisendringer på butikkens prisprofil) for butikken.

Teknisk informasjon
  • VPI-maler for Excel, profil og butikk, bør være satt opp og angitt i systemparameter 692.
    Om dette ikke er angitt, vil standard VPI-mal (systemparameter 204) bli benyttet.  
  • Systemparameter 964 = 58 (antall felt i utlegg og oppdatering).

Alternativer:

Systemparameter 694 = 0:  Import av pris for flere profiler er mulig.

  • Krav til gyldig butikknummer i Excel-arket, da tilhørende prisprofil vil bli brukt.
  • Butikknummer = 0 eller "blank" vil avvises med melding i logg.
  • I butikkregisteret velges om data skal leses inn som profil- eller butikkpris. For butikkpris velges: "RIGAL/Excel VPI pr. butikk".

Systemparameter 694 > 0:  Kun angitt profil blir brukt.

  • Ved butikknummer = 0 i Excel-arket, leses kun profilpris inn KUN for angitt profil.
  • Ved butikknummer > 0 i Excel-arket, leses butikkpris lest inn for butikk på angitt profil.
  • Butikknummer med avvikende profiltilhørighet avvises.

Utlegg av mixmatch til Tokheim fra "Klargjøre vare"

(RTC-37218)

I Klargjøre vare kan eksport gjøres med "Mixmatch" og "mixnummer" som eneste utvalg. Her legges da kun angitte mixmatcher ut. Denne funksjonaliteten støtter også samtidige utlegg av identiske profil mixmatcher på flere profiler, med samme innhold, start- og sluttid. Utlegg av mixmatch til Tokheim POS støttes også på samme måte.

Dette er standardfunksjonalitet både for eksport til EG POS og Tokheim POS.

Utvidet funksjonalitet i "Varebevegelser"

(RTC-37358)

Dersom "Servicehandel" er i bruk, vil også varetransaksjoner for reseptvarer og varesalg for ingredienser (pr råvare) vises i oversikten "Varebevegelser" i Vare-/Prisvedlikehold. Dette vil være tillegg til standard varetransaksjoner og varesalg ellers.

Teknisk informasjon 
Servicehandel: Systemparameter 9003 = 1.

Varemottak som skapes i forbindelse med en internoverføring

(RTC-37990)

Det er ikke mulig å slette varemottak generert fra internoverføring. Dette er innført for å forhindre problemer som følge av sletting av "uventede" varemottak som ikke var bestilt fra leverandør.
Det er heller ikke mulig å slette, legge til eller endre på poster på linjenivå. 

Profilbytte og framtidige prisendringer på ny profil

(RTC-33829)

Ved endring av profilnummer på butikk skapes nye køposter for alle aktive og fremtidige profilprisendringer (dersom butikk ikke har lokal pris). Dette inkluderer kampanjepriser og medlemstilbud. Dersom priskontroll er i bruk vil dette bli hensyntatt og butikken må godkjenne nye prisendringer. 

Automatisk bestilling i "Feltverdier for butikk"

(RTC-34302)

Dersom en vare ikke er merket for "Automatisk bestilling" i Varevedlikehold, men det finnes butikker med dette behovet, løses, dette ved at butikken legger opp en butikklokal verdi for feltet i "Feltverdier for butikk". Denne butikklokale verdien vil benyttes i forbindelse med nye bestillinger på varen.

Sikre at alle proxy-program avslutter riktig

(RTC-34308)

Ved direkte kommunikasjon mot løsninger i Cloud/POS, og Chain Classic "låses" forbindelsen mellom appserver og klient midlertidig. Når oppgaven er utført avsluttes denne forbindelsen og "låsing" fjernes.

Sikre at prosedyrer som kalles opp via plipkall ikke skaper tregheter

(RTC-34272)

For beste ytelse er alle prosedyrene som benyttes via plipkall fra webklientene optimalisert slik at alle aktive transaksjoner og andre bindinger til webklientene termineres når prosedyrekallene er avsluttet.

Opprydding i filko tabellen

(RTC-31531)

Det kan skje at det blir liggende igjen poster i filko som aldri tømmes på normalt vis. Vanligst i testmiljøene, men kan også skje ved feil oppsett i Prod.
Mange slike feilposter i filko kan føre til at jobben Utlegg av data til fil kan ta vesentlig lenger tid enn nødvendig. Dette vil være en kronisk tilstand som bare blir verre.
For å unngå slike forsinkelser kan det være lurt å sette opp en automatjobb som rydder opp i dette. Denne kan for eksempel kjøres en gang i uken.

Teknisk informasjon

Det er programmet "fix\ip\pprog\delfilkoerr.r" som skal kjøres som automatjobb. 
Dersom programmet "Utlegg av data til fil" bruker unormalt lang tid for hver kjøring uten at det legges ut mye data til filer på sendes, bør det sjekkes nærmere hvilke poster som ligger i filko. Finnes det svært mange feilposter kan være fornuftig å slette disse kontrollert før automatjobben for det nye ryddeprogrammet settes opp, 
Under er det listet opp informasjon om det nye ryddeprogrammet:

  • Filnavn på loggfil er: errfilko-åååå-mm-dd.txt
  • Katalog for loggfil: Systemparameter 60 + 58
    • Feilmelding i loggfil: Dato/tid + feilmelding + filko export
  • Følgende feilsituasjoner medfører logging i feillogg + sletting av filko-post:
    • filgr = 0 eller filtype = 0.
    • filgr = 3 eller 11 (RIGAL utlegg), men RIGAL-nr = 0 eller RIGAL-nr mangler.
    • filgr = 5 og filtype = 1, 31 eller 33 og identnr = 0 eller med ukjent profilnr.
    • identnr = 0 for andre filtyper enn 4,5 eller 18 (der det kan finnes totalposter med identnr = 0) eller identnr > 0, men butikk er ukjent.



Chain Classic versjon 2.1.1.0.42

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.1.1.0.42 skal alltid POS levere bonger i POSLog versjon 81

Forbedringer

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.

Logging av "Bestillingsfordeling Excel"

(RTC-36077)

Når bestillinger/varemottak er skapt via programmet "Bestillingsfordeling Excel", vil dette vises i vedlikeholdsprogrammet for "Bestilling".

Utlegg av summen av varetransaksjoner pr. årsakskode til RIGAL F-fil 

(RTC-35910)

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.

Teknisk informasjon
Systemparameter 511 = 1.
Hver varetransaksjonstype som skal legges ut i RIGAL finansfil pr. transaksjonstype og årsakskode,  angis med "Integer" = 1 i Systemalternativer 5

Etikettutskrift fra InStore App

( RTC-36419, RTC-37073)

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. 

Teknisk informasjon
I systemparameter 357 kan kriterier settes for å få kontroll over antall etiketter som skrives ut.

Veid kostpris skal alltid brukes som nettopris for alle priser i POS 

(RTC-35863)

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.

Teknisk informasjon
Dette gjelder spesialløsning for varemottak med systemparameter 528 = elmottakw.



Chain Classic versjon 2.1.1.0.41

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.1.1.0.41 skal alltid POS levere bonger i POSLog versjon 81

Forbedringer

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".
Dersom det hentes inn et stort utvalg varer der mange varer avvises av ulike årsaker, vil melding i brukergrensesnittet være uoversiktlig. Da vil det være enklere å vise avvisningsårsakene via knappen "Avviste varer i kampanjegruppe".
Ved bruk av knappen "Hurtigprising" vil avviste varer kun vises i denne loggen.

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.
Dersom returene skannes hver for seg, vil hver varelinje behandles for seg, men påvirker lager på samme måte.

Sortimentliste Excel

(RTC-34753)

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.

Teknisk informasjon

De som bruker denne rapporten i dag, må kontrollere verdi i systemparameter 964. Gyldige verdier er:

  • Verdi = 0/39 (39 felt)
  • Verdi = 53 (53 felt)
  • Verdi = 58 (58 felt) 

Alle andre verdier vil tolkes som 39 felt.

Systemparameter 692 angir VPI-maler som benyttes ved import av VPI fra Excel.

Systemparameter 694 angir profilnummer som benyttes ved import av VPI fra Excel.

Beskrivelse av forskjellene i innholdet i de 3 alternativene er vedlagt i testdokumentasjonen i saken.

Stanse muligheten til å skape nye varetransaksjoner manuelt 

(RTC-34760)

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.

Teknisk informasjon
Systemalternativ 1000 = 1 stopper muligheten for nyopplegg/kopiering av varetransaksjoner manuelt i Chain Classic.

Oppdatering av salg og varetransaksjoner på reseptvarer ved bruk av Servicehandel

(RTC-34602)

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.

Teknisk informasjon
  • Butikk må ha "Lager" påslått i butikkregisteret.
  • Innholdsvarer i pakke må være lagerstyrt.
  • Råvare må være lagerstyrt.
  • Reseptvare og pakkevarer skal ikke være lagerstyrt. 

Avrunding av salgsbeløp

(RTC-35152)

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.

Teknisk informasjon

Vanligvis hentes alltid salgsbeløp fra "ExtendedAmount/Amount" (i POSLog). Dette avrundes på normal måte (f.eks. 21.68).
Ved oppdatering av kredittsalg til kundesalgsstatistikken hentes salgsbeløpet fra "ExtendedAmountRounded/Amount" (21.67).
Dette er gjort for å sikre overensstemmelse mellom total salgssum og summen av varelinjene ved overføring til Cash Settlement.

Under vises et eksempel på dette:
  

Åpningsfane i "Priskontroll"

(RTC-34829)

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. 

Teknisk informasjon
I systemparameter 1001 settes verdi for hvilken av fanene 1-5 som skal være åpningsvindu i "Priskontroll".

Når Excel og Word ikke kan startes fra Chain Classic 

(RTC-34228)

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.

Visningsalternativer i "Oppdater lager" i varetellingsveiviseren

(RTC-31532)

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

  1. "Alle" - Viser alle varelinjer- De radene som er oppdatert, vises med en mørkere gråfarge i feltene "EAN/PLU-nr" og "Varetekst" (se bilde).
  2. "Oppdaterte" - Viser kun oppdaterte varelinjer og alle har da den mørkere grå fargen i de to kolonnene.
  3. "Ikke oppdaterte" - Viser kun varer som det gjenstår å telle/oppdatere. Disse har normal farge i feltene "EAN/PLU-nr" og "Varetekst".

Lagerinformasjon i Vare- og Pris-vedlikehold

(RTC-34353)

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

  • Lagerpost mangler på vare for butikken og butikken har ikke adgang til å se lagerinformasjon for en annen butikk med lagerpost for varen.
  • Butikken er ikke lagerstyrt.
  • Butikken er ikke aktiv (kommunikasjonstype <> 11).   

RIGAL VPI med kun vareinformasjon og endret varenummer (ingen prisinfo) fra Item Master /Cloud

(RTC-34131)

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.

Teknisk informasjon

Systemparameter 987 = 1 - For å søke frem riktig vare i Chan Classic ved import av VAR-post uten prisinformasjon i RIGAL VPI. 

Dersom tandemnummer er i bruk anbefales følgende oppsett ved bruk av tandemnummer. (Hentet fra RTC-34465 )

Systemparameter 425 = 2 - Vare søkes opp via alle tandem/hovedvare-koblinger

Systemparameter 632 = 1 - Tandem fra RIGAL VPI brukes og fjerner evt. avvik i Chain Classic.

Systemparameter 491 = 0 - Dersom unikt varenummer er i bruk.

Systemparameter 669 = 1 - Unikt varenummer oppdateres fra ny vare i RIGAL VPI og evt. samme varenummer fjernes fra eksisterende vare i Chain Classic.

Finn frem eksisterende vare via tandem ved RIGAL VPI-import

(RTC-34465)  

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:

  1. Ukjent hovedvare i RIGAL VPI, men med tandemEAN som allerede finnes som tandem på eksisterende vare i Chain Classic
  2. Ukjent hovedvare i RIGAL VPI, men med tandemEAN som allerede finnes som hovedvare i Chain Classic
  3. Hovedvare i RIGAL VPI finnes allerede som tandem på hovedvare i Chain Classic

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.

Teknisk informasjon

For optimal bruk av tandem anbefales følgende oppsett:

Systemparameter 425 = 2 - Vare søkes opp via alle tandem/hovedvare-koblinger

Systemparameter 632 = 1 - Tandem fra RIGAL VPI brukes og fjerner evt. avvik i Chain Classic.

Systemparameter 491 = 0 - Dersom unikt varenummer er i bruk.

Systemparameter 669 = 1 - Unikt varenummer oppdateres fra ny vare i RIGAL VPI og evt. samme varenummer fjernes fra eksisterende vare i Chain Classic

Se også (RTC-34131) for ytterligere informasjon om oppsett av parametere ved oppdatering via RIGAL-VPI.

Unntak for sletting av lokale priser ved oppdatering av ordinær prisendring på profilpris fra RIGAL

(RTC-35421)

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.

Teknisk informasjon
Systemparameter 675 styrer om lokale butikkpriser skal rydde bort ved profilprisendring via RIGAL VPI. Det er her mulig å forskyve slettedatoen fram i tid.

Logging ved utlegg av bestillinger til RIGAL

(RTC-35426)

Endringer som fører til utlegg av bestillinger til RIGAL, logges for enklere oppfølging. 

Teknisk informasjon

Navn på loggfil: %%\LRS\logg\"bestill_mmåååå.butnr"

I loggteksten vises brukernavn, dato/tid, om det er utført godkjenning eller bekreftelse eller opphevelse av dette. 

For å skille ut bestillinger som er skapt fra "Bestillingsfordeling Excel", settes et merke i feltet besthode.frigruppe3 (vises kun i editor).
Bestillinger skapt fra "Bestillingsfordeling Excel" får verdien 1 mens varemottak skapt fra samme program, får verdien 2.

Butikker som vises i "Lagerinformasjon"

(RTC-35054)

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.

Teknisk informasjon
Butikker må ha kommunikasjonstype 11 og i tillegg være satt opp med lagerstyring ved at sjekkboks for "Lager" er krysset av.

Utlegg av "utsalgspris" til Tokheim POS for gruppe 1 i mixmatchtype 35

(RTC-35388)

Mixmatchtype 35 er en gruppemix hvor det kan parameterstyres om prispost for gruppe 1 skal legges ut til Tokheim POS.

Teknisk informasjon
Systemparameter 1002 Styrer om pris skal legges ut til Tokheim POS for mixgruppe 1 for mixtype 35.

Bruk av kostpris i "Bestillingsfordeling Excel"

(RTC-33790)

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.

Teknisk informasjon

Funksjonaliteten er parameterstyrt og bestemmes av tre viktige elementer i systemparameter 537:

  1. Frigruppe
    Settes for å ekskludere varer som ikke er suppleringsvarer, og derfor ikke skal benytte denne funksjonaliteten.
  2. Antall dager igjen i kampanje
    For en vare med aktiv kampanjepris benyttes nettopris fra kampanjekalkyle dersom det gjenstår minst X dager av kampanjeperioden.
  3. Antall dager fram i tid
    For varer der det finnes en framtidig kampanje som starter innen Y dager, benyttes nettopris fra den framtidige kampanjekalkylen.

Andre forutsetninger:

  • Dersom "Bestilles til" er angitt på fanen "Tillegg vare" i "Varevedlikehold" for en vare, men denne er eldre enn dagens dato, benyttes ordinær nettopris.
  • Det sjekkes både på kampanjepris og medlemstilbud. Dersom begge typer finnes innenfor oppgitt intervall, benyttes nettopris fra medlemskampanje som antas være gunstigere enn en kampanjepris i samme tidsrom.

Optimalisering av databaseoppslag

(RTC-35227)

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. 

Teknisk informasjon

Alle konsulenter bør være oppmerksom på om CPU-bruken er høy (100%) over lang tid. Da må følgende endringer vurderes:

  1. Antall CPU'er i forhold til antall brukere og oppsett (samme numanode)
  2. MHz på CPU'ene (gjerne 4 GHz)
  3. Minne (må ha nok plass til å kunne cache "minst" halve databasen)

Bruk av indeksene jobbhodeidx8 (kun jobbstatus) og kassdagidx6 (kun dato) er i stor grad erstattet med bruk av bedre indekser som vil bedre brukeropplevelsen.
Men det er viktig å være klar over at dette vil ikke være tilstrekkelig dersom det oppleves kritiske ytelsesproblemer.
Da det utføres et eller flere av overnevnte forslag til serveroppgradering.

Ny godkjenning og utlegg av kampanjegruppe til POS

(RTC-29779)  

Hjelpeprogram til bruk for EG personell.

Teknisk informasjon
Med programmet "Godkjenn kampanjegruppe" (LRS > Korrigere/Endre data) kan en kampanjegruppe søkes fram og godkjennes på nytt.
Dette vil resultere i nytt komplett utlegg til POS og evt.- 3. parts løsninger. 



Chain Classic versjon 2.1.1.0.40

Dokument status: RELEASED

Dato:   

Forutsetninger for oppgradering

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

Forbedringer

Modul 

Beskrivelse 

Bestilling

Behandling av varer merket "Ikke bestilling" i Bestillingsmodulen (RTC-31342)

  • Forsøker man å legge inn en vare merket "Ikke bestilling" i programmet "Bestilling" vil varen avvises med melding om at varen ikke kan bestilles.
  • I programmene "Bestillingsforslag" og "Bestillingskriterier" vil alle varer merket "Ikke bestilling" i "Varevedlikehold" eller som butikklokal verdi for butikken, avvises.
  • Ved oppdatering av RIGAL I-fil vil også varer merket "Ikke bestilling", avvises.  Dette er i utgangspunktet avsenders ansvar, men Chain Classic må korrigere om disse sender feil data.
  • Ved oppdatering av bestillingsrader fra POSLog, vil varer som ikke kan bestilles, avvises.

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.
Dette fjerner avvik som kan skyldes at butikk ikke har skrevet ut etikett eller godkjent prisendring dersom dette er i bruk.  

Skrive rabattalternativer på små rabattprislapper

(RTC-28221)

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


Teknisk informasjon

Systemparameter 645 inneholder en liste over aktuelle rabattprislapper, mens 647 slår på muligheten til å skrive rabattprislapper.

Systemparameter 688 åpner for å kunne benytte 3 rabattalternativer for små rabattprislapper med 21 tegn (type LRS-21).

Beskrivelse av koden over:

  • 1-4 = Index for rabattype: 2207 for prosentrabatt. 2221 for kronerabatt og 2222 for rabattert pris.
  • 5-17 = 13 siffer for EAN.
  • 18-19 = Verdi (%/kr) for valgt rabattype.
  • 20-21 = Årsakskode.             

Bruk av "Excel online" 

(RTC-32817)

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.

  1. Velg ønsket rapport i rapportlisten og trykk på "Excel-knappen".
    • Rapporten flyttes til en egen katalog. som bekreftes med en melding.

  2. Åpne katalogen "Chain_Print" under katalogen "Dokumenter"
    • Her vil de valgte Excel rapportene ligge.

  3. Alle Excel-rapportfiler i Chain_Print kan åpnes direkte i den Excel-løsningen som er tilgjengelig for bruker.

Teknisk informasjon

Systemparameter 992 = 1 åpner for bruk av forenklet løsning for "Excel online".

Merk at dersom OneDrive er i bruk, vil "Dokumenter" katalogen under denne benyttes.

Brukere som fortsatt har Excel lokalt på PC vil ikke merke noen forskjell om den nye parameteren er påslått.

Ekstra utlegg til POS

(RTC-33057)

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.

Teknisk informasjon

Systemparameter 716 aktiverer funksjonalitet for "Utlegg til ekstra POS Server", som vil vises på fanen "Generelt" i programmet "Utlegg til ny butikk".

  • Dersom "Verdi" i systemparameteren ikke er angitt, vil valg for dette ekstra utlegget ikke vises.

  • Merk at poster under "Alternativer" ikke vil legges ut til den ekstra katalogen, dersom det finnes post i Systemalternativ 208 eller Systemalternativ for butikk 208 som stopper utlegget.

Krav om at e-post adresse må angis for kasserer

(RTC-32629)

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 angis ved endring eller oppretting av ny kasserer. 

  1. Ved vedlikehold av eksisterende kasserer uten e-postadresse er det ikke lov å lagre uten at dette feltet er utfylt. 
  2. Ny kasserer kan ikke lagres uten e-postadresse.
  3. Ved oppdatering av kasserere fra og utlegg til RIGAL inngår e-postadresse som siste felt.
  4. Ved oppdatering av ny kasserer fra RIGAL, vil posten avvises dersom e-postadresse mangler når systemparameter 988 er påslått. For eksisterende kasserere med e-postadresse utfylt, beholdes denne uendret.
Teknisk informasjon
  • Krav til e-postadresse for kasserer aktiviseres når systemparameter 988 = 1.
  • Logging av avviste poster skjer i standard feil-katalog (errMMDD.butnr) i loggkatalogen.

Eksport ved sletting av tandem

(RTC-33242)

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.

Teknisk informasjon
Slettepost for tandem i RIGAL V-fila har "S" i feltet foran tandemean som skal slettes.  Dette gjelder felt 7.1.61 og 7.1.63.
Vanligvis inneholder disse E/P for å beskrive om tandem i neste felt er et EAN eller en PLU.

Lag butikkpris selv om EAN = 0

(RTC-32495)

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.

Teknisk informasjon

Systemparameter 112 = 1
Systemparameter 491 = 1
Systemparameter 985 = 1 (eller 2)

Forutsetningen for denne funksjonaliteten dersom EAN mangler i en RIGAL PRI-post, er at det finnes en profilpris for varen med en unik kombinasjon av varenummer og vektkode. Da kan ny lokal butikkpris skapes med riktig EAN.

Logging av godkjenning/fjerne godkjenning i Bestilling

(RTC-33186)

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.

Teknisk informasjon

Når systemparameter 302 = 1 skjules "bekreftelsesknappene" i "Bestilling".
Da behøver brukeren kun forholde seg til "godkjenn knappene".

Systemparameter 989 gir mulighet for å eksportere endret bestilling til ERP i RIGAL I-format.  

Kampanjeperiode via ordinære prisendringer i RIGAL VPI

(RTC-33927)

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.

Utlegg av negativ kundesaldo til Tokheim POS

(RTC-33527)

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.

Alternativer i standard priskontroll

(RTC-33397)

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.

Teknisk informasjon
Dette gjelder standard priskontroll, og det er den to-delte systemparameteren 990 som åpner for denne funksjonaliteten.

Forbedringer i standard priskontroll

(RTC-33786)

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.

Teknisk informasjon

Systemparameter for standard priskontroll:

  • Systemparameter 308: Velg om nye priser, ordinære prisendringer og/eller kampanjepriser skal vises og om bruker kan endre utpris for nye varer/ordinære prisendringer.
  • Systemparameter 616: Skal mixmatch kontrolleres.
  • Systemparameter 936: Skal kampanjepriser og/eller mixrader i en kampanjegruppe kunne godkjenning eller avvises.
  • Systemparameter 990: Fjern mulighet for å kunne "Tilbakestille" tidligere avviste profilprisendringer, og gi mulighet for å kunne analysere bruttofortjeneste ved en prisendring før den godkjenning og forsvinner fra lista. Denne muligheten er nå også tilgjengelig i standard priskontroll, I "Nettopriskontroll" har dette alltid vært standard.     

Systemparameter 890: Skal ikke brukes i standard priskontroll. Skal kun ved bruk av "Nettopriskontroll", og for dette skal alle parametere ovenfor ikke være i bruk.

Utlegg av lagerpost i JSON format

(RTC-31284)

Dersom parameter for dette er påslått, vil det ved oppdatering av lager skapes et automatisk lagerutlegg i JSON format.

Teknisk informasjon

Utlegg av oppdatert lager til JSON format utføres når:

  • Feltet "Logisk" i Systemalternativ 193 for post merket "Lager" er påslått.
    eller
  • Feltet "Parmlog" i Systemalternativ 193 for butikk for post med "Parmnr" = 1, er påslått.

Innføring av 9-sifret kasserernummer

(RTC-33444)

I rapportene "Butikkoppgjør" og "Butikkoppgjør pr. kasserer" er det støtte for bruk av inntil 9-sifret kasserernummer.

Oppdatering av ny vare fra Item Master

(RTC-33599)

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.

Teknisk informasjon
Denne funksjonaliteten krever at systemparameter 185 ikke er i bruk.

Bruk av Excel i "Bestillingskriterier"

  • Knapper for bruk av Excel vises kun dersom Excel er installert lokalt på arbeidsstasjonen.
  • Eksport av bestillingskriterier til Excel kan kun utføres for butikker merket med "Bestilling" påslått i butikkregisteret
  • Import fra Excel kan også kun benyttes for butikker merket med "Bestilling" påslått i butikkregisteret.
  • Nye bestillingskriterier kan kun legges opp for aktive butikker med "Bestilling" påslått i butikkregisteret.
Teknisk informasjon
Aktive butikker  ha kommunikasjonstype = 11.

Sletting av kampanjepriser, medlemstilbud og ordinære prisendringer via RIGAL V-fil

(RTC-31913)

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.

Teknisk informasjon

Det er felt 7.1.5 i RIGAL V-fil som gjør dette mulig:

Verdi A = Sletting av kampanjepris (start- og sluttdato må angis i felt 8 og 9).
Verdi B = Sletting av medlemspris (start- og sluttdato må angis i felt 8 og 9).
Verdi C = Sletting av fremtidig prisendring (fremtidig endringsdato må angis i felt 8).

Logging ved sletting av tandem via RIGAL VPI

(RTC-32771)

Ved sletting av tandem via post i RIGAL V-fil dette logges:

  • I Oppdateringslogg (vpiins*) vil dette telles opp under "Oppdatert".
  • I standard Feillogg (vpierr*) skrives meldingen - "Legger opp sletteposter for TANDEM-nr xxx for hovedvarenummer yyy".
  • I Total feillogg (vpierrtot) skrives også meldingen "Legger opp sletteposter for TANDEM-nr xxx for hovedvarenummer yyy".
Teknisk informasjon
Tandem kan slettes via RIGAL V-fil ved å sette "S" i feltet foran tandem-EAN.

Varehierarkiliste for "Cloud-eksport"

(RTC-33345)

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.

Optimalisering av prosedyre (proxy) for oppdatering av varelokale feltverdier fra InStore App

(RTC-33888)

Utvikling av generelle oppdateringer, fra InStore App, sikrer god dataflyt.

Teknisk informasjon
I intern test ble det avdekt problemer med at oppdateringsprogrammet gikk i heng med status "LOCKED" for appserveragentene.
Et samarbeid mellom Chain Classic teamet og InStore App teamet har løst låseproblemet.
Generelle forbedringer i InStore App minimerer tilsvarende problematikk ved bruk av andre proxy-oppdatering. 



Chain Classic versjon 2.1.1.0.39

Dokument status: RELEASED

Dato:   

Forutsetninger for oppgradering

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

Utlegg til Lexmark ved endring av EAN/PLU

(RTC-32054)

Ved endring av EAN/PLU blir nå følgende lagt ut til Lexmark:

  • Vare-fil til totalbutikk:
    • Slettepost for gammelt EAN/PLU-nummer
    • Ny-post for nytt EAN/PLU-nummer 
  • Pris-fil til vanlige butikker:
    • Slettepost for gammelt EAN/PLU-nummer
    • Ny-post for nytt EAN/PLU-nummer
    • Poster for pågående kampanjer samt framtidige prisendringer og kampanjer legges ut med nytt EAN/PLU-nummer
Teknisk informasjon

Forutsetter at det finnes Lexmark-butikker definert i systemet, dvs. at butikknummer er satt opp i systemalternativer for butikk 717.

Ved endring av EAN/PLU blir nå følgende lagt ut til Lexmark:

  • Vare-fil til totalbutikk:
    • Slettepost for gammelt EAN/PLU-nummer (Lexmark køtype 2, repetert dersom antall tandemer er > 1)
    • Ny-post for nytt EAN/PLU-nummer (Lexmark køtype 1, repetert dersom antall tandemer er > 1)
  • Pris-fil til vanlige butikker:
    • Slettepost for gammelt EAN/PLU-nummer (Lexmark køtype 2, repetert dersom antall tandemer er > 1)
    • Ny-post for nytt EAN/PLU-nummer (Lexmark køtype 1, repetert dersom antall tandemer er > 1)
    • Poster for pågående kampanjer og framtidige prisendringer (Lexmark køtype 6-8, repetert dersom antall tandemer er > 1).
      Legges ut med nytt EAN/PLU-nummer

Utlegg til Lexmark ved bytte av tandemnummer

(RTC-32319)

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

Teknisk informasjon

Forutsetter at det finnes Lexmark-butikker definert i systemet, dvs. at butikknummer er satt opp i systemalternativer for butikk 717.

Følgende utlegg blir gjort:

  • Lexmark vareformat (libitemlex):
    • Sletteposter for tandemer på gammel vare (inkl. den som flyttes).
    • Vareendringsposter for alle tandemer på ny vare (inkl. den som er flyttet).
  • Lexmark prisformat (priceitemlex):
    • Slettepost for tandemer på gammel vare (inkl. den som flyttes).
    • Nyopplegg av tandem til ny vare (inkl. den som er flyttet).

Utlegg til Lexmark ved sletting av tandemnummer

(RTC-32318)

Ved sletting av tandemnummer på en vare legges det nå ut Lexmark-melding både til totalbutikk (libitemlex) og øvrige butikker (priceitemlex).

Teknisk informasjon

Forutsetter at det finnes Lexmark-butikker definert i systemet, dvs. at butikknummer er satt opp i systemalternativer for butikk 717.

Følgende utlegg blir gjort:

  • Lexmark vareformat (libitemlex):
    • Sletteposter for alle tandemer på hovedvare (inkl. tandem som skal slettes).
    • Ny-vareposter for gjenværende tandemer på hovedvare.
  • Lexmark prisformat (priceitemlex):
    • Sletteposter for alle tandemer på hovedvare (inkl. tandem som skal slettes).
    • Ny-vareposter for gjenværende tandemer på hovedvare.
    • Poster for aktive kampanjer, samt for framtidige kampanjer/prisendringer.

Parameterstyrt etikettutskrift for Lexmark 

(RTC-32061)

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.

Teknisk informasjon

Systemparameter 878 er endret og må være satt til gjeldende omsetningskrav for Lexmark-etikett:

  • Verdi 1 = Max antall dager tilbake i tid (seneste salg), ved vareendring/ord. prisendring.
    Verdi 2 = Max antall dager tilbake i tid (seneste salg), ved endring av kampanjepris og medlemstilbud.
  • Antall dager = 0, betyr for begge parametere at det ikke settes krav til omsetning.

Verdiene i systemparameter 878 gjelder generelt for alle butikker med Lexmarkutlegg (alle butikker i systemalternativer for butikk 717).

Systemalternativer for butikk 878 åpner for at butikkbrukere selv kan sette disse verdiene. "Brukerstyrt" og "Tillatt å endre for butikkbrukere" må begge være valgt for dette.

I help-katalogen finnes skriptet "lagbutparmrad_878.p" som kopierer verdier fra systemparameter 878 til "Systemalternativer for butikk 878" for ALLE "Lexmark-butikker". Dersom kun enkelte butikker skal ha denne adgang legges disse opp manuelt. Omsetningskravene kan da endres av de butikker som har adgang dersom det er ønskelig med avvikende verdier.



Chain Classic versjon 2.1.1.0.38

Dokument status: RELEASED

Dato:   

Forutsetninger for oppgradering

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

Forbedringer

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.
I POS fjernes deretter alle relasjoner til de varer som opprinnelig var koblet til mixmatch'en.   

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:

  1. Bong med kun spørring på pris

  2. Annen makulert bong med spørring på pris (f. eks. parkert bong)

  3. Anbud med spørring på pris

  4. Vanlig varesalg med spørring på pris

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. 

  • Felter knyttet til sentrallager (beholdning og i bestilling) skjules når brukerens butikk ikke har referanse til butikknummer for sentrallager
  • Eget butikknummer markeres i listen med grønn bakgrunn for alle varianter slik at det tydelig kommer fram hva som er eget lager

Printervalg for etikett i priskontroll og manuelt varemottak

(RTC-31500)

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.

Teknisk informasjon

Etikettype velges iht. spesifikasjon på varens prispost, og skriver velges automatisk som følge av skriver som er lagt opp.
Velger man en spesifikk etikettype, vil det søkes etter en skriver for butikk/etikettype. Finnes skriveren, vil denne foreslås.

Merk

Merk at i "Etiketter fra varemottak" krever at valgt etikettype er definert som prislapp, se systemparameter 222.

Utlegg av resepter/ingredienser til Tokheim POS

(RTC-30892)

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.

Teknisk informasjon

Med aktiv systemparameter 983 forhindres utlegg av resept- og ingrediensinformasjon.

  • Ingredienser vil i stedet inkluderes i [SHOP_UPDATE] hvor hver ingrediens blir definert for en råvare.
    Ingrediensene kommer etter vareutlegget og med "dummy" EAN-nummer i en gitt nummerserie.
  • For reseptvarer legges ikke reseptinnholdet ut. Det innebærer at hele seksjonen [COMPOSITIONS_UPDATE] fjernes.

Spesialbehandling av antall i varemottak via RIGAL 

(RTC-31684)

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.

Teknisk informasjon

Systemparameter 986 åpner for denne funksjonaliteten.

I Leverandørregisteret merkes de leverandører dette gjelder ved å krysse av "Bruk antall i småpakning".

Merk

Denne funksjonaliteten vil kun fungere som beskrevet ved godkjenning av varemottaket i Chain Classic. 
Ved automatisk oppdatering av varemottak utført i InStore App, forutsettes antallet å være korrekt for alle varer.

Alternative utvalgsfelt i rapport "Grunnlag bestilling" 

(RTC-30600)

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.

Sletting av fremtidig prisendring via RIGAL V-format 

(RTC-31599)

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.

Import/-eksport av bestillingskriterier fra Excel

(RTC-30593)

Ved oppdatering av bestillingskriterier via Excel fra 3. part, finnes det 2 parameterstyrte alternativer.

  1. Ved bruk av basisfunksjonaliteten kan kun parameterstyrte butikker oppdateres, og dette skjer per vare for angitte butikker med angitte verdier.
  2. I tillegg finnes et alternativ hvor oppdatering per vare kan skje for alle butikker 

Innholdet i Excel filen skal bestå av følgende felt, hvorav de i blått kan endres:

  • Butikknr
  • EAN
  • Varetekst
  • Farge
  • Bestillingspunkt
  • Bestillingskvantum
  • Sletting (0 = Nei / 1 = Ja)
  • EAN tekstfelt (Eks. EAN1234567)

Ny butikkpost kan opprettes eller en eksisterende post kan slettes. Antall kan endres (0 er gyldig).

Teknisk informasjon

Oppdatering av bestillingskriterier fra Excel aktiviseres ved å legge inn utvalgte butikker i systemparameter 869.
Da vil knappene for import/-eksport fra Excel vises i programmet.
Denne må være i bruk når systemparameter 984 benyttes for oppdatering til fritt valgte butikker. 

Tillat EAN = 0 i RIGAL prisendring

(RTC-31303)

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.

Merk

PRI-post med ukjent EAN, i Chain Classic, vil bli avvist.

Teknisk informasjon

Viktig at følgende systemparametere har riktig verdi:

112 = 1 (bruk av alfanumerisk varenr)
219 = 1 (søk via varenr ved ukjent EAN)
491 = 1 (påslått betyr ikke krav til unikt varenr)

Hovedparameter i denne saken, for å finne vare via unik kombinasjon varenr og salgsenhet:

Systemparameter 985 kan ha 3 verdier:

    • 0 = Ikke i bruk

    • 1 = Kun for PRI poster

    • 2 = Både VAR og PRI poster

Oppdatering av pakkevarer i bestilling fra InStore App

(RTC-31392)

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.

Teknisk informasjon

Forutsetninger: 

  • Gjelder kun "Elektronisk varemottak" basert på eksisterende bestilling.

  • Pakkevare skal ligge i bestillingen

  • Ved oppdatering av RIGAL I-filen som skapes, lages det varetransaksjoner med antall for innholdet i pakkevaren.

Behandling av RIGAL I-filer med "0-ordrer"

(RTC-31257)

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.

Teknisk informasjon
Systemparameter 953 fører til at ordrerader med antall = 0 blir behandlet.

Endring i eksport av tankstatus til Reporting

(RTC-31543)

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.

Teknisk informasjon
"L15-verdien" vil hentes fra feltet "Kompmengde".

Standardisering av datotype i rapportutvalg

(RTC-31479)

I datoutvalg er årstall standardisert til to siffer for alle rapportutvalg med en hjelpeknapp for kalenderoppslag. 

Oppdatere kun vareinformasjon via RIGAL VPI

(RTC-31803)

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.

Teknisk informasjon

Systemparameter 185 = 0
Systemparameter 191 = 0
Systemparameter 987 = 1

I VPI-mal må verdi for "utprisn" i kolonne "Nullstille" settes til "Ja".
Dette åpner for umiddelbar behandling av poster med kun varefeltene utfylt (pris = 0).

Dersom kolonnen "Nullstille" i VPI-mal er skjult, slå på systemparameter 693.
Kontroller også hvilke andre felt som det skal være tillatt å oppdatere med "nullverdi" fra RIGAL VPI.
Verdi for "Nullstille" i VPI-mal (Ja/Nei), kan kun endres dersom "Logisk" er påslått for VPI-malen(e) i systemalternativer 79.

Logging når ny kampanje-/medlemstilbud "deler" dato-/tid intervall

(RTC-29764)

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

Finn og slett tandemnummer som også finnes som hovedvare

(RTC-31081)

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.

Teknisk informasjon

Programmet "Slett tandem som hovedvare" under "LRS"/"Korrigere/endre data" er som standard satt opp med kun logging (i txt-loggen).
Dette kan uten risiko kjøres som en helsesjekk.
Dersom txt-loggen viser at det finnes avvik, kan programmet kjøres igjen uten avhuking for logging.
Resultat blir da at avvikende tandemer fjernes og legges ut for sletting til POS. Det legges også ut slettepost til Chain Web ved behov.

Kontroll av feil i JSON lagerformat

(RTC-30567)

Forhindre at feilposter i dette JSON-formatet blir liggende ubehandlet

Teknisk informasjon

For å hindre at filko fylles opp med prioriterte lagerposter i feil format, vil nå alle slike poster med < 7 felt forkastes.
De logges før de fjernes fra filko.

For prioritert lagerutlegg i JSON-format:

  • Slå på "Logisk" i Systemalternativer 193, alternativt opprett butikkspesifikk post i Systemalternativ for butikk 193
  • Feil logges til filen lrs\logg\jsonerrMMDD.txt
  • JSON utleggsfil havner i sendes-katalogen dersom ikke en alternativ katalog er angitt med komplett sti i systemparameter 798 (for eksempel. C:\lrs\json_stock)

Vedlikehold av "Feltverdier i butikk"

(RTC-30424)

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.

Teknisk informasjon
I systemalternativer 1019 er det verdi i feltet "Logisk" som avgjør om et feltnavn skal vises eller ikke. 

Sletting av Chain Classic bruker

(RTC-31487)

Ved sletting av bruker i Chain Classic slettes alle brukerrelaterte data. 

Teknisk informasjon
Systemparameter 993 åpner for mulighet at utviklingsbuker kan få lov å slette annen utviklingsbruker.
Det anbefales at dette kun slås på ved ekstraordinære behov.
Dersom alle utviklingsbrukere slettes, blir det vanskelig å rette opp problemer som krever en bruker med rettigheter på høyeste nivå.

Utlegg av sletteposter for butikklokale mixrader ved sletting av butikkpris

(RTC-31530)

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.



Chain Classic versjon 2.1.1.0.37

Dokument status: RELEASED

Dato:   

Forutsetninger for oppgradering

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

Forbedringer

Modul 

Beskrivelse 

Lexmark

Lexmark oppdatering når tilbud = ordinærpris (RTC-29650)

I situasjonen der kampanjepris/medlemstilbud = normalpris og normalpris økes i tilbudsperioden vil dette ikke trigge etikett.
Hvis kampanjeprisen deretter økes slik at denne igjen blir lik normalpris vil dette gi etikett til Lexmark merket som prisendring i stedet for kampanje/medlemstilbud.
Det er kun utprisendring til tilbud lavere enn ordinærpris som vil gi etikett merket kampanjepris/medlemstilbud. 

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.
Når dette er i bruk legges disse 0-postene ut ved alle typer at varetelling.  

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.  

Bytte av butikknummer

(RTC-28607)

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.

Teknisk informasjon
Ved butikknummerbytte endres det i gammel butikkpost i butikkregisteret til nytt butikknummer.
Dersom gammelt butikknummer skal beholdes, lages en ny post med gammelt butikknummer, profilnummer er beholdt, kommunikasjonstype settes = 1 og butikknavn blir satt til: "Old store no. for store xxxx (nytt butikknr).
Ellers er oppsettsdata blanke.

Automatisk opplegg av varemottak ved internoverføring

(RTC-28722)

Uansett hvilken RIGAL-kode som brukes for faktura eller bestilling/bekreftelse, vil det alltid lages et automatisk varemottak ved internoverføring mellom butikker.

Eksport av alle kunder i til Customer Service

(RTC-29646)

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

Teknisk informasjon

Systemparameter 982 må settes opp med sti (path) til katalog for kunderelaterte JSONL-filer, for eksempel: json_cust\ , denne må også skapes manuelt i LRS-katalogen.

  • Dette er en første utgave som sannsynligvis må endres videre sammen med løsningene som skal motta dette formatet.

Eksporter alle kundegrupper til Customer Service i JSON-formatet 

(RTC-29536

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. 

Teknisk informasjon
Det må manuelt lages en katalog, under LRS-katalogen, med samme navn som er brukt i feltet "Verdi" i systemparameter 982.

Sletting av lokale butikkpriser

(RTC-30014)

Denne funksjonaliteten brukes når en butikk kun skal ha profilpriser, og aktive lokale butikkpriser skal derfor fjernes. 

  • Ytelse er vesentlig forbedret.
  • Det kan velges å skrive en rapport, men kun dersom antall forventes å være under 200.000 lokale prisposter.
  • Mulighet å lage utvalg på varegruppeliste er lagt til
  • Antall poster vises direkte i jobblisten, rapport trenger ikke å lages for dette
Teknisk informasjon

Grunnet begrensning i 3. part programmet "vsView", er rapport genereringen begrenset til maks 200.000 lokale prisposter. Dersom antall er større enn dette, er risikoen for heng i programeksekveringen stor. Nå er det vel uansett ikke aktuelt å lese en rapport med så mange varelinjer. 

  • Systemparameter 997 finnes for å angi maks antall poster varer som kan skrives ut i rapport. Maksimalt 200.000 og 0 = ikke i bruk.
  • "Ikke lag rapport" er et valg på fanen "Alternativer" som unngår å lage rapport uansett antall varer i utvalg. Dette bør brukes når det er kjent at det er mange lokale butikkpriser som skal slettes og/eller at rapport er unødvendig.
  • Dersom funnet antall poster overgår verdi i systemparameter 997 eller 200.000 stk., vil det heller ikke lages rapport.
  • Hvis rapport ikke skrives, vises dette som: "Ingen rapport" først i kolonnen "Resultat" i rapportlisten for antall varer. 

Logging av "Mottak av webordre"

(RTC-20334)

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.

Teknisk informasjon

Loggfilen har følgende innhold:

  - Beskrivende tekst
  - Butikknr
  - Ordrenr
  - Ordretype
  - Sendstatus
  - Dato/tid for når mottaket ble registrert
  - Kollinr
  - Lagersted  

Hva som trigger logging:

  - Ingen kontakt med webservice
  - Webordre mottatt i butikk
  - Overføring via webservice feilet
  - Webordre IKKE mottatt komplett i butikk

Import av sortimentliste Excel i fullt format 

(RTC-30412)

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. 

Teknisk informasjon
  • Fullformat Sortimentliste Excel aktiveres ved å sette systemparameter 964 = 1.
  • Laget Excel-rapport representerer det fullformat som skal brukes for VPI-import via excelvpi.csv.
  • Det er KUN felt fra standardformatet som oppdateres, ikke de nye feltene.

Forbedret oppdatering i søkefunksjon i lagerprogrammer for drivstoff

(RTC-30780)

På toppen av den oppdaterbare delen i programmet "Manuell tankstatus" kan HK-bruker søke etter aktive butikker med minst en tilkoblet tank.
For butikkbrukere vises kun egen butikk dersom det finnes minst en tank registrert på butikken. 
I tillegg vil det nå i det vanlige registreringsprogrammet, "Tankstatus", alltid vise korrekt produktnavn dersom man endrer tanknr/tankgr.

Alternativ for utlegg av reseptvare til Tokheim POS

(RTC-29655)

Utlegg av info for servicehandels-varer kan parameterstyres for å forhindre varer fjernes utilsiktet fra en resept i Tokheim POS.

Teknisk informasjon
Aktiv systemparameter 983 medfører at feltet COMP_TYPE i utlegg av reseptvare til Tokheim POS skal ha verdien "3" i stedet for "2".



Chain Classic versjon 2.1.1.0.36

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer

Modul 

Beskrivelse 

Etikett

Etikett skrives ikke uten endring av utpris (RTC-29332)

Hvis ny kampanjepris er lik utpris eller hvis kampanjenettopris, men ikke utpris, endres på aktiv kampanje da skrives det ikke etikett ved noen av disse tilfellene.

Kampanjegruppe

Sletting av mixmatch fra ikke godkjent kampanjegruppe (RTC-29477)

Ved opplegg av ny kampanjegruppe med flere mixmatcher kan bruker slette både en og flere mixmatcher før selve kampanjegruppen godkjennes.    


Samme vare i multiple michmatcher i samme kampanjegruppe (RTC-27651)

Det er mulig å ha flere mixmatcher, med samme vare, i en kampanjegruppe, uten risiko for komplikasjoner grunnet identisk start- og/eller sluttdato.  

Mixmatch

Innhenting av nye varer i allerede godkjent mixmatch (RTC-29815)

I manuell mixmatch eller mixmatch i kampanjegruppe kan innhenting av nye varer gjøres på flere måter. Uansett metode vil både automatisk og manuell godkjenning/lagring lage varekøposter med samme butikknummer som er gjeldende i nevnte tilbudstyper.

Rapporter

Antall solgte varer i grafisk varegruppesalgsrapport (RTC-29486)  

Ved bruk av grafisk varegruppesalgsrapport kan det åpnes et vindu for "Fordeling pr. butikk". Generelt vil denne "pop-up" ha en kolonne for antall, men i tabeller for varegruppe- og undergruppesalg gir det ikke mening å lagre antall (av uidentifiserte varer). For å unnvike misforståelse ekskluderer disse salgsrapportene kolonne "Antall", i stedet for å vise verdi 0 for alle poster.  

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.

  • Alle nettoprisendringer oppdateres.
  • Kun nettoprisendringer til beløp > 0 oppdateres.
  • Ingen nettoprisendringer oppdateres, opprinnelig verdi alltid gjeldende samme.
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.

Merk!

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:

  • 1  Synlig svinn" (1)
  • 2  Intern forbruk" (2)
  • 6  Lagerjustering" (6)
  • 11 Nedpakking

Alternativ:

  • 7  Varetelling - kan parameterstyres til om dette skal tillates eller ikke

Følgende transaksjonstyper kan ikke registreres, kopieres eller motposteres:

  • 3  Retur
  • 4  Reklamasjon fra kunde, utføres i POS (Transaksjonstekst inneholder "kasse")
  • 5  Varemottak
  • 8  Tellsvinn
  • 9  Internoverføring 

Knapp for "Kopiering" og "Motpostering" (= sletteknapp) er deaktivert for de transaksjonstyper det ikke er tillatt å registrere.

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.

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

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

Med oppgradering til Chain Classic versjon 2.1.1.0.35 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)

  • Det kan velges om butikkbrukere eller alle brukere, unntatt utviklingsbrukere, skal ha begrenset adgang til funksjonalitet ved vedlikehold av kampanjegruppe. Fanene "Kampanjepris", "Medlemstilbud" og "Mixmatch" kan alle deaktiveres, enten for kun butikkbrukere eller for alle brukere, unntatt utviklingsbrukere som alltid har adgang til alle fanene.
  • Det er også mulig å sperre for manuelle valg av kampanje-ID når butikklokal kampanjegruppe opprettes, dette gjelder uansett brukertype. Denne funksjon forutsetter et ønske om at alle butikklokale kampanjegrupper alltid skal ha samme kampanje-ID. Denne verdien for kampanje-ID parameterstyres.
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). 

  • Hvis kostpris mangler i varetransaksjon hentes dette fra ordinærpris.
  • Det skrives en fane for hver butikk i Excel-rapporten, med butikknr som fanenavn.
  • Det skapes også en PDF rapport med samme opplysninger.



Chain Classic versjon 2.1.1.0.34

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer

Modul 

Beskrivelse 

Etikett 

Bestill etikettutskrift med forskjellige etikettyper (RTC-27262)

Det er mulig å bestille og skrive ut etiketter med forskjellige etikettyper i samme etikettbestilling fra InStore App. 

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

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:

  • Kun for butikk med denne funksjonaliteten aktiv.
  • Mengdefeltet til Reporting oppdateres dersom "komplestmengde" > 0.

Vedlikehold av Tankstatus:

  • Feltet for "L15 kompensert" mengde vises kun for butikk med denne funksjonalitet aktiv og "komplestmengde" > 0.

Loggrapport loggtype 80:

  • I loggtype 80 logges endringer av "komplestmengde".
  • Rapporten takler også loggposter med kun 7 felt, uten "komplestmengde", da vises feltet "L15 kompensert" = 0.
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 lagerfil i JSON-format til egen katalog for videre bruk i Inventory Module. Viktig at "Eksport av lager til Inventory" er avhuket.

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

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

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:

  • Manuell innlegging
  • Hent nye varer
  • Hent varer via utvalg 
  • Hent varer via varegr 
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.1.1.0.32

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

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

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.

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. 

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.

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.

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

Innlesing av JSON-fil fra StoreMaster

(RTC-25721)

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

  • Adresse
  • Åpnet dato
  • E-post 
  • Lagerstyrt
  • Mobilnr
  • EAN-lokasjonsnr
  • Andre butikker med lager som denne butikken kan se.
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. 

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

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer 

Modul Beskrivelse 
Kunde 

Oppdatering av kundeinfo i Chain Classic når Chain Web er kundemaster (RTC-23787)

Det er parameterstyrt om kunde skal oppdateres i Chain Classic når Chain Web tar over som kundemaster. Uansett om kundeinfo finnes eller ikke, vil det være mulig å vise web-/kundeordre i Chain Classic. 

Teknisk informasjon
Systemparameter 418 må settes opp riktig hvis kundeinfo skal oppdateres, i Chain Classic, via web-/kundeordre når Chain Web har tatt over som kundemaster.
Mixmatch

Varegruppemix (RTC-23878)

Ved opplegg av varegruppemix kan knappen "Hent varer via varegruppe" brukes. Krav er at det finnes profilpris og at varen er aktiv på butikk, for team gjelder da dette for alle butikker ellers vil varegruppe ikke hentes inn. For beste funksjonalitet er det derfor anbefalt å bruke spesifiserte dummyvarer, en for hver enkelt varegruppe. Da er det nok at én dummyvare pr. varegruppe er aktiv, dog på alle team sine butikker.

Teknisk informasjon
Systemparameter 779 spesifiseres valgfri PLU-nummerserie, som ikke er i bruk, for opplegg av dummy-varer for varegrupper, hvor for eksempel XXXXX1 er dummy-vare for varegruppe 1 og xx9999 er dummy-vare for varegruppe 9999. De siste fire sifrene MÅ tilsvare varegruppe. Det må også lages/finnes en tilsvarende dummyvare for vær varegruppe, denne skal ha profilpris og være aktiv for alle butikker.  
Rapporter

Rapport "Grunnlag bestilling" (RTC-23465)

Rapporten "Grunnlag bestilling" er laget for at lageransvarlig skal få overblikk bestillingsgrunnlag for egen butikk, men det er også mulig for HK-bruker å ta frem en sammenstilling over flere butikker samtidig.


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.


Avgrensing i varekølogg (RTC-23553)

Normalt er varekølogg kjørt via EOD og da hentes alle ønskede køposter med dato/tid og køtype som utvalg. Det er også mulig å kjøre slike rapporter på et mer avgrenset utvalg, som på varenivå med kun et spesifikk  EAN/PLU-nummer. 

Register

Avvik mellom postnummerregister i Chain Classic og Chain Web (RTC-23376)

Hvis register for postnummer i Chain Web oppdateres før register i Chain Classic er oppdatert, når kundeordre kommer til Chain Classic, da lagres ukjent verdi i postnummertabellen, med informasjonsteksten:  "Created from CW", dato og tid. Slik at det kan verifiseres at dette postnummeret er opprettet av Chain Web. 

Varetelling 

Varetellingsliste lages ikke (RTC-24318)

En feil i patch 2.1.1.0.28 er korrigert og allerede levert i ombygget patch 2.1.1.0.31.

Hotfix er tilgjengelig for patch 2.1.1.0.18 - 2.1.1.0.30.

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

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.

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

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.  

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 må være i bruk.

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

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.

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

Bestilling av kun hele forpakninger fra InStore App

(RTC-23459)

Det er mulig å parameterstyre om kun hele forpakninger skal være mulig å bestille når anbrekk ikke er tillatt for varen. 

  1. Bestilling i InStore App med antall som er lavere enn angitt i (små)forpakning endres opp til "antall i pakning"
  2. Bestilling i InStore App med antall som er høyere enn angitt i (små)forpakning, men ikke tilsvarer et helt antall forpakninger, endres ned til det som tilsvarer nærmeste antall hele forpakninger.
  3. Logg kan lages under: "Rapporter"/"Logger"/"Loggutskrift": Loggtype 27 "Endret antall i bestilling fra ISA". Det er parameterstyrt om denne skal vises for butikkbruker. 
Teknisk informasjon

Systemparameter 955 =1

Systemalternativer 1034, rad 27 
   - Logisk = Vise alternativ under "Loggutskrifter" (Standard)
   - Integer = 0 (Skjul for butikkbruker, standard) 
   - Integer > 0 (Vis for butikkbruker)

Funksjonalitet kan IKKE kombineres med aktiv systemparameter 650!

Tandemnummer i bestilling fra InStore App

(RTC-23885)

Ved innlesing av bestilling i Chain Classic, fra InStore App, fanges også vare med tandemnummer opp, hvis den er brukt i bestilt pakkevare.

Teknisk informasjon
Systemparameter 9007 er det skjulte parameter som fjerner innsendt dublett av bestillingsrad i varemottak.

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"

Utskrift av etikett ved bruk av Pakke-ID

(RTC-23684)

Det er mulig å skrive ut etiketter fra elektronisk varemottak også ved bruk av pakke-ID sammen med ordrenummer.

Teknisk informasjon
Systemparameter 956 = 1 slår på funksjonalitet som finner frem riktig etikettgrunnlag, for kombinasjon av pakke-ID + ordrenr, til å skrive ut etiketter i elektronisk varemottak.

Behandling av antall = 0 ved import av bestilling via RIGAL-fil

(RTC-22349)

Standard er at rader med antall = 0 avvises ved RIGAL-import. Det er mulig å parameterstyre funksjonaliteten slik at innsendt bestillingsrad med antall = 0, i RIGAL I-fil, ikke blir avvist.

Teknisk informasjon

Systemparameter 953 = 1  (Bestillingsrad opprettes fra RIGAL I-fil når bestilt antall = 0)

Ny funksjonalitet dersom parameter er påslått:

  • Post med antall = 0 leses inn og opprettes som bestillingsrad.
  • Dersom ALLE rader har antall = 0, settes bestillingen til status "mottatt" direkte, og eksport av RIGAL I-fil foretas (eksport kun hvis systemparameter 271 = 1).
  • Når åpne varemottak hentes inn til InStore App vil ikke 0-radene komme med. Når alle "ikke 0-rader" er behandlet i InStore App, sørger Chain Classic for at disse eksporteres sammen med 0-radene, i bestillingen, som et komplett utlegg fra elektronisk varemottak. 

Utlegg av tellegrunnlag for butikker utenlagerstyring til Chain Web 

(RTC-23050)

Det er mulig å legge ut tellegrunnlag også for ikke-lagerstyrte butikker, via "Lagerinformasjon til fil". For å lage tellegrunnlag må varen være aktiv og ha pris på butikk eller profil.

Teknisk informasjon

Oppsett:

Systemalternativer 196 - Lager:  Integer >= 10 + Logisk.

Systemparameter 666 må settes for logging av proxy-relaterte lagerutlegg til Chain Web.

  • Utlegg av gjeldende lagerverdier = 0
  • Utlegg av verdi for lagerstyring = No

Legg ut 20-kode uten sjekksiffer i RIGAL

(RTC-23176)

På vektvarer brukes EAN med 20-koder, for eksempel 2000123400000 hvor de siste 5 sifrene = 0 for å sette pris/vekt etter veiing og utskrift av prislapp. Ved utlegg av disse til RIGAL er det likevel standard at koden rekalkuleres og at det da lages en sjekksiffer slik at koden kan skannes om den skrives ut på etikett. Det er mulig å parameterstyre at 20-kode alltid skal legges ut med 0 som siste siffer til RIGAL-format.

Teknisk informasjon
Systemparameter 954 = 1 betyr at sjekksiffer ikke skal brukes, KUN 0 som siste siffer i 20-koder ved utlegg av RIGAL-filer.

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.

Eksternt ordrenummer og eksternt linjenummer i varemottak

(RTC-23180)

Chain Classic kan kommunisere eksternt ordre- og linjenummer via RIGAL I-fil.

Teknisk informasjon

Det er feltene 37 (egentlig "refnr") og 38 ("reflinjenr"), i RIGAL I-fil som ikke er i bruk fra før og kan derfor benyttes for "Eksternt pakkseddelnr" og "Eksternt radnr". Felt 37 støtter 9 siffer i eksternt pakkseddelnummer og felt 38 klarer inntil fire siffer i eksternt radnummer. Etter varemottak lagres begge verdiene i feltet "Fritekst" i bestrad-tabellen, separert med komma. Verdiene vises ikke og kan ikke redigeres i Chain Classic. 

Når lager oppdateres legges verdiene ut i felt 37-38 i RIGAL I-fil.

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.

Programmet "Slette/fjerne fra kasse"

(RTC-22976)

Mulighetene til logging er utvidet, men fremfor alt er ytelsesforbedringene vesentlige i programmet "Slette/fjerne fra kasse", som består av to behandlingsvarianter:

  • Fjerne vare fra kasse
  • Slette varer/priser

"Fjerne vare fra kasse" betyr at det legges ut deaktivering av vareutvalg til POS. Dette er en vareoppdatering som derfor gjelder ALLE prisprofiler. Det betyr at alle profiler må sjekkes på evt. lagerbeholdning, salg etter angitt dato som kan forhindre at vare fjernes fra POS.

  • Merk at noen parameteroppsett kan overstyre dette og deaktiverer da kun varene på valgt profil, se tekniske release notes.

"Slette varer/priser" betyr at de varene (prisene) som faller innenfor kriteriene skal slettes, noe som er mer ytelseskrevende. 

  • Loggen i rapportlisten viser nå antall varer og den tid det tar.
  • Det er mulig med mer detaljert logging, akkurat som for "Oppdater vare", "Klargjør varekø" og "Hurtigprising".
Teknisk informasjon

Systemparameter 860 har annen hoved funksjonalitet men påvirker alternativet "Fjerne vare fra kasse" på følgende måte.
   - 860 = 0 : Alle prisprofiler behandles (standard) 
   - 860 = 1 : Kun valgt prisprofil behandles

Systemalternativer 215: Oppsett av utvidet logging ved å slå på logisk

Unngå deadletters når Chain Web tar over som kasserermaster

(RTC-23612)

Chain Classic må tilpasses når Chain Web tar over som master for kasserere. 

Teknisk informasjon

Hvis Chain Web er master for kasserere og deadletters dukker opp når kassereroppdatering fra Chain Web, via kassererProxyp.p, avvises med melding: IP 493. Da løses dette ved tilpassing i Chain Classic hvor 1. verdi MÅ settes = 0 i systemparameter 731 =0,x,y.

Konsekvensen som følge av dette er at det blir mulig å sette blank passord, noe som ikke er anbefalt og i denne situasjonen bør derfor menyvalg for vedlikehold av kasserer fjernes i Chain Classic.



Chain Classic versjon 2.1.1.0.30

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer 

Modul Beskrivelse 
Vare

Servicehandel og relasjon antall/pris (RTC-22910)

Ingredienser, resept og pris er sammenkoblet i "Servicehandel". Som følge av dette vil for eksempel tilsvarende pris oppdateres korrekt også i "Resept" og "Pris" hvis antall endres på noen poster i "Ingredienser".

RIGAL

Oppdatering av pris via tandem i RIGAL-VPI (RTC-22919)

Tandemnummer kan benyttes til prisendring, hvis dette sendes inn som hovedvare og skjer via PRI-post i RIGAL V-fil.

Rapport

Makulerte bonger i "Butikkoppgjør total" (RTC-22956)

POS-bonger med kundeordre og varesalg som makuleres i kassen registreres korrekt i Chain Classic og oppdaterer raden "Mak. av bong" i rapporten "Butikkoppgjør total".

Kampanjegruppe

Se profilkampanjer som butikkbruker (RTC-23239)

Det finnes mulighet å åpne for at butikkbruker også ser profilkampanjegrupper. Dette kan være fornuftig da disse også gjelder egen butikk. For butikkbruker er det da mulig å se, men ikke å endre noe, i profilkampanjegruppen. Det er mulig å kopiere slik at butikken får en egen kopi av profilkampanjegruppen. Denne kan deretter kompletteres og endres hvis butikken ønsker å gi bedre tilbud, innenfor samme periode. 

Teknisk informasjon

Systemparameter 723 styrer om profilkampanjegrupper skal vises eller ikke.

SKU-felt for Chain Web i vare.99900

(RTC-18501)

Feltet "SKU" legges ut blank fra Chain Classic til totalbutikken i følgende to formater, vare.99900 hvor det er felt 92 som benyttes og tandem.99900 hvor felt 5 benyttes. I Chain Web kan feltet ha inntil 50 tegn, men vil alltid være tomt når det legges ut fra Chain Classic.

POS bruker kan bruke dette felt til felles funksjonalitet ved oppdatering både fra Chain Classic og Chain Web. 

Tekniske release notes

For å benytte denne funksjonalitet følgende oppsett være på plass.

  1. Systemalternativer 121, kode 1 (VPI) sett Integer = 92 for utlegg av 92 felt i  vare.99900
  2. Systemalternativer 121, kode 27 (Tandem) sett Integer = 5 for utlegg av 5 felt i  tandem.99900

Fabrikat i rapport "Aldersfordelt lagerverdi"

(RTC-21047)

Rapporten "Aldersfordelt lagerverdi" viser nå også "Fabrikat" for varene i  en ny kolonne.

Ugyldige tegn i sensitive tekstfelt

(RTC-21344)

I "Vare", Kunde" og forskjellige registerprogrammer kan det få konsekvenser hvis det lagres ugyldige tegn i sensitive navnefelt. 

Usynlige tegn, som ved "uhell" kommer med i tekst ved for eksempel kopiering, fjernes automatisk ved lagring i brukergrensesnittet eller RIGAL VPI-import. Utover dette kan andre tegn som oppdages underveis legges til i en liste for å unngå fremtidige problemer.

Tekniske release notes

Usynlige tegn som ASCII 1-31 og ASCII 127, er hardkodet og fjernes automatisk ved lagring/VPI-import.

I systemparameter 951 kan en liste lages med "egne funn" av tegn som kan gi problemer mot Chain Web eller 3. part. I tillegg ligger det hardkodet i programmet at pipe-tegn erstattes med dobbelt anførselstegn og at hash-tegn erstattes med CR/LF. 

Nettopriskontroll med profilprisendringer

(RTC-21684)

Hvis nettopriskontroll utvides med utpriskontroll i tillegg, vil profilpris bli foreslått som utpris. Dette gjelder både for butikker som har lokal butikkpris fra før og de som ikke har lokal butikkpris fra før. Ved standard "Nettopriskontroll" vil butikker som har lokal butikkpris få gjeldende butikkpris som forslag på utpris, og de butikkene som ikke har lokal butikkpris blir gammel profilpris foreslått i utprisfeltet. 

Tekniske release notes

Systemparameter 890 = 1,1,0,0 (Standard nettopriskontroll)

Systemparameter 890 = 1,1,1,1 (Nettopriskontroll + priskontroll ved endret profilpris)

Systemparameter 909 = 2 (Hvis ikke lokalstyrte varer IKKE skal til priskontroll, gjelder for begge variantene ovenfor)

Sletting av gamle loggposter i database

(RTC-22696)

Det er anbefalt å løpende slette utdaterte statistikk- og registerposter via EOD. Hvis ikke kan datamengden etterhvert risikere og nå maksimal grense og da krasjer databasen.

Da gammel loggdata også bygger seg opp, kan også dette slettes via EOD for registervedlikehold. 

Tekniske release notes

For sletting av loggposter i register velges i "Systemalternativer 139": Kode 8 "Logg"
 - Verdi1: Angir antall dager tilbake i tid som sletting skal begynne.

Ved oppstart: Husk at sletting er meget tidkrevende og det sannsynligvis finnes mange millioner poster. Det er derfor anbefalt å begynne langt tilbake og så jobbe seg nedover ved å sette kortere tid (lavere verdi) for hver EOD-kjøring.

Sletting av vaskeprogram i Tokheim POS

(RTC-22804)

Hver butikk med tredjepartssystemet Tokheim POS og bilvaskanlegg har lagt opp egne poster for hvert vaskeprogram under "Feltverdier for butikk", for tilsvarende vare. Det er denne vaskeprogramsposten som skal slettes hvis butikken ønsker å fjerne et vaskeprogram. Utlegg som fjerner vaskeprogrammet fra kassen sendes deretter til Tokheim POS.

Alternativ metode for oppdatering av fastprisflagg på ny butikkpris

(RTC-22907)

Generelt oppdateres merknaden for "Fast pris" via standard felt i VPI. Det er også mulig å sette opp systemet for å alltid sette "Fast pris" likt oppsett for profilpris, når ny butikkpris lages eller ved endring av eksisterende butikkpris, via RIGAL VPI.

Tekniske release notes
  • VPI-mal for fastpris MÅ settes med "Oppdatering "= Ja og "Nullstilling" = Nei
  • Slå på verdien "Logisk" i systemalternativer: 1091: Kode 2 - fastpris.

Det betyr at ved ALLE RIGAL-oppdateringer av butikkprisendringer, vil fastpris-flagg primært hentes fra tilsvarende felt i profilpris. Dette tilsvarer RIGAL-oppdateringen av feltverdi for alle vektkoder (ordinær pris, kampanjepris og medlemstilbud) som skjer på samme måte.

Rapportene "Varekølogg" og "Logg el. hylleforkanter"

(RTC-22924)

Rapportgrunnlag lagres i databasen, uansett om rapportene er i bruk eller ikke. Det har ikke så mye å si hvis det er gode rutiner for vedlikehold og sletting av gamle data. Rapportene "Varekølogg" og "Logg el. hylleforkanter" er viktige rapporter for de som bruker disse, men de er av en type som genererer store mengder data. Denne datamengden kan selvfølgelig vedlikeholdes med gode sletterutiner, men hvis rapportene ikke er i bruk er det unødvendig å lagre så mye data, kun for å slette dem etterpå.

Hvis vedlikeholdsrutinene ikke er på plass kan det føre til overfylt database og systemproblemer som følge av dette. Det er derfor anbefalt å parameterstyre om logging skal skje for noen av disse rapportene. Hvis man ønsker å kjøre rapportene i en periode er det enkelt at slå på logging og senere slå av denne igjen. 

Tekniske release notes

For å ikke endre på noe som er i bruk leveres patchen med logging for begge rapportene påslått, dette betyr logging foregår som før.

Standard for de fleste bør likevel være systemparameter 952 = 0,0 
   - den 1. gjelder om "Varekølogg" er i bruk eller ikke
   - den 2. gjelder om "Logg el. hylleetiktter" er i bruk eller ikke

  • Bruk av "Varekølogg" settes opp i systemparameter 805. Hvis denne har, i det minste en aktiv post (verdi = køtype), kan logging skje av denne/disse køpostene som loggtype 12 i loggtabellen. Her må også systemparameter 952 = 1,x før aktivering skjer. Hvis rapporten "Varekølogg" ikke lenger skal brukes, la verdiene ligge igjen hvis tidligere oppsett skal gjenopptas, deaktivisering skjer ved å sette systemparameter 952 = 0,x      (x gjelder rapport nedenfor)
  • "Logg el. hylleetiktter", spesifikke utlegg til el. etikettløsning, logges kontinuerlig som loggtype 7 i loggtabellen hvis systemparameter 952 = x,1 for deaktivisering av dette settes systemparameter 952 = x,0     (x gjelder rapport ovenfor)

Slett ikke-aktiv butikk

(RTC-22966)

Når en butikk avsluttes settes kommunikationstype = 1 og "Stengt dato" med avsluttingsdato for butikken i butikkregisteret. Dette fører til at en del register slettes, men butikken vises fortsatt i butikkregisteret. Hvis butikken skal fjernes fra butikkregisteret må support/konsulent kjøre oppryddingsprogram for dette slik at resterende data for statistikk og register fjernes sammen med butikken.

Tekniske release notes
Programmet "Slett ikke aktiv butikk" ligger under "LRS"/"Korrigere/endre data"/"Slett ikke aktiv butikk".

Sletting av gammel statistikk og registre

(RTC-23165)

Det er lurt å ha rutine for sletting av gammel statistikk (salgstall) og registre, ellers er det risiko for å fylle opp databasen over tid, noe som kan føre til totalstopp i all oppdatering. Det vil da kreves omfattende sletting av gammel data, en jobb som er helt unødvendig da det er mulig å sette opp løpende sletting hver dag. For eksempel kan grensa for sletting settes på 90 dager, for hver ny dag vil dag 91 slettes slik at det alltid finnes statistikk og registre 90 dager tilbake. 

Tekniske release notes

Antall dager før sletting settes opp i systemparameter 46 og 139.

Hvis funksjonaliteten ikke er i bruk er antall dager: Verdi1 = 9999.



Chain Classic versjon 2.1.1.0.29

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer 

Modul Beskrivelse 
Kampanjegruppe

Manglende oppdatering i POS ved endring av verdier i  Kampanjegruppe RTC-19966)

Dersom det er en endring av HK-eide verdier (for eksempel fastpris) i Kampanjegruppe må utlegg til POS parameterstyres via ordinær prisendring slik at kassen oppdateres.

Tekniske release notes
I systemalternativer 214 kan alle verdier med "Logisk", unntatt felt 6 - "Vekt", settes med "Integer" = 1 for ekstra utlegg av ordinær pris-fil, hvis kun denne verdien endres i Kampanjegruppe. 
Vare

Korrekt kalkulering av ingredienspris (RTC-22406)

Ved bruk av reseptvarer er funksjonen laget slik at det blir tatt vare på fire desimaler. Pris for "Ingrediens" vises med riktig kalkulert beløp, ned til to desimaler.

Varemottak

InStore App-varemottak av pakkevare som inkluderer vektvare (RTC-21673)

Når varemottak av pakkevare fra InStore App utføres brukes pakken sine inngående varer. I Chain Classic beregnes mottak av selve pakkevaren på grunnlag av kontroll i InStore App. Når mottatt mengde er et desimaltall, for eksempel vektvare, avrundes dette til nærmeste heltall ved innlesing av bong og vises både i "El. varemottak/Varemottak" og "Bestilling".


Behandling av antall ved varemottak fra InStore App (RTC-22354)

Ved Varemottak gjort i InStore App vil registrert antall kun oppdatere verdien for "Kontrollert antall" i Chain Classic, mens verdien for "Mottatt antall" ikke vil oppdateres. Brukeren kan da senere følge opp og se differansen mellom det antallet som skulle mottas og det antallet som virkelig er mottatt.

Referansetekst i bestilling

(RTC-21928)

Det er mulig å se, sortere og filtrere på "Referansetekst" ved søk i "Bestilling", "Varemottak" og "El. varemottak".

Det er mulig å fjerne linjen "Vår ref." med denne referanseteksten i rapporten "Utskrift av bestilling"

Tekniske release notes
Systemparameter 950 = 1: Fjerner linjen "Vår ref." i rapporten "Utskrift av bestilling"

Ny priskanal i Kampanjegruppe

(RTC-20975)

Ny priskanal i kampanjegruppe legges opp i systemalternativer 206. Deretter kan de legges ut til POS via Kampanjegruppeutlegg.

Tekniske release notes

Systemalternativer 206

Nye priskanaler i kampanjegruppe, legges opp i systemalternativer 206. Det er plass til opp til 6 stk. priskanaler i kampanjegruppe.

Verdien "Logisk" hukes av på de priskanaler som skal være standardvalg når ny kampanjegruppe lages.

Alternative utlegg til Breece og Pricer

(RTC-20390)

  1. Det er mulig å forhindre utlegg av tilbud fra Kampanjegruppe hvis annen priskanal enn "Alle" er valgt.
  2. Det er mulig å velge et oppsett slik at varer med gitt etikettype bytter plass på enhetspris og ord./kampanjepris ved utlegg till Breece/Pricer. Gjelder både hoved-EAN og tandem.


Teknsike release notes

Alternative utlegg til Breece og Pricer

  1. Systemparameter 948 = 1 forhindrer utlegg av tilbud fra kampanjegruppe hvis annen priskanal enn "Alle" er valgt
  2. Systemparameter 947 = X hvor X er gitt etikettype som skal trigge spesifiserte feltbytten, se nedenfor, for varer som trenger dette.

Utlegg til Breece:

  • Ordinær pris
  • Ordinær enhetspris
  • Ordinær Euro pris
  • Ordinær Euro enhetspris
  • Kampanjepris
  • Enhetspris for kampanjepris
  • Kampanjepris Euro pris
  • Kampanjepris Euro enhetspris
  • Medlemstilbud   
  • Enhetspris for medlemstilbud
  • Medlemstilbud Euro pris
  • Medlemstilbud Euro enhetspris

Utlegg til Pricer

  • Ordinær pris
  • Ordinær enhetspris
  • Kampanjepris
  • Enhetspris for kampanjepris
  • Enhet for enhetspris
  • Enhet for salgspris

Vektkode på ny butikkpris når verdi mangler i VPI

(RTC-22344)

Manglende vektkode i VPI for ny butikkpris settes normalt i henhold til oppsett i VPI-mal. Men det er mulig parameterstyre dette slik at man istedet henter gjeldende verdi for varens vektkode (enhet) fra gjeldende profilpris.

Tekniske release notes

Denne funksjonaliteten aktiveres når systemalternativer 1091: "Vekt": settes til "Logisk"

Oppsett i systemparameter 638 kan også påvirke sluttresultat etter ønske.



Chain Classic versjon 2.1.1.0.28

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer 

Modul Beskrivelse 
Kunde

Kunder med postnummer 0 tillates (RTC-19993)

Det er tillatt med postnr = 0 på kunde i Chain Classic.

Mixmatch

Sletting av mixvarer og hel mixmatch (RTC-21479)

Grunnet statistikk er det generelt ikke anbefalt å slette varelinjer i aktiv mixmatch eller å slette hel mixmatch (i aktiv kampanjegruppe), men det er mulig og kan være nødvendig ved administrative feil. Ved slike slettinger legges det kun ut sletting i mixfiler, alternativt RIGAL-filer, til aktive butikker.

Pris

"Send vare til kasse" og profilbutikk (RTC-21769)

Ved bruk av "Profilbutikk" og funksjonen "Send vare til kasse" vil det være kun filen pris.999xx som legges ut til profilbutikken. Øvrige format legges kun ut til aktive butikker.

Vare

Oppdatering av varetekst og vareinfo samtidig (RTC-21888)

Hvis det i "Varevedlikehold" skjer endring av varedata og "Vareinfo" innenfor et kort tidsintervall resulterer dette i korrekt utlegg av filene vare.99900 og vareinfo.butnr.

Varetelling

Oppdatering av varetellingsfiler på vent (RTC-22006)

Når varetellingsfiler settes på vent åpnes muligheten å oppdatere lager senere enn talt dato. Programmet sørger for at varene likevel oppdateres med riktig beløp i kostpris, salgssum og mva.


Manuell registrering i "varetellingsveiviseren" (RTC-21903)

Ved varetelling og manuell registrering av lagerstyrt vare skjer det en kontroll om varen finnes på lager. Dersom veiviseren ikke finner lagersaldo blir denne tellingen likevel registrert og lagerantall blir oppdatert med gyldig lagerstatus.

Endre engrospris per butikk

(RTC-21699)

Engrospris kan endres ved å lese inn en fil med navn "inkopspris.butnr.csv", hvor innholdet i filen kun er alfanumerisk varenummer og ny engrospris.  For endring kreves det at butikkpris finnes fra før. Ved bruk av denne funksjonen vil kun aktiv ordinær pris oppdateres med den nye engrosprisen, mens fremtidige ordinære prisendringer ikke forandres.

Merk: engrospris  skrives med punktum, for eksempel 3.44, hvis kommategn brukes blir ny engrospris 344.

Innlesing av denne filen kan enten gjøres manuelt via program: "System"/"Administrative rutiner"/"Diverse hjelperutiner"/"Oppdatering av engrospris", eller ved å sette opp en jobb for EOD-kjøring.

Systemalternativer 1011

For EOD-kjøring må post for dette finnes i systemalternativer 1011.

Medlemstilbud i kundeordre ved bruk av CoopID

(RTC-21569)

  • Hvis CoopID er i bruk kan status "Medlem" settes når ny kundeordre lagres, før varene legges inn.
  • Det er ikke mulig å endre status "Medlem" etter første lagring av kundeordre. 
  • Ekstern oppdatering av kundeordre kan heller ikke påvirke denne statusen.
  • Varer som ikke viser medlemspris, kan fjernes og så legges inn på nytt for oppdatering av pris.
  • Skript er laget for oppdatering av status "Medlem" på kundeordrer med verdi i CoopID, som innenfor angitt tidsintervall, antall dager tilbake.


Konfigurasjon 
Forutsettning: Systemparameter 943 er satt opp med verdi = 1,0 eller 1,1.

E-postadresse på kasserere

(RTC-21407)

I registeret for kasserere kan e-postadresse legges opp for utlegg til POS.

Konfigurasjon
Systemalternativer 121 rad 14 for kasserer må settes opp med "Integer" = 21, slik at felt 21 for e-postadresse legges ut i kasserer-fil til POS

Merk flere rader i priskontroll 

(RTC-22008

Før godkjenning/avvisning av varer i priskontroll er det mulig å velge flere linjer samtidig.

  • Flere enkeltlinjer kan velges ved å trykke CTRL + klikk på ønskede varer.
  • Enkeltlinjer kan fjernes fra utvalg for godkjenning/avvisning på samme måte.
  • Markering av sammenhengende linjer velges enklest ved å klikke på første eller siste vare og så SHIFT + klikk på varen som avslutter det sammenhengende utvalg som ønskes.

Varetype i RIGAL

(RTC-21716)

Varetype er normalt et utvalg av standard varetyper som legges ut i RIGAL V- og J-fil. Det finnes en mulighet å ikke benytte seg av disse og heller sette opp egne varetyper. Det er ikke mulig å kombinere disse to alternativene.

Teknisk informasjon: 
Varetyper i bruk er satt opp i systemalternativer 60, med standardtypene mellom 1-12. Hvis alternative varetyper ønskes, da skal de settes opp med kode fra 50 og oppover, disse vil da overta, og standard varetyper vil ikke legges ut. 

Fastpris

(RTC-20814)

Funksjonaliteten "Fast pris" settes i priskalkyleprogrammet i "Varevedlikehold" eller "Prisvedlikehold". At fastpris er satt vises også i prisfanen i de andre moduler, men kan ikke endres der.

Avvikende radnummer i varemottak

(RTC-21285)

Noen leverandør klarer ikke å returnere opprinnelige radnummer, fra bestilling i Chain Classic, i levert varemottaksfil. Det er mulig å parameterstyre slik at EAN skal brukes i stedet for radnummer for å matche mottaksrader med rader i opprinnelig bestilling.

  • Hvis samme EAN finnes på flere rader i varemottaksfila vil samtlige avvises.
  • Vare i varemottak som ikke finnes, i opprinnelig bestilling, legges til i både bestilling og varemottak. 


Konfigurasjon
Systemparameter 949 = 1 slår på denne funksjonaliteten.

Skille mellom kundeordre/webordre og serviceordre

(RTC-20752)

Når Chain Web blir master for kundeordre/webordre skal ikke dette legges ut fra Chain Classic til POS, men det vil fortsatt være behov for å legge ut info om serviceordre. Kundeordre/webordre og serviceordre er derfor splittet opp slik at dette enkelt kan forandres når behovet oppstår.

Konfigurasjon

Funksjonaliteten endres i systemalternativer 182 hvor #kundeordre og #serviceordre kan sperres fra utlegg når Chain Web tar over som master for ordretypen.

Når Chain Web er master for kundeordre og Chain Classic er master for serviceordre skal ikke Chain Classic returnere kundeordrer ved online søk etter ordre fra POS. Dette kan konfigurere som angitt nedenfor (se bilde), ved å fjerne # tegnet foran kundeordre: 

Hvis kunde allerede har Chain Web som kundeordremaster på butikknivå finnes det poster i "Systemalternativer for butikk 182" med navn:  "ordrehode". Disse kan korrigeres manuelt ved å kjøre skriptet: updbutparmrad_182.p som ligger i hjelpkatalogen. Dette bytter navn fra "ordhode" til "kundeordre" for alle butikker med dette oppsettet.

Etikett med registreringsdato

(RTC-20948)

Kundespesifikk etikettdesign med nytt felt i stylecode 1.


Teknisk informasjon

I hjelpkatalogen ligger oppdateringen: etidesign_1_12.d

Varetype for "Lokal vare" til Tokheim kassesystem

(RTC-21737)

Ved bruk av utlegg til tredjepartssystemet Tokheim settes alltid varetype til verdi 1, "Butikkvare", når en ny "Lokal vare" lages.

Teknisk informasjon:
  • I "LRS\hjelpkatalogen" ligger skriptet "updvaretype.p" som kan brukes for å automatisk rette opp de lokale varer som mangler varetype.
  • Denne funksjonaliteten gjelder kun for Tokheim-oppsett med systemparameter 586 = 3.



Chain Classic versjon 2.1.1.0.27

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer 

Modul Beskrivelse 
Pris

Utlegg av fremtidige priser (RTC-21154)
Ved bruk av utlegg av fremtidige priser til POS er det viktig at riktig kønummer blir brukt. Sjekken av dette er forbedret slik at det ikke blir problemer med gjeldende ordinærpris i POS.

Systemparameter 545

Utlegg av fremtidige priser til POS settes opp i systemparameter 545.                                     

Denne parameteren er skjult som standard.

Bestilling

Referansetekst i "Bestilling" og "Elektronisk varemottak" (RTC-20347)

Melding angitt i felt for "Referansetekst" i "Bestilling" hentes opp i tilsvarende ordre i "Elektronisk varemottak", og vises der i en egen kolonne.

Ved bruk av spesialprogrammet "Bestillingsforslag Excel" må det legges med en merknad av bestillingen. Denne meldingen havner i "Referansetekst" i "Bestilling" og vises da også som beskrevet i "Elektronisk varemottak".  

Butikk

Ingen utlegg til butikker med kommunikasjonstype = 1 (RTC-20589)

Det gjøres aldri noen utlegg til POS eller tredjepartssystem, for butikker med kommunikasjonstype = 1 i butikkregisteret i Chain Classic. Disse butikkene kan derfor brukes som "referansebutikker" ved RIGAL-import fra ERP.

Rapporter

Antall salg pr periode i rapporten "Dagsrapport" (RTC-20392)

Antall salg som vises i rapporten "Dagsrapport" viser:

  1. Salg totalt i denne måned.
  2. Salg totalt i forrige måned.
  3. Salg totalt siste 12 måneder.

Disse tallene endres ikke av forskjellige utvalg på dato eller annet.


Rapporter for team over flere profiler (RTC-21189)

Teambrukere kan velge profil i utvalgsbilde ved rapportkjøring. Vilkår for at dette kan gjøres er at det aktuelle teamet inneholder butikker fra flere profiler og at teambrukeren er laget med profiltilhørighet "Alle".


Butikkoppgjør total (RTC-21072)

Rapporten er justert slik at dersom alle mulige visningsalternativer er i bruk samtidig så lages rapporten fortsatt på en side.

RIGAL

Oppdatering av RIGAL N-fil (RTC-20048)

Ved oppdatering av RIGAL N-fil oppdateres varepost som forventet, også om det er finnes eksisterende varefeltinfo.

System

Begrense oppstart av antall samtidige EOD-jobber RTC-19734)

Programmet jobbserver kontrollerer antall startede rapporter (inkludert etikettutskrifter eller andre batchjobber), og det er parameterstyrt hvor mange jobber som kan startes opp og kjøres samtidig. Hvis en "Startet"-jobb ikke kommer seg til jobbstatus "Kjører", defineres jobben som feilet og forhindrer derfor ikke en annen batchjobb fra oppstart eller å bli ferdigstilt.

Antall jobber som kan startes opp og kjøres samtidig styres av systemparameter 250 som normalt skal ha fire verdier. Færre verdier kan godtas, men for servere med "mange" butikker/brukere og dermed høyt antall EOD-rapporter, bør absolutt fire verdier brukes. Men det anbefales at fire verdier i systemparameter 250 brukes som standard til alle kunder.

Utlegg til Tokheim

Utlegg til Tokheim når kasserer sperres (RTC-19671)

Når kasserer "sperres" i Chain Classic eller i Chain Web legges sletting av kasserer/bruker ut fra Chain Classic til 3. partssystemet Tokheim POS. 

Varemottak

Logging av endringer av kostpris i "Fakturakontroll" (RTC-20293)

Spesialprogrammet "Fakturakontroll" i Varemottak logges slik at avvik ved endring av veid kostpris kan ettergås. 

Loggutskrift ligger i LRS\logg med filnavn: veidkost<mmdd>.<butnr>


Internoverføring og fargevarianter på prisfanen i varemottak (RTC-19626)

Ved bruk av spesialversjon av varemottak - "elmottakw" og internoverføring mellom butikker, vises overført variant for modellfarge i fanen Pris. Dette for utskrift av prislapper og blir slik selv om overført variant er hovedvare for størrelsen eller ikke.

Dette gjelder kun for varemottak med systemparameter 528 = elmottakw og systemparameter 512 = 1 

Kampanjegruppe

Hurtigprising i kampanjegruppe (RTC-20892)

Prisendringsprogrammet "Hurtigprising" er et eget menyvalg, som dekker det meste av multiple prisendringer. Hurtigprising ved kampanjetilbud bør likevel gjøres via kampanjegruppe da dette gir fordeler på ytelse og feilsøking.


Standard priskontroll og datoendring på kampanjegruppe (RTC-20372)

Ved endring av dato på kampanjegruppe tas det hensyn til tidligere behandling i priskontroll. Det betyr at en butikk som har avvist eller godkjent kampanjeposter, mixmatch eller hel kampanjegruppe ikke må gjøre dette igjen hvis dato/tid endres på kampanjegruppe. Status beholdes og det er kun dato-/tid endring som oppdateres.  

Varekøbehandling 

(RTC-20054) 

Behandling av varekøposter (f.eks. prisendringer) som inkluderer bruk av tredjepartssystemet Lexmark innebærer omfattende kontroll av hver post, men skjer med nærmest samme ytelse som tilsvarende ikke-Lexmarkrelaterte køposter.

Hvis det oppleves at køposter behandles tregere kan logging pr. post slås på for å finne ut av om det er noe som styrker denne opplevelsen. Obs: Disse loggene kan ta mye plass og funksjonaliteten bør derfor kun brukes en kortere periode. 

Systemalternativer 215

Ny systemalternativer 215 der det aktuelle batchprogrammet ligger med programtittel og programnavn. 

Ved behov og videre utvikling kan flere legges til.

  • Avhuking på "Logisk" angir om logging skal utføres eller ikke. 

Beskrivelse av logg

  • Logging skjer i standard programlogg.
  • For alle program skrives først i hver melding:
      - tid i sekunder
      - prosedyrenavn
  • For "Oppdater vare" skrives følgende i hver melding:
      - EAN
      - meldingsnr  
      - profnr
      - butnr
      - kotype
  • For "Klargjør varekø" skrives i tillegg følgende i hver melding:
      - EAN
      - butnr
      - meldingsnr
      - kotype
  • Sist kommer melding med antall behandlede varekøposter og total tid.

Lexmark etikettflagg på tilbudsvarer

(RTC-19633)

Ved bruk av tredjepartsystemet Lexmark for etikettutskrift, skal etikett skrives ut for tilbudsvare uansett om det tidligere har vært salg på varen eller ikke.  

Dette unntak overstyrer permanent systemparameter 878 > 0 som forhindrer etikettutskrift på varer som ikke er solgt innenfor angitt antall dager.

Utvidet løsning for visning for CoopID

(RTC-20481) 

Det er parameterstyrt om CoopID skal vises på kundeordre, og om medlemsnummerfeltet skal vises i Kundevedlikehold. Del 1 av parameteren åpner for å oppdatere de nye Loyalty feltene (inkl. CoopID) fra POSLog. CoopID vises i "Kundeordre".

Del 2 av parameteren tas i bruk når kobling av kunder til S-lagsnr/medlemsnr skal fjernes. Dette skjer via skript hvor det kan velges om utlegg umiddelbart skal gjøres til POS eller ikke, samtidig fjernes felt for S-lagnr/medlemsnr i "Kundevedlikehold".

Systemparameter 943

Systemparameter 943 er todelt: 

  • 1. parameter er påslått:
      - Oppdatering av CoopID relaterte felt fra POSLog
      - Kundeordre viser CoopID istedenfor Medlemskortnr
  • 2. parameter er påslått:  
      - Kunder fra RIGAL oppdateres uten slagnr/mednr 
      - Fjerning av felt for slagsnr/mednr fra GUI i "Kundevedlikehold"

Endre engrospris per butikk

(RTC-19844)

Engrospris kan endres ved å lese inn en fil med navn "inkopspris.butnr.csv", som inneholder kun alfanumerisk varenummer og ny engrospris. Merk: engrospris  skrives med punktum, for eksempel 3.44, hvis kommategn bukes blir ny engrospris 344.

For endring kreves det  i tillegg at butikkpris finnes fra før. 

Innlesing av denne filen kan enten gjøres manuelt via program: "System"/"Administrative rutiner"/"Diverse hjelperutiner"/"Oppdatering av engrospris", eller ved å sette opp en jobb for EOD-kjøring.

Systemalternativer 1011

For EOD-kjøring må ny post lages i systemalternativer 1011.

Grunnlag etikett i "Varekølista" 

(RTC-19495) 

Hvis etikett skrives fra varekø vises informasjon om at etikett skal skrives i feltet for "Grunnlag etikett" i "Varekølista". Det er første viktige årsak til at etikett skrives som blir brukt, for eksempel prisendring.

Opplegg av ny vare via RIGAL fra ItemMaster

(RTC-19281)

Opplegg av ny vare i Chain Classic via RIGAL V-filer fra ItemMaster skjer i to omganger. Først sendes en fil med vareinformasjon og deretter en fil med prisinformasjon. Disse blir slått sammen til ny vare, i VPI-vedlikehold hvor de ved godkjenning importeres til Chain Classic.     

Teknisk informasjon

Krav: Systemparameter 185 = 0, ellers avvises varefil med pris = 0,00

ItemMaster sender inn RIGAL V-filene i to omganger
1. RIGAL V-fil av type "VAR" (vare)
2. RIGAL V-fil av type "PRI" (pris).
    - Omvendt rekkefølge feiler.

Følgende felt vil oppdateres i "Pris" på første runde hvis varefilen har denne info eller om disse feltene er satt opp med standardverdi i VPI-mal:

            - levnr
            - levnr2
            - levvnr
            - bestnr/best2nr
            - sortnr

Hvis flere prisfiler sendes inn før oppdatering i "VPI-vedlikehold", vil butnr og profnr for siste fil bli gjeldende prispost på varen i Chan Classic. 

Oppdater butikker via JSON-import

(RTC-19018)

Chain Classic kan nå opprette og oppdatere butikker via JSON-innlesning fra Store Service.

Konfigurasjon

Ny systemparameter 946 angir katalog (under LRS) JSON-filer leses fra. Dette bør være en katalog som ikke brukes til noe annet. Det må også opprettes en backup katalog under denne.

Ny systemalternativer 216 opprettet. Filtyper som kan leses inn fra JSON ligger som rader under denne, og for hver filtype er det angitt start på filnavn. Foreløpig leses kun butikker inn, der filnavn skal starte med "stores".

Logging av "uønskede" Breece-utlegg

(RTC-20799)

Antall felt som legges ut til tredjepartsleverandøren Breece kontrolleres via systemalternativer 125, rad 9 (Breece) og verdien i feltet "Integer". Det legges kun ut poster med riktig antall felt per post. Det kan skje tilfeller hvor det blir forsøkt lagt ut andre formater med flere eller færre felt. Disse fjernes og kommer seg ikke videre til Breece, men logges før sletting med filnavn "breece_feil. butnr. yyyymmdd" i backup-katalogen.

Logging aktiveres ved å sette en verdi >0 i feltet "Desimal" i systemalternativer 125, rad 9 for Breece.

"Klargjør vare" legger ut alternativ pris til Breece

(RTC-20728)

Ved bruk av "Alternativ pris", for spise ute/inne, legges dette ut til Breece ved kjøring av "Klargjør vare". 

Konfigurasjon 

Systemalternativer 125 rad 9 må ha "Integer" >= 48, for utlegg i felt 48

Systemparameter 734 og systemparameter 735 har betydning for resultatene.

I "Varevedlikehold" må "Endre mva" være avhuket.

Varetyper for "Spillvarer/Elektronisk produkt/MBXP webhandel"

(RTC-20062)

Disse varetypene vises i "Varevedlikehold, men kan kun vedlikeholdes via RIGAL-import. Det er følgende varetyper for "Spillvarer/Elektronisk produkt/MBXP webhandel" som kan være i bruk: 

  • eSale_NT - Spillvare fra Norsk Tipping.
  • eSale_Goyoda - Elektronisk produkt fra Goyada, alternativt eSale_MBXP - elektronisk produkt fra MBXP.
  • MBXPwebsale - MBXP webhandelsprodukt.  


Systemparameter 458

I systemparameter 458 settes bruk av disse varetypene opp. Som verdi 2 i verdifeltet må det av alternativene  "eSale_Goyoda" eller "eSale_MBXP" som skal brukes, være angitt. 

Varetype settes på vare ved å sende inn en av bokstavene foran ønsket varetype nedenfor. Det er RIGAL V-formatet, felt 7.1.48, som benyttes for dette.

Alternativene er beskrevet i RIGAL-dokumentet, og i RIGAL beskrivelsen i tabellen under. 

  • S:                      eSale_NT
  • E, P eller G:      eSale_Goyoda alternativt eSale_MBXP
  • Y, W eller Z:     MBXPwebsale  

Vare/Prisinfo 

Innlesing og utlegg

Kode i filnavn: V

RIGAL feltnrBetegnelseFeltinnholdFormat Kommentar

7.1.48

Vtype

Varetype

T

N= vanlig vare

K = vektvare (veies i kassen)

O= åpen pris

X= vare som ikke skal sendes til kasse (kun LCM)

S= spill fra Norsk Tipping

F= vare med fastpris

E= MBXP-vare

P= MBXP-vare + fastpris

G= MBXP-vare + åpen pris

B= Smartbox (elektronisk vare)

W=MBXP websalg

Y=MBXP websalg + fastpris

Z=MBXP websalg + åpen pris

Kun ordinærpris på etikett fra InStore App

(RTC-19894)

Etikettype kan settes til å alltid vise ordinærpris, til tross for aktiv kampanjepris, når etikett lages fra InStore App eller etikettliste i Chain Classic. Dette gjøres ved å hukes av "Vis alltid ordinær pris" i "Vedlikehold av etikettdesign".

Retur av svarpost til InStore App

(RTC-20151)

Hvis butikk og vare finnes i Chain Classic, vil det alltid legges ut svarpost til InStore App. Dette gjelder også i tilfeller hvor varemottak eller butikklokale verdier av spesialgruppetekst eller bestillingstype på varen mangler.

Det betyr at det returneres data selv om det ikke er gjort varemottak på varen, slik at man fortsatt får informasjon om for eksempel "bestillingstype" i InStore App. 

Det logges fortsatt hvis det ikke finnes noe varemottak for vare/butikk, men InStore App får uansett svar på verdier som finnes.

Bestillinger: Vis alle åpne i InStore App og slett utdaterte via EOD i Chain Classic

(RTC-17671)

Ved å "sende" EAN fra InStore App hentes alle åpne (ikke mottatte) bestillingsrader fra Chain Classic til InStore App.

Utdaterte bestillinger kan, etter å ha blitt eldre enn angitt registreringsdato, slettes i Chain Classic: automatisk via EOD eller manuelt via programpunkt - 
"System"/"Administrative rutiner"/"Diverse hjelperutiner"/"Slett åpne bestillinger"

NB: Visning av aktive ordre er for kommende funksjonalitet i Instore App 2. kvartal 2022

Konfigurasjon

Systemparameter 944:

Grense, antall dager, for når bestilling skal slettes.

Systemalternativer 1011:

Oppsett for EOD-kjøring - ip\best\delOpenOrdersp.r 

Opprydding ved EAN/PLU-nummerbytte

(RTC-16355) 

For å unngå avvik mellom Chain Classic og POS ved EAN/PLU-nummerbytte legges det ut slettemelding for gammel EAN/PLU (som blir ny tandem) til totalbutikken i vare.99900. POS sletter da av vare- og prisinfo på varen.

Deretter legges alle gjeldende og fremtidige prisendringer, tilbud og annet ut for oppdatering i POS. Dette slik at begge plattformer har lik informasjon på gjeldende EAN/PLU og tandemnummer.

Oppdatering av hel kampanjegruppe i priskontroll

(RTC-19717)

Ved bruk av standard priskontroll og godkjenning/avvisning av hel kampanjegruppe behandles alle poster som hører til kampanjegruppen.

Disse vises deretter ikke under mixmatch eller kampanjepriser. Behandling av enkeltvarer eller mixmatcher må derfor skje før hele kampanjegruppen behandles. 

Oppsett av "menytilgang" via skript fra "Admin- server"

(RTC-19732)

Standard måte å endre menyvalg i Chain Classic er å skjule eller vise disse på enkelt bruker eller brukergruppe i programmet "Tilgangskontroll". Det er også mulig å sette opp denne menytilgang, på forskjellige Chain Classic-servere, via skript som kjøres fra "Admin-server".

Skript for oppsett av menytilgang

Skriptet "updacces.r" ligger på Help-katalogen.

Veiledningen: Veiledning updacess.pdf ligger også på Help-katalogen.

Ny EAN-nr blir hoved-EAN ved samme vare- og variantnummer

(RTC-18853) 

NB: Kundetilpasset spesialfunksjon!

Når vare sendes inn via RIGAL V-fil sjekkes det om det allerede finnes en vare med samme varenummer (alfanumerisk) og variantnummer i Chain Classic.

Hvis varen finnes og EAN-nummeret i RIGAL V-fil enten er nytt eller er tandemnummer til gjeldende vare utføres det et EAN/PLU-nummerbytte. Da blir sendt EAN ny hoved-EAN, og gjeldende EAN flyttes til tandemnummer på eksisterende vare.

Konfigurasjon
  • Systemparameter 945 = 1 (Kun for Swedemount)
  • Systemparameter 112 = 1
  • Systemparameter 219 = 1
  • Systemparameter 491 = 1
  • VPI-mal: 410 "Variantnr": Oppdatering = Ja

NB: I tillegg er det laget et oppryddingsskript med tilhørende Excel-ark som må kjøres før denne funksjonaliteten blir tatt i bruk. Ta kontakt med Team Chain Classic for hjelp med dette. 



Chain Classic versjon 2.1.1.0.26

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering

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

Forbedringer 

Modul Beskrivelse 
Bestilling 

Bestilling av pakkevare som inneholder pantevare (RTC-19152)

Visning av bestillinger med pakkevarer som inneholder pantevarer  er forbedret slik at det også gir visuelle varelinjer i Bestilling i Chain Classic. 


Automatisk utlegg med pakkevare (RTC-18770)

Funksjonaliteten for automatiske utlegg av pakkevare er forbedret. En ordre fra InStore App, med kun én pakkevare, eller pakkevare på siste rad, legges nå automatisk ut komplett via RIGAL, fra Chain Classic.

Ordre

Webordre med bestillingsvare som ikke skal lage bestilling i Chain Classic (RTC-19125)

Det er gjort forbedringer for webordre i Chain Classic som inneholder bestillingsvarer. Dersom bestillingsfunksjonen ikke er aktiv i Chain Classic vil det ikke bli opprettet bestillinger selv om webordren inneholder en slik bestillingsvare.

Rapporter

Manglende plukkliste til webordre (RTC-18592) 

Enkelttilfeller hvor plukkliste for webordre ikke ble automatisk generert er utbedret.


Butikkoppgjørsrapport med priskanaler på én side (RTC-18117) 

Butikkoppgjørsrapport med bruk av flere salgskanaler er forbedret slik at all data kommer på én side som forventet.

Vare

Årsakskode med fire siffer kan ikke vises i "Varebevegelser" (RTC-18584)

Årsakskoder i vises nå korrekt også når årsakskoden inneholder fire siffer.


Manglende sletteposter ved bruk av "Slette/fjerne fra kasse" (RTC-18299)

Det er laget forbedringer i oppryddingsprogrammet "Slette/fjerne fra kasse". Ved å fjerne unødvendig kontroll av vareendringsdatoen sikres det at forventede sletteposter blir laget. 

Logging av handlekurvkontroll av selvbetjent kasse

(RTC-17044)

Ved manuell kontroll av handlekurv i selvbetjent kasse logges dette i rapportene "Butikkoppgjør total" og "Butikkoppgjør pr. kasserer". 

To nye poster i disse rapportene:

  • Totalt antall kontrollerte bonger.
  • Antall godkjente kontroller, samt godkjenningsprosent av totalt antall kontroller.

For denne loggingen MÅ POSLog 81 brukes!

Konfigurasjon

Det kan skapes to nye finanstransaksjonstyper i kassdag.
  - Transtype 886: hvis POSLog - ReceiptAuditInfo Type="Visual" 
  - Transtype 887: hvis POSLog - ReceiptAuditInfo Type<>"Visual" (gjelder bådet tekst og siffer)

Kontroll avvises/oppdateres ikke, hvis POSLog: 
  - ReceiptAuditInfo Type="None"
  - ReceiptAuditInfo Type=" "
  - ReceiptAuditInfo Type=""

Kontrollerende kasserer logges på følgende måte:
  - hvis POSLog - AuditBy="X"  (hvor X er gyldig kasserernummer)
  - hvis POSLog - AuditBy="Y"  (hvor Y er gyldig kasserernavn, da brukes tilhørende kasserernummer)
  - hvis POSLog - AuditBy="Z"  (hvor Z er blank, da brukes kassens opprinnelige kasserernummer)

Kundespesifikk identifikator i kundeordre

(RTC-18347)

Det er laget mulighet for å legge inn kundespesifikk identifikator i "Kundeordre" for medlemmer, som deretter overføres til POS. Det gamle feltet slagnr/mednr fjernes når nytt identifikatorfelt blir tatt i bruk.

Konfigurasjon
Denne funksjonaliteten aktiveres med systemparameter 943 = 1.

Fjerning av medlemslink i Chain Classic

(RTC-18211)  

Denne patchen fjerner alle spor av data av kombinert medlemsnummer og s-lagsnummer som tidligere ble vist i feltet medlemskortnummer i kundeordre i Chain Classic.

Konfigurasjon

Kunder som ikke har brukt feltet medlemskortnummer, trenger ikke å gjøre noe.

Patch-installasjonen fjerner alle kombinasjoner av medlems- og S-lagsnummer. Deretter sendes korrigerte kunder til POS for oppdatering.

Forbedret plukkliste for E-handel/webordre

(RTC-17040)

Denne varianten av plukkliste kjennetegnes av at eksternt ordrenummer med strekkode, sammensatt hyllelokasjon og leveransemetode vises helt øverst. Visning er videreutviklet med følgende:

  • Kundenavn skrives med stor tekst 
  • Varene listes opp pr. varegruppe
  • Varegruppene er sortert i bokstavsrekkefølge
  • Varene er også sortert i bokstavsrekkefølge
  • Leveransemetode kommer alltid nederst

Konfigurasjon

For denne varianten av plukkliste gjelder følgende oppsett:

  • Systemparameter 610 = 1
  • Systemparameter 932 > 0 (verdien er varegruppe for leveransemetode)

Nettopriskolonne i elektronisk varemottak

(RTC-18206) 

Det er utvidet funksjonalitet for hvilken type "innpris" som skal vises i Elektronisk varemottak.

Følgende varianter brukes:

  • Nettopris hentes fra bestilling, engrospris fra bestilling kan ikke endres. (Standard)
  • Engrospris hentes fra ordinærpriskalkyle i Chain Classic og , engrospris fra bestilling kan endres.
  • Nettopris hentes fra ordinærpriskalkyle i Chain Classic og , engrospris fra bestilling kan endres (nytt alternativ).


Konfigurasjon

Oppsett gjøres i systemparameter 799.

NB! Hvis ny kolonne "Nettopris LC" ikke vises i browser, da må kolonnene sorteres om ved å høyreklikke på noen av kolonneoverskriftene:

  • Velg "Tilbakestill" og "Standard kolonneposisjoner og størrelse"
    • Nå skal ny kolonne vises.
    • Lagre "Kolonneposisjoner og størrelse"

Hvis kolonnene skal settes opp i individuell rekkefølge:

    • Velg i samme meny som tidligere "Flytt kolonne"
    • Gjør endringene
    • Lagre "Kolonneposisjoner og størrelse" 

Automatisk oppdatering av HK-styrte prisfeltendringer

(RTC-17617)

Det er laget mulighet for å angi hvilke HK-styrte prisfelt som alltid skal oppdateres fra "Pris" ved endring til nye verdier.
Disse feltene er følgende:

  • Oppsatt funksjonalitet gjelder for alle eksisterende aktive og fremtidige prisendringer (prisendring, kampanjepriser og medlemstilbud) som allerede ligger skapte i varekøene. For utvalgte felt hentes da verdi fra "Pris" og for ikke utvalgte felt blir opprinnelig verdi liggende igjen. 
  • Dette gjelder også ved kopiering av gammel kampanjegruppe. For utvalgte felt hentes da verdi fra "Pris" og for ikke utvalgte felt hentes verdi fra gammel kampanjegruppe. 


Vær oppmerksom på at denne funksjonaliteten vil belaste systemet betraktelig, med lavere ytelse som følge av dette, når ALLE køposter av type 5, 6, 7 og 8 må sjekkes på angitte felter hver gang varekøbehandling kjøres.  

Konfigurasjon/oppsett

De HK-prisfelt som alltid skal oppdateres fra nyeste verdi i "Pris" settes i systemalternativer 214 med "Logisk" avhaket.

  • Når minst 1 felt har "Logisk" = aktiv, tiltres ny funksjonalitet, ellers ikke. 
  • Endring utføres pr pris, dvs enten 1 profilpris eller 1 butikkpris. 
  • Det er ikke uavnlig med parameteroppsett hvor en endring på profilpris også kopieres til eventuelle butikkpriser. I det tilfelle gjelder endring av felt på profilpris også alle tilhørende butikker.
  • Vektfeltet er egentlig 3 separate felt, (ord. pris, kampanje- og medlemstilbud) og behandles derfor litt spesielt. 
      - Endring av vektkode for ordinær pris oppdaterer kun ordinærpriser. 
      - Endring av vektkode for kampanjepris vil kun oppdatere kampanjepriser.
      - Endring av vektkode for medlemstilbud vil kun oppdatere medlemstilbud.

Godkjenning av mixmatch i priskontroll

(RTC-14416)

Ved bruk av priskontroll og det er satt opp for godkjenning av mixmatch så er det gjort store forbedringer. Tidligere var det nok å godkjenne én valgfri vare i én mixmatch for å godkjenne hele mixmatchen, dette gjorde det hele vanskelig å kontrollere. Ny funksjonalitet samler alle mixmatcher på egen fane og det er selve mixmatchen som godkjennes, ikke vare. Ved dobbeltklikk kan mixmatchen åpnes ( se bilde nedenfor) og kontrolleres før godkjenning. Det er mulig å godkjenne eller avvise en enkelt mixmatch i tillegg til å godkjenne alle mixmatcher med et trykk.

Konfigurasjon

For bruk av mixmatchgodkjenning trengs oppsett av priskontroll.

 - Aktivere noen av priskontrollparameterne 308 (Standard priskontroll) eller 890 (Nettopriskontroll)
 - For mixmatch i priskontroll kreves systemparameter 616=1 
 - Butikker som skal ha dette må settes opp med "Priskontroll" i butikkregisteret.
 - Hvis systemparameter 723=0, vil kun manuell mixmatch bli mulig å åpne, ikke mixmatch i kampanjegruppe

Kampanjegruppe i priskontroll

(RTC-14744)

Kontroll av kampanjegruppe i priskontroll er forbedret. Kampanjeprisene vises under egen fane, hvor de kan godkjennes og avvises.

  • I tillegg finnes en parameterstyrt mulighet å legge opp fanen "Kampanjegrupper" hvor også hel kampanjegruppe kan godkjenne eller avvises.
  • Ved å dobbeltklikke på kampanjegruppen, under fanen kampanjegrupper, åpnes denne opp i eget vindu for enklere overblikk.
  • Enkeltvarer kan godkjennes/avvises under fanen "Kampanjepriser" og så godkjennes eller avvises hele kampanjegruppen under fanen "Kampanjegrupper" slik at kun de varer butikken virkelig ønsker, på kampanjepris, blir sendt til POS.
  • Hvis kampanjegruppe godkjennes, kan tilhørende poster fortsatt ligge kvar under fanene kampanjpris/mixmatch. Dette korrigeres ved oppdatering av skjermbilde, merk valgfri post og tast "F5". Ellers vil forsøk til godkjenn/avvis gi følgende melding: Køstatus ble ikke satt (IP:181), noe som i dette tilfelle betyr at posten allerede er behandlet og burde vært skjult. 


Konfigurasjon
  • Kampanjegruppefanen aktiveres ved å sette systemparameter 936 = 1
  • Hvis butikkbrukere skal få åpnet og se på (ikke endre) kampanjegruppe, under fanen kampanjegruppe, da gjelder oppsatt av systemparameter 723 = 1.  - Hvis systemparameter 723=0, vil ikke kampanjegruppe være mulig å åpne.

 - Krav: standard priskontroll må være i bruk, hvor systemparameter 308  må ha noen av verdiene 2,3,6 eller 7 i første post.
 - For mixmatch er det krav på at systemparameter 616 = 1.

  • Avvis-knappen i  verktøylinjen aktiveres med 3. post i systemparameter 308 eller om det er satt opp at kun mixmatch skal kontrolleres ikke kampanjepriser.
  • Logging er forbedret slik at det skrives en melding i loggfilen for butko, for hver post hvor køstatus endres i priskontroll, gjelder for alle varer i en mix eller kampanjegruppe.

Bestillinger fra InStore App skal ikke havne i Elektronisk varemottak

(RTC-18899)

Bestillinger fra InStore App kan automatisk avsluttes og gjøre et utlegg til RIGAL I-fil. For å forhindre påvirkning av annen funksjonalitet er et hittil ubrukt felt "besthode.lukket" tatt i bruk for å markere at bestilling fra InStore App er blitt automatisk avsluttet. Alle bestillinger med denne merknad blir filtrert bort i "Elektronisk varemottak".

Konfigurasjon
Funksjonaliteten settes i bruk ved å sette systemparameter 934 = 1.

Parameterstyring av ikke-lagerstyrt flagg ved eksport av tellegrunnlag til Chain Web

(RTC-17977)

Det er laget et nytt felt, i eksport til Chain Web, som angir om en vare er lagerstyrt eller ikke. Dette feltet legges kun ut hvis funksjonaliteten er påslått. 

Systemkrav: Chain Web versjon 2.10.110

Konfigurasjon

Funksjonalitet for eksport av lagertstyringsinformasjon, i stockbasis.butnr, til Chain Web kontrolleres via systemalternativer 196.

Aktiveres ved å sette:

  • Integer = 10
  • Logisk = valgt

Valg av om hoved-EAN skal byttes ved RIGAL-oppdatering på tandem-EAN eller ny EAN

(RTC-17621)

Det er mulig å styre om hoved-EAN skal endres fra hoved-EAN til tandem-EAN når det via RIGAL kommer inn vare-/prisendringer på eksisterende tandem-EAN eller på ny EAN/PLU som ikke eksisterer i Chain Classic. Dette er standard.

Ny løsning innebærer at hoved-EAN aldri endres ved vare-/prisoppdateringer via RIGAL, når eksisterende tandem-EAN eller nytt EAN brukes. Vare- og prisinfo oppdateres på opprinnelig hoved-EAN og ved ny ukjent EAN legges dette inn som tandem-EAN på eksisterende hovedvare.

Dette gjelder både ved bruk av RIGAL V-fil og Excel VPI.

Konfigurasjon

Funksjonaliteten settes i bruk ved å sette systemparameter 942 = 1.

I systemparameter 219 vises valg av om levnr/bestnr eller levnr/varenr, styrer identifikasjon av eksisterende vare hvis det kommer inn vare-/prisinformasjon på ukjent EAN.

Eksport av nonsaletype

(RTC-18342)

Det er laget nytt vedlikeholdsprogram for nonsaletype,  System > Kasse > Nonsaletype.

Her kan det for nonsaltype:

  • Legges opp ny
  • Endres
  • Slettes

Ved slike aktiviteter skjer direkte utlegg via filen tekster.butnr. I tillegg kan nonsaletyper legges ut fra programmet Tekster til kasse via filen tekster.butnr. Da skjer det et komplett utlegg av alle nonsaletyper til angitte butikker.  

Hvis Chain Web skal være master for nonsaletype må følgende tegn: # fjernes foran teksten i systemalternativer 194, kode 1032.

Ikke ødelegg lokale varer

(RTC-16270)

Ved bruk av funksjonaliteten "Lokale varer" er det laget en sikring mot å ødelegge disse varene ved å bruke EAN/PLU-endring i "Varevedlikehold". Dette ved å deaktivere EAN/PLU-knappen når lokale varer er valgt og gjelder både HK- og lokale brukere.

Import av vannmengde via PU-fil til Tokheim

(RTC-18575)

Det er laget forbedringer som nå oppdaterer begge vannkodene WAT (vannstand) og WATQUA (vannmengde), ved import av PU-formatet fra tredjepartssystemet Tokheim til Chain Classic.



Chain Classic versjon 2.1.1.0.25

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering 

Oppgradering til Chain Classic versjon 2.1.1.0.25 forutsetter at POS leverer bong-format i POSLog versjon 75. 

Forbedringer i Chain Classic

ModulBeskrivelse
Kundeordre
To ordrelinjer i samme kundeordre fra POS (RTC-18410)
Det er laget løsning for to eller flere ordrelinjer med samme vare, i en kundeordre, som betales samtidig i POS. Begge linjene blir med over til kundeordre i Chain Classic.
Serviceordre

Lagring av oppsøkt vare i "Serviceordre" (RTC-18058)

Det er gjort forbedringer ved lagring av vare som er hentet opp via søkefunksjon i programmet "Serviceordre" slik at varen lagres som forventet.

Varemottak

Ugyldig tegn i varemottak (RTC-17319)

Hvis man i spesialversjon av varemottak skriver inn tegnet ? i feltet for "Pakkseddelnr" og deretter lagrer, fjernes nå ?-tegn fra feltet, slik at det ikke lenger skal føre til heng når nye ordrelinjer opprettes.  

Gjaldt kun hvis systemparameter 528 var i bruk.

Mixmatch

To mixmatcher av samme mixtype i kampanjegruppe med samme vare (RTC-18394)

Utlegg av kampanjegruppe er forbedret og sikrer nå at samme vare i to eller flere forskjellige mixmatcher av samme mixtype i samme kampanjegruppe legges ut til POS i alle mixmatcher den representerer. 

Vare

Aktivering av vare for team med felles vareregister (RTC-18193)

Funksjonalitet er forbedret slik at aktivering av vare også skjer når det mangler profilpris. Kravet er at det må finnes minst én butikk i teamet med både pris og aktiv vare. Da vil funksjonen "Felles vareregister for team" aktivere alle varer innenfor gitt utvalg og opprette butikkpriser der dette mangler for hver butikk i teamet.


Utlegg av butikktandem via "Klargjør vare" (RTC-18381)

Det er nå mulig å velge "Butikklokale EAN" i "Klargjør vare" også for de som bruker funksjonaliteten "Lokal vare". 

Dette gjelder ved bruk av systemparameter 757 (Grenser lokale PLU = butikktandem)

I tillegg må systemalternativer 153 være  satt opp riktig hvis dette skal være forvalgt som standard.

Varetelling

Behandling av lagerstyrt butikk i varetelling (RTC-18089)

Innhenting av lagerstyringsstatus er endret for ikke-lagerstyrte butikker slik at kun klargjorte rader vises i "Korriger varetelling". 

Varefil til Lexmark

(RTC-16793)

Utleggene til tredjepartssystemet Lexmark er spisset for å hindre at unødvendige data legges ut.

Konfigurasjon

Følgende skjer ved utlegg av følgende køtyper:
 1. Køtype 1 - Ny vare:
     - Utlegg i nytt format "itemlex", til totalbutikken (99900)
     - Utlegg i formatet "priceitemlex", til alle "lexmarkbutikker"

 2. Køtype 2 - EAN-/PLU-nummerendring:
     - KUN utlegg til totalbutikken (99900)
     - Utlegg med ny EAN legges til både totalbutikk og lexmarkbutikker i respektive format.

 3. Køtype 3 - Vareendring:
     - KUN utlegg til totalbutikken (99900)

 4. Køtype 6 - Prisendring:
     - Utlegg av prisendring til berørte Lexmarkbutikker.

Utlegg av kampanjegruppe med priskanal til Lexmark

(RTC-16790)

Der er nå mulig å legge ut priskanaler til tredjepartssystemet Lexmark.  

Konfigurasjon

Det nye feltet aktiveres i systemalternativer 125, hvis "Integer" = 48 (eller mer), for Lexmark (kode 17).

Dersom det er angitt at det skal legges ut 48 felt for Lexmark, vil nå alle priskanaler som brukes i kampanjegruppen legges ut som en kommaseparert liste bakerst på linjen. 

Ny mixinformasjon til Lexmark

(RTC-16786)

Tre nye felt er laget for utlegg av mixmatch til tredjepartssystemet Lexmark. De nye mixfeltene "Tilleggstekst", "Utpris fra mixhode" og "Flagg for selvskanning" 
fylles ut når data er tilgjengelig. 

Konfigurasjon

Feltene fylles ut med informasjon fra en aktiv mixmatch med mixtype 1 som varen evt. inngår i.

Dette skjer primært kun ved mixtype 1. Dersom det finnes flere med denne mixtypen benyttes den "første og beste".

Det er likevel mulig å parameterstyre om flere mixtyper skal inngå, men mixtype 1 skal alltid foretrekkes om denne finnes.

Funksjonaliteten aktiveres i systemalternativer 125 når "Integer" settes = 51 for Lexmark (kode 17)

Med systemparameter 941 = 0 gjelder som standard at kun mixtype 1 brukes. Denne kan likevel, med "Verdi" = 1, hensynta alle mixtyper. Hvis det ikke finnes noen mixtype 1 brukes da første og beste av hvilken som helst annen mixmatch. 

Sentral kampanje-ID på lokale kampanjevarer

(RTC-17890)

Tidligere levert funksjonalitet ble vanskelig å overføre til POS. Det lages derfor et "fiktivt" kampanjegruppehode for butikk, når sentral-ID skal benyttes innenfor lokal kampanjeperiode, noen som hjelper POS å holde styr på bytte til sentral kampanje-ID på vare i lokal kampanje.

Deaktivering av nonsalevarer med salg

(RTC-17450)

Det er lagt til en sjekk på salg av nonsalevarer slig at deaktivering ikke skjer hvis det er salg innenfor det antall dager tilbake i tid som er angitt salgsintervall hvor deaktivering skal forhindres.

Konfigurasjon
Antall dager tilbake i tid som deaktivering skal forhindres angis i feltet "Integer" i systemalternativer 201, kode 2.

Webordre fra EG POS - Automatisk internoverføring fra sentrallager til butikk

(RTC-17256)

Ved salg av vare i butikk som kun finnes på sentrallager. Kunde betaler vare i kasse, salg sluttføres i kasse, via ny funksjonalitet for bruk av levering fra webbutikken. Webordre sendes til Chain Classic hvor det opprettes ordre og en internoverføring av vare fra sentrallager til butikk. Varen leveres så til kunde.

POSLog 80 må være i bruk i hele systemet for denne internoverføringen i Chain Classic.

Utlegg ved endring av veid kostpris

(RTC-16633)

Ved bruk av veid kostpris, legges endringer av veid kostpris i Chain Classic ut til POS i nettoprisfeltet. Dette gjelder alle, aktive og fremtidige, tilbud og prisendringer som tidligere er lagt ut til POS.

Ekstra desimaler i "Reseptvare"

(RTC-16642)

Ved bruk av "Servicehandel" er det i "Reseptvare" mulig å bruke inntil 4 desimaler i feltene for Netto- og Brutto-antall og fast respektive kalkulert nettopris på "Reseptvare".

Konfigurasjon

For å ta dette i bruk
1.  "Servicehandel" være i bruk: Systemparameter 9003 = 1 

2. Kjør skriptene nedenfor, vedlagt i "help-katalogen", viktig med riktig rekkefølge:

      1. chgingred.p :  antall og kostprisfelt knyttet til ingrediens ganges opp med 100
      2. kalkresept.p :  genererer opp kostpriser for alle ingredienser og resepter

Ny kolonne i reseptvare for kalkulert nettopris pr. ingrediens

(RTC-16629)

Ved bruk av servicehandelsfunksjon vises nå ny kolonne, under fanen "Reseptvare" i "Varevedlikehold", med kalkulert nettopris pr. ingrediens. Pris kalkuleres på følgende måte "Ingrediensens nettopris * antall". Summen av alle ingrediensvarelinjenes nettopriser er lik reseptvarens nettopris.
Ved endring av profil /butikk rekalkuleres feltene. Hvis en enkelt ingrediens mangler profil-/butikkpris, hentes dette fra nærmeste profilpris slik at prisen kan beregnes.

Nye felt i programmet "Lokal vare"

(RTC-16643)

I spesialprogrammet "Lokal vare" kan "Momsgruppe" og "DUN-nr" legges opp på nye lokale varer. Verdiene vises på tvers av "Varevedlikehold" og "Lokal vare" og kan administreres på begge plassene. I VPI-mal kan standardverdi for MVA settes opp hvis ønskelig.

Ny hovedvare erstatter "Lokal vare"

(RTC-16146)

Dette gjelder ved bruk av funksjonaliteten "Lokal vare". Lokal vare har et PLU-nummer innenfor gitt nummerserie. På lokal PLU kan det legges opp tandem, så kallet butikklokal tandem, noe som ofte er en reell EAN-kode. I det tilfelle HK velger å legge opp en ny hovedvare med samme EAN som allerede er brukt til butikklokal tandem på en lokal PLU, da vil det komme en melding om dette. I tillegg til et spørsmål om den lokale varen skal konverteres til sentral vare. Ved bekreftelse fullføres opplegg av ny hovedvare med riktig info og profilpris. Ved konvertering blir da tidligere buttandem ny hovedvare, PLU-nummer blir tandem til ny hovedvare og pris på lokal vare kopieres inn som ny butikkpris på hovedvaren. Deretter fjernes tidligere lokal PLU fra programmet "Lokal vare".

Nye obligatoriske felt i "Lokal vare"

(RTC-16144)

Ny funksjonalitet i programmet "Lokal vare" i "Prisvedlikehold" er parameterstyring av standardverdi i feltene "Enhetstekst" og "Mengde", normal er disse feltene blanke når lokal vare lages. 

  • Ved ny vare hentes standardverdiene for disse feltene fra VPI-mal. Hvis ingen standardverdi er angitt brukes verdien 1. Hvis verdien for "Mengde" har desimaler må dette angis med desimaltegn.
  • Ingen tvang om endring av feltene for eksisterende poster, men dersom man endrer et av feltene, må begge settes med aktiv verdi før varen kan lagres.
Konfigurasjon

Systemparameter 938 = 1 aktiverer denne funksjonalitet 

Systemparameter 938 = 0 kreves hvis feltene "Enhetstekst" eller "Mengde" skal nullstilles.

Nye meldinger ved bruk av EAN i "Lokal vare"

(RTC-16143)

Ved oppretting av nye varer i programmet "Lokal vare" er funksjonaliteten forbedret. Hvis EAN/Strekkode som skal skannes finnes, begynn alltid med å legge inn dette i feltet for EAN/PLU direkte, IKKE trykk på "Ny":

  1. Hvis EAN er ukjent i vareregisteret blir det foreslått å legge opp en ny lokal vare, og som følge av dette blir brukt EAN lagt opp som "Buttandem", tandemvare til butikken på den nye lokale varen.
  2. Hvis EAN er kjent i Chain Classic blir det foreslått å bruke eksisterende hovedvare.
  3. Hvis EAN er kjent som tandem til annen hovedvare blir det foreslått å bruke eksisterende hovedvare.
  4. Hvis EAN finnes som tandem til annen lokal vare foreslås å bruke eksisterende lokale vare. Butikken legger opp egen pris og får angitt EAN som buttandem, tandem til lokal vare.

Kontroll over lagerstyring i "Lokal vare"

(RTC-16142)

I programmet "Lokal vare" er det nå mulig å sette ønsket type lagerstyring. I felt for "Lager" kan ønsket alternativ for dette velges ved nyoppretting av lokal vare hvis standardvalg ikke er aktuelt. Det er også mulig å endre dette felt på eksisterende varer.

Konfigurasjon
Hva som skal være standardvalg settes opp i VPI-mal for "Lager".



Chain Classic versjon 2.1.1.0.24

Dokument status: RELEASED

Dato:  

Forutsetninger for oppgradering 

Oppgradering til Chain Classic versjon 2.1.1.0.24 forutsetter at POS leverer bong-format i POSLog versjon 75. 

Forbedringer i Chain Classic

ModulBeskrivelse
Eksport 

Eksport av ny butikk og omfattende utvalg (RTC-17233)

Det er gjort forbedringer i programmet for eksport av ny butikk. Hvis butikkutvalget inkluderer butikker på forskjellige profiler vil det, dersom profilutvalg også brukes, kun legges ut til butikker kun med valgt profiltilhørighet.

Mixmatch

Alle mixpriser = 0 kr i mixmatchtype 34 (RTC-16892)

Mixmatchtype 34 ble opprinnelig laget for tredjepartsystemet Tokheim POS, hvor en vare skal være tildelt en mixpris. Det er nå laget en tilpasning til EG POS slik at alle mixpriser settes til 0 kr for kunder som ikke bruker Tokheim POS.  

Pris

Prisendring på ny vare i Serviceordre (RTC-17054)

Det er gjort forbedringer slik at opplegg av ny vare på fanen "Oppgaver/Deler" i programmet "Serviceordre" og samtidig endring av utpris, beholder ny utpris ved lagring.


Mangelende utlegg av veiledende pris (RTC-16570)

Utlegg av poster for kampanjegruppe og pris er forbedret slik at også veiledende pris legges med disse.


Ny pris kan ikke lagres med "gammel dato" (RTC-16705)
Funksjonalitet for kopiering av prispost er forbedret slik at det ved kopiering av pris med ubehandlet køpost (etikettkrav), og som følge av dette gammel dato, nå settes ny dato i datofeltet på ny prispost, og denne kan lagres uten problemer.

Rapporter

Engelsk oversettelse av rapporter (RTC-16807)

Rapportene Kassereroppgjør, X- og Z-rapporter finnes nå med engelsk oversettelse.

Varetransaksjoner 

Årsakskode med fire siffer i Varetransaksjoner (RTC-17211)

Programmet "Varetransaksjoner" kan nå vise fire siffer i feltene for "Årsakskode" og "Behandlingskode" mot tidligere maks tre. 

VPI sync

Forbedret slettefunksjonalitet i VPI-sync V1 og V2 (RTC-16851)

Ved bruk av VPI-sync har det vært tilfeller hvor avvik ikke har blitt korrigert når riktig pris sendes til POS. Dette fordi korrekt pris ikke ble oppfattet som endring i POS. Dette er tatt hensyn til ved at det nå først sendes en sletting av pris og deretter aktuelle prisstatuser på vare med opprinnelig avvik. I denne forbedringen av VPI-sync korrigeres også avvik hvor hovedvare i POS er tandem i Chain etter EAN/PLU-bytte.

Ved manuell åpning av "Klargjør vare" kan visning av alternativet Slettepost før nytt utlegg aktiveres ved å skru på systemparameter 939.

Begrense valg av kampanjetype

(RTC-16175)

Det er mulig å sette opp standardvalg for butikk-/team- og/eller profilbruker for kampanjetype i kampanjegruppe.

I tillegg er det mulig å sette opp om det skal være mulig for bruker å endre kampanjetype eller ikke. 

Konfigurasjon

Begrense valg av kampanjetype 

Ny systemparameter 937 har en firedelt verdi= X,X,X,X

  • 1. verdi > 0: kampanjetypenummer til standard kampanjetype for butikkbruker.
  • 2. verdi = 0: kampanjetype kan IKKE endres av butikkbruker
    2. verdi = 1: kampanjetype kan endres av butikkbruker
  • 3. verdi > 0: kampanjetypenummer til standard kampanjetype for profilbruker.
  • 4. verdi = 0: kampanjetype kan IKKE endres av profilbruker
    4. verdi = 1: kampanjetype kan endres av profilbruker

Når Verdi = 0,0,0,0,0 er parameter ikke i bruk og standardvalg = "Ingen". Alle kan endre mellom de valg som finnes i register for kampanjetyper.

Ny rapport: Sortimentsliste Excel Alternativ

(RTC-16526) 

Det er laget en ny spesialtilpasset versjon av "Sortimentsliste Excel" med navnet "Sort.liste Excel Alternativ". Denne inneholder andre kolonner sammenlignet med opprinnelig rapport.

Utvidet oppsett for "Lokal vare" i Prisvedlikehold 

(RTC-16141)

Oppsett av hvilke butikker som skal bruke funksjonaliteten "Lokal Vare" i "Prisvedlikehold" er utvidet med mulighet å legge til butikk for butikk, i tillegg til tidligere mulighet å fjerne butikk for butikk.

Konfigurasjon

Grunnoppsett:
     - Knappen "Lokal vare" vises for alle butikkbrukere i Tokheimbutikk når:
          - Systemparameter 586 = 3 
          - Systemparameter 756 = 2
          - Systemparameter 575 = 0 
          - Systemalternativer for butikk 586 er blank = ingen butikker
          - Systemalternativer for butikk 1076 er blank = ingen butikker

Videre oppsett:
     - Knappen "Lokal vare" skal vises for alle butikker unntatt butikk X og butikk Y:
          - Systemalternativer for butikk 586 er blank, legg inn butikkene X og Y

     - Knappen "Lokal vare" skal KUN vises for butikk A og butikk B:
         - Legg inn butikkene A og B i systemalternativer for butikk 1076

     - Knappen "Lokal vare" skal skjules for butikk B:
         - Legg inn butikk B i systemalternativer for butikk 586 (586 vinner over 1076)
               eller
         - Fjern butikk B fra systemalternativer for butikk 1076  

Bestillingspunkt skal vises i InStore App

(RTC-14646)   

Det er laget nye utlegg av lagerinfo, slik at "Bestillingspunkt" fra Chain Classic i InStoreApp. 

I tillegg er det laget støtte for å vise varer med enten bestillingstype autosupplering eller automatisk bestilling, i programmet "Bestillingskriterier" i Chain Classic.

Oppdatering av endret pris på råvare i ingrediens

(RTC-16440)

Gjelder ved bruk av "Servicehandel". Det er gjort forbedringer slik at nettoprisendringer på råvare oppdateres direkte etter endring på alle steder dette vises. Dette hvis brukt program åpnes etter endring, hvis programmet er åpent må F5-tast brukes for å oppdatere  skjermbilde til å vise forventet nettoprisendring. 

Den tidligere brukte systemparameteren 907 er fjernet og trengs ikke ved bruk av servicehandel.

Kontrollere antall felt som eksporteres til filkø og JSON

(RTC-16103) 

Det er innført parameterstyring av antall felt som benyttes i både eksport i flatfil og i utlegg til JSON av prioriterte lagerendringer. Dette ved behov hvis det ved overgang til nye felt ikke er full kompatibilitet.

Konfigurasjon 

Systemalternativer 193

Utlegg av antall felt til JSON settes i systemalternativer 193. 

  • Integer = 0 betyr utlegg av alle tilgjengelige felt (i denne versjon = 8, i tillegg til butnr og dato: totalt 10 felt).
  • Integer = 7 betyr at 7 felt legges ut (i tillegg til butnr og dato: totalt 9 felt).

Eksport av bestillingsverdi til totalbutikken 99900

(RTC-15951)

Det er utviklet støtte for å legge ut verdien for "Bestilling", til totalbutikken 99900, i formatet vare.99900. Verdien kan da kan hentes opp og brukes i InStoreApp.

Konfigurasjon 

Systemalternativer 121

Antall felt i vare.butnr må være 91.
Konfigureres i Systemalternativer 121, kode 1 "VPI": Integer = 91.


Systemparameter 36

Verdiene i "Bestilling" (Varevedlikehold) settes opp i systemalternativer 36. Opp til 30 tegn kan legges ut, kuttes til 30 om det er lengre.

Utvidelse av JSON stock-fil

(RTC-8082)

Ved utlegg av JSON stock-fil legges det nå ut et ekstra felt, "quantityReserved", bakerst på hver linje. Feltet viser reservert antall (differanse mellom antall solgt og antall levert i kundeordre/webordre) for aktuell vare. 

Utvidet informasjon til Tokheim POS ved sletting

(RTC-16444)

Ved sletting av vare i kampanjegruppe eller mixmatch er utlegg for tredjepartssystemet Tokheim POS utvidet med ny sletteinfo. 

[SHOP_DELETE]
PRO116,1=82130
PRO120,1=57009
[END_SHOP_DELETE]

  • No labels