Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Forbedringer

Modul

Beskrivelse 

Lager

Lageroppdatering av bestilt pakkevare (RTC-40732)

Pakkevarer inneholder ofte mer enn én vare.
Ved bestilling av pakkevare er det selve pakkevaren som bestilles, men det er "innholdsvarene" som lagerstyres og det er der bestilt antall vil bli oppdatert i lagerposten.
Ved varemottak av en pakkevare oppdateres lagerantall på "innholdsvarene" og bestilt antall reduseres der. 

Lageroversikt

Lagerlogg viser alle endringer på lager i "Lageroversikt" (RTC-40438)

I programmet "Lageroversikt" kan alle endringer på lager sjekkes for valgt butikk under knappen Lagerlogg.
Her vises endringene samt hvilket program som er benyttet og hvilken bruker.
Dette er et godt hjelpemiddel ved uklarheter om gjeldende lagerverdi.
Dato/tid/bruker gjør det enklere å finne tilhørende transaksjoner i "Varetransaksjoner".

Vare

Tandem for varianter på modellvare med samme farge (RTC-40558)

Ved bruk av kun en hovedvare for kombinasjonen modell/farge, har kun tandemnummer på hovedvaren vært synlig på fanen for tandem. 
Tandemnummer på de andre variantene med samme modell/farge vedlikeholdes via knappen Tandem på "fanen "Størrelser".

Varemottak

Utvidet logging ved manuelt varemottak (RTC-37621)

Ved et manuelt varemottak som ikke kobles til en allerede eksisterende bestilling/varemottak, vil det kun logges "Manuell" i Transtekst feltet i tilhørende varetransaksjonspost.
Dersom mottaket kobles til én eksisterende bestilling/varemottak, vil dette logges i samme felt med "Manuell: Ordre/rad: XXX YY". 

Varetransaksjoner

Oppdatering av varetransaksjoner på reseptvarer og butikkvarer i samme POSLog (RTC-43995)

Det er mulig å oppdatere varetransaksjoner på både reseptvarer og på vanlige butikkvarer i samme POSLog. Forskjellen er at varetransaksjonspostene oppdateres på butikkvaren, mens det for en reseptvare skapes varetransaksjoner på råvarene som ingrediensene i reseptvaren er skapt fra.

Webordre 

Sikre unikt jobbnummer når plukkliste skapes for en webordre (RTC-41864)

Når Plukkliste skal skrives for en webordre, behøves et unikt jobbnummer. Dette hentes fra en teller i Chain Classic.
Dersom neste ledige jobbnummer mot formodning allerede eksisterer, vil telleren telles opp med +1 inntil første ledige jobbnummer.

Laveste pris siste 30 dager  

(RTC-40443RTC-41092RTC-41093RTC-41714RTC-42197)  

Laveste pris siste 30 dager (LPS30D) er en funksjonalitet laget for å vise kundene i butikken hva den laveste salgsprisen har vært de seineste 30 dagene. Denne beregnes av alle pristyper uavhengig av hvordan prisendringen ble skapt, av ny pris, tilbudspris eller ordinær prisendring. Alle varianter kan inngå i beregningen av periodens laveste pris.

Det er også LPS30D som skal brukes når en rabattbasert tilbudspris beregnes av en angitt kr- eller %-rabatt.
Dette kan innebære at butikker med en lavere LPS30D enn hva profilprisen har, vil få en lavere tilbudspris sammenlignet med de andre butikkene.
Prisendringer som fører til at LPS30D endres til en lavere verdi, vil medføre en automatisk rekalkulering i framtidige, ikke aktive krone- eller prosentbaserte tilbudspriser.
Ved kopiering av tilbudspriser basert på en krone- eller prosentrabatt vil gjeldende LPS30D bli brukt og utsalgsprisen vil bli kalkulert ut fra dette.
For avsluttede kampanjegrupper vises LPS30D som ble brukt, når kampanjen var aktiv.

Utlegg av LPS30D skjer kun for tilbudspriser, og da til POS og 3. partssystemene Pricer, Breece og Lexmark.
I Chain Classic vises LPS30D for tilbudspriser i alle prisvedlikeholdsprogram. 

På en varelinje i en profilkampanje vil knappen "Butikklokale kampanjepriser" (nedenfor) vise eventuelle butikker som vil få en lavere tilbudspris enn profilkampanjen.

Image Added

Knappen "Endringer av laveste pris" (nedenfor) er en god hjelp for å følge historikken for LPS30D-endringer over tid. Utsalgsprisen i disse prisloggposter vil fortelle hva neste tilbudspris vil bruke som LPS30D. Laveste priskolonnen vil alltid være 0 for prislogg poster for ny pris eller ordinære prisendringer.

  • For profilbruker vises alltid med poster for profilpris
  • For butikkbruker vises profilpris og eventuelt prisloggposter for egen butikk (se bilde nedenfor)
  • For teambruker vises profilpris og eventuelt prisloggposter for team-butikker

Image Added

Expand
titleKonfigurasjon
Teknisk informasjon

Systemparameter 1006 =30 aktiverer LPS30D-funksjonaliteten (> 0)

I systemparameter 1007 velges om utlegg av LPS30D skal skje til Pricer, Breece og Lexmark

I systemparameter 1017 settes antall dager tilbake som LPS30D-endringer skal vises i "Endringer av laveste pris"

Når tilbudspriser ikke skal benytte LPS30D eller skal beregnes på ordinær pris

(RTC-42538, RTC-43245, RTC-43249RTC-44071RTC-44075, RTC-44387)

Rabattårsaker kan brukes for både manuelle tilbudspriser skapt i Prisendring og tilbudspriser i Kampanjegruppe. Disse kan brukes til å overstyre beregning av en ellers alt for lav LPS30D. 
En krone- eller prosentrabatt basert tilbudspris vil da kalkuleres fra ordinærpris istedenfor LPS30D.
I tillegg vil det være mulig for en gitt rabattårsak å unnta at en tilbudspris skal inngå i beregningen av LPS30D for en annen tilbudspris.
Dette er i overenstemmelse med myndighetskrav.
Vedlikeholdsprogrammet "VPI rabattårsaker" er laget for å enkelt kunne vedlikeholde disse valgene.

Image Added

Ved utlegg av tilbudspriser til POS og 3. partsløsningene vil rabattårsak alltid være utfylt. For ordinære priser er feltet alltid 0.

Valg av rabattårsaker på tilbudspriser i en kampanjegruppe kan skje på forskjellige måter:

  • Skriv rabattårsaksnummer direkte i feltet for rabattårsak i varebrowser.
  • Ved å dobbeltklikke i feltet for rabattårsak vil dialogen "Velg rabattårsak " åpnes (se nedenfor).
  • Ved å dobbeltklikke på annet felt på varelinjen vil full priskalkyle åpnes der rabattårsaken også kan endres.

Image Added

Expand
titleKonfigurasjon
Teknisk informasjon

For utlegg til POS må "Systemalternativer" 121 settes opp slik:

  • Kode 25: Pris med "Integer" = 30
  • Kode 34: Kampgr med "Integer" = 66

For utlegg til 3. part må "Systemalternativer" 125 settes opp slik:

  • Kode 4: Pricer med "Integer" = 30
  • Kode 9: Breece med "Integer" = 66
  • Kode 17: Lexmark med "Integer" = 54

Til POS legges rabattårsak ut i formatene pris.butnr og kampgr.butnr.

I 3. partsløsningene Breece og Pricer (standard Pricer format) ligger kampanjepris og medlemstilbud på samme rad, derfor legges det ut rabattårsak både for kampanjepris og medlemstilbud i samme post.

Til Lexmark legges rabattårsaken bakerst for kampanjepriser og medlemstilbud som alltid legges ut hver for seg.

Rabattårsak kan oppdateres fra RIGAL-formatene V og J, og legges ut til de samme formatene. 
Når det gjelder J-formatet er både standard og full bredde inkludert.

Softpay terminaltype and card types

(RTC-44405RTC-44745RTC-44864)

Ved bruk av SoftPay betalingsmiddel, vil finanstransaksjoner for alle korttyper som har vært i bruk, bli oppdatert.
Dette forutsetter bruk av en dedikert løsning for netthandel.
Disse finanstransaksjonene:  

  • Oppdateres pr kasse/kasserer
  • Legges ut i RIGAL F-fil
  • Vises i rapporten "Omsetning pr korttype"
Expand
titleKonfigurasjon
Teknisk informasjon

Systemparameter 610 = 1

Programpost: program_xkortsalp_Coop.d må hotfixes da standardrapport "Omsetning pr korttype" må roteres til liggende A4 for å få plass til å vise SoftPay-betalinger.

  • Utlegg per korttype i RIGAL F-fil (S00-S99). I tillegg vil også evt. bruk av reserveløsning for SoftPay bli lagt ut.
  • Som de andre korttranskasjonene (totalt, websalg og for Coopay), legges det ut totalt pr dato pr kasse (FKD), pr kasserer (FKD) og totalt (FTD).

Åpne kampanjegruppe på vare fra Prisvedlikehold

(RTC-42114)

Kampanjegruppe kan åpnes direkte fra Prisendring for tilbudspriser som er skapt i en kampanjegruppe. Velg varekøposten for kampanjen og knappen "Kampanjegruppe" blir aktiv. Knappen er en snarvei til å åpne opp Kampanjegruppe vedlikehold på varekøpostens kampanjegruppe.

Image Added

Godkjenning av priser i "Priskontroll"

(RTC-40918)

I "Priskontroll" kan priser godkjennes på forskjellige måter:

  1. På knappen "Godkjenn merkede poster" vil kun merkede poster godkjennes.
  2. På knappen "Godkjenn utvalget" vil som standard de 50 første, ikke godkjente prisendringene bli behandlet. 
    Når disse er kontrollert godkjennes disse via knappen "Godkjenn utvalget".
    Dersom det fortsatt finnes flere poster igjen å godkjenne, vil neste batch hentes inn for kontroll og ny godkjenning inntil alle poster er behandlet. 
  3. Knappen "Komplett godkjenning" benyttes dersom alle prisendringer er kontrollert og skal godkjennes.
    Alle aktuelle prisendringer inkludert de som ennå ikke er innhentet for kontroll på gjeldende fane, vil da bli godkjent direkte.

"Mal-butikk" i "Bestillingskriterier" 

(RTC-41178)

Normalt skapes bestillingskriterier for vanlige butikker med "Kommunikasjonstype" = 11 og "Bestilling" påslått. 
Det er også mulig å legge opp bestillingskriterier for såkalte "mal-butikker" som kun benyttes til dette formålet.
Vanlige butikker som benytter en malbutikk i "Mal for bestillingskriterier", vil bruke dennes bestillingskriterier dersom det ikke finnes bestillingskriterier på egen butikk.

Expand
titleKonfigurasjon
Teknisk informasjon
En "mal-butikk" legges opp i butikkregisteret med "Kommunikasjonstype" = 1.

Ikke vis varer som mangler både profilpris og butikkpris

(RTC-41286)

Det finnes tre alternativer for hvordan vare uten gyldig pris skal vises i Vare- og Prisvedlikehold:

  • 0 = Alle brukere kan se alle varer også de som ikke har en gyldig pris. Disse vil vises med merknad "Ingen pris".
  • 1 = Varer uten gyldig pris er skjult for profilbruker.
  • 2 = Varer uten gyldig pris er skjult for både profil- og butikkbruker.
Expand
titleKonfigurasjon
Teknisk informasjon

Systemparameter 374 kontrollerer hvordan varer uten pris skal vises for profil- og butikkbruker. 
Denne er endret fra å kun ha 2 mulige verdier (0 eller 1) til å også kunne ha verdien 2.

Utlegg av drivstoffendringer til Reporting 

(RTC-42339)

Ved endringer av gamle verdier i vedlikeholdsprogrammene for "Fylling", "Tankstatus" og "Manuell tankstatus", eller ved utlegg av gamle poster via "Data til Reporting", vil dette kunne føre til omfattende rekalkuleringsjobber i Reporting.
For å unngå at det oversendes for mye data, bør det derfor settes opp hvor mange dager tilbake i tid det skal være mulig å legge ut til Reporting 

Expand
titleKonfigurasjon
Teknisk informasjon
Systemparameter 1018 angis med maks antall dager tilbake som skal legges ut til Reporting ved endring.
Datovalg i "Data til Reporting" vil begrenses til å gjelde alle lagrede poster innenfor gyldig antall dager i systemparameteren. 

Lage grunnlaget for massesletting av varer

(RTC-40770)

Ved massesletting i svære vareregister er det viktig å ta dette kontrollert med begrensede utvalg i flere omganger.
På generelt grunnlag anbefales ikke å slette 100-tusenvis (eller millioner) av varer på en gang. Dette vil alltid ta mye kapasitet og bruke tid som kan påvirke andre oppgaver. 
Programmet "Oppdatering av sletteliste" benyttes for å lage grunnlaget for programmet "Sletting av varer" i den spesielle varelisten (listenr 100000002) som er avsatt til dette formålet.
Dette grunnlaget kan lages ved å begrense på ulike utvalg eller benytte varelister, varegruppelister eller modellister.
Ved kjøring kan det velges mellom å kun lage en rapport som viser varer som kan bli slettet, eller å både lage rapport og oppdatering av varene i den spesielle varelisten .
Når grunnlag er på plass, kan "Sletting av varer" utføres, manuelt eller aut. ved EOD,
Da vil alle varer som ligger som ligger i den spesielle varelisten bli slettet.
Varelisten tømmes etter bruk.

Expand
titleKonfigurasjon
Teknisk informasjon

Systemparameter 906 må være i bruk med alle tre verdiene utfylt.
Programmet "Oppdatering av sletteliste" fyller opp den "Spesielle varelisten" (listenr 100000002) med varer som kan slettes.

Følgende begrensinger kan angis:

  • Vareliste
  • Varegruppeliste
  • Kategoriliste
  • Modelliste
  • Unnta aktive varer (unnta vare dersom aktiv på noen butikk)
  • Benytt unntaksbutikker (unnta aktiv vare på butikk, angitt i systemalternativer for butikk 14)
  • Unnta varer med beholdning (unnta vare med lagerantall > 0)
  • Unnta endring av lager etter (unnta vare med lagerendringsdato nyere enn angitt dato)
  • Unnta varer med salg etter (unnta vare (inkl. tandem) med salgsdato etter angitt dato)
  • Unnta varer endret etter (unnta vare med vare- eller prisendring etter angitt dato)
  • Unnta nye varer etter (unnta vare ny- eller prisregistrering etter angitt dato)
  • I tillegg unntas linkvare til annen vare og varer som inngår i pakkevare

Bruker begrense noe, enten som liste eller på "Utvalg", ellers vil ikke jobben starte.
Standardvalg i programmet er "Unnta aktive varer" og "Unnta varer med beholdning".
Oppsett for standardvalg kan endres i systemalternativ 207: kode 5 - 12 ("Logisk" hukes av for standardvalg).
Standard for datovalg er satt 10000 dager tilbake i tid og kan også endres.
Disse verdiene er satt for å unngå forhastede masseslettinger og for "tvinge" bruker til å tenke gjennom hva som er fornuftige verdier for standard bruk.

Ved kjøring, velg:

  • Kun rapport (viser de varer som kan slettes, sortert på avdeling og varegruppe) eller
  • Utfør og få rapport i tillegg (fyll opp liste med varer som skal slettes + rapport)

Dersom hovedvare for modellfarge slettes vil en annen variant på samme modell/farge settes som hovedvare for modellfargen.

Behandling av pakkevarer i bestilling

(RTC-40776)

En pakkevare består gjerne av flere varer eller antall > 1 av varen som inngår.
Ved bestilling er det mulig å bestille kun pakkevaren.
Både ved bestilling og varemottak er det lager for innholdsvarene som oppdateres
Pakkevarene er ikke lagerstyrt. 

Expand
titleKonfigurasjon
Teknisk informasjon
Det anbefales på det sterkeste at alle kunder, som bruker bestillingsmodulen i Chain Classic og pakkevarer oppgraderer til denne patchen. 
I tabellen for bestilling/varemottak (bestrad) vil innholdsvarene ha samme radnummer som pakkevaren adskilt med sekvensnr.

Overstyring av faste dager for bestillingsforslag

(RTC-41807)

Ved bruk av bestillingsforslag er det mulig å parameterstyre genereringen av bestillingsforslag til én fast ukedag pr. butikk.
Dette kan overstyres manuelt i programmet slik at alle butikker, uansett ukedag, skal behandles samtidig.
Det er også mulig å legge opp en EOD-jobb for dette dersom det er behov for å generere bestillingsforslag for butikker en fast gang pr. uke.   

Expand
titleKonfigurasjon
Teknisk informasjon
Butikker skal legges opp i Systemalternativer for butikk 1075, med angitt ukedag.
Systemparameter 1016 må settes opp med ukedag for den dagen det skal genereres bestillingsforslag for alle butikker.

Utlegg av RIGAL-VPI til butikk

(RTC-42098)

I "Klargjøre vare" vil det ved valg av kun "RIGAL VPI", legges ut RIGAL V-fil og D-fil til valgt butikk. 
Innhold i V-fil vil være alle varer innenfor utvalg, med lokale butikkpriser der disse eksisterer, mens det for øvrige varer brukes profilpris.
D-fil vil inneholde alle varer med tilgjengelig profil "vareinformasjon". Der det finnes butikkspesifikk vareinformasjon vil denne bli brukes. 

Image Added

Dersom valget "Kun butikkpriser" legges til, vil de samme filformatene som ovenfor bli skapt, men kun inneholde varer med lokal butikkpris for valgt butikk.
Dette innebærer at ingen varer med kun profilpriser vil eksporteres.
Butikkspesifikk vareinformasjon på varer med kun profilpris vil heller ikke bli lagt ut.
Dette vil kun skje ved generelt RIGAL VPI-utlegg på hele profilen.

Image Added


...

Chain Classic versjon 2.1.1.0.44

...

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. 

...

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.

...

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.

...

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.

...

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.  

...

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

...

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.  

...

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.

...

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.

...

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.

...

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

...

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. 

Expand
titleKonfigurasjon
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.

Expand
titleKonfigurasjon
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.

...

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. 

Info
titleTeknisk informasjon

Systemparameter 723 styrer om profilkampanjegrupper skal vises eller ikke.

...

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.

Expand
titleKonfigurasjon
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.

...

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.

...

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.

Expand
titleKonfigurasjon
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.

Info

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. 

Info

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.

Info

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.  

...

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. 

...