Chain Classic versjon 2.2.0.0.13
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.13 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:
|
| 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 Rapportlista.
|
| RIGAL | Varetype til RIGAL og logging av oppdatering fra RIGAL VPI (RTC-36476) Chain Classic legger alltid ut "Varetype" i RIGAL V-fil. |
| Vare | Fjern "Stopp salg av vare" i POS (RTC-38072) I Chain Classic kan en vare som har blitt sperret, senere åpnes for salg på kassene igjen. Dette skjer enten ved å bruke knappen "Friskmeld vare" i "Varevedlikehold eller ved å velge "Friskmeld vare" ved utlegg av varen fra "Klargjøre vare". |
| Vare-/kundegrupperabatt | Bruk av varelister i "Vare-/kundegrupperabatt" (RTC-34434) Ved opplegg og vedlikehold av varerabattposter i "Vare-/kundegrupperabatt" kan varelister med varelistenummer opp til 8 siffer benyttes. |
| Varetransaksjoner | Bongnummer og kundeordrenr/radnr i "Varetransaksjoner" (RTC-36528) For økt sporbarhet og enklere oppfølging oppdateres "Bongnummer" alltid når "Varetransaksjoner" oppdateres fra POSLog, og kundeordrenr/rad oppdateres også når dette er tilgjengelig. |
Vise laveste pris de siste 30 dagene før kampanjestart
(RTC-38287,RTC-38447, RTC-38451)
Ifølge markedsføringsloven skal referansepris, dersom den vises på elektroniske etiketter (Pricer og Breece) og papirbaserte etiketter eller plakater fra Lexmark, være den laveste prisen som har vært brukt i butikken de siste 30 dagene.
Kontrollperioden begynner dagen før tilbudsstart og strekker seg angitt antall dager tilbake i tid (minst 30 dager). Verdiene kan derfor bli forskjellige, i forhold til startdato, når det lages framtidige tilbud på samme vare.
I laveste pris inkluderes tidligere ordinære prisendringer, kampanjepriser og medlemstilbud som har vært lavere enn gjeldende ordinærpris. Gjeldende ordinære pris vil derfor kun benyttes som laveste pris dersom denne faktisk er den laveste prisen i perioden.
I program for Kampanjegruppe og manuell Prisvedlikehold vil verdi for laveste pris vises i eget felt, når kampanjepris eller medlemstilbud legges opp.
| Expand | ||
|---|---|---|
| ||
|
Bruk av Excel online i Chain Classic
Dersom Microsoft "online Excel-løsning" benyttes, kan ikke rapporter i XML-format brukes. Det vil derfor lages en CSV-versjon av denne rapporten som kopieres til katalogen Chain_Print.
- Velg ønsket rapport i rapportlisten og trykk på "Excel-knappen".
- Excel rapporten flyttes til katalogen Chain_Print. Dette bekreftes med en melding.
- Dersom rapporten er i XML-format (formattert Excel) vil det i tillegg lagres en CSV-versjon av rapporten på samme katalog. Meldingen vil nå henvise til at begge rapporter er kopiert.
- Åpne katalogen "Chain_Print" under katalogen "Dokumenter". Her vil de lagrede Excel rapportene ligge, både i XML og CSV format dersom rapporten er formattert.
Alle rapportfiler i format .csv, kan åpnes direkte i den Excel-løsningen som er tilgjengelig for bruker.
| Expand | ||
|---|---|---|
| ||
|
Oppdatering av RIGAL VPI med VAR- og PRI-poster fra Item Master
Når Item Master blir tatt i bruk, er det viktig Chain Classic er oppdatert til nyeste patch og at systemparameterne er satt opp korrekt.
Generell funksjon er som følger:
- RIGAL VPI med VAR-post på eksisterende vare i Chain Classic blir oppdatert dersom det er endret vareinformasjon i importen.
- RIGAL VPI med VAR-post på ny vare blir liggende igjen i VPI-vedlikehold inntil tilhørende PRI-post oppdateres. Dette innebærer at en komplett ny vare kan oppdateres til Chain Classic.
- RIGAL VPI med PRI-post for ny vare blir avvist dersom det ikke finnes en ventende VAR-post i VPI-vedlikehold.
- For ny vare må derfor alltid VAR-post oppdateres før PRI-post
- RIGAL VPI med PRI-post på kjent vare i Chain Classic, oppdateres dersom det finnes endret prisinformasjon.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av omsetning til Nielsen IQ
Utlegg av "Omsetning til Nielsen IQ" kan legges opp som en automatisk jobb i forbindelse med EOD, men programmet kan også brukes manuelt.
Standardverdi for ukenummer går ut fra dagens dato og 6 dager tilbake i tid, og kan endres etter ønske ved manuelle utlegg.
Omsetning legges ut pr solgt EAN/PLU med egne poster for salg på tandemnummer.
| Expand | ||
|---|---|---|
| ||
|
Mixtype 46: "Betal med Coopay og få x kr/% ekstra kjøpeutbytte"
Når ny mixmatch med mixtype 46 opprettes, hentes korttype for Coopay inn automatisk. Korttypen kan ikke endres.
Verdi for Rabattkr eller Rabatt% må angis. Selvskanning kan i tillegg velges.
Denne mixtypen fungerer uavhengig av varene i handlekurven, derfor skapes kun 1 mixrad med en angitt "Dummy-vare" om sørger for mix utlegget til POS via varekø.
| Expand | ||
|---|---|---|
| ||
|
Bruk av modellvarer i mixmatch
Noen mixmatchtyper kan brukes med modellvarer. Dette er noe som forenkler å legge inn et utvalg varer der kun en variant representerer alle varer i modellen.
For å få denne funksjonaliteten i POS, må valg av Modellvarer hukes av.
For å unngå problemer i POS kan ikke denne funksjonaliteten endres etter godkjenning av mixmatchen.
Flere slike kritiske valg er deaktivert slik at verdien beholdes uendret i hele mixmatchen "levetid".
Bruk av nettopris fra ordinær priskalkyle i rapporten "Lagerliste Excel"
- Rapporten "Lagerliste Excel" er i utgangspunktet laget for å vise kostpris for butikkenes varer der veid kostpris > 0. For varer uten veid kostpris, skrives 0 i denne kolonnen.
- Dersom parameter for å vise nettopris fra ordinær priskalkyle slås på, vil disse verdiene vises og bli brukt til å beregne kostpris for varer som ikke har en gyldig veid kostpris
Dersom nevnte parameter slås på, vil denne rapporten vise samme verdier som alt rapport "Lagerliste".
| Expand | ||
|---|---|---|
| ||
|
Prisimport via resultat-fil fra "Sortimentliste Excel"
Ved innlesing av VPI fra Excel kan det oppdateres prisendringer for profilpriser fra ulike profiler og butikkpriser. Hvordan prisendring skal oppdateres, bestemmes av om "RIGAL/Excel VPI pr butikk" er avkrysset (prisendringer på butikkpris) eller ikke (prisendringer på butikkens prisprofil) for butikken.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av mixmatch til Tokheim fra "Klargjøre vare"
I Klargjøre vare kan eksport gjøres med "Mixmatch" og "mixnummer" som eneste utvalg. Her legges da kun angitte mixmatcher ut. Denne funksjonaliteten støtter også samtidige utlegg av identiske profil mixmatcher på flere profiler, med samme innhold, start- og sluttid. Utlegg av mixmatch til Tokheim POS støttes også på samme måte.
Dette er standardfunksjonalitet både for eksport til EG POS og Tokheim POS.
Utvidet funksjonalitet i "Varebevegelser"
Dersom "Servicehandel" er i bruk, vil også varetransaksjoner for reseptvarer og varesalg for ingredienser (pr råvare) vises i oversikten "Varebevegelser" i Vare-/Prisvedlikehold. Dette vil være tillegg til standard varetransaksjoner og varesalg ellers.
| Expand | ||
|---|---|---|
| ||
|
Varemottak som skapes i forbindelse med en internoverføring
Det er ikke mulig å slette varemottak generert fra internoverføring. Dette er innført for å forhindre problemer som følge av sletting av "uventede" varemottak som ikke var bestilt fra leverandør.
Det er heller ikke mulig å slette, legge til eller endre på poster på linjenivå.
Profilbytte og framtidige prisendringer på ny profil
Ved endring av profilnummer på butikk skapes nye køposter for alle aktive og fremtidige profilprisendringer (dersom butikk ikke har lokal pris). Dette inkluderer kampanjepriser og medlemstilbud. Dersom priskontroll er i bruk vil dette bli hensyntatt og butikken må godkjenne nye prisendringer.
Automatisk bestilling i "Feltverdier for butikk"
Dersom en vare ikke er merket for "Automatisk bestilling" i Varevedlikehold, men det finnes butikker med dette behovet, løses, dette ved at butikken legger opp en butikklokal verdi for feltet i "Feltverdier for butikk". Denne butikklokale verdien vil benyttes i forbindelse med nye bestillinger på varen.
Sikre at alle proxy-program avslutter riktig
Ved direkte kommunikasjon mot løsninger i Cloud/POS, og Chain Classic "låses" forbindelsen mellom appserver og klient midlertidig. Når oppgaven er utført avsluttes denne forbindelsen og "låsing" fjernes.
Sikre at prosedyrer som kalles opp via plipkall ikke skaper tregheter
For beste ytelse er alle prosedyrene som benyttes via plipkall fra webklientene optimalisert slik at alle aktive transaksjoner og andre bindinger til webklientene termineres når prosedyrekallene er avsluttet.
Opprydding i filko tabellen
Det kan skje at det blir liggende igjen poster i filko som aldri tømmes på normalt vis. Vanligst i testmiljøene, men kan også skje ved feil oppsett i Prod.
Mange slike feilposter i filko kan føre til at jobben Utlegg av data til fil kan ta vesentlig lenger tid enn nødvendig. Dette vil være en kronisk tilstand som bare blir verre.
For å unngå slike forsinkelser kan det være lurt å sette opp en automatjobb som rydder opp i dette. Denne kan for eksempel kjøres en gang i uken.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.2.0.0.12
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.12 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. |
...
Dokument status: Status colour Green title released
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.11 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". |
| 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. |
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.10 skal alltid POS levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
Bestilling | Behandling av varer merket "Ikke bestilling" i Bestillingsmodulen (RTC-31342)
|
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. |
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.09 skal alltid POS levere bonger i POSLog versjon 81.
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.08 skal alltid POS levere bonger 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. |
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:
|
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.
|
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.07 skal alltid POS levere bonger 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. |
| 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. |
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.06 skal alltid POS levere bonger 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. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.2.0.0.05 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Etiketter fra varekø | Skrive varekøetiketter fra InStore App (RTC-26686) Det er støtte for å skrive ut etiketter, fra varekø i Chain Classic, direktete fra InStore App. De som kan skrives ut vises også i "Varekøliste" med etikettflagg = "Nei", og betyr at det ikke er skrevet ut. |
| RIGAL | Mixmatch og kampanjegruppe sendes alltid med referanse via RIGAL (RTC-28418) Kampanjehode og mixmatchhode må ha referanse til tilbudsvarene. Kundespesifikke oppsett gir forskjellige løsninger på dette. På den ene siden kan kampanjegruppnr og/eller mixmatchnr brukes, hvis disse numrene ikke er i bruk gjelder "Kampanje-ID" og "ekstern mix ID". Utleggene skjer i RIGAL-filer for kampanjegruppe (J) og mixmatch (X). |
| Vareinformasjon | Vareinformasjonstekst (RTC-27650) Når det gjelder beskrivelse av vare i vareinformasjonstekst, er det ingen begrensning i tekstlengde. |
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.04 anbefales det at POS leverer bong-format i POSLog versjon 81.
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. |
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.03 anbefales det at POS leverer bong-format i POSLog versjon 81.
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". |
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.02 anbefales det at POS leverer bong-format i POSLog versjon 81.
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Ved oppgradering til Chain Classic versjon 2.2.0.0.01 anbefales det at POS leverer bong-format i POSLog versjon 81.
...