Chain Classic version 2.2.0.0.15

Dokument status: RELEASED

Datum: 01 Nov 2024  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.15 ska POS alltid leverera kvitton i POSLog version 81. 

Förbättringar

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.

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.

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"

Öppna kampanjgrupp på vara från Prisregister

(RTC-42114)

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"

(RTC-40918)

I "Priskontroll" kan priser godkännas på olika sätt:

1. På knappen "Godkänn märkta poster" kommer bara märkta poster att godkännas.
2. 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. 
3. 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" 

(RTC-41178)

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.

Visa inte vara som saknar både profilpris och butikspris

(RTC-41286)

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.

Utlägg av drivmedelsändringar till Reporting 

(RTC-42339)

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.

Skapa underlag för massrensning av varor

(RTC-40770)

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.

Behandling av paketvaror i beställning

(RTC-40776)

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. 

Överstyrning av fasta dagar för beställningsförslag

(RTC-41807)

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.   

Utlägg av RIGAL-VPI till butik

(RTC-42098)

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

Dokument status: RELEASED

Datum: 30 Apr 2024  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.14 ska POS alltid leverera kvitton i POSLog version 81. 

Förbättringar

Förhindra erbjudandepriser på "fastpris"-varor

(RTC-39428)

Det är möjligt att förhindra uppläggning av erbjudanden (kampanjpriser och medlemserbjudanden) på varor med fastpris. 

Manuell prisändring:
Val för att skapa kampanjpris kommer inte att vara möjligt för användare som normalt har denna behörighet. 

Kampanjgrupp:
Det tillåts inte uppläggning av varor med fastpris vid manuellt val av vara, vid "Snabb prisändring", vid "Hämta nya varor" eller vid inläsning via "Excel" (csv-/xlsx-format).
Meddelande om detta visas i kampanjgruppsloggen.

Snabb prisändring :
Även vid snabb prisändring avvisas erbjudandepriser för dessa varor, och dessutom loggas detta i "Loggutskrift" för loggtyp 6: "Avvisat i snabb prisändring". Meddelande 12 visas: "Varan har fastpris".  

Butiksrutiner:
För butiksanvändare som bara kan skapa erbjudandepriser, kommer knappen "Ändra pris på vara" att vara deaktiverad.
För användare som också kan ändra ordinarie pris, kommer val för kampanjpris och medlemserbjudande att vara deaktiverat i prisdialogen.

Meddelande ": IP 557 "Denna vara har "Fastpris" och kampanjpris/medlemserbjudande kan därför inte användas", att visas när EAN/PLU kan skrivas i EAN-fältet och lämnar detta eller trycker på sparaknappen.

Kontroll mot SAP om borttagningspost för vara ska köras eller inte

(RTC-34179)

Det kan sättas upp ett jobb som varje natt kontrollerar, mot SAP, om aktiva borttagningsposter i varukön ska behandlas eller inte.
Om SAP har information om att vara fortfarande finns i lager, kommer borttagningsdatumet att flyttas X antal dagar framåt i tid, för ny kontroll senare.

Priskanal och utlägg till elektroniska etiketter

(RTC-39745)

Vid användning av priskanal i kampanjgrupp är det parameterstyrt hur utlägg ska ske till Breece/Pricer. 
Utlägg kan göras oavsett val av priskanal (standard) eller bara när det valts priskanal "Alla".
Om vald priskanal är "Alla", görs inga utlägg om priskanal till exempel = "Shop express".

Administration av kassörer och kund endast i Chain Classic

(RTC-39482)

När kund eller kassör skapas/ändras är det normalt att lägga ut detta till POS. Men används 3:e-parts POS-lösning (t.ex. Tokheim POS), kan det vara önskvärt att detta inte sker.
Då går det parameterstyra detta så att onödiga köposter tas bort automatiskt.

Uppdatering av ny vara från Item Master

(RTC-39334)

Vid uppdatering av ny vara i Chain Classic från RIGAL är det nödvändigt att både varu- och prisinformationen levererats från Item Master.
När båda posterna är på plats i "VPI Registervård" slås de ihop och en ny vara med pris skapas i Chain Classic.
Även ordningsföljden är viktig, för ny vara måste varuposten komma in före prisposten. Kommer prisposten först, kommer prisposten att ignoreras då det inte finns någon vara att koppla den till.
I detta fall kommer en efterföljande varupost att bli liggande tills en ny prispost kommer så att ny vara kan skapas.

Uppdatering av kostpris vid varumottagning av ny vara på befintlig profilkampanj

(RTC-40022)

Ny vara saknar lokalt butikspris och lagerpost. När ny vara aktiveras via Varumottagning, skapas butikspris med kopia av kampanjposter från profilpris.
Dessutom skapas en prisändring för butikspris med prisdata hämtad från Varumottagning. Detta gäller vid: 

RIGAL-import till varumottagning, ändring av pris och/eller antal för mottagning av varor och efterföljande uppdatering av lager.

RIGAL-import till varumottagning och direkt val av lageruppdatering utan föregående ändring av varumottagningsposten.

Manuellt skapad post i varumottagning, lagring av pris och antal av mottagen vara och efterföljande uppdatering av lager. 

När varan kommer in i Varumottagning, aktiveras varan med profilpris inkl. aktiv profilkampanj för butiken. 
När lager uppdateras, kommer lagerpost med kostpris att skapas och det skapas samtidigt nytt butikspris med kopia av profilkampanjen. 
Vid utlägg till POS kommer alltid kostpris att användas som nettopris för alla pristyper.

Loggning av webservice

(RTC-40216)

Loggning av vad som skickas till POS Services och vad som skickats tillbaka via en webservice är normalt avslagen.
Men det kan slås på vid behov under test av en ny webservice eller vid felsökning.
För närvarande är denna funktionalitet införd i webservice som används i RTC-34179.

Loggning av borttagning av orderrader och kompletta ordrar 

(RTC-37992)

Under "Rapporter - Loggar" ligger möjligheten till att skriva ut loggrapporter. För att följa upp borttagning av ordrar och/eller orderrader för beställning/varumottagningar, används: Loggutskrift "Borttagen order/orderrad". 

Följande borttagningsaktiviteter loggas: 

• Beställning: Orderrader och kompletta beställningar 
• Elektronisk varumottagning: Orderrader och kompletta varumottagningar
• Varumottagningar: Orderrader och kompletta varumottagningar
• Borttagning av öppna beställningar 
• Beställningsrader från RIGAL

Loggning av lagerrörelser

(RTC-38346)

När Chain Classic inte är master för lagerstyrning, kommer ERP att sända lageruppdateringar via RIGAL.
Det betyder att det kan dyka upp ändringar i lagerbehållningen som inte visas som registrerade aktiviteter i Chain Classic.
Chain Classic kan bara hålla koll på lagerbehållning mellan uppdateringarna från ERP. 
Därför kommer alla ändringar av lagerbehållning att lagras i lagerdag-tabellen med en registrering per ändring.

Avsluta gamla beställningar/kundordrar

(RTC-39498)

Det finns två hjälpprogram, under LRS-menyn, för att avsluta gamla beställningar och kundordrar som aldrig blir avslutade på annat sätt: 

• "Avsluta beställningar" - Ändrar alla ej mottagna beställningsrader/-huvuden, före angivet datum, till status mottagen.
• "Avsluta kundordrar" - Ändrar alla ej betalda eller ej levererade orderrader, samt ej levererade orderhuvuden, före angivet datum, till status betald och levererad.

I båda programmen omräknas värden i lagerpost för vara på alla ändrade rader.

Standard antal dagar är parameterstyrt och kan överstyras vid programkörning från menyn.

Nollställning av kvittonr

(RTC-40699)

I Chain Classic sparas de 10 senast inlästa kvittonumren per butik. Om support av någon orsak måste läsa in ett kvitto med ett kvittonummer i denna lista, kommer kvittot att avvisas med meddelande om att kvittonumret redan använts.
Den lagrade nummerserien måste därför raderas. Hjälpprogram för detta finns under "LRS- Korrigera/ändra data".
Med "Nollställing av kvittonr" raderas alla de 10 lagrade kvittonumren för butik(erna). Därefter kan det saknade kvittot läsas in på nytt.

Underhåll av beställningsrader i elektroniskt varumottagning

(RTC-39437)

Det finns många möjligheter att anpassa elektronisk varumottagning. Till exempel:

• Ska det gå att lägga in ny beställningsrad i existerande varumottagning?
• Ska det gå att ta bort en beställningsrad som inte är mottagen?
• Ska det gå att att ändra nettopris?

Kontrollera inställning av rensningsdagar för "Rensning av statistik"

(RTC-40102)

Regler för visning av "Lägsta pris senaste X dagar" medför ändringar när det gäller rensning av prislogg- poster.
Dessa måste behållas när en vara tas bort eftersom samma EAN/PLU kan skapas på nytt inom angivna tidsintervall för lägsta pris.
Prisloggposter kommer därför inte att tas bort via varuköbehandling eller via batchprogrammet "Rensning av varor". 

Detta medför att innehållet i prislogg-tabellen växer snabbare om den inte är uppsatt med en förnuftig rensningsfrekvens i det automatiska jobbet för "Rensnings av statistik" som körs varje EOD. 
Detta gäller inte bara prislogg-tabellen, det är också viktigt att mängden data i alla statistiktabeller hålls inom förnuftiga mängder, att man bara sparar det man har användning för. 

Chain Classic version 2.2.0.0.13

Dokument status: RELEASED

Datum: 29 Feb 2024  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.13 ska POS alltid leverera kvitton i POSLog version 81. 

Förbättringar

Visa lägsta pris de sista 30 dagarna före kampanjstart

(RTC-38287,RTC-38447, RTC-38451) 

Enligt markadsföringslagen ska referenspris, om det visas på elektroniska etiketter (Pricer och Breece) och pappersbaserade etiketter eller skyltar från Lexmark, vara det lägsta priset som har använts i butiken de senaste 30 dagarna.

Kontrollperioden börjar dagen innan kampanjstart och sträcker sig angivet antal dagar tillbaka i tid (minst 30 dagar). Värdena kan därför bli olika, i förhållande till startdatum, när det skapas framtida erbjudanden på samma vara.

I lägsta pris inkluderas tidigare ordinarie prisändringar, kampanjpriser och medlemserbjudanden som har varit lägre än gällande ordinariepris. Gällande ordinarie pris kommer därför endast att användas som lägsta pris om detta faktiskt är det lägsta priset under perioden.

I programmet för Kampanjgrupp och manuellt Prisunderhåll kommer värdet för lägsta pris att visas i eget fält, när kampanjpris eller medlemserbjudande läggs upp.

Använda Excel online i Chain Classic

(RTC-37084)

Om Microsoft "online Excel-lösning" används, kan inte rapporter i XML-format användas. Det kommer därför att skapas en CSV-version av denna rapport som kopieras till katalogen Chain_Print. 

1. Välj önskad rapport i rapportlistan och tryck på "Excel-knappen".
   • Excel-rapporten flyttas till katalogen Chain_Print. Detta bekräftas med ett meddelande.
   • Om rapporten är i XML-format (formaterad i Excel) kommer den dessutom att sparas en CSV-version av rapporten på samma katalog. Meddelandet visar nu att båda rapporterna är kopierade.
2. Öpppna katalogen "Chain_Print" under katalogen "Dokument". Här ligger de sparade Excelrapportna, både i XML och CSV format om rapporten är formaterad.

Alla rapportfiler i format .csv, kan öppnas direkt i den Excellösning som är tillgänglig för användaren. 

Uppdatering av RIGAL VPI med VAR- och PRI-poster från Item Master 

(RTC-38435)

När Item Master tas i bruk, är det viktigt att Chain Classic är uppdaterad till senaste patch och att systemparametrarna är korrekt uppsatta.

Generell funktion är som följande:

1. RIGAL VPI med VAR-post på existerande vara i Chain Classic blir uppdaterad om det ändrats varuinformation i importen.
2. RIGAL VPI med VAR-post på ny vara ligger kvar i VPI-registret tills tillhörande PRI-post uppdateras. Detta innebär att en ny vara kan uppdateras till Chain Classic.
3. RIGAL VPI med PRI-post för ny vara avvisas om det inte finns en väntande VAR-post i VPI-registret.
4. För ny vara måste därför alltid VAR-post uppdateras före PRI-post.
5. RIGAL VPI med PRI-post på känd vara i Chain Classic, uppdateras om det finns ändrad prisinformation.

Utlägg av omsättning till Nielsen IQ

(RTC-38850)

Utlägg av "Omsättning till Nielsen IQ" kan läggas upp som ett automatisk jobb i förbindelse med EOD, men programmet kan också köras manuellt.
Standardvärde för veckonummer utgår från dagens datum och 6 dagar bakåt i tiden, och kan ändras efter önskemål vid manuella utlägg.
Omsättning läggs ut per såld EAN/PLU med egna poster för försäljning på tandemnummer. 

Mixtyp 46: "Betala med Coopay och få x kr/% extra återbäring" 

(RTC-36758

När ny mixmatch med mixtyp 46 skapas, hämtas korttyp för Coopay in automatiskt. Korttypen kan inte ändras.
Värde för Rabattkr eller Rabatt% måste anges. Självskanning kan också väljas.
Denna mixtyp fungerar oberoende av varorna i kundkorgen, och därför skapas bara 1 mixrad med en angiven "Dummy-vara" och hanterar mixutlägget till POS via varukön.

Användning av modellvaror i mixmatch

(RTC-37236)

Några mixmatchtyper kan användas med modellvaror. Detta är något som förenklar att lägga in ett urval av varor där bara en variant representerar alla varor i modellen.

För att få denna funktionalitet i POS, måste val av Modellvaror markeras.
För att slippa problem i POS kan denna funktionalitet inte ändras efter att mixmatchen godkänts.
Flera sådana kritiska val är deaktiverade så att värdet behålls oförändrat under hela mixmatchens "levnadstid".

Användning av nettopris från ordinarie priskalkyl i rapporten "Lagerlista Excel"

(RTC-39048)

1. Rapporten "Lagerlista Excel" är i princip skapad för att visa inköpspris för butikernas varor där kostpris > 0. För varor utan kostpris, skrivs 0 i denna kolumn.
2. Om parametern för att visa nettopris från ordinarie priskalkyl slås på, kommer dessa värden att visas och användas till att beräkna inköpspris för varor som inte har ett giltigt kostpris.

Om nämnda parameter slås på, kommer denna rapport att visa samma värden som alt. rapport "Lagerlista".

Prisimport via resultat-fil från "Sortimentlista Excel"

(RTC-37853)

Vid inläsning av VPI från Excel kan det uppdateras prisändringar för profilpriser från olika profiler och butikspriser. Hur prisändring ska uppdateras, bestäms av om "RIGAL/Excel VPI per butik" är markerat (prisändringar på butikspris) eller inte (prisändringar på butikens prisprofil) för butiken.

Utlägg av mixmatch till Tokheim från "Verkställ vara"

(RTC-37218)

I Verkställ vara kan export göras med "Mixmatch" och "mixnummer" som enda urval. Här läggs då endast angivna mixmatchar ut. Denna funktionalitet stödjer också samtidiga utlägg av identiska profil-mixmatcher på flera profiler, med samma innehåll, start- och sluttid. Utlägg av mixmatch till Tokheim POS stöds också på samma sätt.

Detta är standardfunktionalitet både för export till EG POS och Tokheim POS.

Utökad funktionalitet i "Varurörelser"

(RTC-37358)

Om "Servicehandel" används, kommer också varutransaktioner för receptvaror och varuförsäljning av ingredienser (per råvara) att visas i översikten "Varurörelser" i Varu-/Prisregister. Detta är tillägg till standard varutransaktioner och varuförsäljning i övrigt.

Varumottagning som skapas i förbindelse med en internöverföring

(RTC-37990)

Det går inte att ta bort varumottagning som genererats från internöverföring. Detta har införts för att förhindra problem som följd av borttagning av "oväntade" varumottagningar som inte var beställda från leverantör.
Det går heller inte att ta bort, lägga till eller ändra poster på radnivå. 

Profilbyte och framtida prisändringar på ny profil

(RTC-33829)

Vid ändring av profilnummer på butik skapas nya köposter för alla aktiva och framtida profilprisändringar (om butik inte har lokalt pris). Detta inkluderar kampanjpriser och medlemserbjudanden. Om priskontroll används, kommer detta att beaktas och butiken måste godkänna nya prisändringar. 

Automatisk beställning i "Fältvärden för butik"

(RTC-34302)

Om en vara inte är märkt för "Automatisk beställning" i Varuregister, men det finns butiker med detta behov, löses detta genom att butiken lägger upp ett butikslokalt värde för fältet i "Fältvärden för butik". Detta värde används i samband med nya beställningar på varen.

Säkerställ att alla proxy-program avslutas rätt

(RTC-34308)

Vid direkt kommunikation mot lösningar i Cloud/POS, och Chain Classic "låses" förbindelsen mellan appserver och klient tillfälligt. När uppgiften utförts avslutas denna förbindelse och "låsningen" upphör.

Säkerställ att procedurer som anropas via plipanrop inte skapar trögheter

(RTC-34272)

För bästa prestanda är alla procedurer som används via plipanrop från webklienterna optimerade så att alla aktiva transaktioner och andra bindningar till webklienterna avslutas när proceduranropen är avslutade.

Rensning av filkö-tabellen

(RTC-31531)

Det kan hända att det blir poster kvar i filkön som aldrig töms på normalt sätt. Vanligast i testmiljön, men kan också ske vid fel inställning i Prod.
Många sådana felposter i filkön kan göra att jobbet Utlägg av data till fil kan ta betydligt längre tid än nödvändigt. Detta är ett kroniskt tillstånd som bara blir värre.
För att slippa sådana fördröjningar kan det vara smart att sätta igång ett automatjobb som rensar upp i detta. Detta kan till exempel köras en gång i veckan.

Chain Classic version 2.2.0.0.12

Dokument status: RELEASED

Datum: 08 Dec 2023  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.12 ska alltid POS leverera kvitton i POSLog version 81.

Förbättringar

Uppdatering av varutransaktioner på receptvaror

(RTC-36584)

När varutransaktioner på receptvaror registrerade i POS eller i InStore App och resultatet uppdateras från POSLog till Chain Classic, sparas dessa på råvarorna som ingredienserna i receptvarorna skapats ifrån.
Samtidigt loggas det också en transaktion på själva receptvaran för uppföljning i rapporten "Varutransaktionslista".

Rapport Varutransaktionslista för receptvaror

(RTC-36584)

Vid registrering av varutransaktioner på receptvaror i POS eller i InStore App, kan man följa upp transaktionerna på receptvarorna genom att markera i rutan för "Receptvaror" i rapporten "Varutransaktionslista".

Rapport över försäljning på ingredienser

(RTC-36949)

Det kan finnas behov att kunna se varuförsäljning fördelat på råvarorna som ingredienserna i receptvaror består av.
Rapporten "Försäljningstatistik" är anpassad till att visa detta om man väljer att markera i rutan för "Ingredienser".
Resultatet visar försäljningen per råvara med upp till 3 decimaler i antalskolumnerna. 

Etikettutskrift från InStore App

( RTC-36419, RTC-37073)

Vid utskrift av etikett från InStore App går det att parameterstyra om kriterier för varuförsäljning, lagerbehållning eller beställning ska användas för att begränsa antal etiketter som skapas. 

Loggning av "Beställningsfördelning Excel"

(RTC-36077)

När beställningar/varumottagningar har skapats via programmet "Beställningsfördelning Excel", kommer detta att visas i registervårdsprogrammet för "Beställning".

Utlägg av summan av varutransaktioner per orsakskod till RIGAL F-fil 

(RTC-35910)

Via programmet "Utlägg av RIGAL statistik" är det möjligt att lägga ut summan av varutransaktioner per transaktionstyp och orsakskod till RIGAL F-fil (finansfil) total per dag.
RIGAL-kod för dessa poster är IVtnnnn, där t = transaktionstyp och nnnn är orsaksnummer inkl. inledande nollor (hämtat från Systemalternativ 1000).

Detta är parameterstyrd tilläggsfunktionalitet.

Lagring av försäljningsdata för receptvaror

(RTC-36577)

I servicehandelsmodulen kan det finnas behov att kunna se försäljning registrerad på receptvaror. Normalt sparas sådana försäljningstransaktioner på själva råvarorna, men för receptvaror lagras detta i egen tabell "recepttrans", som bara fungerar som logg och som underlag för rapport. 

Lagring av försäljningsdata för ingredienser 

(RTC-36815)

I servicehandelsmodulen kan det finnas behov för att kunna se försäljning som registrerats på ingredienser i receptvaror. Normalt sparas sådana försäljningstransaktioner på själva receptvaran, men för ingredienser sparas detta i en särskild tabell "ingredfsg", som endast fungerar som logg och som underlag för rapport. 

Tabell för lagring av försäljning på ingredienser

(RTC-36848)

Det kan finnas behov att kunna se både försäljning och svinn för ingredienserna som används i receptvaror.
Tabellen "ingredfsg" uppdateras fortlöpande med försäljning på råvarorna som ingredienserna skapats ifrån.
Denna försäljning sparas totalt per råvara per dag per butik.

Kostpris ska alltid användas som nettopris för alla priser i POS 

(RTC-35863)

När funktionalitet för kostpris används och detta är > 0, är det alltid detta som ska användas som nettopris i POS för alla priser, både aktiva och framtida.
Vid ändring av kostpris i förbindelse med en varumottagning, kommer det att skapas ett utlägg till POS för alla aktiva och framtida priser med det nya kostpriset i nettoprisfältet.

Chain Classic version 2.2.0.0.11

Dokument status: RELEASED

Datum: 31 Oct 2023  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.11 ska alltid POS leverera kvitton i POSLog version 81.

Förbättringar

Sortimentslista Excel

(RTC-34753)

Rapporten "Sortimentslista Excel" erbjuder tre olika, parameterstyrda, alternativ med 39, 53 eller 58 kolumner/fält i Excelrapporten.
Samma format kan också användas till uppdatering/nyuppläggning av varor vid import av VPI från Excel.

Streckkodslösning i rapport

(RTC-35633)

I rapporten "Prisändring med etikettsimulering" visas streckkod för PLU/EAN med 1-13 siffrigt.

Stoppa möjligheten att skapa nya varutransaktioner manuellt 

(RTC-34760)

Om det inte ska gå att skapa manuella varutransaktioner i Chain Classic, kan knapparna i verktygsraden för nyuppläggning och kopiering att tas bort.
Med detta kommer det bara gå att utföra motposteringar.

Uppdatering av försäljning och varutransaktioner på receptvaror vid bruk av Servicehandel

(RTC-34602)

Generellt ska receptvaror aldrig vara lagerstyrda. Det är råvarorna som ingredienserna i receptvaran skapats ifrån, som ska vara lagerstyrda.
Vid uppdatering av varutransaktioner från POSLog som registrerats på en receptvara, kommer det att skapas varutransaktioner i databasen på råvarorna som ingredienserna i receptvaran är uppbyggd av.
Samtidigt kommer även lagret att uppdateras samma råvaror.

Det går också registrera varutransaktioner i POSLog på en paketvara. Då kommer det att skapas varutransaktioner i databasen på innehållsvarorna. Likaså uppdateras lagret på dessa innehållsvaror.

Vid försäljning av en receptvara (från Tokheim POS eller EG POS) så kommer försäljningen att registreras på receptvaran, medan lagret också uppdateras på råvarorna via samma ingredienserna.

Avrundning av försäljningsbelopp

(RTC-35152)

Normalt så kommer Chain Classic att avrunda försäljningsbelopp från kvittot. Undantaget från detta är när kreditförsäljningen uppdateras till kundförsäljningsstatistiken (underlag för utlägg av kreditförsäljning till Cash Settlement).
Då används färdiga avrundade belopp från kvittot.

Öppningsflikarna i "Priskontroll"

(RTC-34829)

Olika inställningar av Priskontroll medför att det kan vara praktiskt att parameterstyra vilken av de fem flikarna som ska visas när programmet startas. 

När Excel och Word inte kan startas från Chain Classic 

(RTC-34228)

Användning av Excel och Word i Chain Classic fungerar bara om det finns en lokal installation av Office-programmen på arbetsstationen. Saknas detta, kommer meddelande att förklara orsaken.
Dessa meddelanden visas också om det bara finns en onlinelösning av Office. Chain Classic kommer då inte att få kontakt med dessa Office-program.

Visningsalternativ i "Uppdatera lager" i inventeringsguiden

(RTC-31532)

I aktiv inventering där inventerade varor ska godkännas och lager ska uppdateras, går det se vilka varurader som redan uppdaterats och vilka som inte uppdaterats.

Det finns tre urvalsalternativ för "Visa varor":

1. "Alla" - Visar alla varurader- De rader som är uppdaterade, visas med en mörkare gråfärg i fälten "EAN/PLU-nr" och "Varutext" (se bild).
2. "Uppdaterade" - Visar bara uppdaterade varurader och alla har då den mörkare grå färgen i de två kolumnerna.
3. "Ej uppdaterade" - Visar bara varor som återstår att inventera/uppdatera. Dessa har normal färg i fälten "EAN/PLU-nr" och "Varutext".

Lagerinformation i Varu- och Pris-register

(RTC-34353)

Knappen för "Lagerinformation" är inte alltid aktiv i Varu- och Prisregister. Den är inaktiv vid följande tre tillfällen:

• Lagerpost saknas på vara i butiken och butiken har inte åtkomst till att se lagerinformation för en annan butik med lagerpost för varan.
• Butiken är inte lagerstyrd.
• Butiken är inte aktiv (kommunikationstyp <> 11).   

RIGAL VPI med endast varuinformation och ändrat varunummer (ingen prisinfo) från Item Master /Cloud

(RTC-34131)

Det är skillnad mellan fältinställningar i Item Master och Chain Classic.
Varuuppdatering utan prisinformation är standard i Item Master, men som utgångspunkt inte tillåtet i Chain Classic.
Det är därför viktigt med en riktig parameterinställning för alla kunder.

Hitta existerande vara via tandem vid RIGAL VPI-import

(RTC-34465)  

Det rekommenderas att aktivera fullt stöd för att söka fram existerande vara via tandemnummer när EAN för huvudvara i RIGAL VPI är okänd i Chain Classic.
Det hindrar att det skapas dubletter av samma vara. Exempel på detta är:

1. Okänd huvudvara i RIGAL VPI, men med tandemEAN som redan finns som tandem på existerande vara i Chain Classic
2. Okänd huvudvara i RIGAL VPI, men med tandemEAN som redan finns som huvudvara i Chain Classic
3. Huvudvara i RIGAL VPI finns redan som tandem på huvudvara i Chain Classic

I dessa fall kommer det att göras ett EAN/PLU-nr byte där existerande huvudEAN i Chain Classic ändras till tandemnummer och nytt huvudEAN från RIGAL-VPI tar över.

Undantag för borttagning av lokala priser vid uppdatering av ordinarie prisändring på profilpris från RIGAL

(RTC-35421)

Det kan parameterstyras om en profilprisändring via RIGAL VPI, ska ta bort ev. tillhörande lokala butikspriser.
Detta gäller inte om butikspriserna har ett aktivt eller framtida kampanjpris, medlemserbjudande eller en butikslokal mixmatch där varan ingår.

Loggning vid utlägg av beställningar till RIGAL

(RTC-35426)

Ändringar som medför utlägg av beställningar till RIGAL, loggas för enklare uppföljning. 

Butiker som visas i "Lagerinformation"

(RTC-35054)

I "Lagerinformation" som öppnas via en knapp i verktygraden från Varu-/Prisregister, och i andra program som visar lagerposter för flera butiker, kommer bara lager för aktiva och lagerstyrda butiker att visas.

Utlägg av "försäljningspris" till Tokheim POS för grupp 1 i mixmatchtyp 35

(RTC-35388)

Mixmatchtyp 35 är en gruppmix där det kan parameterstyras om prispost för grupp 1 ska läggas ut till Tokheim POS.

Använda inköpspris i "Beställningsfördelning Excel"

(RTC-33790)

Beräkning av nettopris på beställningsrad, vid användning av "Beställningsfördelning Excel", utförs på samma sätt som vid manuell registrering av beställning eller vid beställning skapad från POSLog.

Hur nettopriset beräknas, är parameterstyrt och fungerar för varor som inte är kompletteringsvaror.
Antal återstående dagar i aktiv kampanjperiod eller antal dagar till framtida kampanjperiod kan också påverka resultatet.

Optimering av databassökning

(RTC-35227)

Generell prestanda i Chain Classic är framför allt beroende av serverinställningar och serverkonfiguration.
Optimerad indexanvändning förbättrar denna prestanda och ger användarna en ändå bättre upplevelse. 

Nytt godkännande och utlägg av kampanjgrupp till POS

(RTC-29779)  

Hjälpprogram för användning av EG-personal.

Chain Classic version 2.2.0.0.10

Dokument status: RELEASED

Datum: 01 Sep 2023

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.10 ska alltid POS leverera kvitton i POSLog version 81. 

Förbättringar

Skriva rabattalternativ på små rabattprislappar

(RTC-28221)

Funktionalitet för utskrift av små rabattprislappar finns i "Butiksrutiner", "Varuregistrering" och "Prisregistrering". Knappen visas alltid i "Butiksrutiner" men måste specifikt väljas för användning i de andra två registreringsprogrammen.

Det kan parameterstyras om det bara ska vara möjligt att ange en procentuell rabatt eller om det också ska vara möjligt att välja mellan en kronrabatt eller ett rabatterat pris. vilket fall som helst är det bara möjligt att ange två siffror. Det angivna värdet skrivs sedan ut under streckkoden i det valda fältet nedan (2 siffror). 

Användning av "Excel online" 

(RTC-32817)

Chain Classic har många funktioner som behöver en lokal installation av Excel på din arbetsstation. Microsoft erbjuder också en "online Excel-lösning" som inte fungerar i Chain Classic, men det skapade en lösning som förenklar öppningen av Excel-rapporterna.

1. Välj önskad rapport i rapportlistan och tryck på "Excel-knappen".
   • Rapporten flyttas till en egen katalog som bekräftas med ett medddelande.
2. Öppna katalogen "Chain_Print" under katalogen "Dokument"
   • Här kommer de valda Excel rapporterna ligga.
3. Alla Excel-rapportfiler i Chain_Print kan öppnas direkt i den Excel-lösning som är tillgänglig för användare.

Extra utlägg till POS

(RTC-33057)

Det är möjligt att lägga ut all data för en ny butik till POS. Detta innebär att utlägget normalt placeras i katalogen "Skickat" för överföring till POS med möjlighet till extra kopior av filerna till en angiven katalog. Men det kan också anges att utlägget endast ska läggas ut till denna extra katalog och inte till POS.

Krav om att e-postadress måste anges för kassör

(RTC-32629)

Om e-postadressen ska användas som användarnamn för kassören i andra lösningar, rekommenderas att aktivera kravet på att e-postadressen måste anges när du byter eller skapar en ny kassör. 

1. Vid registrering av existerande kassör utan e-postadress är det inte tillåtet att spara utan att detta fält fylls i.
2. Ny kassör kan inte sparas utan e-postadress.
3. Vid uppdatering av kassör och utlägg till RIGAL ingår e-postadress som sista fält.
4. Vid uppdatering av ny kassör från RIGAL, kommer posten avvisas om e-postadressen saknas när systemparameter 988 är på. För existerande kassör med e-postadress ej ifylld, behålls denna oförändrad.

Export vid borttagning av tandem

(RTC-33242)

Vid borttagning av tandem läggs alltid tandemen ut till filen tandem.butnr till POS. Som tillägg kan det också läggas ut raderingspost via RIGAL V-fil.

Skapa butikspris även om EAN = 0

(RTC-32495)

Det är standard att avvisa RIGAL-poster när de saknar EAN. Det finns dock en parameterstyrd funktionalitet för att söka efter produkten via det befintliga profilpriset.

Loggning av godkännande/borttagning i Beställning

(RTC-33186)

Det är parameterstyrt om ändringar i en godkänd beställning ska exporteras till ERP i RIGAL-format. Ändringarna loggas också med användar-ID och tid vid godkännande eller borttagning av autentisering. Om bekräftelse används kommer även denna eller borttagning av bekräftelse att loggas, både i beställningshuvudet och på beställningsraderna. Om bekräftelse inte används kan knapparna Bekräfta/ta bort verifiering döljas för användaren.

Kampanjperiod via ordinarie prisändringar i RIGAL VPI

(RTC-33927)

Det är möjligt att "simulera ett "kampanjpris" genom att uppdatera två vanliga prisändringar från RIGAL VPI.
Detta kan gälla för varor med ett fast pris där det inte är tillåtet att använda ett vanligt kampanjpris i POS.
Du uppdaterar först en framtida "startartikel" med önskad prisändring och sedan en slutpost där ordinarie pris ofta ändras tillbaka till det ursprungliga priset.
Dessa poster kan gärna skickas in i samma RIGAL V-fil.
Detta bör endast användas i särskilda fall och bör inte ersätta användningen av standardiserade kampanjgrupper med alla de fördelar som det ger.

Utlägg av negativt kundsaldo till Tokheim POS

(RTC-33527)

Om kreditkunder betalar för mycket kan kundsaldon bli negativa. Dessutom bokförs negativa belopp till Tokheim POS när uppdateringen kommer från Chain Web via Chain Classic.
När Chain Web är master för kunder uppdateras alla ändringar i Chain Classic.

Alternativ i standard priskontroll

(RTC-33397)

Det är möjligt att ta bort möjligheten att återställa avvisade prisändringsposter via en parameter.
Detta rekommenderas eftersom det kan vara förvirrande att du inte kan utföra återställningen som förväntat eftersom posterna i kön har bearbetats och tagits bort.
Dessutom kan man välja att skjuta upp godkännandet av manuellt ändrade artiklar (försäljningspriset har ändrats) för analys av konsekvenserna av ändringen innan prisändringarna godkänns som helhet.

Förbättringar i standard priskontroll

(RTC-33786)

Användning av standard Priskontroll kan via systemparameter anpassas för olika behov, där priser som ska kontrolleras är tillgängliga i aktiva flikar.
Denna inställning styr om de fem flikarna "Nya priser", "Ordinarie prisändringar", "Kampanjpriser", "Mixmatch" och "Kampanjgrupp" ska vara aktiva eller ej. 

Det går också att välja vad som ska ske med ändrat försäljningspris. Vanligvis kommer ändringen att godkännas direkt, och då tas posten bort.
Alternativt kan sparande och godkännande vänta så att man kan analysera effekten av en prisändring. Posten kommer då att finnas kvar och tas bort först när den godkänns.

Det går också att ta bort funktionalitet för "Återstäillning" av en avvisad profilprisändring. Detta rekommenderas om dessa varuköposter bara är tillgängliga under en kort period tills de är färdigbehandlade.
Risken är att man inte "hinner" återställa posterna under den korta tiden mellan att man trycker på knappen "Avvisa" och nästa varuköbehandling.
I praktiken varar detta "tidsfönster" bara mellan 0-120 sekunder, sedan går det inte att använda funktionaliteten.
För de flesta kommer det därför att vara mindre förvirrande om denna funktionalitet tas bort.

Layout för VPI-mallar

(RTC-30541)

Programmet "VPI-mallar" ger möjlighet till a differentiera mellan olika typer/behov av RIGAL V-fil import. I den första fliken "VPI-mall" visas namn och nummer. I fliken "Fält i mall" visas alla poster i den aktuella VPI-mallen.

Underhåll av mixmatchtyper

(RTC-31184)

För val av vilka mixmatchtyper en kedja använder och anpassning av dessa, används nu programmet "Mixmatchtyper" i menyn Register - Generella.
Denna menypunkt är i utgångspunkt tillgänglig för alla, men systemadministratör kan ändra inställning och vilka mixmatchtyper som ska användas och visas för vanliga användare.

Utlägg av lagerpost i JSON-format

(RTC-31284)

Om parameter för detta är påslagen, så kommer det vid uppdatering av lager att skapas ett automatiskt lagerutlägg i JSON-format.

Införande av 9-siffrigt kassörnummer

(RTC-33444)

I rapporterna "Butiksredovisning" och "Butiksredovisning per kassör" finns det stöd för användning av upp till 9-siffrigt kassörsnummer.

Uppdatering av ny vara från Item Master

(RTC-33599)

När Item Master skapar en ny vara, ska denna normalt sändas som två poster (en VAR-post och en PRI-post) via RIGAL V-formatet till Chain Classic.
VAR-posten måste alltid sändas först, och i denna uppdateras också vissa fält (t.ex. sortimentskod) som egentligen ligger på pris i Chain Classic.
Vid uppdatering av efterföljande PRI-post, kommer dessa fält att behålla sina originalvärden från VAR-posten.

Användning av Excel i "Beställningskriterier"

• Knappar för användning av Excel visas bara om Excel är installerat lokalt på arbetsstationen.
• Export av beställingskriterier till Excel kan endast utföras för butiker markerade med "Beställning" i butiksregistret.
• Import från Excel kan också bara användas för butiker markerade med "Beställning" påslaget i butiksregistret.
• Nya beställningskriterier kan bara läggas upp för aktiva butiker med "Beställning" påslaget i butiksregistret.

Rensning av kampanjpriser, medlemserbjudanden och ordinarie prisändringar via RIGAL V-fil

(RTC-31913)

Det går att ta bort både ett kampanjpris och ett medlemserbjudande med samma start/slut-datum via samma RIGAL V-fil. Detta gäller både aktiva och framtida erbjudanden.
Dessutom kan framtida ordinarie prisändringar tas bort.

Loggning vid borttagning av tandem via RIGAL VPI

(RTC-32771)

Vid borttagning av tandem via post i RIGAL V-fil loggas detta:

• I Uppdateringslogg (vpiins*) kommer detta att räknas upp under "Uppdaterat".
• I standard Fellogg (vpierr*) skrivs meddelande - "Lägger upp borttagningsposter för TANDEM-nr xxx för huvudvarunummer yyy"
• I Total fellogg (vpierrtot) skrivs också meddelande "Lägger upp borttagningsposter för TANDEM-nr xxx för huvudvarunummer yyy"

Varuhierarkilista för "Cloud-export"

(RTC-33345)

Vid behov av export av varuhierarkin til "Cloud", används rapporten "Varuhierarki Excel" under menyn Rapporter - Vara. Rapporten skapas bara till Excel.
Notera att i sista kolumnen kombineras varugrupp och undergrupp med 4 siffror (inkl. inledande nollor) för varje fältvärde (tillsammans 8 siffror).
Varugrupp 1 med undergrupp 10 kommer då att få värdet "00010010" i detta kombinerade fält.

Optimering av procedur (proxy) för uppdatering av varulokala fältvärden från InStore App

(RTC-33888)

Utveckling av generella uppdateringar, från InStore App, säkerställer bra dataflöde.

Chain Classic version 2.2.0.0.09

Dokument status: RELEASED

Datum: 22 Jun 2023  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.09 ska alltid POS leverera kvitton i POSLog version 81. 

Utlägg till Lexmark vid ändring av EAN/PLU

(RTC-32054)

Vid ändring av EAN/PLU läggs nu följande lagt ut till Lexmark:

• Varufil till totalbutik:
  • Borttagningspost för gammalt EAN/PLU-nummer.
  • Ny post för nytt EAN/PLU-nummer. 
• Prisfil till vanliga butiker:
  • Borttagningspost för gammalt EAN/PLU-nummer.
  • Ny post för nytt EAN/PLU-nummer.
  • Poster för pågående kampanjer samt framtida prisändringar och kampanjer läggs ut med nytt EAN/PLU-nummer.

Utlägg til Lexmark vid byte av tandemnummer

(RTC-32319)

När ett tandemnummer angivits på en vara i RIGAL varufil, och detta nummer redan kopplats till en annan huvudvara, blir tandemnumret "flyttat" från gammalt till nytt huvudvaruummer förutsatt att systemparameter 632 är satt. Vid denna operation har det tidigare inte kommit något utlägg til Lexmark, medan det nu läggs ut filer både till totalbutik (libitemlex) och övriga butiker (priceitemlex).

Utlägg till Lexmark vid borttagning av tandemnummer

(RTC-32318)

Vid borttagning av tandemnummer på en vara läggs det nu ut Lexmark-meddelande både till totalbutik (libitemlex) och övriga butiker (priceitemlex).

Parameterstyrd etikettutskrift för Lexmark 

(RTC-32061)

Omsättningskrav för etikettutskrift i Lexmark kan sättas för alla etikettskapande ändringar. Det betyder att det måste finnas omsättning inom ett angivet antal dagar bakåt i tiden för att etikett ska skrivas ut.
Systemparameter 878 har två värden, ett för kampanjpris/medlemerbjudande och ett för alla övriga ändringar. Sätts parametervärde till 0 kommer det inte att vara något krav på omsättning på varan för att etikett ska skrivas.

Dessa parametervärden sätts som utgångspunkt på kedjenivå (Systemparameter), men kan överstyras i enskilda butiker. Butiksanvändare kan ändra dessa värden via fliken "Butiksparametrar" i program för underhåll av butiksregistret.

Chain Classic version 2.2.0.0.08

Dokument status: RELEASED

Datum: 02 Jun 2023  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.08 ska alltid POS leverera kvitton i POSLog version 81. 

Förbättringar

Printerval för etikett i priskontroll och manuell varumottagning

(RTC-31500)

Vid användning av pappersetiketter kommer det vid avslutning av "Priskontroll" eller "Manuell varumottagning" att komma upp en dialog för etikettutskrift med val av etikettyp och skrivare.
Ska standard etikettyp och skrivare användas, behålls standardinställningarna som visas nedan. Etikettyp och skrivare väljs då automatiskt.

Om detta ska överstyras, kan andra alternativ väljas i denna skärmbild.

Utlägg av recept/ingredienser till Tokheim POS

(RTC-30892)

Det går parameterstyra om recept-/ingrediensinformation ska läggas ut till Tokheim POS.
Standard är att informationen läggs ut, men om detta inte är önskvärt kan det ändras via en systemparameter.

Specialbehandling av antal i varumottagning via RIGAL 

(RTC-31684)

Det går parameterstyra uppdatering av varumottagning av D-packvaror via RIGAL så att antal av D-packvaran multpliceras med antal i paket (förpackningar).
Detta gäller bara för utvalda leverantörer.

Alternativa urvalsfält i rapporten "Underlag beställning" 

(RTC-30600)

I rapporten "Underlag beställning" är det i fliken "Alternativ" nu möjligt att använda urval för "Min." och "Max." disponibelt antal.
Standardvärden är från 0 till 99999. Vid användning av minimumvärde = 0 kommer även varor med negativt disponibelt antal att tas med i rapporten.
Anger man ett värde större än 0 i detta fält, kommer bara varor med disponibelt antal större eller lika med detta värde att tas med.

Borttagning av framtida prisändring via RIGAL V-format 

(RTC-31599)

Framtida ordinarie prisändringar kan tas bort via RIGAL V-fil genom att sätta värde C i fält 7.1.5 Kod.
Prisändringarna rensas då i Chain Classic och nödvändiga utlägg skickas till POS.

Import/-export av beställningskriterier från Excel

(RTC-30593)

Vid uppdatering av beställningskriterier via Excel från 3:e part, finns det 2 parameterstyrda alternativ.

Vid användning av basfunktionaliteten kan bara parameterstyrda butiker uppdateras, och det sker per vara för angivna butiker med angivna värden.

Dessutom finns ett alternativ där uppdatering per vara kan ske för alla butiker 

Innehållet i Excelfilen ska bestå av följande fält, varav de i blått kan ändras:

• Butiksnr
• EAN
• Varutext
• Färg
• Beställningspunkt
• Bestillningskvantitet
• Rensning (0 = Nej / 1 = Ja)
• EAN textfält (Ex. EAN1234567)

Ny butikspost kan skapas eller en existerande post kan tas bort. Antal kan ändras (0 är giltigt).

Tillåt EAN = 0 i RIGAL prisändring

(RTC-31303)

Det går parameterstyra uppdatering av prisändringar från RIGAL V-formatet där EAN = 0.
Förutsättning för detta är krav på unik kombination av varunr och försäljningsenhet (viktkode) i RIGAL-posterna.
Om detta är uppfyllt, ska känd vara i Chain Classic kunna sökas fram via kombinationen av varunr och försäljningsenhet.
Om poster med EAN = 0 inte finns via en unik kombination av varunr och viktkode, kommer posterna att avvisas med ett felmeddelande i VPI felloggar.

Uppdatering av paketvaror i beställning från InStore App

(RTC-31392)

Varumottagning för paketvara från InStore App specialbehandlas vid uppdatering från POSLog.
Vid mottagning av paketvaran skapas varutransaktioner för varan/varorna som ingår i paketvaran,
Lager uppdateras också för dessa varor.

Behandling av RIGAL I-filer med "0-ordrar"

(RTC-31257)

Det kan parameterstyras om en RIGAL varumottagsfil (I-formatet) där alla varurader har mottagit antal = 0, också ska behandlas. Då kommer ordern att få status "Mottagen".
Det skapas en RIGAL "kvittofil" som kopia av de ursprungliga RIGAL-posterna.

Ändring i export av tankstatus till Reporting

(RTC-31543)

Endast för bruk med Tokheim POS. Om det finns ett "L15-värde", kommer detta att exporteras till Reporting.
Om ett sådant värde saknas, kommer fältet "Mängd" att läggas ut.

Standardisering av datumtyp i rapporturval

(RTC-31479)

I datumurval är årtal standard satt till två siffror för alla rapporturval med en hjälpknapp för kalenderuppslag. 

Uppdatera endast varuinformation via RIGAL VPI

(RTC-31803)

När ItemMaster (IM) bara sänder varuinformation via RIGAL V-formatet till Chain Classic, uppdateras inte posterna innan prisinformationen är på plats.
Det har införts ett parameterstyrt undantag från detta. När denna parameter slås på, kommer VPI-poster utan pris att uppdateras. Pris behålls då oändrat.

Loggning när nytt kampanj-/medlemserbjudande "delar" datum-/tid intervall

(RTC-29764)

Vid nyupplägg av kampanj och medlemserbjudande är det parameterstyrt om det är tillåtet med delvis överlappning.
Om detta inte är tillåtet eller det lagts in ett ogiltigt värde med samma start-/sluttid, förklaras detta med informativa felmeddelanden i användargränssnittet om varona avvisas.
Detta gäller både i Kampanjgrupp och för manuella kampanjer (skapat vid Prisändring) oavsett metod för inhämtning av data.
Förutom felmeddelandet i användargränssnittet, kan loggposterna hämtas via knappen "Avvisade varor i kampanjgrupp".

Samma knapp finns också i programmet för "Mixmatch".

Hitta och ta bort tandemnummer som också finns som huvudvara

(RTC-31081)

Tandemnummer som också finns som huvudvara, är nåt som måste korrigeras.
Ett hjälpprogram kan korrigera detta genon att ta bort tandemnumret i Chain Classic och lägga ut borttagning av tandem til POS.

Kontroll av fel i JSON lagerformat

(RTC-30567)

Förhindra att felposter i detta JSON-format blir kvarobehandlade.

Underhåll av "Fältvärden i butik"

(RTC-30424)

I fliken "Fältvärden i butik" i "Varuregister" och "Prisregister" kan man välja vilka fält som butikerna i en kedja ska kunna se och ändra.
Ointressanta fält döljs. Detta är parameterstyrt.

Borttagning av Chain Classic användare

(RTC-31487)

Vid borttagning av användare i Chain Classic raderas alla användarrelaterade data. 

Utlägg av borttagningsposter för butikslokala mixrader vid borttagning av butikspris

(RTC-31530)

När ett butikspris ska raderas, kontrolleras det nu om det finns några aktiva eller framtida lokala butiksmixar där denna vara ingår.
Om så är fallet, läggs det ut borttagningspost för dessa poster till POS.

Chain Classic version 2.2.0.0.07

Dokument status: RELEASED

Datum: 27 Apr 2023 

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.07 ska alltid POS leverera kvitton i POSLog version 81. 

Förbättringar

Övergång till kampanjsgruppsutlägg

(RTC-28386)

Användning av kampanjgruppsutlägg rekommenderas då det betyder mycket vid felsökning vid avvikelse, men viktigast är säkerhet och prestanda som är mycket bättre.
Funktionaliteten kan aktiveras på manuellt via systemparameter, men det rekommenderas att använda eget program för detta för snabbare och säkrare resultat vid konvertering av existerande kampanjgrupper för nytt utlägg i kampanjgruppsformatet.  

VPI-mall för etikett

(RTC-30032)

För 3:e-partssystemet Lexmark används egen VPI-mall för etiketter.
Menypunkt för denna etikettmall är: "Register"/"Generella"/"Villkor för Lexmarkutlägg", som öppnar programmet "Etikettmallar".

I kolumnen "Filutlägg" (samma som "Uppdatera" i VPI-mall), betyder "Ja" att ändring av aktuellt fält medför utlägg av Lexmark-fil. 
I kolumnen "Etikettutskrift" (samma som "nollställa" i VPI-mall), betyder "Ja" att ändring i detta fält aktiverar etikettkrav i Lexmark-utlägg.
Standard är att endast ändringar av utpris (ordinariepris, kampanj- och medlemserbjudande) ska ge etikett i Lexmark.
Det går skriva ut etikett i Lexmark även víd ändring av andra fält. 
Notera att detta bara gäller fält i "Pris" (Lexmark varuändringar går bara till totalbutik) såsom leverantör, bestnr, etikettnr och sortiment.

Byte av butiksnummer

(RTC-28607)

När gammalt butiksnummer behålls, genom byte av butiksnummer, säkerställs det mot problem i kvittouppdatering från 3:e-part (till exempel webbutik).
Detta kan ske om butiksnummer inte ändras i alla system samtidigt. 
I programmet "Ändring av butiksnr" i fliken "Alternativ" är därför detta förvalt, men kan överstyras om det är full kontroll på att butiksnummerbyte sker samtidigt i alla lösningar.

Automatisk upplägg av varumottagning vid internöverföring

(RTC-28722)

Oavsett vilken RIGAL-kod som används för faktura eller beställning/bekräftelse, kommer det alltid att skapas en automatisk varumottagning vid internöverföring mellan butiker.

Export av alla kunder till Customer Service

(RTC-29646)

För Export av alla kunder i Chain Classic via JSONL-formatet, till Customer Service (Chain Web) används programmet: "System"/"Administrativa rutiner"/"Utlägg av data"/"Kunder till customer service".

Exportera alla kundgrupper till Customer Service i JSON-formatet 

(RTC-29536

Via programmet "System"/"Administrativa rutiner"/"Utlägg av data"/"Kunder till Cust. Serv." kan kundgrupper läggas ut i JSONL-format till Customer Service i Chain Web. 

Borttagning av lokala butikspriser

(RTC-30014)

Denna funktionalitet används när en butik endast ska ha profilpriser, och aktiva lokala butikspriser ska därför tas bort. 

• Prestandan är väsentligt förbättrad.
• Det kan väljas att skriva en rapport, men bara om antal förväntas vara under 200.000 lokala prisposter.
• Möjlighet att skapa urval på varugruppslista har lagts till.
• Antal poster visas direkt i jobblistan, rapport inte skapas för detta.

Loggning av "Mottagning av weborder"

(RTC-20334)

Om "Mottagning av weborder" används finns behov av att logga alla aktiviteter knutna till lagring av ändrad lagerplats.
Om webservice (WS) inte fungerar kommer klienten att hänga sig och kan också att avbrytas.
Loggfilen mottawebmmdd.butnr läggs dagligen ut på loggkatalogen via standard utlägg.

Import av sortimentlista Excel i fullt format 

(RTC-30412)

Utöver standardformat finns ett parameterstyrt fullformat av "Sortimentlista Excel".
Dett fullformat motsvarar det Excel-dokument som skapas i rapporten "Sortimentlista Excel".
Det innebär också att VPI-import bara har stöd för detta format. 

Förbättrad uppdatering i sökfunktion i lagerprogram för drivmedel

(RTC-30780)

Längst upp i den uppdaterbara delen i programmet "Manuell tankstatus" kan HK-användare söka efter aktiva butiker med minst en ansluten tank.
För butiksanvändare visas bara egen butik om det finns minst en tank registrerad i butiken. 
Dessutom kommer det nu i det vanliga registreringsprogrammet, "Tankstatus", alltid att visa korrekt produktnamn om man ändrar tanknr/tankgr.

Alternativ för utlägg av receptvara till Tokheim POS

(RTC-29655)

Utlägg av info för servicehandels-varor kan parameterstyras för att förhindra att varor raderas oavsiktligt från ett recept i Tokheim POS.

Chain Classic version 2.2.0.0.06

Dokument status: RELEASED

Datum: 20 Feb 2023  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.06  rekommenderas det att POS levererar kvittoformat i POSLog version 81. 

Förbättringar

Prisändring av utgången vara via RIGAL

(RTC-29117)

Utgången vara (från leverantör) innebär att varan har en framtida borttagningspost för när varan ska raderas från systemet. Hur många dagar framåt i tid detta datum sätts är parameterstyrt. När det kommer en RIGAL-fil med besked om utgången vara, "U", skapas en borttagningspost. Borttagningsdatum blir ett framtida datum motsvarande idag plus parameterstyrt antal dagar. 

Utgången vara betyder att varan inte längre kan beställas, beställningsnummer raderas därför från etikett och elektroniska hyllkantsetiketter

Om besked om utgången vara kommer tillsammans med en eller flera framtida prisändringar skapas flera prisändringsposter. Den första med dagens datum för att säkerställa gällande pris, att varan uppdateras med sortimentskod "U" och att beställningsnummer därför raderas från pappers- och el. etikett. Det skapas också en post per framtida prisändring, där datum för den sista prisändringen läggs ihop med parameterstyrt antal dagar fram i tiden för att sätta borttagningsdatum på varans borttagningspost.

Uppdatering av mixmatch i POS vid ändring av gällande undantagsvarugrupper

(RTC-28210)

Vid underhåll i programmet "Speciell varugruppslista", en lista med varor som inte ska ge prisreduktion på utvalda mixmatchtyper, läggs all mixmatchinformation (endast mixhuvud) ut på nytt. Så att alla mixmatch det berör i POS, uppdateras med korrigeringar av gällande undantagsvarugrupper.

Betala presentkort med annat presentkort och/eller tillgodokvitto

(RTC-27954

Om presentkort och/eller tillgodokvitto används för att betala ett nytt presentkort så skapas en särskild finanstransaktion för detta. 

Integration med Q-bank (bildbank)

(RTC-26841)

Detta är en moln-anpassad bildbankslösning. Istället för att hämta bilder från lokal server hämtas de via URL och bildnamnet är identiskt med EAN för huvudvara eller kopplat tandemnummer. 

Nettoprisändring vid uppdatering av varumottagning

(RTC-28738)

Det finns tre möjliga parameterstyrda alternativ för hur nettopris ska uppdateras via RIGAL/POSLog.

• Alla nettoprisändringar uppdateras.
• Endast nettoprisändringer med belopp > 0 uppdateras.

• Inga nettoprisändringar uppdateras, ursprungligt värde är alltid det samma.

Återställ svinntransaktioner vid nollställning av försäljningsdag

(RTC-28665)

Om försäljningsdag måste all försäljningsdata raderas för en hel dag och sedan läsas in igen. Det betyder alla kvitton som levererats till Chain Classic inom angivet datumintervall. Detta inkluderar varutransaktioner för inventeringsvinn, om de levererats via POSLog. 

Ändra nettopris direkt i elektronisk varumottagning

(RTC-28547)

I "Elektronisk varumottagning" går det som standard inte ändra nettopris, som det är i det specialanpassade programmet "Varumottagning". Men det går parameterstyra "El. varumottagning" så att nettopris kan redigeras direkt i programmet utan att använda "Manuell varumottagning".

Underhåll av poster i "Varutransaktioner"

(RTC-28638)

I programmet "Varutransaktioner" visas alla transaktioner oberoende av transtyp.

Det går endast lägga upp/kopiera/motpostera följande transaktionstyper:

• 1  Synligt svinn" (1)
• 2  Intern förbrukning" (2)
• 6  Lagerjustering" (6)
• 11 Nedpackning

Alternativ:

• 7  Inventering - kan parameterstyras till om detta ska tillåtas eller inte.

Följande transaktionstyper kan inte registreras, kopieras eller motposteras:

• 3  Retur
• 4  Reklamation från kund, utförs i POS (Transaktionstext innehåller "kassa")
• 5  Varumottagning
• 8  Inventeringssvinn
• 9  Internöverföring 

Knapp för "Kopiering" och "Motpostering" (= tabort-knapp) är avaktiverad för de transaktionstyper som inte är tillåtet att registrera.

Uppdatera klientfiler i bakgrunden

(RTC-28374)

Av säkerhetsskäl kan det vara en fördel att installera klient-filerna vid uppdatering av patch i bakgrunden. För detta krävs minst en AD-användare med "Single Sign On" (SSO). Då denna loggar in automatiskt utförs klientuppdatering utan "störningar".

Datumbegränsad nyregistrering av poster i "Drivmedel"

(RTC-29240)

Vid nyregistrering av poster i serviceprogrammen "Leverans". "Manuell tankstatus" och "Tankstatus" under "Drivmedel", går det parameterstyra hur långt tillbaka i tid det går att nyregistrera en post. Felmeddelande kommer då upp om för gammalt datum väljs och man kan då inte spara.

Trunkering av varunamn vid export Tokheim POS

(RTC-28646)

Som följd av begränsningar i 3:e-partssystemet Tokheim POS är antal tecken i varunamn, vid export, nu begränsat till 20 tecken.

Fel butiksnummer i POSLog

(RTC-28614)

Ifall butiksnummer ska bytas i Chain Classic och detta inte utförs samtidigt på andra ställen, till exempel i webshop, får detta stora konsekvenser i systemet. För att undvika att det kommer in försäljning på saknad butik i Chain Classic, avvisas dessa kvitton och loggas så att de kan identifieras och skickas in på nytt med rätt butiksnummer. 

Övergång till kampanjgruppsutlägg  

(RTC-28386)  

Användning av kampanjgruppsutlägg rekommenderas då det betyder mycket för felsökning vid avvikelse, men viktigast är säkerhet och prestanda som är betydligt bättre. Funktionaliteten kan aktiveras manuellt via systemparameter, men det rekommenderas att använda särskilt program för detta för snabbare och säkrare resultat vid konvertering av existerande kampanjgrupper till nytt utlägg i kampanjgruppsformatet.

Begränsa möjlighet att skapa informationstext under HK-nivå

(RTC-27990)

För programmet "Varuregister"/"Varuinformation" finns en parameterstyrt begränsning som förhindrar att det skapas informationstexter på lägre nivå än HK-nivå (profil 0/butik 0). De informationstyper detta gäller är följande:

1: "Etikettexter"
2: "Viktdeklaration"
3: "Varuinformation"
4: "Teknisk information"

Export av ej mottagna beställningar till Chain Web

(RTC-28298)

För export, av ej mottagna beställningar, från Chain Classic till Chain Web i formatet J-SON, används programmet "Beställningar till Procurement".

Programmet ligger under "System"/"Administrativa rutiner"/"Utlägg av data. Samlat utlägg läggs på parameterstyrd plats. Om så önskas kan också sendes/backup användas för backup.

Blanka fält eller standardvärden för ny vara

(RTC-28978)

Om parameterstyrning till VPI-mall för standardvärden inte används, blir alla fält blanka när "Ny vara" skapas. Detta är standard.

När ny vara skapas manuellt i programmet "Varuregister" i Chain Classic kan det vara önskvärt att några fält alltid uppdateras med samma standardvärden. Detta kontrolleras genom parameterstyrning i en anpassad VPI-mall med standardvärden för "Ny vara". Det är följande fält som kan sättas upp med standardvärden: 

I fliken "Vara":
  - hgr
  - ugr
  - prodnr
  - sgr
  - fgr
  - momsgr
  - branch och agr om bransch > 0
  - enva
  - varutyp
  - lager
  - beställ
  - enhet
  - aktiv
  - opris
  - krabatt
  - fabrikatnr
  - chgmva
  - lokalstyrt

I fliken "Tillägg vara":
  - modellnr/modellnr2
  - färgnr
  - storlnr
  - fabrikatnr
  - matrialkod
  - säsongnr
  - garantikl
  - individtyp
  - idkrav
  - tryckbild
  - ursprung
  - larmvara
  - kross
  - kunlot

Chain Classic version 2.2.0.0.05

Dokument status: RELEASED

Datum: 18 Jan 2023  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.05 rekommenderas det att POS levererar kvittoformat i POSLog version 81. 

Förbättringar

Loggning av ändringar i kundordrar

(RTC-27035)

Borttagning av orderrad och orderhuvud loggas i "Borttagna kundordrar" under "Rapporter"/"Loggar". 

Även prisnedsättningar loggas om ändring av försäljningspris överstiger parameterstyrda referensvärden. Det är två värden som måste uppfyllas, det första anger min. radsumma (försäljningspris före ändring) på en rad, och andra värdet anger min. total prissänkning som är gjord på denna rad.

Loggning av internöverföring

(RTC-28535)   

Vid internöverföring loggas detta i loggfil: internlogg_DD-MM-YY.butnr.

Loggning gäller både om det gjorts via InStore App eller direkt i Chain Classic. Ifall det görs i Chain Classic skrivs det "CC CLIENT" så att det framgår hur denna transaktion skapats. 

Begränsa valmöjligheter för butiksanvändare i kampanjgrupp

(RTC-28230)

• Det kan väljas om butiksanvändare eller alla användare, undantaget utvecklingsanvändare, ska ha begränsad åtkomst till funktionalitet vid underhåll av kampanjgrupp. Flikarna "Kampanjpris", "Medlemserbjudande" och "Mixmatch" kan alla avaktiveras, antingen endast för butiksanvändare eller för alla användare, undantaget utvecklinganvändare som alltid har åtkomst till alla flikar.

• Det går också spärra manuella val av kampanjID när butikslokal kampanjgrupp skapas, detta gäller oavsett användartyp. Denna funktion förutsätter en önskan om att alla butikslokala kampanjgrupper alltid ska ha samma kampanjID. Detta värde för kampanjID parameterstyrs.

Utlägg av informationstext i beställning till leverantör, via RIGAL

(RTC-27713)

För information till externa lösningar läggs informationstext ut via RIGAL I-fil, om det angivits i beställningsfälten "Meddelande till leverantör" och "Referenstext". 

Varutransaktionslista Excel

(RTC-26927)

Genom att avgränsa urval på transaktionstyp, period och butik(er), ger rapporten "Varutransaktionslista Excel" en överblick över perioden på ackumulerade värden, där inköpspris är summerat per butik per undergrupp (till skillnad från den vanliga varutransaktionslistan). 

• Om inköpspris saknas i varutransaktion hämtas detta från ordinariepris.
• Det skrivs en flik för varje butik i Excelrapporten, med butiksnr som fliknamn.
• Det skapas också en PDF-rapport med samma upplysningar.

Chain Classic version 2.2.0.0.04

Dokument status: RELEASED

Datum: 19 Dec 2022  

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.04 rekommenderas det att POS levererar kvittoformat i POSLog version 81. 

Förbättringar

Uppdatering av ordinariepris i kampanjgrupp

(RTC-27852)  

I kampanjgrupp finns möjlighet att använda funktionalitet för att ange fast kr- eller %rabatt på varurad i både kampanj eller medlemerbjudande. Vid ändring av ordinariepris i "Priskalkyl", räknas erbjudandepris om även i kampanjgrupp och ändring till POS läggs ut via det utläggsalternativ som används, kampgr eller prisfil.

Ange fast bruttoförtjänst på RIGAL-uppdaterade varugrupper

(RTC-26674)

Det går ange fast bruttoförtjänst på ordinarie priser för varor på angivna varugrupper. Nytt utpris kommer då att räknas om och avrundas i förhållande till detta, när de uppdateras via RIGAL VPI. 

Underhåll görs i registervårdsprogrammet "Bruttoförtjänst i RIGAL" där det går lägga in fast bruttoförtjänst för varor i nya varugrupper och ändra på befintliga. 

Loggning av ändringar på utvalda varufält

(RTC-27142)

Det går välja om loggning ska ske, vid ändring på alla varufält märkta med "Uppdatering" = "Ja", i en utvald VPI-mall. Detta gäller då bara för en utvald VPI-mall, och då vid manuell ändring direkt i Chain Classic eller uppdatering via RIGAL VPI.  

Ändringarna loggas i loggkatalogen med filnamn "chgvaruddmmyyyy.txt". Både nytt och gammalt värde visas, och ackumuleras i denna månadsfil.

Loggning av RIGAL X-filer i VPI-logg

(RTC-27143)

Det går logga uppläggning och uppdatering av mixmatch via RIGAL- X-filer i VPI-loggar. Meddelandetexten är formaterad på samma sätt som vid loggning från uppdatering av RIGAL V-formatet och J-formatet (utökat J-format = V-fil i innehållet).

Alla meddelanden skrivs i standard VPI-loggar (vpierr*., vpierrtot.* och VPIins*.*) 
Det skrivs ingenting i standard fellogg/uppdateringsloggar (err*.* errtot*.* eller ins*.*) 

Specificerade varugrupper/producenter ska inte uppdateras via RIGAL VPI

(RTC-26673)    

Det går att undvika uppdatering på varor, vid ändring via RIGAL V-/J-filer, om det gäller parameterstyrda varugrupper och/eller producenter.

Avvisningar loggas i någon av filerna VPI-err*.* eller err*.*

Streckkoder i lagerrapport "Fellista"

(RTC-27037)

Det är möjligt att skriva ut streckkod på varorna i lagerrapporten "Fellista". Detta görs som standard endast för varor med negativa lagerantal, men det går också att sätta upp "Skriv streckkod" som standard. Något som måste till om man tar ut denna rapport vid EOD.

Avskriv ej levererade rader vid första varumottagning

(RTC-26858)

Om funktionalitet för att stänga order vid första varumottagning och avskriva ej levererade rader används, ska alla rader kvitteras vid utlägg av RIGAL I-fil, även de ej mottagna.

L15 funktionalitet per butik

(RTC-26923)

Det går att välja om en butik ska ha möjlighet att använda funktionalitet för L15 kompenserade värden. Detta gäller för 3:e-partssystemet Tokheim.

Utlägg till Reporting:

• Endast för butik med denna funktionalitet aktiv.
• Mängdfältet  för Reporting uppdateras om "kompenserad mängd" > 0.

Underhåll av Tankstatus:

• Fältet för "L15 kompenserad" mängd visas endast för butik med denna funktionalitet aktiv och "kompenserad mängd" > 0.

Loggrapport loggtyp 80:

• I loggtyp 80 loggas ändringar av "kompenserad mängd".
• Rapporten klarar också loggposter med endast 7 fält, utan "kompenserad mängd". Då visas fältet "L15 kompenserat" = 0.

Manuell tankstatusregistrering 

(RTC-26929)

Vid användning av 3:e-partssystemet Tokheim kan manuell uppdatering, generellt underhåll eller borttagning av registrerad tankstatus görs i drivmedelsprogrammet "Manuell tankstatus". 

Resultatet läggs ut till "Reporting".

JSON till Inventory Module 

(RTC-27043)

Inventory Module är en cloud modul som är lager-master. Chain Classic lägger ut komplett lagerfil i JSON-format till en särskild katalog för vidare användning i Inventory Module. Viktigt att "Export av lager till Inventory" är ikryssat.

Chain Classic version 2.2.0.0.03

Dokument status: RELEASED

Date: 07 Nov 2022 

Förutsättningar för uppgradering

Med uppgradering till Chain Classic version 2.2.0.0.03 rekommenderas det att POS levererar kvittoformat i POSLog version 81. 

Förbättringar

Exkludera varugrupp från snabbprisändring i mixmatch

(RTC-26094)

Det går sätta upp varugrupper så att de inte blir med i mixmatch via snabbprisändring (Hämta varor via urval), in i mixmatch. Vilka mixmatchtyper detta ska gälla måste sättas upp. Det är dock fortfarande möjligt att lägga in varor från exkluderad varugrupp, då det förväntas att den som gör jobbet har kontroll på detta. 
Endast för mixmatchtyper uppsatta med denna funktionalitet visas knappen "Ingen prissänkning". Bakom denna knapp visas den/de varugrupper som exkluderas vid snabbprisändring i aktuell mixmatchtyp.

E-handel: Uppdatera varumottagningskvitto i Chain Classic

(RTC-25897)

Automatisering av mottagning av varor i butik gör att "Mottagning av weborder" i Chain Classic inte används, men att statusfält fortfarande uppdateras.

Loggning av kundändringar

(RTC-26092)

Om kundändringar ska loggas går det ange vilka kundposter som ska loggas vid ändring.

Ändringslogg med en post per ändrat fältvärde skrivs till filen "chgkunde<mmåååå>.txt" i "LRS"/"logg-katalogen".

Ny rapport "Kundändringslogg" som visar denna logg ligger under "Rapport"/"Loggar".

Provisionsförsäljning - butik i butik

(RTC-26096)

Provisionsförsäljning efter provisionsvarulista, i ett särskilt registervårdsprogram, läggs ut till EG Cash Settlement efter varje EOD. Det går endast lägga upp och använda en provisionsvarulista per butik.

"Radera/ta bort från kassa" loggar leverantör i rapport 

(RTC-26095)

Vid användning av programmet "Radera/ta bort från kassa" kommer leverantörsnr och leverantörsnamn också att visas i alla rapporter som skapas, oavsett urval.

Förhindra mixmatchkonflikt

(RTC-25910)

Om en vara redan finns i en mixmatch och samma vara läggs upp i ny mixmatch kontrolleras startdatum/-tid och slutdatum/-tid. Om dessa sammanfaller kommer den nya mixvaran att avvisas. Det kan nämligen inte hanteras två sådana köposter med samma start/slut-datum/tid. Denna avvisning presenteras antingen med meddelande och eller loggas i loggrapport för loggutskrifter.

Detta gäller:

• Manuell inläggning
• Hämta nya varor
• Hämta varor via urval 
• Hämta varor via varugr 

Förväntat datum i "Beställningsfördelning Excel"

(RTC-26399)

Vid användning av "Beställningsfördelning Excel" kan användare välja att antingen göra beställningar eller varumottagningar. I båda dessa fall sätts förväntat leveransdatum utan värde i programmet "Beställning".

Sortimentslista Excel

(RTC-25218)

Rapporten "Sortimentslista Excel" kan skapas med standard 39 kolumner eller via parameterstyrning med utökat format, alla 53 kolumnerna.

Vem är "chef" för mixmatch 

(RTC-25909)  

Varor i mixmatch som överlappar är inga problem om det är skillnad på både start- och slutdatum/tid. Men det går inte för Chain Classic att ha två poster på samma mixvara, på samma nivå (butik eller profil), med samma start- eller sluttid. Om detta sker medför det alltid att den ena posten avvisas. Det är samma regler som gäller för kampanjpris och medlemserbjudanden. Det rekommenderas därför att man tar beslut om vad som faktiskt ska prioriteras.  

Chain Classic version 2.2.0.0.02

Dokument status: RELEASED

Datum: 03 Oct 2022 

Förutsättningar för uppdatering

Med uppgradering til Chain Classic version 2.2.0.0.02 rekommenderas det att POS levererar kvittoformat i POSLog version 81. 

Förbättringar 

Användning av lägsta nettopris i "Beställningsfördelning Excel"

(RTC-25219)

Standard funktionalitet i programmet "Beställningsfördeling Excel" är att nettopris ALLTID uppdateras från kalkylarket om detta har ett värde > 0.

För alternativet "Beställningsförslag":

Om nettopris i kalkylarket är 0 kopieras detta från priskalkylen och då väljs lägsta  tillgängliga nettopris på aktivt ordinariepris eller kampanjpris  (vid önskat leveransdatum), och sätts på beställningsraden. Det kontrolleras dock inte på nettopris för ev. aktivt medlemerbjudande.

För valet "Varumottagning":

Vid standard konfiguration kontrolleras det inte på lägsta nettopris i priskalkylen.

Utökad funktionalitet:

Det går också att parameterstyra så att även medlemserbjudande inkluderas när lägsta nettopris i priskalkylen ska räknas fram. Detta gäller då komplett kontroll av ordinarie-, kampanj- och medlemerbjudande för både "Beställningsförslag" och "Varumottagning" i programmet.

Alla butikspriser ska ha samma värde på viktkod och fastpris

(RTC-23534)

Det går att alltid ha samma värde på viktkod och fastpris på profilpris och alla butikspriser på samma profil, också när ändringar sker via RIGAL-uppdatering.

Beställningsfördelning Excel och lägsta nettopris från priskalkyl, vid manuell varumottagning

(RTC-25221)

Vid användning av "Manuell varumottagning" och "Beställningsfördeling Excel" finns möjlighet att hämta lägsta nettopris på ordinariepris, kampanjpris eller medlemserbjudande i priskalkylen (om aktiva för valt datum), om nettopris = 0 i Excel kalkylark. Om nettopris i kalkylark > 0 används dock ALLTID belopp i kalkylark.

Som standard kontrolleras nettopris ENDAST mot ordinariepris och kampanjpris för "Beställningsförslag". För varumottagning görs det ingen kontroll.

Behandling av Coopay reservlösning i finansredovisning

(RTC-24960)

I de fall Coopay-betalningar inte genomförs innan EOD, behandlas detta med reservlösning och totalbelopp visas i båda butiksredovisningsrapporterna. Dessutom skickas information om detta via finansutlägg till EG Cash Settlement. 

Mixmatch med varor som saknas i varuregistret

(RTC-24623)

Det är standard att avvisa hel mixmatch när det finns en eller flera okända varor. Det går välja de mixmatchtyper, där det ska vara möjligt att bortse från standarden och istället skapa en mixmatch med endast de kvarvarande kända varorna i RIGAL-filen.

Alternativ borttagning av mixmatch

(RTC-24624)

Standard för borttagning av varurad i mixmatch, från ERP via RIGAL-utlägg, är att lägga ut komplett mixmatch till Chain Classic med alla varurader, och med aktivt borttagningsmeddelande på varje mix-varurad som ska tas bort. Det finns också ett inställningsalternativ där det blir går att endast lägga ut de varurader som ska vara kvar i mixmatchen, resterande varurader raderas då från aktiv mixmatch. Om utlägget saknar varurader leder det till att hela mixmatchen avslutas/raderas. 

Inläsning av JSON-fil från StoreMaster

(RTC-25721)

Vid inläsning av JSON-fil från StoreMaster ingår också dessa fält:

• Adress
• Öppnat datum
• E-post 
• Lagerstyrt
• Mobilnr
• EAN-platsnr
• Andra butiker med lager som denna butik kan se.

Wet Stock - justering av tanknivå

(RTC-24621)

"Justering av tanknivå" väljs vid manuell justering av tanknivå i programmet "Leverans". Justerade poster visas i en egen kolumn i programmet. Information om justering av tankstatus läggs ut till "Reporting". Funktionen är bara tillgänglig när ny post skapas. Leveransnummerserien för detta är paramaterstyrd och uppdateras automatiskt vid val av "Justering av tanknivå".
Om användare ångrar val av "Justering av tanknivå" och tar bort notering eller avbryter hela registreringen, så kommer räknaren för leveransnummer att räknas tillbaka igen för att slippa att det skapas "oanvända" hål i nummerserien.

Wet Stock och temperaturkompenserat mängd i "Tankstatus"

(RTC-25555)

Temperaturkompenserad mängd "L15" visas i eget fält i program för "Tankstatus".

Om detta värde = 0 visas inte fältet och nivåvärdet läggs ut till "Reporting" istället.

Uppdatering av tankstruktur till Tokheim

( RTC-24058)

När tankstruktur uppdateras till 3:e-partssystemet Tokheim POS och det blir ändring i kapacitet på en tankgrupp, kommer detta att uppdateras på tankgrupp oavsett om tanken är ansluten eller inte. Vid saknad tankinfo skapas en ny tankgruppsinfo och uppdateringen exporteras till Tokheim POS.

Chain Classic version 2.2.0.0.01

Dokument status: RELEASED

Datum: 16 Sep 2022 

Förutsättningar för uppdatering

Vid uppdatering till Chain Classic version 2.2.0.0.01  rekommenderas det att POS levererar kvittoformat i POSLog version 81. 

Förbättringar 

Rapport för makulering i självbetjänad kassa

(RTC-23527)

Rapporten "Kassörstatistik - Självutcheckning visar antal kvitton som makulerats och/eller har rader som är raderade från självbetjänad kassa.  Dessutom visar den vilken kassör som gjorde detta. 

Begränsa utlägg till färskvaruvåg och el. etiketter

(RTC-23517)

Man kan begränsa utlägg till el. etiketter och färskvaruvågar till endast de faktiska ändringar som gäller dessa lösningar.

Montering som länkobjekt

(RTC-23520)

Det är inte bara pant som kan användas som länkobjekt. "Montering" kan också användas för detta. Till exempel för en värmepump väljer du länkposten "Montering" och länktyp 2, då påverkas inte pantredovisningen. Särskilda justeringar har även gjorts på det elektroniska hyllkantssystemet Breece. Summan av huvudvara och länkvara (t.ex. värmepump och montering) slås samman och texten inkl. montering (eller vilket namn denna varan har) visas på Breece-displayen.

Borttagning av sista pris raderar också vara i Lexmark

(RTC-24697)

Vid borttagning av pris raderas detta från 3:e-partslösningen Lexmark. Om priset är det enda återstående,  tas också varan bort från Lexmark.

Utlägg av ekologisk märkning i viktformatet XML

(RTC-24625)

Det går ange butik som Debio-godkänd, detta gör att ekologiskt märke alltid läggs ut till viktformatet XML.

Borttagning av pris via RIGAL

(RTC-24622)

Borttagning av pris och vara om det bara finns ett pris, utförs genom att sätta funktionskod "S" i fält 5 i RIGAL V-fil. Borttagning görs då omedelbart. 

Aktivt varukönr i "Varu- och Prisregister"

(RTC-24541)

Det blir allt viktigare, speciellt för EG:s personal som måste reda ut vilken av flera kampanjpriser som är det som är aktivt i POS. Detta visas i både "Varu- och Prisregister" för ordinarie pris, kampanjpris, medlemspris och tidsstyrt pris.

Återställ saknade varuköposter

(RTC-24400)

Om en butik saknar köposter för en vara med kampanjpris, medlemserbjudande eller mixmatch (inkluderar också framtida prisändringar). kan dessa återställas.
Detta kan göras på saknad vara  i "Prisregister" av antingen HK-användare, butiksanvändare eller teamanvändare. Gällande köposter visas under fliken "Köposter i butik". Genom att trycka på knappen "Kontrollera kö" återställs saknade köposter, som beskrivet ovan. För HK-användare kontrolleras vald vara för alla butiker, för teamanvändare för alla butiker på aktuellt team och för butiksanvändare endast på aktuell butik.  

Skapa lokal kampanj från InStore App

(RTC-18658)

Det går att välja en vara i InStore App för att sedan skapa en lokal kampanj (ej kampanjgrupp) i Chain Classic. Därefter läggs kampanjen ut till POS. Gällande regler för kampanj, enligt till parameterinställning, måste följas och vid ogiltiga data avvisas uppdateringen. Avvikelser loggas i loggutskrifter - post 28 "Avvisade butiksprisändringar från ISA".

Lägg inte ut borttagna varor till POS 

(RTC-23707)

Vid användning av borttagning av varor i parameterstyrd speciallista för borttagning, kan  kan man välja om information om denna borttagning ska läggas ut till POS. Standard vid användning av denna funktionalitet är att varorna i varulistan tas bort i Chain Classic och därefter läggs ut för borttagning i POS/CW. Men det kan vara så att det är bättre att bara ta bort i Chain Classic, för att sedan ta bort, manuellt, direkt i POS. Detta är ett manuellt val i programmet "Borttagning av varor".

Importera EAN/PLU från CSV-fil till varulista

(RTC-23728)

När varulista skapas används ofta Excel-formatet för att importera EAN/PLU till ny varulista. För att fortsatt ha denna möjlighet utan tillgång till Excel har det skapats ny funktionalitet för att göra samma sak med textfil i CSV-format. Det förväntas vara endast en EAN/PLU på varje rad, och sista raden blank.

Dett gäller också för "Speciella varulistor", skillnaden ligger i att här uppdateras en befintlig varulista. I "Varulista" skapas alltid ny varulista - precis som när man trycker på knappen för "Importera från Excel".

Vågutlägg vid borttagning av post i näringsinnehåll

(RTC-24257)

Om en post tas bort i butik, i näringsinnehåll, men det fortfarande finns värde på profil då kommer den att läggas ut som ersättningsvärde för butik. Bara om det inte finns profilvärde kommer det att läggas ut borttagning av post till våg i butik.

Näringsinnehåll i viktutlägg till Finnvacum

(RTC-24372)

Till 3:e-partssystemet "Finnvacum" läggs näringsinnehållstyperna: 11 Kostfiber, 12 Protein och 13 Salt ut på en och samma rad. Det gäller för Finnvacum viktetikett, färskvaruvåg, i format: atte2.butnr.

Externt MixID i kampanjgrupp

(RTC-24514)

I kampanjgrupp visas "Externt MixID" i egen kolumn på sidan över alla ingående mixmatcher i kampanjgruppen. Detta under förutsättning att inte "Kupongkod" används.

Inläsning av data från Store Manager (JSON)

(RTC-25314)

Det har skapats möjlighet att använda prefix, som anger vilken tabell som ska uppdateras vid inläsning av JSON-filer i Chain Classic. Men tills vidare är detta ingen standard, så därför läses samtliga data från input-katalogen in.

Kampanj-ID till Tokheim POS 

(RTC-25331)

Vara som ligger i flera aktiva mixmatch i samma eller olika kampanjgrupper, läggs till  3:e-partsystemet Tokheim POS med var och en av de olika kampanj-ID som används i Chain Classic. Detta säkerställer ett korrekt underlag, när Tokheim POS ska välja bästa erbjudandet för kunden.