Chain Classic versjon 2.1.1.0.32
Dokument status: Status colour Green title 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"
Standard funksjonalitet i programmet "Bestillingsfordeling Excel" er at nettopris ALLTID oppdateres fra regnearket hvis denne har en verdi > 0.
...
| Expand | ||
|---|---|---|
| ||
|
Alle butikkpriser skal ha samme verdi på vektkode og fastpris
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.
| Expand | ||
|---|---|---|
| ||
|
Bestillingsfordeling Excel og laveste nettopris fra priskalkyle, ved manuelt varemottak
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.
...
| Expand | ||
|---|---|---|
| ||
|
Behandling av Coopay reserveløsning i finansoppgjør
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.
| Expand | ||
|---|---|---|
| ||
|
Mixmatch med varer som mangler i vareregisteret
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.
| Expand | ||
|---|---|---|
| ||
|
Alternativ sletting av mixmatch
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.
| Expand | ||
|---|---|---|
| ||
|
Innlesing av JSON-fil fra StoreMaster
Ved innlesing av JSON-fil fra StoreMaster inngår også disse feltene:
...
| Expand | ||
|---|---|---|
| ||
|
Wet Stock - justering av tanknivå
"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.
| Expand | ||
|---|---|---|
| ||
|
Wet Stock og temperaturkompensert mengde i "Tankstatus"
Temperaturkompensert mengde "L15" vises i eget felt i program for "Tankstatus".
...
| Expand | ||
|---|---|---|
| ||
|
Oppdatering av tankstruktur til Tokheim
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:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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.
| |||||||
| 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.
| |||||||
| 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
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
Det er mulig å begrense utlegg til el. etiketter og ferskvarevekter til kun de faktiske endringer som gjelder disse løsningene.
| Expand | ||
|---|---|---|
| ||
|
Montering som linkvare
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.
| Expand | ||
|---|---|---|
| ||
|
Sletting av siste pris sletter også vare i Lexmark
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.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av økologisk-merke i vektformatet XML
Det er mulighet å angi butikk som Debio-godkjent, dette fører til at økologisk merke alltid legges ut til vektformatet XML.
| Expand | ||
|---|---|---|
| ||
|
Sletting av pris via RIGAL
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"
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
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
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".
| Expand | ||
|---|---|---|
| ||
|
Importere EAN/PLU fra CSV-fil til vareliste
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
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
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
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.
| Expand | ||
|---|---|---|
| ||
|
Bestilling av kun hele forpakninger fra InStore App
Det er mulig å parameterstyre om kun hele forpakninger skal være mulig å bestille når anbrekk ikke er tillatt for varen.
...
| Expand | ||
|---|---|---|
| ||
|
Tandemnummer i bestilling fra InStore App
Ved innlesing av bestilling i Chain Classic, fra InStore App, fanges også vare med tandemnummer opp, hvis den er brukt i bestilt pakkevare.
| Expand | ||
|---|---|---|
| ||
|
Skap lokal kampanje fra InStore App
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
Det er mulig å skrive ut etiketter fra elektronisk varemottak også ved bruk av pakke-ID sammen med ordrenummer.
| Expand | ||
|---|---|---|
| ||
|
Behandling av antall = 0 ved import av bestilling via RIGAL-fil
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.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av tellegrunnlag for butikker utenlagerstyring til Chain Web
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.
| Expand | ||
|---|---|---|
| ||
|
Legg ut 20-kode uten sjekksiffer i RIGAL
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.
| Expand | ||
|---|---|---|
| ||
|
Innlesing av data fra Store Manager (JSON)
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.
| Expand | ||
|---|---|---|
| ||
|
Eksternt ordrenummer og eksternt linjenummer i varemottak
Chain Classic kan kommunisere eksternt ordre- og linjenummer via RIGAL I-fil.
| Expand | ||
|---|---|---|
| ||
|
Kampanje-ID til Tokheim POS
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"
Mulighetene til logging er utvidet, men fremfor alt er ytelsesforbedringene vesentlige i programmet "Slette/fjerne fra kasse", som består av to behandlingsvarianter:
...
| Expand | ||
|---|---|---|
| ||
|
Unngå deadletters når Chain Web tar over som kasserermaster
Chain Classic må tilpasses når Chain Web tar over som master for kasserere.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.30
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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.
|
SKU-felt for Chain Web i vare.99900
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.
...
| Expand | ||
|---|---|---|
| ||
|
Fabrikat i rapport "Aldersfordelt lagerverdi"
Rapporten "Aldersfordelt lagerverdi" viser nå også "Fabrikat" for varene i en ny kolonne.
Ugyldige tegn i sensitive tekstfelt
I "Vare", Kunde" og forskjellige registerprogrammer kan det få konsekvenser hvis det lagres ugyldige tegn i sensitive navnefelt.
...
| Expand | ||
|---|---|---|
| ||
|
Nettopriskontroll med profilprisendringer
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.
| Expand | ||
|---|---|---|
| ||
|
Sletting av gamle loggposter i database
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.
...
| Expand | ||
|---|---|---|
| ||
|
Sletting av vaskeprogram i Tokheim POS
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
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.
| Expand | ||
|---|---|---|
| ||
|
Rapportene "Varekølogg" og "Logg el. hylleforkanter"
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å.
...
| Expand | ||
|---|---|---|
| ||
|
Slett ikke-aktiv butikk
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.
| Expand | ||
|---|---|---|
| ||
|
Sletting av gammel statistikk og registre
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.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.29
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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.
| |||||||
| 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
Det er mulig å se, sortere og filtrere på "Referansetekst" ved søk i "Bestilling", "Varemottak" og "El. varemottak".
...
| Expand | ||
|---|---|---|
| ||
|
Ny priskanal i Kampanjegruppe
Ny priskanal i kampanjegruppe legges opp i systemalternativer 206. Deretter kan de legges ut til POS via Kampanjegruppeutlegg.
| Expand | ||
|---|---|---|
| ||
|
Alternative utlegg til Breece og Pricer
- Det er mulig å forhindre utlegg av tilbud fra Kampanjegruppe hvis annen priskanal enn "Alle" er valgt.
- 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.
...
| Expand | ||
|---|---|---|
| ||
|
Vektkode på ny butikkpris når verdi mangler i VPI
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.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.28
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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
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.
...
| Expand | ||
|---|---|---|
| ||
|
Medlemstilbud i kundeordre ved bruk av CoopID
- 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.
...
| Expand | ||
|---|---|---|
| ||
|
E-postadresse på kasserere
I registeret for kasserere kan e-postadresse legges opp for utlegg til POS.
| Expand | ||
|---|---|---|
| ||
|
Merk flere rader i priskontroll
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
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.
| Expand | ||
|---|---|---|
| ||
|
Fastpris
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
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.
...
| Expand | ||
|---|---|---|
| ||
|
Skille mellom kundeordre/webordre og serviceordre
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.
| Expand | ||
|---|---|---|
| ||
|
Etikett med registreringsdato
Kundespesifikk etikettdesign med nytt felt i stylecode 1.
...
| Info | ||
|---|---|---|
| ||
I hjelpkatalogen ligger oppdateringen: etidesign_1_12.d |
Varetype for "Lokal vare" til Tokheim kassesystem
Ved bruk av utlegg til tredjepartssystemet Tokheim settes alltid varetype til verdi 1, "Butikkvare", når en ny "Lokal vare" lages.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.27
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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)
| |||||||
| 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:
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.
| |||||||
| 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.
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.
| |||||||
| 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
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.
...
| Expand | ||
|---|---|---|
| ||
Beskrivelse av logg
|
Lexmark etikettflagg på tilbudsvarer
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.
| Info |
|---|
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
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".
...
| Expand | ||
|---|---|---|
| ||
|
Endre engrospris per butikk
Engrospris kan endres ved å lese inn en fil med navn "inkopspris.butnr.csv", som inneholder kun alfanumerisk varenummer og ny engrospris. Merk: engrospris MÅ skrives med punktum, for eksempel 3.44, hvis kommategn bukes blir ny engrospris 344.
...
| Expand | ||
|---|---|---|
| ||
|
Grunnlag etikett i "Varekølista"
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
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.
| Expand | ||
|---|---|---|
| ||
|
Oppdater butikker via JSON-import
Chain Classic kan nå opprette og oppdatere butikker via JSON-innlesning fra Store Service.
| Expand | ||
|---|---|---|
| ||
|
Logging av "uønskede" Breece-utlegg
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
Ved bruk av "Alternativ pris", for spise ute/inne, legges dette ut til Breece ved kjøring av "Klargjør vare".
| Expand | ||
|---|---|---|
| ||
|
Varetyper for "Spillvarer/Elektronisk produkt/MBXP webhandel"
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:
...
| Expand | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Vare/Prisinfo Innlesing og utlegg Kode i filnavn: V
|
Kun ordinærpris på etikett fra InStore App
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
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.
...
| Info |
|---|
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
Ved å "sende" EAN fra InStore App hentes alle åpne (ikke mottatte) bestillingsrader fra Chain Classic til InStore App.
...
| Expand | ||
|---|---|---|
| ||
|
Opprydding ved EAN/PLU-nummerbytte
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
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"
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".
| Expand | ||
|---|---|---|
| ||
|
Ny EAN-nr blir hoved-EAN ved samme vare- og variantnummer
NB: Kundetilpasset spesialfunksjon!
...
| Expand | ||||
|---|---|---|---|---|
| ||||
|
...
Chain Classic versjon 2.1.1.0.26
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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
Ved manuell kontroll av handlekurv i selvbetjent kasse logges dette i rapportene "Butikkoppgjør total" og "Butikkoppgjør pr. kasserer".
...
| Expand | ||
|---|---|---|
| ||
|
Kundespesifikk identifikator i kundeordre
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.
| Expand | ||
|---|---|---|
| ||
|
Fjerning av medlemslink i Chain Classic
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.
| Expand | ||
|---|---|---|
| ||
|
Forbedret plukkliste for E-handel/webordre
Denne varianten av plukkliste kjennetegnes av at eksternt ordrenummer med strekkode, sammensatt hyllelokasjon og leveransemetode vises helt øverst. Visning er videreutviklet med følgende:
...
| Expand | ||
|---|---|---|
| ||
|
Nettopriskolonne i elektronisk varemottak
Det er utvidet funksjonalitet for hvilken type "innpris" som skal vises i Elektronisk varemottak.
...
| Expand | ||
|---|---|---|
| ||
|
Automatisk oppdatering av HK-styrte prisfeltendringer
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:
...
| Expand | ||
|---|---|---|
| ||
|
Godkjenning av mixmatch i priskontroll
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.
...
| Expand | ||
|---|---|---|
| ||
|
Kampanjegruppe i priskontroll
Kontroll av kampanjegruppe i priskontroll er forbedret. Kampanjeprisene vises under egen fane, hvor de kan godkjennes og avvises.
...
| Expand | ||
|---|---|---|
| ||
|
Bestillinger fra InStore App skal ikke havne i Elektronisk varemottak
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".
| Expand | ||
|---|---|---|
| ||
|
Parameterstyring av ikke-lagerstyrt flagg ved eksport av tellegrunnlag til Chain Web
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.
...
| Expand | ||
|---|---|---|
| ||
|
Valg av om hoved-EAN skal byttes ved RIGAL-oppdatering på tandem-EAN eller ny EAN
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.
...
| Expand | ||
|---|---|---|
| ||
|
Eksport av nonsaletype
Det er laget nytt vedlikeholdsprogram for nonsaletype, System > Kasse > Nonsaletype.
...
| Info |
|---|
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
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
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:
| Status | ||||
|---|---|---|---|---|
|
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
| Modul | Beskrivelse | |||||
|---|---|---|---|---|---|---|
| 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.
| |||||
| 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".
| |||||
| 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
Utleggene til tredjepartssystemet Lexmark er spisset for å hindre at unødvendige data legges ut.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av kampanjegruppe med priskanal til Lexmark
Der er nå mulig å legge ut priskanaler til tredjepartssystemet Lexmark.
| Expand | ||
|---|---|---|
| ||
|
Ny mixinformasjon til Lexmark
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.
| Expand | ||
|---|---|---|
| ||
|
Sentral kampanje-ID på lokale kampanjevarer
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
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.
| Expand | ||
|---|---|---|
| ||
|
Webordre fra EG POS - Automatisk internoverføring fra sentrallager til butikk
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.
| Info |
|---|
POSLog 80 må være i bruk i hele systemet for denne internoverføringen i Chain Classic. |
Utlegg ved endring av veid kostpris
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"
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".
| Expand | ||
|---|---|---|
| ||
|
Ny kolonne i reseptvare for kalkulert nettopris pr. ingrediens
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"
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"
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"
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.
...
| Expand | ||
|---|---|---|
| ||
|
Nye meldinger ved bruk av EAN i "Lokal vare"
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":
- 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.
- Hvis EAN er kjent i Chain Classic blir det foreslått å bruke eksisterende hovedvare.
- Hvis EAN er kjent som tandem til annen hovedvare blir det foreslått å bruke eksisterende hovedvare.
- 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"
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.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.24
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
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
| Modul | Beskrivelse |
|---|---|
| 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) |
| 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
Det er mulig å sette opp standardvalg for butikk-/team- og/eller profilbruker for kampanjetype i kampanjegruppe.
...
| Expand | ||
|---|---|---|
| ||
|
Ny rapport: Sortimentsliste Excel Alternativ
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
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.
| Expand | ||
|---|---|---|
| ||
|
Bestillingspunkt skal vises i InStore App
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
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.
| Info |
|---|
Den tidligere brukte systemparameteren 907 er fjernet og trengs ikke ved bruk av servicehandel. |
Kontrollere antall felt som eksporteres til filkø og JSON
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.
| Expand | ||
|---|---|---|
| ||
|
Eksport av bestillingsverdi til totalbutikken 99900
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.
| Expand | ||
|---|---|---|
| ||
|
Utvidelse av JSON stock-fil
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
Ved sletting av vare i kampanjegruppe eller mixmatch er utlegg for tredjepartssystemet Tokheim POS utvidet med ny sletteinfo.
...