Chain Classic versjon 2.1.1.0.46
| Status | ||||||
|---|---|---|---|---|---|---|
|
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.46 skal POS alltid levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Bestilling | Behold fokus/merknad på aktuell varelinje i bestilling (RTC-48363) Når bestilling opprettes, forventes en gjennomgang av varelinjene for kontroll av antall bestilte varer før godkjenning. |
| Logging | Logging av ugyldig versjon av POSLog (RTC-45428) Dersom det sendes inn en POSLog med ugyldig versjon til Chain Classic, vil dette vises i loggen for POSLog-import. |
| Rapporter | Logging av innmelding og utmelding av priser (RTC-43630) Dersom det er behov for å finne ut hva/hvem som har utmeldt eller gjeninnmeldt en pris, finnes det en loggrapport for dette. I rapporten "Loggutskrift" velger man loggtype "31 Ut-/Innmelding av priser" og ønsket datointervall. Rapporter viser SoftPay-betalinger (RTC-45199) Når betalingstypen "SoftPay" brukes, vises dette i følgende rapporter:
Rabattårsak i logg for laveste pris siste 30 dager (RTC-46116) Når det er lagt inn rabattårsak på en tilbudspris, kan den unntas fra beregning av laveste pris siste 30 dager (LPS30D) for senere tilbudspriser. Rapport for tilbudssalg med rabattårsak (RTC-46147) Ved bruk av rabattårsak i tilbudspriser kan rapporten "Salgsstatistikk rabattårsak" benyttes til å vise omsetning pr tilbudspris. |
| Varemottak | Utlegg av ukjent vare til ERP etter automatisk godkjenning i varemottak (RTC-45218) Hvis automatisk godkjenning er i bruk ved varemottak fra InStore App (ISA) via POSLog, eksporteres komplett varemottak til ERP i RIGAL format. I tillegg må varen eksistere i Chain Classic dersom lager skal oppdateres. Ved manuelt varemottak vil en ukjent vare bli liggende ubehandlet inntil vareinformasjon blir oppdatert i vareregisteret. Varen kan da oppdateres mot lager og varemottaket avsluttes. Ved automatisk varemottak må den ukjente varen også behandles ved at mottaksposten "nullstilles" og legges ut i RIGAL I-fil med varetekst "Ukjent vare". |
Automatisk korrigering av LPS30D ved feil utpris fra RIGAL
Dersom det ved en feil blir sendt inn en alt for lav utpris, kan dette få uheldige konsekvenser når dette blir brukt som LPS30D for en annen tilbudspris på samme vare.
Det er derfor mulig å få korrigert dette automatisk via innsending av korrekt utpris via en ny RIGAL fil.
Vilkårene for dette er at det må i en ny parameter angis maksimal tidsgrense for når korrigeringen må sendes inn og oppdateres.
I tillegg må det i samme parameter være angitt en minimum %-vis økning av utpris.
Dersom begge disse vilkårene er oppfylt, vil den alt for lave utprisen merkes som ikke i bruk i prishistorikken, og vil ikke bli brukt i beregning av lps30d for nye tilbudspriser på samme vare.
| Expand | ||
|---|---|---|
| ||
|
Manuell korrigering av "feilskapt" laveste pris i prishistorikk
Ved bruk av funksjonalitet for laveste pris, kan det skje at noen skriver feil og starter en tilbudspris med altfor lav salgspris.
Denne lave tilbudsprisen vil være grunnlag for beregning av laveste pris for andre tilbudspriser på samme vare i de påfølgende 30 dagene.
Brukere med tilgang kan korrigere en slik feil ved å bruke programmet Korrigering av prishistorikk, som finnes under System>Administrative rutiner>Diverse hjelperutiner.
Når en post korrigeres, vil feltene for rabattårsak (endres til 99), bruker som utførte endringen og dato/tid fylles ut og farges gule, mens hele raden ellers farges grå.
Rabattårsak 99 betyr at "Ny utpris", i denne posten, ikke vil bli benyttet i beregning av laveste pris og vil derfor heller ikke vises i loggen for laveste pris.
| Expand | ||
|---|---|---|
| ||
|
Kunne se laveste pris og rabattårsak
Med "Laveste pris seneste 30 dager" og tilhørende "Rabattårsaker" påslått, vil det vises egne kolonner for disse verdiene.
Gjeldende verdier vil vises for varekøposter for tilbudspriser i:
- "Varevedlikehold" på fanen "Pris"
- "Prisvedlikehold" på fanen "Prisvedlikehold"
I programmet "Butikkrutiner" (kun for butikkbrukere) er det litt annerledes.
Her vises "Laveste pris seneste 30 dager" og tilhørende "Rabattårsak" (nummer og tekst) for tilbudspriser for både aktive og siste avsluttende tilbudspriser.
Det er derfor lagt til 4 nye kolonner i dette programmet.
Etter "Kampanjepris" vises:
- "Laveste pris (K)" for kampanjepris
- "Rabattårsak (K)" for kampanjepris
Etter "Medlemstilbud" vises:
- "Laveste pris (M)" for medlemstilbud
- "Rabattårsak (M)" for medlemstilbud
| Expand | ||
|---|---|---|
| ||
|
Bruk av opprinnelig laveste pris ved forlengelse av profiltilbud
Hvis et profiltilbud skal forlenges, må opprinnelig LPS30D (laveste pris siste 30 dager) beholdes fordi grunnlaget for det nye tilbudet er den samme.
Det er parameterstyrt når det nye tilbudet seinest må starte i forhold til når det opprinnelige tilbudet ble avsluttet.
Vilkår:
- Opprinnelig profiltilbud kan være både kampanjepris eller medlemstilbud.
- Nytt, forlenget tilbud kan være kampanjepris og/eller medlemstilbud.
- Nytt tilbud kan legges opp på opprinnelig profilpris eller på butikkpris på samme profil.
- For nytt tilbud skapt via RIGAL gjelder samme regler som ovenfor.
| Expand | ||
|---|---|---|
| ||
|
Legg ut laveste pris = ? (ukjent verdi) når denne ikke skal benyttes i POS
Dersom POS ikke skal benytte LPS30D som legges ut fra Chain Classic, vil feltet settes til ? (ukjent verdi) i filformatene som benyttes.
Da vil POS beregne rabatter ift. gjeldende ordinære pris.
Kryptert E-postløsning i Cloud
Dersom kryptering av E-post i Cloud skal benyttes, ved sending av EOD-rapporter og meldinger via kundeordre, kan ikke standard løsning via SMTP brukes.
I stedet sendes meldinger med vedlegg via web service (WS) til POS Services og derfra til E-postløsningen i Cloud (MDS).
| Expand | ||
|---|---|---|
| ||
|
Send oppgjørsrapporter i Excel-format som vedlegg, i E-post
PDF-formatet har alltid vært brukt når oppgjørsrapporter settes opp for å sendes på e-post via EOD-rutinen.
Dersom EOD-rapportene sendes via web service (kryptert E-postløsning i Cloud), og "Send Epost" er valgt, er det mulig å velge mellom tre forskjellige oppsett for formater i vedlegg:
- Kun PDF (standard)
- Både PDF og Excel
- Kun Excel
Når e-post skal sendes fra kundeordre via web service må feltene "Emne" og "Melding" alltid fylles ut.
Det er derfor lagt opp parameterstyrte standardtekster for dette. Disse tekstene kan tilpasses dersom det er behov for det.
| Expand | ||
|---|---|---|
| ||
|
Sletting av lokale butikkpriser etter lokale tilbud
Ved bruk av funksjonalitet for sletting av lokale butikkpriser etter avsluttet lokal kampanjepris eller medlemstilbud, gjelder følgende:
- Funksjonaliteten benyttes fordi det er ønsket at butikkene primært skal bruke profilpris.
- Tilbudspris som skapes for butikk, vil alltid få en slettepost i varekø som sletter den lokale prisen etter at tilbudsperioden er avsluttet.
- Sletteposten vil alltid ligge bak den lengstvarende tilbudsprisen for butikkprisen
| Expand | ||
|---|---|---|
| ||
|
Forhindre at ugyldige MVA-grupper kan skapes ved RIGAL-oppdatering
Ny MVA-gruppe skapes dersom en ny verdi sendes inn.
Det sjekkes om ny verdi er gyldig og om det finnes ledig MVA-gruppe innen de 9 gyldige verdiene. Det sjekkes på:
- MVA-satser over 99 % ignoreres
- Det er kun plass til 9 MVA-grupper i registeret. Deretter må evt. manuelt vedlikehold benyttes, for å tilpasse til ønsket behov.
...
Chain Classic versjon 2.1.1.0.45
| Status | ||||||
|---|---|---|---|---|---|---|
|
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.45 skal POS alltid levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Lager | Lageroppdatering av bestilt pakkevare (RTC-40732) Pakkevarer inneholder ofte mer enn én vare. |
| Lageroversikt | Lagerlogg viser alle endringer på lager i "Lageroversikt" (RTC-40438) I programmet "Lageroversikt" kan alle endringer på lager sjekkes for valgt butikk under knappen Lagerlogg. |
| Vare | Tandem for varianter på modellvare med samme farge (RTC-40558) Ved bruk av kun en hovedvare for kombinasjonen modell/farge, har kun tandemnummer på hovedvaren vært synlig på fanen for tandem. |
| Varemottak | Utvidet logging ved manuelt varemottak (RTC-37621) Ved et manuelt varemottak som ikke kobles til en allerede eksisterende bestilling/varemottak, vil det kun logges "Manuell" i Transtekst feltet i tilhørende varetransaksjonspost. |
| Varetransaksjoner | Oppdatering av varetransaksjoner på reseptvarer og butikkvarer i samme POSLog (RTC-43995) Det er mulig å oppdatere varetransaksjoner på både reseptvarer og på vanlige butikkvarer i samme POSLog. Forskjellen er at varetransaksjonspostene oppdateres på butikkvaren, mens det for en reseptvare skapes varetransaksjoner på råvarene som ingrediensene i reseptvaren er skapt fra. |
| Webordre | Sikre unikt jobbnummer når plukkliste skapes for en webordre (RTC-41864) Når Plukkliste skal skrives for en webordre, behøves et unikt jobbnummer. Dette hentes fra en teller i Chain Classic. |
Laveste pris siste 30 dager
(RTC-40443, RTC-41092, RTC-41093, RTC-41714, RTC-42197)
Laveste pris siste 30 dager (LPS30D) er en funksjonalitet laget for å vise kundene i butikken hva den laveste salgsprisen har vært de seineste 30 dagene. Denne beregnes av alle pristyper uavhengig av hvordan prisendringen ble skapt, av ny pris, tilbudspris eller ordinær prisendring. Alle varianter kan inngå i beregningen av periodens laveste pris.
...
Åpne kampanjegruppe på vare fra Prisvedlikehold
Kampanjegruppe kan åpnes direkte fra Prisendring for tilbudspriser som er skapt i en kampanjegruppe. Velg varekøposten for kampanjen og knappen "Kampanjegruppe" blir aktiv. Knappen er en snarvei til å åpne opp Kampanjegruppe vedlikehold på varekøpostens kampanjegruppe.
Godkjenning av priser i "Priskontroll"
...
| Expand | ||
|---|---|---|
| ||
|
Ikke vis varer som mangler både profilpris og butikkpris
...
| Expand | ||
|---|---|---|
| ||
|
Utlegg av drivstoffendringer til Reporting
Ved endringer av gamle verdier i vedlikeholdsprogrammene for "Fylling", "Tankstatus" og "Manuell tankstatus", eller ved utlegg av gamle poster via "Data til Reporting", vil dette kunne føre til omfattende rekalkuleringsjobber i Reporting.
For å unngå at det oversendes for mye data, bør det derfor settes opp hvor mange dager tilbake i tid det skal være mulig å legge ut til Reporting
| Expand | ||
|---|---|---|
| ||
|
Lage grunnlaget for massesletting av varer
...
Behandling av pakkevarer i bestilling
En pakkevare består gjerne av flere varer eller antall > 1 av varen som inngår.
Ved bestilling er det mulig å bestille kun pakkevaren.
Både ved bestilling og varemottak er det lager for innholdsvarene som oppdateres
Pakkevarene er ikke lagerstyrt.
| Expand | ||
|---|---|---|
| ||
|
Overstyring av faste dager for bestillingsforslag
Ved bruk av bestillingsforslag er det mulig å parameterstyre genereringen av bestillingsforslag til én fast ukedag pr. butikk.
Dette kan overstyres manuelt i programmet slik at alle butikker, uansett ukedag, skal behandles samtidig.
Det er også mulig å legge opp en EOD-jobb for dette dersom det er behov for å generere bestillingsforslag for butikker en fast gang pr. uke.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av RIGAL-VPI til butikk
...
I "Klargjøre vare" vil det ved valg av kun "RIGAL VPI", legges ut RIGAL V-fil og D-fil til valgt butikk.
Innhold i V-fil vil være alle varer innenfor utvalg, med lokale butikkpriser der disse eksisterer, mens det for øvrige varer brukes profilpris.
D-fil vil inneholde alle varer med tilgjengelig profil "vareinformasjon". Der det finnes butikkspesifikk vareinformasjon vil denne bli brukes.
Dersom valget "Kun butikkpriser" legges til, vil de samme filformatene som ovenfor bli skapt, men kun inneholde varer med lokal butikkpris for valgt butikk.
Dette innebærer at ingen varer med kun profilpriser vil eksporteres.
Butikkspesifikk vareinformasjon på varer med kun profilpris vil heller ikke bli lagt ut.
Dette vil kun skje ved generelt RIGAL VPI-utlegg på hele profilen.
...
Chain Classic versjon 2.1.1.0.44
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.44 skal POS alltid levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Elektroniske etiketter | Utlegg til elektroniske etiketter ved forlengelse av tilbudspriser (RTC-39381) Ved forlengelse av en tilbudspris (kampanjepriser eller medlemstilbud), ny sluttdato på aktivt tilbud, skal det alltid legges ut oppdaterte poster med tilbudspriser til Lexmark. Elektroniske etikettløsninger derimot behøver ikke denne oppdatering da disse får egne utlegg når tilbudsprisen avsluttes. |
| Kampanjegruppe | Kopiering av kampanjegruppe for "Team" (RTC-39969) Når en team-kampanjegruppe kopieres, er det mulig å kopiere denne til en kampanjegruppe for butikk eller profil. |
RIGAL | Framtidig prisendring og utmeldt vare (RTC-39744) Dersom en vare meldes ut via RIGAL, settes sortimentkode til "Utmeldt" og bestillingsnummer nullstilles på pris. Det lages også en slettepost med parameterstyrt slettedato X dager fram i tid. Dersom det etter dette kommer nye eller framtidige prisendringer for samme vare, vil dato for slettepost flyttes fram i tid i forhold til den nye prisendringsdatoen, mens sortimentskode "Utmeldt" og nullstilt bestillingsnummer beholdes. |
| Tankstatus | Registrering av flere tankstatus poster på samme dag (RTC-39257) Det er mulig å registrere flere tankstatuser på dagens dato, så lenge de registrerte målingene har et unikt tidspunkt. |
...
| Expand | ||
|---|---|---|
| ||
|
Kontroll mot SAP om slettepost for vare skal kjøres eller ikke
...
Det kan settes opp en jobb som hver natt kontrollerer, mot SAP, om aktive sletteposter i varekø skal behandles eller ikke.
Dersom SAP har informasjon om at vare fortsatt finnes i lager, vil slettedatoen flyttes X antall dager fram i tid, for ny kontroll senere.
...
| Expand | ||
|---|---|---|
| ||
|
Administration av kasserer og kunde kun i Chain Classic
Når kunde eller kasserer skapes/endres er det normalt å legge ut dette til POS. Men benyttes 3.parts POS-løsning (f.eks. Tokheim POS), kan det være ønskelig at dette ikke skjer.
Da er det mulig å parameterstyre dette slik at unødvendige køposter fjernes automatisk.
| Expand | ||
|---|---|---|
| ||
|
Oppdatering av ny vare fra Item Master
Ved oppdatering av ny vare i Chain Classic fra RIGAL er det nødvendig at både vare- og prisinformasjonen er levert fra Item Master.
Når begge postene er på plass i "VPI Vedlikehold" slås de sammen og en ny vare med pris skapes i Chain Classic.
Også rekkefølgen er viktig, for ny vare må, varepost komme inn før prispost. Kommer prispost først, vil prisposten forkastes da det ikke finnes noen vare å koble den til.
I dette tilfelle vil en etterfølgende varepost bli liggende til en ny prispost kommer slik at ny vare kan skapes.
Oppdatering av veidkost ved varemottak av ny vare på eksisterende profilkampanje
...
| Expand | ||
|---|---|---|
| ||
|
Logging av webservice
...
| Expand | ||
|---|---|---|
| ||
|
Vedlikehold av bestillingsrader i elektronisk varemottak
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.43 skal POS alltid levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Elektronisk varemottak | Varesøk i elektronisk varemottak (RTC-38982) Dersom det oppleves problemer med standard varesøk i ordre i elektronisk varemottak, prøv da følgende rutine:
|
| EOD-rapport | Melding når E-post feiler i EOD-Rapport (RTC-36556) Dersom melding ikke kan leveres når EOD-rapport (som også skal sendes som E-post) skapes (nettverksproblemer eller annet problem), vil dette logges direkte i Status feltet i Rapportlisten.
|
| 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. |
...
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"
...
| Expand | ||
|---|---|---|
| ||
|
Prisimport via resultat-fil fra "Sortimentliste Excel"
...
| Expand | ||
|---|---|---|
| ||
|
...
| 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"
...
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
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.42 skal alltid POS levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Kasserer | Antall siffer for kasserernummer (RTC-34270) Kasserernummer kan ha inntil 9 siffer i Chain Classic. |
| Nettleser | Nettleser i Chain Classic (RTC-35855) Knapper som åpner nettleseren i Chain Classic vil alltid benytte Microsoft Edge. |
Logging av "Bestillingsfordeling Excel"
...
| Expand | ||
|---|---|---|
| ||
|
Etikettutskrift fra InStore App
Ved utskrift av etikett fra InStore App er det mulig å parameterstyre om kriterier for varesalg, lagerbeholdning eller bestilling skal benyttes for å begrense antall etiketter som lages.
| Expand | ||
|---|---|---|
| ||
|
Veid kostpris skal alltid brukes som nettopris for alle priser i POS
...
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.41
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.41 skal alltid POS levere bonger i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Bestilling | Lagring av varelinje i vedlikehold av Bestilling (RTC-35375) Lagring av ny/endret varelinje er optimalisert for forbedret ytelse når mange brukere jobber med dette samtidig |
| Bestilling/Varemottak | Antall varelinjer i bestilling og varemottak (RTC-35812) Det er mulig å bruke 5 sifret antall varelinjer i både bestilling og varemottak. Dette betyr at det kan være > 1000 varelinjer i en og samme ordre når neste tildelte radnr økes med 10. |
| Kampanjegruppe | Melding på skjerm når importerte varer sammenfaller i ulike kampanjegrupper (RTC-35734) Når to kampanjegrupper har samme start dato/tid eller slutt dato/tid og inneholder samme varer, avvises varene i den andre kampanjegruppen fordi de er sammenfallende. Meldinger om dette vil vises på skjermen. Dette gjelder også ved bruk av knappen "Hent nye varer". |
| 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. |
Sortimentliste Excel
Rapporten "Sortimentliste Excel" tilbyr tre forskjellige, parameterstyrte, alternativer med 39, 53 eller 58 kolonner/felt i Excel rapporten.
De samme formatene kan også brukes til oppdatering/nyopplegg av varer ved import av VPI fra Excel.
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
Oppdatering av salg og varetransaksjoner på reseptvarer ved bruk av Servicehandel
...
| Expand | ||
|---|---|---|
| ||
|
Åpningsfane i "Priskontroll"
...
| Expand | ||
|---|---|---|
| ||
|
Når Excel og Word ikke kan startes fra Chain Classic
...
| Expand | ||
|---|---|---|
| ||
|
Finn frem eksisterende vare via tandem ved RIGAL VPI-import
Det anbefales å slå på full støtte for å søke frem eksisterende vare via tandemnummer når EAN for hovedvare i RIGAL VPI er ukjent i Chain Classic.
Dette vil forhindre at det skapes dubletter av samme vare. Eksempler på dette er:
...
| Expand | ||
|---|---|---|
| ||
|
Logging ved utlegg av bestillinger til RIGAL
Endringer som fører til utlegg av bestillinger til RIGAL, logges for enklere oppfølging.
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
Utlegg av "utsalgspris" til Tokheim POS for gruppe 1 i mixmatchtype 35
...
| Expand | ||
|---|---|---|
| ||
|
Bruk av kostpris i "Bestillingsfordeling Excel"
...
Ny godkjenning og utlegg av kampanjegruppe til POS
Hjelpeprogram til bruk for EG personell.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.40
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.40 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
Bestilling | Behandling av varer merket "Ikke bestilling" i Bestillingsmodulen (RTC-31342)
|
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. |
...
Funksjonalitet for utskrift av små rabattprislapper finnes i "Butikkrutiner", "Varevedlikehold" og "Prisvedlikehold". Knappen vises alltid i "Butikkrutiner" men må spesifikt velges for bruk i de andre to vedlikeholdsprogrammene.
Det kan parameterstyres om det kun skal være mulig å angi prosentrabatt eller om det i tillegg skal være mulig å velge mellom kronerabatt eller rabattert pris.
Det er uansett kun mulig å angi to siffer. Angitt verdi skrives da ut under strekkoden i markert felt nedenfor (2 siffer).
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
Forbedringer i standard priskontroll
...
| Expand | ||
|---|---|---|
| ||
|
Varehierarkiliste for "Cloud-eksport"
...
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.39
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.39 anbefales det at POS leverer bong-format i POSLog versjon 81.
Utlegg til Lexmark ved endring av EAN/PLU
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.38 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
Kampanjegruppe | Sletting av hel mixmatch i kampanjegruppe (RTC-32186) Det er mulig å slette en komplett mixmatch i kampanjegruppe. Det blir da gjort et utlegg til POS av kun en post for sletting av mixhode. |
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.
|
...
Utlegg av resepter/ingredienser til Tokheim POS
Det er mulig å parameterstyre om resept-/ingrediensinformasjon skal legges ut til Tokheim POS.
Standard er at informasjonen legges ut, men dersom dette ikke er ønskelig kan dette endres via en systemparameter.
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | |||||||
|---|---|---|---|---|---|---|---|
| |||||||
|
...
Innholdet i Excel filen skal bestå av følgende felt, hvorav de i blått kan endres:
- Butikknr
- EAN
- Varetekst
- Farge
- Bestillingspunkt
- Bestillingskvantum
- Sletting (0 = Nei / 1 = Ja)
- EAN tekstfelt (Eks. EAN1234567)
...
| Expand | ||
|---|---|---|
| ||
|
Tillat EAN = 0 i RIGAL prisendring
...
Oppdatering av pakkevarer i bestilling fra InStore App
Varemottak for pakkevare fra InStore App spesialbehandles ved oppdatering fra POSLog.
Ved mottak av pakkevaren vil det bli opprettet varetransaksjoner for varen(e) som inngår i pakkevaren,
Lager vil også bli oppdatert for disse varene.
| Expand | ||
|---|---|---|
| ||
|
Behandling av RIGAL I-filer med "0-ordrer"
Det kan parameterstyres om en RIGAL varemottaksfil (I-formatet) der alle vareradene har mottatt antall = 0, også skal behandles. Da vil ordren få status "Mottatt".
Det skapes en RIGAL "kvitteringsfil" som kopi av de opprinnelige RIGAL postene.
| Expand | ||
|---|---|---|
| ||
|
Endring i eksport av tankstatus til Reporting
...
| Expand | ||
|---|---|---|
| ||
|
Standardisering av datotype i rapportutvalg
...
Ved nyopplegg av kampanje- og medlemstilbud er det parameterstyrt om det er tillatt med delvis overlapping.
Dersom dette ikke er tillatt eller det er lagt inn en ugyldig verdi med samme start-/sluttid, forklares dette med informative feilmeldinger i brukergrensesnittet dersom varene avvises.
Dette gjelder både i Kampanjegruppe og for manuelle kampanjer (skapt i Prisendring) uansett metode for innhenting av data.
I tillegg til feilmeldingen i brukergrensesnittet, kan loggpostene hentes opp via knappen "Avviste varer i kampanjegruppe".
Den samme knappen finnes også i programmet for "Mixmatch".
Finn og slett tandemnummer som også finnes som hovedvare
Tandemnummer som også finnes som hovedvare, er noe som må korrigeres.
Et hjelpeprogram kan korrigere dette ved å fjerne tandemnummeret i Chain Classic og legge ut sletting av tandem til POS.
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
Sletting av Chain Classic bruker
Ved sletting av bruker i Chain Classic slettes alle brukerrelaterte data.
| Expand | ||
|---|---|---|
| ||
|
Utlegg av sletteposter for butikklokale mixrader ved sletting av butikkpris
Når en butikkpris skal slettes, sjekkes det nå om det finnes noen aktive eller fremtidige lokale butikkmix'er der denne varen inngår.
Om det er tilfelle, vil det legges ut slettepost for disse postene til POS.
...
Chain Classic versjon 2.1.1.0.37
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.37 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Lexmark | Lexmark oppdatering når tilbud = ordinærpris (RTC-29650) I situasjonen der kampanjepris/medlemstilbud = normalpris og normalpris økes i tilbudsperioden vil dette ikke trigge etikett. |
| 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. |
Overgang til kampanjegruppeutlegg
...
| Expand | ||
|---|---|---|
| ||
|
Sletting av lokale butikkpriser
...
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic versjon 2.1.1.0.36
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.36 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Etikett | Etikett skrives ikke uten endring av utpris (RTC-29332) Hvis ny kampanjepris er lik utpris eller hvis kampanjenettopris, men ikke utpris, endres på aktiv kampanje da skrives det ikke etikett ved noen av disse tilfellene. |
| Kampanjegruppe | Sletting av mixmatch fra ikke godkjent kampanjegruppe (RTC-29477) Ved opplegg av ny kampanjegruppe med flere mixmatcher kan bruker slette både en og flere mixmatcher før selve kampanjegruppen godkjennes. Samme vare i multiple michmatcher i samme kampanjegruppe (RTC-27651) Det er mulig å ha flere mixmatcher, med samme vare, i en kampanjegruppe, uten risiko for komplikasjoner grunnet identisk start- og/eller sluttdato. |
| Mixmatch | Innhenting av nye varer i allerede godkjent mixmatch (RTC-29815) I manuell mixmatch eller mixmatch i kampanjegruppe kan innhenting av nye varer gjøres på flere måter. Uansett metode vil både automatisk og manuell godkjenning/lagring lage varekøposter med samme butikknummer som er gjeldende i nevnte tilbudstyper. |
| Rapporter | Antall solgte varer i grafisk varegruppesalgsrapport (RTC-29486) Ved bruk av grafisk varegruppesalgsrapport kan det åpnes et vindu for "Fordeling pr. butikk". Generelt vil denne "pop-up" ha en kolonne for antall, men i tabeller for varegruppe- og undergruppesalg gir det ikke mening å lagre antall (av uidentifiserte varer). For å unnvike misforståelse ekskluderer disse salgsrapportene kolonne "Antall", i stedet for å vise verdi 0 for alle poster. |
| Varemottak | Utskrift av prislapper i varemottak (RTC-28791) Ved bruk av parameterstyrt spesialløsning for varemottak (ikke standardløsningen el. varemottak), er det mulig å skrive ut etiketter via knappene "Prislapp" og "Prislapp lager". Funksjonen gir prislapper for nye varer og i programmet utførte prisendringer på både eksisterende og nye varer. Oppdatering av nettopris i eksisterende el. varemottak ved manuelt varemottak (RTC-28081) Hvis det oppdages en vare med feil nettopris i elektronisk varemottak, kan dette korrigeres ved å lage et manuelt varemottak og sette riktig kostpris på varen der. Det lages da en varetransaksjonspost som har riktig verdi og lager oppdateres. Hvis man, som riktig er i dette tilfelle, velger å oppdatere mot eksisterende ordre da blir tilsvarende ordrelinje i elektronisk varemottak oppdater med ny verdi på nettopris og også data i ordrehode blir rekalkulert i forhold til ny verdi fra manuelt varemottak. |
...
Betale gavekort med annet gavekort og/eller tilgodelapp
Hvis gavekort og/eller tilgodelapp brukes for å betale et nytt gavekort lages en egen finanstransaksjon for dette.
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
Rulle tilbake tellesvinntransaksjoner ved nullstilling av salgsdag
...
| Expand | ||
|---|---|---|
| ||
|
Endre nettopris direkte i elektronisk varemottak
I "Elektronisk varemottak" er det som standard ikke mulig å endre nettopris, slik det er i det spesialtilpassede programmet "Varemottak". Men det er mulig å parameterstyre "El. varemottak" slik at nettopris kan redigeres direkte i programmet uten å bruke "Manuelt varemottak".
| Expand | |||||||
|---|---|---|---|---|---|---|---|
| |||||||
|
...
| Expand | ||
|---|---|---|
| ||
|
Feil butikknummer i POSLog
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.35 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Etiketter fra varekø | Skrive varekøetiketter fra InStore App (RTC-26686) Det er støtte for å skrive ut etiketter, fra varekø i Chain Classic, direktete fra InStore App. De som kan skrives ut vises også i "Varekøliste" med etikettflagg = "Nei", og betyr at det ikke er skrevet ut. |
| RIGAL | Mixmatch og kampanjegruppe sendes alltid med referanse via RIGAL (RTC-28418) Kampanjehode og mixmatchhode må ha referanse til tilbudsvarene. Kundespesifikke oppsett gir forskjellige løsninger på dette. På den ene siden kan kampanjegruppnr og/eller mixmatchnr brukes, hvis disse numrene ikke er i bruk gjelder "Kampanje-ID" og "ekstern mix ID". Utleggene skjer i RIGAL-filer for kampanjegruppe (J) og mixmatch (X). |
| Vareinformasjon | Vareinformasjonstekst (RTC-27650) Når det gjelder beskrivelse av vare i vareinformasjonstekst, er det ingen begrensning i tekstlengde. |
Logging av endringer i kundeordrer
...
Logging gjelder både hvis det er gjort via InStore App og direkte i Chain Classic. Ved tilfelle hvor det gjøres i Chain Classic skrives det "CC CLIENT" slik at det fremgår hvor denne transaksjon er skapt.
| Expand | ||
|---|---|---|
| ||
|
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.34 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Etikett | Bestill etikettutskrift med forskjellige etikettyper (RTC-27262) Det er mulig å bestille og skrive ut etiketter med forskjellige etikettyper i samme etikettbestilling fra InStore App. |
| Lager | Utlegg av lagerfil til Chain Web (RTC-27548) Ved utlegg av lagerfil til Chain Web fra Chain Classic vil alltid tidligere eksportert fil, "StockBasis.butnr", skrives over, hvis den ikke er hentet opp. Optimalisering av utlegg ved lagerendring (RTC-27423) Generelt legges ikke lagerendringer ut til POS, dette skal kun skje ved endring av pris eller veidkost. Varemottak er derfor eneste grunn for filutlegg, med lagerendringer, til POS og evt. annen 3.part. |
| Rapporter | Leveringsdato i rapporten "Grunnlag bestilling" (RTC-27033) Når spesialfunksjonalitet for å vise leveringsdato i "Bestilling" er i bruk, viser dette leveringsdato på ordre linje i rapporten "Grunnlag bestilling". |
| RIGAL | Utlegg av leverandørordre-ID etter varemottak (RTC-27182) Leverandørordre-ID er et felt som ikke vises i Chain Classic men som kan benyttes når leverandør sender inn varemottak via RIGAL I-fil. Når varemottak er godkjent legges leverandør-ID ut i RIGAL I-formatet, dette gjelder uansett om varemottak gjøres i InStore App eller i Chain Classic. RIGAL V-fil og kampanjegruppedata (RTC-27899) Ved utlegg av RIGAL V-fil, fra "Klargjøre vare", legges det ut kampanjegruppeinfo for kampanjegruppenummer, kampanje-ID, navn på kampanjegruppe tilhørende formatene "K" (kampanjevare) og "M" (Medlemstilbud). I tillegg legges det ut RIGAL J-fil med tilsvarende informasjon. |
Oppdatering av ordinærpris i kampanjegruppe
I kampanjegruppe finnes mulighet for å bruke funksjonalitet for å angi fast kr- eller %rabatt på varelinje i både kampanje eller medlemstilbud. Ved endring av ordinærpris i "Priskalkyl", rekalkuleres tilbudspris også i kampanjegruppe og endring til POS legges ut via det utleggsalternativ som brukes, kampgr eller prisfil.
| Expand | ||
|---|---|---|
| ||
|
...
Strekkoder i lagerrapport "Feilliste"
Det er mulig å skrive ut strekkode på varene i lagerrapporten "Feilliste". Dette gjøres som standard kun for varer med negative lagerantall, men det er også mulig å sette opp "Skriv strekkode" som standard. Noe som må til hvis man tar ut denne rapporten ved EOD.
| Expand | ||
|---|---|---|
| ||
|
Avskriv uleverte rader ved første varemottak
...
Inventory Module er en cloud modul som er lager-master. Chain Classic legger ut komplett lagerfil i JSON-format til egen katalog for videre bruk i Inventory Module. Viktig at "Eksport av lager til Inventory" er avhuket.
| Expand | ||
|---|---|---|
| ||
|
...
Dokument status:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Dato:
Forutsetninger for oppgradering
Med oppgradering til Chain Classic versjon 2.1.1.0.33 anbefales det at POS leverer bong-format i POSLog versjon 81.
Forbedringer
Modul | Beskrivelse |
|---|---|
| Bestilling | Butikk uten "Bestilling" (RTC-19163) Det anbefales at alle butikker har "Bestilling" påslått i butikkregisteret. Men fra patch 32 bør det sjekkes at butikker som ikke har bestilling, da faktisk ikke har "Bestilling" valgt i butikkregisteret. Dette for å sikre at bestillinger ikke lages, på disse butikkene, via automatikk ved for eksempel Kundeordre og Varemottak fra POS eller InStore App. |
| Lexmark integrasjon | Utlegg av tilbudsposter til Lexmark (RTC-26601) Utlegg av kampanje- og medlemstilbudsposter til 3. partssystemet Lexmark er begrenset til kun de de som er nødvendige for Lexmark sin funksjonalitet, der finnes ikke samme behov som ved tilsvarende utlegg til POS. |
| Rapporter | Utvalg i rapporten "Nonsalerapport pr. nonsaletype" (RTC-26418) Ved bestilling av rapporten "Nonsalerapport pr. nonsaletype" er det mulig å sette opp forskjellige utvalg, for eksempel varegruppe. |
| RIGAL | RIGAL-oppdatering av "Fastpris" (RTC-26656) Flagget "Fastpris" oppdateres via RIGAL-fil. Verdiene F, "P eller Y setter fastprisflagget aktivt. Alle andre bokstaver deaktiviserer fastpris. Hvis verdi mangler, skjer ingen forandring av "Fastpris". |
...
| Expand | ||
|---|---|---|
| ||
|
Logging av kundeendringer
...
| Expand | ||
|---|---|---|
| ||
|
Provisjonssalg - butikk i butikk
Provisjonssalg etter provisjonsvareliste, i eget vedlikeholdsprogram, legges ut til EG Cash Settlement etter hver EOD. Det er kun mulig å legge opp og bruke én provisjonsvareliste pr. butikk.
| Expand | ||
|---|---|---|
| ||
|
"Slette/fjerne fra kasse" logger leverandør i rapport
Ved bruk av programmet "Slette/fjerne fra kasse" vil leverandørnr og leverandørnavn også vises i alle rapporter som lages, uansett utvalg.
Forhindre mixmatchkonflikt
...
| Expand | ||
|---|---|---|
| ||
|
Forventet dato i "Bestillingsfordeling Excel"
Ved bruk av "Bestillingsfordeling Excel" kan bruker velge å opprette enten bestillinger eller varemottak. I begge disse tilfellene settes forventet leveringsdato uten verdi i programmet "Bestilling".
| Expand | ||
|---|---|---|
| ||
|
Sortimentsliste Excel
Rapporten "Sortimentsliste Excel" kan lages med standard 39 kolonner eller via parameterstyring med utvidet format, alle 53 kolonnene.
| Expand | ||
|---|---|---|
| ||
|
Hvem er "sjef" for mixmatch
...
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"
...
| 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 | ||
|---|---|---|
| ||
|
Mixmatch med varer som mangler i vareregisteret
...
| Expand | ||
|---|---|---|
| ||
|
Innlesing av JSON-fil fra StoreMaster
...
- Adresse
- Åpnet dato
- E-post
- Lagerstyrt
- Mobilnr
- EAN-lokasjonsnr
- Andre butikker med lager som denne butikken kan se.
| 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 | ||
|---|---|---|
| ||
|
...
| 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.
...
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
...
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
...
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
...
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"
...
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
...
| Expand | ||
|---|---|---|
| ||
|
Slett ikke-aktiv butikk
...
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. |
...
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
...
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.
| Info |
|---|
Merk: engrospris MÅ skrives med punktum, for eksempel 3.44, hvis kommategn brukes blir ny engrospris 344. |
Innlesing av denne filen kan enten gjøres manuelt via program: "System"/"Administrative rutiner"/"Diverse hjelperutiner"/"Oppdatering av engrospris", eller ved å sette opp en jobb for EOD-kjøring.
| 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
...
- 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
...
| 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 | ||
|---|---|---|
| ||
|
...
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. |
...
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".
Del 2 av parameteren tas i bruk når kobling av kunder til S-lagsnr/medlemsnr skal fjernes. Dette skjer via skript hvor det kan velges om utlegg umiddelbart skal gjøres til POS eller ikke, samtidig fjernes felt for S-lagnr/medlemsnr i "Kundevedlikehold".
| Expand | ||
|---|---|---|
| ||
|
...
| Expand | ||
|---|---|---|
| ||
|
Grunnlag etikett i "Varekølista"
...
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
...
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:
- eSale_NT - Spillvare fra Norsk Tipping.
- eSale_Goyoda - Elektronisk produkt fra Goyada, alternativt eSale_MBXP - elektronisk produkt fra MBXP.
- MBXPwebsale - MBXP webhandelsprodukt.
...
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
...
Det betyr at det returneres data selv om det ikke er gjort varemottak på varen, slik at man fortsatt får informasjon om for eksempel "bestillingstype" i InStore App.
| Info |
|---|
Det logges fortsatt hvis det ikke finnes noe varemottak for vare/butikk, men InStore App får uansett svar på verdier som finnes. |
...
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"
...
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. |
...
- Totalt antall kontrollerte bonger.
- Antall godkjente kontroller, samt godkjenningsprosent av totalt antall kontroller.
| Info |
|---|
For denne loggingen MÅ POSLog 81 brukes! |
| 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 | ||
|---|---|---|
| ||
|
...
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:
- Oppsatt funksjonalitet gjelder for alle eksisterende aktive og fremtidige prisendringer (prisendring, kampanjepriser og medlemstilbud) som allerede ligger skapte i varekøene. For utvalgte felt hentes da verdi fra "Pris" og for ikke utvalgte felt blir opprinnelig verdi liggende igjen.
- Dette gjelder også ved kopiering av gammel kampanjegruppe. For utvalgte felt hentes da verdi fra "Pris" og for ikke utvalgte felt hentes verdi fra gammel kampanjegruppe.
| Info |
|---|
Vær oppmerksom på at denne funksjonaliteten vil belaste systemet betraktelig, med lavere ytelse som følge av dette, når ALLE køposter av type 5, 6, 7 og 8 må sjekkes på angitte felter hver gang varekøbehandling kjøres. |
| 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
...
| 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.
...
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.
...
| 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 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.
...
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.
...