Chain Classic version 2.1.1.0.45
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.45 ska alltid POS leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Lager | Lageruppdatering av beställd paketvara (RTC-40732) Paketvaror innehåller ofta mer än en vara. |
Lageröversikt | Lagerloggen visar alla ändringar på lager i "Lageröversikt" (RTC-40438) I programmet "Lageröversikt" kan alla ändringar på lager kontrolleras i vald butik under knappen Lagerlogg. |
Varor | Tandem för varianter på modellvara med samma färg (RTC-40558) Vid användning av endast en huvudvara med kombinationen modell/färg, har bara tandemnummer på huvudvaran synts i fliken för tandem. |
Varumottagning | Utökad loggning vid manuell varumottagning (RTC-37621) Vid en manuell varumottagning som inte kopplas till en redan existerande beställning/varumottagning, kommer det endast att loggas "Manuell" i Transtext-fältet i tillhörande varutransaktionspost. |
Varutransaktioner | Uppdatering av varutransaktioner på receptvaror och butiksvaror i samma POSLog (RTC-43995) Det går uppdatera varutransaktioner på både receptvaror och på vanliga butiksvaror i samma POSLog. Skillnaden är att varutransaktionsposterna uppdateras på butiksvaran, medan det för en receptvara skapas varutransaktioner på råvarorna som ingredienserna i receptvaran skapats ifrån. |
Weborder | Säkerställa unikt jobbnummer när plocklista skapas för en weborder (RTC-41864) När Plocklista ska skrivas för en weborder, behövs ett unikt jobbnummer. Detta hämtas från ett löpnummer i Chain Classic. |
Lägsta pris senaste 30 dagar
(RTC-40443, RTC-41092, RTC-41093, RTC-41714, RTC-42197)
Lägsta pris senaste 30 dagar (LPS30D) är en funktionalitet som skapats för att visa kunderna i butiken vad det lägsta försäljningspriset har varit de senaste 30 dagarna. Detta beräknas av alla pristyper oberoende av hur prisändringarna skapades, av nytt pris, kampanjpris eller ordinarie prisändring. Alla varianter kan ingå i beräkningen av periodens lägsta pris.
Det är också LPS30D som ska användas när ett rabattbaserat kampanjpris beräknas av en angiven kr- eller %-rabatt.
Detta kan innebära att butiker med en lägre LPS30D än vad profilpriset har, kommer att få ett lägre kampanjpris jämfört med de andra butikerna.
Prisändringar som gör att LPS30D ändras till ett lägre värde, kommer att medföra en automatisk omberäkning av framtida, ej aktiva kronor- eller procentbaserade kampanjpriser.
Vid kopiering av kampanjpriser baserat på kronor- eller procentrabatt kommer gällande LPS30D att användas och försäljningspriset blir beräknat från detta.
För avslutade kampanjgrupper visas LPS30D som användes när kampanjen var aktiv.
Utlägg av LPS30D sker endast för kampanjpriser, och då till POS och 3:e-partssystemen Pricer, Breece och Lexmark.
I Chain Classic visas LPS30D för kampanjpriser i alla prisunderhållsprogram.
På en varurad i en profilkampanj kommer knappen "Butikslokala kampanjpriser" (nedan) att visa eventuella butiker som kommer att få ett lägre kampanjpris än profilkampanjen.
Knappen "Ändringar av lägsta pris" (nedan) är en god hjälp för att följa historiken för LPS30D-ändringar över tid. Utpriset i dessa prisloggposter visar vad nästa kampanjpris använder som LPS30D. Lägsta priskolumnen kommer alltid att vara 0 för prislogg-poster för nytt pris eller ordinarie prisändringar.
- För profilanvändrare visas alltid poster med profilpris.
- För butiksanvändare visas profilpris och eventuella prisloggposter för egen butik (se bild nedan).
- För teamanvändare visas profilpris och eventuella prisloggposter för team-butiker.
| Expand | ||
|---|---|---|
| ||
|
När kampanjpriser inte ska använda LPS30D eller ska beräknas på ordinare pris
(RTC-42538, RTC-43245, RTC-43249, RTC-44071, RTC-44075, RTC-44387)
Rabattorsaker kan användas för både manuella kampanjpriser skapade i Prisändring och priser i Kampanjgrupp. Dessa kan användas till att överstyra beräkning av allt för lågt LPS30D.
En kronor- eller procentrabatt baserat på kampanjpris beräknas då från ordinarie pris istället för LPS30D.
Dessutom går det för en given rabattorsak att undanta att ett kampanjpris ska ingå i beräkningen av LPS30D för ett annat kampanjpris. Detta är i överenstämmelse med myndighetskrav.
Programmet "VPI rabattorsaker" har gjorts för att enkelt kunna underhålla dessa val.
Vid utlägg av kampanjpriser till POS och 3:e-partslösningarna är rabattorsakerna alltid ifyllda. För ordinarie priser är fältet alltid 0.
Val av rabattorsaker på kampanjpriser i en kampanjgrupp kan ske på olika sätt:
- Skriv rabattorsaksnummer direkt i fältet för rabattorsak i varubrowsern.
- Genom att dubbelklicka i fältet för rabattorsak kommer dialogen "Välj rabattorsak" att öppnas (se nedan).
- Genom att dubbelklicka på annat fält på varuraden så kommer full priskalkyl att öppnas där rabattorsaken också kan ändras.
| Expand | ||
|---|---|---|
| ||
|
Softpay terminaltyp och korttyper
(RTC-44405, RTC-44745, RTC-44864)
Vid användning av SoftPay betalningsmedel, kommerl finanstransaktioner för alla korttyper som använts, att bli uppdaterade.
Detta förutsätter användning av en dedikerad lösning för näthandel.
Dessa finanstransaktioner:
- Uppdateras per kassa/kassör
- Läggs ut i RIGAL F-fil
- Visas i rapporten "Omsättning per korttyp"
| Expand | ||
|---|---|---|
| ||
|
Öppna kampanjgrupp på vara från Prisregister
Kampanjgrupp kan öppnas direkt från Prisändring för erbjudandepriser som skapats i en kampanjgrupp. Välj varuköposten för kampanjen och knappen "Kampanjgrupp" blir aktiv. Knappen är en genväg till att öppna upp Kampanjgruppsregistret på varuköpostens kampanjgrupp.
Godkännande av priser i "Priskontroll"
I "Priskontroll" kan priser godkännas på olika sätt:
- På knappen "Godkänn märkta poster" kommer bara märkta poster att godkännas.
- På knappen "Godkänn urvalet" kommer som standard de 50 första, ej godkända prisändringarna att behandlas.
När dessa kontrollerats godkänns dessa via knappen "Godkänn urvalet".
Om det fortfarande finns flera poster kvar att godkänna, kommer nästa batch att hämtas in för kontroll och nytt godkännande tills alla poster är behandlade. - Knappen "Komplett godkännande" används om alla prisändringar är kontrollerade och ska godkännas.
Alla aktuella prisändringar inklusive de som ännu inte är inhämtade för kontroll i gällande flik, kommer då att godkännas direkt.
"Mall-butik" i "Beställningskriterier"
Normalt skapas beställningskriterier för vanliga butiker med "Kommunikationstyp" = 11 och "Beställning" påslagen.
Det går också lägga upp beställningskriterier för så kallade "mall-butiker" som bara används till detta ändamål.
Vanliga butiker som använder en mallbutik i "Mall för beställningskriterier", kommer att använda dennas beställningskriterier om det inte finns beställningskriterier på egen butik.
| Expand | ||
|---|---|---|
| ||
|
Visa inte vara som saknar både profilpris och butikspris
Det finns tre alternativ för hur vara utan giltigt pris ska visas i Varu- och Prisregister:
- 0 = Alla användare kan se alla varor även de som inte har ett giltigt pris. Dessa kommer att visas med markeringen "Inget pris".
- 1 = Varor utan giltigt pris är dolt för profilanvändare.
- 2 = Varor utan giltigt pris är dolt för både profil- och butiksanvändare.
| Expand | ||
|---|---|---|
| ||
|
Utlägg av drivmedelsändringar till Reporting
Vid ändringar av gamla värden i programmen för "Fyllning", "Tankstatus" och "Manuell tankstatus", eller vid utlägg av gamla poster via "Data till Reporting", kommer detta att kunna leda till omfattande omräkningsjobb i Reporting.
För att slippa att det sänds för mycket data, bör det därför sättas upp hur många dagar bakåt i tiden det ska vara möjligt att lägga ut till Reporting.
| Expand | ||
|---|---|---|
| ||
|
Skapa underlag för massrensning av varor
Vid massrensning i stora varuregister är det viktigt att göra detta kontrollerat med begränsade urval i flera omgångar.
På generellt underlag rekommenderas det att inte rensa 100-tusentals (eller miljoner) varor på en gång. Detta tar alltid mycket kapacitet och använda lång tid som kan påverka andra uppgifter.
Programmet "Uppdatering av rensningslista" används för att skapa underlaget för programmet "Rensning av varor" i den speciella varulistan (listnr 100000002) som är avsedd för detta ändamål.
Detta underlag kan skapas genom att begränsa på olika urval eller använda varulistor, varugruppslistor eller modellistor.
Vid körning kan det väljas mellan att endast skapa en rapport som visar varor som kan rensas, eller att både skapa rapport och uppdatering av varorna i den speciella varulistan.
När underlaget är på plats, kan "Rensning av varor" göras, manuellt eller automatiskt via EOD,
Då kommer alla varor som ligger i den speciella varulistan att rensas.
Varulistan töms efteråt.
| Expand | ||
|---|---|---|
| ||
|
Behandling av paketvaror i beställning
En paketvara består ofta av flera varor eller antal > 1 av varan som ingår.
Vid beställning går det beställa endast paketvaran.
Både vid beställning och varumottagning är det lager för innehållsvarorna som uppdateras.
Paketvarorna är inte lagerstyrda.
| Expand | ||
|---|---|---|
| ||
|
Överstyrning av fasta dagar för beställningsförslag
Vid användning av beställningsförslag går det att parameterstyra genereringen av beställningsförslag till en fast veckodag per butik.
Detta kan överstyras manuellt i programmet så att alla butiker, oavsett veckodag, ska behandlas samtidigt.
Det går även lägga upp ett EOD-jobb för detta om det finns behov av att generera beställningsförslag för butiker en fast gång per vecka.
| Expand | ||
|---|---|---|
| ||
|
Utlägg av RIGAL-VPI till butik
I "Verkställ vara" kommer det vid val av endast "RIGAL VPI", att läggas ut RIGAL V-fil och D-fil till vald butik.
Innehåll i V-fil kommer att vara alla varor inom urvalet, med lokala butikspriser där dessa existerar, medan det för övriga varor används profilpris.
D-fil kommer att innehålla alla varor med tillgänglig profil "varuinformation". Där det finns butiksspecifik varuinformation används denna.
Om valet "Endast butikspriser" läggs till, kommer samma filformat som ovan att skapas, men bara innehålla varor med lokalt butikspris för vald butik.
Detta innebär att inga varor med endast profilpriser exporteras.
Butiksspecifik varuinformation på varor med endast profilpris kommer heller inte att läggas ut.
Detta kommer bara att ske vid generellt RIGAL VPI-utlägg på hela profilen.
...
Chain Classic version 2.1.1.0.44
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.44 ska alltid POS leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Elektroniska etiketter | Utlägg till elektroniska etiketter vid förlängning av erbjudanden (RTC-39381) Vid förlängning av ett erbjudande (kampanjpriser eller medlemserbjudanden), nytt slutdatum på aktivt erbjudande, ska det alltid läggas ut uppdaterade poster med erbjudanden till Lexmark. Elektroniska etikettlösningar däremot behöver inte denna uppdatering då dessa får egna utlägg när erbjudanden avslutas. |
Kampanjgrupp | Kopiering av kampanjgrupp för "Team" (RTC-39969) När en team-kampanjgrupp kopieras, går det kopiera denna till en kampanjgrupp för butik eller profil. |
RIGAL | Framtida prisändring och utgången vara (RTC-39744) Om en vara utgår via RIGAL, sätts sortimentskod till "Utgången" och beställningsnummer nollställs på pris. Det skapas också en borttagningspost med parameterstyrt rensningsdatum X dagar framåt i tid. Om det efter detta kommer nya eller framtida prisändringar för samma vara, kommer datum för borttagningspost att flyttas fram i tid i förhållande till det nya prisändringsdatumet, medan sortimentskod "Utgången" och nollställt beställningsnummer behålls. |
Tankstatus | Registrering av flera tankstatusposter på samma dag (RTC-39257) Det går registrera flera tankstatusar på dagens datum, så länge de registrerade mätningarna har en unik tidpunkt. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.43 ska alltid POS leverera kvitton i POSLog version 81.
Förbättringar
| Modul | Beskrivning |
|---|---|
Elektronisk varumottagning | Varusökning i elektronisk varumottagning (RTC-38982) Om det upplevs problem med standard varusökning i order i elektronisk varumottagning, prova då följande rutin: 1. Sortera först beställningsrader på EAN/PLU, (tryck på kolumnrubrik), så att lägsta nummer är överst. 2. Öppna standard sökprogram "Sök vara", antingen genom att trycka på "Kikaren" eller bara skriva EAN/PLU-nummer direkt.
1. Hittat EAN/PLU hämtas in på första orderrad, med efterföljande EAN/PLU nedanför. 2. För att ta bort filter som döljer ovan liggande orderrader:
|
EOD-rapport | Meddelande när E-post felar i EOD-Rapport (RTC-36556) Om meddelande inte kan levereras när EOD-rapport (som också ska skickas som E-post) skapas (nätverksproblem eller annat problem), så kommer detta att loggas direkt i Status- fältet i Rapportlistan.
|
RIGAL | Varutyp till RIGAL och loggning av uppdatering från RIGAL VPI (RTC-36476) Chain Classic lägger alltid ut "Varutyp" i RIGAL V-fil. |
Varor | Ta bort "Stoppa försäljning av vara" i POS (RTC-38072) I Chain Classic kan en vara som har blivit spärrad, senare öppnas för försäljning på kassorna igen. Detta sker antingen genom att använda knappen "Aktivera vara" i " Varuregister eller genom att välja "Aktivera vara" vid utlägg av varan från "Verkställ vara". |
Varu-/kundgruppsrabatt | Användning av varulistor i "Varu-/kundgruppsrabatt" (RTC-34434) Vid uppläggning och underhåll av varurabattposter i "Varu-/kundgruppsrabatt" kan varulistor med varulistnummer upp till 8 siffror användas. |
Varutransaktioner | Kvittonummer och kundordernr/radnr i "Varutransaktioner" (RTC-36528) För ökad spårbarhet och enklare uppföljning uppdateras "Kvittonummer" alltid när "Varutransaktioner" uppdateras från POSLog, och kundordernr/rad uppdateras också när detta är tillgängligt. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.42 ska alltid POS leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Kassör | Antal siffror för kassörnummer (RTC-34270) Kassörnummer kan ha upp till 9 siffror i Chain Classic. |
Webbläsare | Webbläsare i Chain Classic (RTC-35855) Knappar som öppnar webbläsaren i Chain Classic kommer alltid att använda Microsoft Edge. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.41 ska alltid POS leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Beställning | Spara varurad vid registrering av Beställning (RTC-35375) Spara ny/ändrad varurad är optimerat för förbättrad prestanda när många användare jobbar med detta samtidigt. |
Beställning/Varumottagning | Antal varurader i beställning och varumottagning (RTC-35812) Det går använda 5-siffrigt antal varurader i både beställning och varumottagning. Det betyder att det kan vara > 1000 varurader i en och samma order när nästa tilldelade radnr ökas med 10. |
Kampanjgrupp | Meddelande på skärm när importerade varor sammanfaller i olika kampanjgrupper (RTC-35734) När två kampanjgrupper har samma startdatum/tid eller slutdatum/tid och innehäller samma varor, avvisas varorna i den andra kampanjgruppen för att de sammanfaller. Meddelande om detta visas på skärmen. Detta gäller även vid användning av knappen "Hämta nya varor". |
Lager | Uppdatering av lager efter retur av samma vara på flera varurader i samma kvitto (RTC-34933) Om samma vara ska returneras flera gånger, matas vanligtvis antal in på befintlig varurad. Lagret uppdateras då med totalt antal. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.40 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Beställning | Behandling av varor märkta "Ej beställning" i Beställningsmodulen (RTC-31342)
|
Lager | Se lager i andra butiker (RTC-32343) Med funktionsknappen "Lagerinformation" i Varu- och Prisregister visas lagersaldo för butiksanvändaren om butiken har lagerpost på varan. Utan lagerpost på varan är knappen deaktiverad. Med åtkomst till andra butikers lagersaldon kan butiksanvändaren se lagersaldon i dessa butiker förutom egen lagerstatus. Om egen butik inte har lagerpost på en vara, kan butiksanvändaren ändå se lagersaldon i de andra butikerna. |
Utlägg till POS | Korrekt användning av av punkt som decimaltecken vid export av mixmatch till POS (RTC-32523) När en lokal butiksmixmatch eller kampanjgrupp skapas i Chain Classic efter att ha importerat en RIGAL X/J-fil och nyskapade butikspriser som saknas, används punkter alltid som decimaltecken i kassautlägg till POS. |
VPI-Sync | VPI-Sync och flera obehandlade ordinarie prisändringar i varukö (RTC-31186) Det händer att Chain Classic och POS "inte är eniga" om vad som gäller ordinarie pris. För att VPI-Sync inte ska visa onödiga avvikelser, kommer senast "godkända" pris i Chain Classic skickas till POS och användas för sammankoppling för motsvarande pris där. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.39 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.38 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Kampanjgrupp | Borttagning av hel mixmatch i kampanjgrupp (RTC-32186) Det går radera en komplett mixmatch i kampanjgrupp. Det görs då ett utlägg till POS av endast en post för borttagning av mixhuvud. |
Rapporter | "Fråga på pris" i rapport (RTC-31806) I många omsättningsrapporter för kassörer går det se antal förfrågningar på pris som gjorts i kassan. Det är totalt fyra varianter av detta som kan medföra att räknaren ökar: 1. Kvitto med bara fråga på pris 2. Annat makulerat kvitto med fråga på pris (t. ex. parkerat kvitto) 3. Offert med fråga på pris 4. Vanlig varuförsäljning med fråga på pris |
Varuregister | Lagerinformation i varu- och prisregister (RTC-30139) Genom att använda knappen "Lagerinformation" i "Varu- och Prisregister" visas lager på varan som är i fokus i en söklista för alla butiker som användaren har tillgång till och som har lagerpost.
|
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum: 2023-04-27
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.37 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Lexmark | Lexmark uppdatering när erbjudande = ordinariepris (RTC-29650) I situationer då kampanjpris/medlemserbjudande = normalpris och normalpris ökas under kampanjperioden kommer detta inte att skapa etikett. |
RIGAL | DUN-nummer i RIGAL VPI (RTC-30127) Uppdatering och ändring av DUN-nummer kan kommuniceras via, fält 7.1.56, i RIGAL V-fil. |
Inventering | Utlägg till 3:e-part av inventerade varor med resultat = 0 (RTC-30681) Vid utlägg av svinnposter til 3:e-part efter inventering kan det finnas tillfällen då inventerade varor med 0 som resultat också ska läggas ut. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.36 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
|---|---|
Etikett | Etikett skrivs inte utan ändring av utpris (RTC-29332) Om nytt kampanjpris är samma som utpriset eller om kampanjnettopriset, men inte utpriset, ändras på aktiv kampanj då skrivs det ingen etikett vid något av dessa tillfällen. |
Kampanjgrupp | Borttagning av mixmatch från ej godkänd kampanjgrupp (RTC-29477) Vid uppläggning av ny kampanjgrupp med flera mixmatch kan användaren ta bort både en och flera mixmatch innan själva kampanjgruppen godkänns. Samma vara i multipla mixmatcher i samma kampanjgrupp (RTC-27651) Det går ha flera mixmatch, med samma vara i en kampanjgrupp, utan risk för komplikationer på grund av identiska start- och/eller slutdatum. |
Mixmatch | Hämtning av nya varor i redan godkänd mixmatch (RTC-29815) I manuell mixmatch eller mixmatch i kampanjgrupp kan hämtning av nya varor göras på flera sätt. Oavsett metod kommer både automatiskt och manuellt godkännande/lagring att skapa varuköposter med samma butiksnummer som är gällande i nämnda erbjudandetyper. |
Rapporter | Antal sålda varor i grafisk varugruppsförsäljningsrapport (RTC-29486) Vid användning av grafisk varugruppsförsäljningsrapport kan det öppnas ett fönster för "Fördelning per butik". Generellt kommer denna "pop-up" att ha en kolumn för antal, men i tabeller för varugrupp- och undergruppsförsäljning är det ingen mening att lagra antal (av oidentifierade varor). För att undvika missförstånd exkluderar dessa försäljningsrapporter kolumnen "Antal", istället för att visa värde 0 på alla poster. |
Varumottagning | Utskrift av prislappar i varumottagning (RTC-28791) Vid användning av parameterstyrd speciallösning för varumottagning (ej standardlösningen el. varumottagning), går det skriva ut etiketter via knapparna "Prislapp" och "Prislapp lager". Funktionen ger prislappar för nya varor och i programmet utförda prisändringar på både befintliga och nya varor. Uppdatering av nettopris i existerande el. varumottagning vid manuell varumottagning (RTC-28081) Om det uppdagas en vara med fel nettopris i elektronisk varumottagning, kan detta korrigeras genom att skapa en manuell varumottagning och sätta rätt pris på varan där. Det skapas då en varutransaktionspost som har rätt värde och lagret uppdateras. Om man, som riktigt är i detta fall, väljer att uppdatera mot befintlig order blir motsvarande orderrad i elektronisk varumottagning uppdaterad med nytt värde på nettopris och även data i orderhuvudet blir omräknat i förhållande till nytt värde från manuell varumottagning. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.35 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
|---|---|
| Etiketter från varukö | Skriva varuköetiketter från InStore App (RTC-26686) Det finns stöd för att skriva ut etiketter, från varukö i Chain Classic, direkt från InStore App. De som inte kan skrivas ut visas också i "Varukölista" med etikettflagga = "Nej", och betyder att de inte är utskrivna. |
| RIGAL | Mixmatch och kampanjgrupp sänds alltid med referens via RIGAL (RTC-28418) Kampanjhuvud och mixmatchhuvud måste ha referens till varona i erbjudandet. Kundspecifika inställningar ger olika lösningar på detta. Dels kan kampanjgruppsnr och/eller mixmatchnr användas, om dessa nummer inte används gäller "Kampanj-ID" och "externt mix-ID". Utläggen sker i RIGAL-filer för kampanjgrupp (J) och mixmatch (X). |
| Varuinformation | Varuinformationstext (RTC-27650) När det gäller beskrivning av vara i varuinformationstext, finns ingen begränsning i textlängd. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum: 19 dec 2022
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.34 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Etikett | Beställ etikettutskrift med olika etikettyper (RTC-27262) Det går beställa och skriva ut etiketter med olika etikettyper i samma etikettbeställning från InStore App. |
Lager | Utlägg av lagerfil till Chain Web (RTC-27548) Vid utlägg av lagerfil till Chain Web från Chain Classic kommer alltid tidigare exporterad fil, "StockBasis.butnr", att skrivas över, om den inte hämtats. Optimering av utlägg vid lagerändring (RTC-27423) Generellt läggs inte lagerändringar ut till POS, detta ska bara ske vid ändring av pris eller kostpris. Varumottagning är därför enda anledning för filutlägg, med lagerändringar, till POS och ev. annan 3:e part. |
Rapporter | Leveransdatum i rapporten "Underlag beställning" (RTC-27033) När specialfunktionalitet för att visa leveransdatum i "Beställning" används, visar detta leveransdatum på orderrad i rapporten "Underlag beställning". |
RIGAL | Utlägg av leverantörsorder-ID efter varumottagning (RTC-27182) Leverantörsorder-ID är ett fält som inte visas i Chain Classic men som kan användas när leverantör sänder in varumottagning via RIGAL I-fil. När varumottagning är godkänd läggs leverantörs-ID ut i RIGAL I-formatet, detta gäller oavsett om varumottagning görs i InStore App eller i Chain Classic. RIGAL V-fil och kampanjgruppsdata (RTC-27899) Vid utlägg av RIGAL V-fil, från "Verkställ vara", läggs det ut kampanjgruppsinfo för kampanjgruppsnummer, kampanj-ID, namn på kampanjgrupp tillhörande formaten "K" (kampanjvara) och "M" (Medlemserbjudande). Dessutom läggs det ut RIGAL J-fil med motsvarande information. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Date:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.33 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Beställning | Butik utan "Beställning" (RTC-19163) Det rekommenderas att alla butiker har "Beställning" påslaget i butiksregistret. Men från patch 32 bör det kontrolleras att butiker som inte har beställning, då faktiskt inte har "Beställning" valt i butiksregistret. Detta för att säkerställa att beställningar inte skapas på dessa butiker per automatik i till exempel Kundorder och Varumottagning från POS eller InStore App. |
Lexmark integration | Utlägg av kampanjposter till Lexmark (RTC-26601) Utlägg av kampanj- och medlemserbjudandeposter till 3:e-partssystemet Lexmark är begränsat till endast de som är nödvändiga för Lexmarks funktionalitet. Det finns inte samma behov som vid motsvarande utlägg till POS. |
Rapporter | Urval i rapporten "Nonsalerapport per nonsaletyp" (RTC-26418) Vid beställning av rapporten "Nonsalerapport per nonsaletyp" går det att ange olika urval, till exempel varugrupp. |
RIGAL | RIGAL-uppdatering av "Fastpris" (RTC-26656) Flaggan "Fastpris" uppdateras via RIGAL-fil. Värdena F, "P eller Y sätter fastprisflaggan aktiv. Alla andra bokstäver deaktiverar fastpris. Om värde saknas, sker ingen förändring av "Fastpris". |
...
Med uppgradering til Chain Classic version 2.1.1.0.32 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Wet Stock | Wet Stock mängder (RTC-24636) För att göra det lättare att förstå att de mängder som används i Wet Stock-projektet kan vara i både liter eller kilo, visas dessa med enhet "Liter/Kilo". |
...
Vid uppdatering till Chain Classic version 2.1.1.0.31 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning | |||||||
|---|---|---|---|---|---|---|---|---|
Kund | Uppdatering av kundinfo i Chain Classic när Chain Web är kundmaster (RTC-23787) Det är parameterstyrt om kund ska uppdateras i Chain Classic när Chain Web tar över som kundmaster. Oavsett om kundinfo finns eller inte, kommer det vara möjligt att visa web-/kundorder i Chain Classic.
| |||||||
Inventering | Inventeringslista skapas inte (RTC-24318) Ett fel i patch 2.1.1.0.28 är rättat och redan levererat i ombyggd patch 2.1.1.0.31. Hotfix är tillgänglig för patch 2.1.1.0.18 - 2.1.1.0.30. | |||||||
Mixmatch | Varugruppsmix (RTC-23878) Vid upplägg av varugruppsmix kan knappen "Hämta varor via varugrupp" användas. Kravet är att det finns profilpris och att varan är aktiv på butik, för team gäller då detta för alla butiker annars kommer varugruppen inte att hämtas in. För bästa funktionalitet rekommenderas därför att använda specificerade dummyvaror, en för varje varugrupp. Då räcker det att en dummyvara per varugrupp är aktiv, dock på alla teambutiker.
| |||||||
Rapporter | Rapport "Beställningsunderlag" (RTC-23465) Rapporten "Beställningsunderlag" har skapats för att lageransvariga ska få en överblick över beställningsunderlag för egen butik, men det är också möjligt för HK-användare att ta fram en sammanställning över flera butiker samtidigt. Beställningsnummer i rapporten "Självbetjänade varor" (RTC-23516) Rapporten "Självbetjänade varor" har utökats med kolumn för "Beställningsnummer" där stöd för alfanumeriska eller numeriska beställningsnummer finns. Avgränsning i varukölogg (RTC-23553) Normalt körs varuköloggen via EOD och då hämtas alla önskade köartiklar med datum/tid och kötyp som urval. Det är också möjligt att köra sådana rapporter på ett mer begränsat urval, till exempel på artikelnivå med endast ett specifikt EAN/PLU-nummer. | |||||||
Register | Avvikelse mellan postnummerregister i Chain Classic och Chain Web (RTC-23376) Om registret för postnumret i Chain Web uppdateras innan registret i Chain Classic uppdateras när kundordern kommer till Chain Classic, så lagras ett okänt värde i postnummertabellen, med informationstexten: "Skapad från CW", datum och tid. Så att det kan verifieras att detta postnummer skapades av Chain Web. |
...
Vid uppdatering till Chain Classic version 2.1.1.0.30 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning | |||||
|---|---|---|---|---|---|---|
Vara | Servicehandel och relation antal/pris (RTC-22910) Ingredienser, recept och pris är sammankopplade i "Servicehandel". Som resultat kommer till exempel motsvarande pris att uppdateras korrekt i "Recept" och "Pris" om numret ändras på några varor i "Ingredienser". | |||||
RIGAL | Uppdatering av pris via tandem i RIGAL-VPI (RTC-22919) Tandemnummer kan användas till prisändring, om detta skickas in som huvudvara och sker via PRI-post i RIGAL V-fil. | |||||
Rapport | Makulerade kvitton i "Butiksredovisning total" (RTC-22956) POS-kvitton med kundorder och varuförsäljning som makuleras i kassan registreras korrekt i Chain Classic och uppdaterar raden "Mak. av kvitto" i rapporten "Butiksredovisning total". | |||||
Kampanjgrupp | Se profilkampanjer som butiksanvändare (RTC-23239) Det finns möjlighet att göra så att butiksanvändare också ser profilkampanjgrupper. Detta kan vara smart då dessa också gäller egen butik. För butiksanvändare är det då möjligt att se, men inte att ändra något, i profilkampanjgruppen. Det går kopiera så att butiken får en egen kopia av profilkampanjgruppen. Denna kan därefter kompletteras och ändras om butiken önskar att ge bättre erbjudande inom samma period.
|
...
Vid uppdatering till Chain Classic version 2.1.1.0.29 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning | |||||||
|---|---|---|---|---|---|---|---|---|
| Kampanjgrupp | Saknad uppdatering i POS vid ändring av värden i Kampanjgrupp RTC-19966) Om det är en ändring av HK-ägda värden (exempelvis fastpris) i Kampanjgrupp måste utlägg till POS parameterstyras via ordinarie prisändring så att kassan uppdateras.
| |||||||
Varor | Korrekt beräkning av ingredienspris (RTC-22406) Vid användning av receptvaror har funktionen gjorts så att den tar fyra decimaler. Pris för "Ingrediens" visas med korrekt belopp, ned till två decimaler. | |||||||
Varumottagning | InStore App-varumottagning av paketvara som inkluderar viktvara (RTC-21673) När varumottagning av paketvara från InStore App utförs använder paketen sina ingående varor. I Chain Classic beräknas mottag av själva paketvaran på grund av kontroll i InStore App. När mottagen mängd är ett decimaltal, exempelvis viktvara, avrundas det till närmsta heltal vid inläsning av kvitto och visas både i "El. varumottag/Varumottag" och "Beställning". Behandling av antal vid varumottagning från InStore App (RTC-22354) Vid varumottagning gjord i InStore App kommer registrerat antal bara att uppdatera värden för "Kontrollerat antal" i Chain Classic, medan värden för "Mottaget antal" inte kommer uppdateras. Användaren kan då senare följa upp och se skillnaden mellan det antal som skulle mottas och det som faktiskt har mottagits. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.28 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Kund | Kunder med postnummer 0 tillåts (RTC-19993) Det är tillåtet med postnr = 0 på kund i Chain Classic. |
Mixmatch | Borttagning av mixvaror och hel mixmatch (RTC-21479) Statistik visar att det inte är att rekommendera radering av artikelrader i en aktiv mixmatch eller att ta bort en hel mixmatch (i en aktiv kampanjgrupp), men detta är möjligt och kan vara nödvändigt vid administrativa fel. För sådana raderingar läggs endast borttagningar i mixfiler, alternativt RIGAL-filer, till aktiva butiker. |
Pris | "Sänd vara till kassa" och profilbutik (RTC-21769) Vid användning av "Profilbutik" och funktionen "Sänd vara till kassa" kommer det endast att vara filen pris.999xx som läggs ut till profilbutiken. Övriga format läggs bara ut till aktiva butiker. |
Vara | Uppdatering av varutext och varuinfo samtidigt (RTC-21888) Om det i "Varuregistrering" sker ändring av varudata och "Varuinfo" inom en kort tidsintervall resulterar det i korrekt utlägg av filerna vara.99900 och varuinfo.butnr. |
Inventering | Uppdatering av inventeringsfiler som ligger i kö (RTC-22006) När inventeringsfiler läggs i kö öppnas möjligheten att uppdatera lager senare än inventerat datum. Programmet säkerställer att varorna fortfarande är uppdaterade med rätt belopp i inköpspris, försäljningspris och moms. Manuell registrering i "inventeringsguiden" (RTC-21903) Vid inventering och manuell registrering av lagerstyrd vara sker det en kontroll om varan finns på lager. Om guiden inte hittar lagersaldo blir inventeringen ändå registrerad och lagerantal uppdateras med korrekt lagerstatus. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.27 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning | |||||||
Pris | Utlägg av framtida priser (RTC-21154) Vid användning av utlägg av framtida priser till POS är det viktigt att rätt könummer används. Kontrollen av detta har förbättrats så att det inte uppstår problem med gällande ordinarie pris i POS.
| |||||||
Beställning | Referenstext i "Beställning" och "Elektronisk varumottagning" (RTC-20347) Meddelande angivet i fält för "Referenstext" i "Beställning" hämtas upp i motsvarande order i "Elektronisk varumottagning" och visas där i en egen kolumn. Vid användning av specialprogrammet "Beställningsförslag Excel" måste en beställningsanteckning följa med. Detta meddelande hamnar i "Referenstext" i "Beställning" och visas då även enligt beskrivning i "Elektroniskt varumottagning". | |||||||
Butik | Inget utlägg till butiker med kommunikationstyp = 1 (RTC-20589) Det görs aldrig något utlägg till POS eller tredjepartssystem för butiker med kommunikationstyp = 1 i butiksregistret i Chain Classic. Dessa butiker kan därför användas som "referensbutiker" vid RIGAL-import från ERP. | |||||||
Rapporter | Antal försäljningar per period i rapporten "Dagsrapport" (RTC-20392) Antal försäljningar som visas i rapporten "Dagsrapport" visar: Försäljning totalt denna månad. Försäljning totalt föregående månad. Försäljning totalt senaste 12 månaderna. Dessa nummer ändras inte av olika val på datum eller på annat sätt.
Rapporter för team över flera profiler (RTC-21189) Teamanvändare kan välja profil i urvalsbilden vid rapportkörning. Villkor för att detta kan göras är att det aktuella teamet innehåller butiker från flera profiler och att teamanvändaren har skapat med profiltillhörighet "Alla". Butiksredovisning totalt (RTC-21072) Rapporten anpassas så att om alla möjliga visningsalternativ används samtidigt skapas rapporten fortfarande på en sida. | |||||||
RIGAL | Uppdatering av RIGAL N-fil (RTC-20048) Vid uppdatering av RIGAL N-fil uppdateras varupost som förväntat, även om det finns existerande varufältsinfo. | |||||||
System | Begränsa uppstart av antal samtidiga EOD-jobb RTC-19734) Programmet jobbserver kontrollerar antal startade rapporter (inkluderat etikettutskrifter eller andra batchjobb), och det är parameterstyrt hur många jobb som kan startas och köras samtidigt. Om ett "Startat" jobb inte når jobbstatusen "Kör" definieras jobbet som misslyckat och hindrar därför inte ett annat batchjobb från att starta eller slutföras.
| |||||||
Utlägg till Tokheim | Utlägg till Tokheim när kassör spärras (RTC-19671) När kassör "spärras" i Chain Classic eller i Chain Web läggs borttagning av kassör/användare ut från Chain Classic till tredjepartssystemet Tokheim POS. | |||||||
Varumottagning | Loggning av förändringar av kostpris i "Fakturakontroll" (RTC-20293) Specialprogrammet "Fakturakontroll" i Varumottagning loggas så att avvikelse vid ändring av kostpris kan åtgärdas.
Internöverföring och färgvarianter på prisfliken i varumottagning (RTC-19626) Vid användning av specialversion av varumottagning - "elmottakw" och internöverföring mellan butiker, visas överförd variant för modellfärg i fliken Pris. Detta är för utskrift av prislappar och kommer att vara så även om den överförda varianten är huvudprodukten för storleken eller inte.
| |||||||
Kampanjgrupp | Snabb prissättning i kampanjgrupp (RTC-20892) Prisändringsprogrammet "Snabbprissättning" är ett separat menyalternativ, som täcker de flesta av de multipla prisändringarna. Snabbprissättning för kampanjerbjudanden bör fortfarande göras via kampanjgruppen eftersom detta ger fördelar för prestanda och felsökning. Standard priskontroll och datumändring på kampanjgrupp (RTC-20372) Vid ändring av datum på kampanjgrupp tas hänsyn till tidigare behandling i priskontroll. Det betyder att en butik som har avvisat eller godkänt kampanjposter, mixmatch eller hel kampanjgrupp inte måste göra detta igen om datum/tid ändras på kampanjgrupp. Status behålls och endast datum/tidsändringen uppdateras. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.1.1.0.26 rekommenderas det att POS levererar kvittoformat i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Beställning | Beställning av paketvara som innehåller pantvara (RTC-19152) Visning av beställningar med paketvaror som innehåller pantvaror har förbättrats så att det också ger visuella varurader i Beställning i Chain Classic. Automatiskt utlägg med paketvara (RTC-18770) Funktionen för automatiska utlägg av paketvara har förbättrats. En order från InStore App med bara en paketvara, eller paketvara på sista raden, läggs nu automatiskt ut komplett via RIGAL, från Chain Classic. |
Order | Webborder med beställningsvara som inte ska skapa beställning i Chain Classic (RTC-19125) Det har gjorts förbättringar för webborder i Chain Classic som innehåller beställningsvaror. Om beställningsfunktionen inte är aktiv i Chain Classic kommer det inte skapas beställningar även om webbordern innehåller en sådan beställningsvara. |
Rapporter | Plocklista för webborder saknas (RTC-18592) Enstaka fall där plocklistan för webborder inte genererades automatiskt har förbättrats. Butiksredovisningsrapport med priskanaler på en sida (RTC-18117) Butikredovisningsrapport med användning av flera försäljningskanaler har förbättrats så att all data kommer på en sida som förväntat. |
Varor | Orsakskod med fyra siffror kan inte visas i " Varurörelser" (RTC-18584) Orsakskoder visas nu korrekt även när orsakskoden innehåller fyra siffror. Saknade borttagningsposter när du använder "Rensa/Ta bort från kassan" (RTC-18299) Förbättringar har gjorts i rensningsprogrammet "Rensa/Ta bort från kassan". Genom att ta bort onödig kontroll av varuändringsdatum säkerställs det att förväntade borttagningsposter skapas. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum: 08.dec.2021
Förutsättningar för uppgradering
Uppgradering till Chain Classic version 2.1.1.0.25 förutsätter att POS levererar kvittoformat i POSLog version 75.
...
Dokument status: Status colour Green title released
Datum:
Förutsättningar för uppgradering
Uppgradering till Chain Classic version 2.1.1.0.24 förutsätter att POS levererar kvittoformat i POSLog version 75.
...