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. 

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

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

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

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.

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.

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.

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.

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. 

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

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

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. 

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

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.

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.

Antall siffer for kasserernummer (RTC-34270)

Kasserernummer kan ha inntil 9 siffer i Chain Classic.

Nettleser i Chain Classic (RTC-35855)

Knapper som åpner nettleseren i Chain Classic vil alltid benytte Microsoft Edge.

Bestilling

Lager

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.  

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

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. 

DUN-nummer i RIGAL VPI (RTC-30127)

Oppdatering og endring av DUN-nummer kan kommuniseres via, felt 7.1.56, i RIGAL V-fil. 

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.  

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.

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.  

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.

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.  

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.

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.

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

Vareinformasjonstekst (RTC-27650)

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

Bestill etikettutskrift med forskjellige etikettyper (RTC-27262)

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

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.   

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

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.

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. 

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.  

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

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. 

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.

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

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.

Kunder med postnummer 0 tillates (RTC-19993)

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

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.

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

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.

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.

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

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

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.

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.

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.

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.

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