Chain Classic version 2.1.1.0.47

27 Aug 2025 

Förutsättningar för uppgradering

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

Förbättringar

Flaxlott premieutbetaling

(RTC-48772)

Vid utbetalning av Flaxlottsvinster kommer detta att visas i butiksredovisningen med positivt värde på egen rad för: "Flaxlott vinstutbetalning".
Dessutom kommer detta att ingå som negativt belopp i summa för Nonsale.
Här används samma funktionalitet som för Pantutbetalning.

Startuppdatering för "Lägsta pris sista 30 dagar"

(RTC-49915)

När funktionalitet för "Lägsta pris sista 30 dagar" aktiveras, kommer det inte att finnas värden för LPS30D bakåt i tid.
Då är det viktigt att alla aktiva och framtida kampanjpriser blir uppdaterade med korrekt LPS30D.
Programmet Uppdatering av LPS30D gör detta.
Detta kan först köras med endast listan för granskning.
Därefter kan programmet startas igen med "Uppdatera" som val.
Förutom uppdatering av angivna poster kommer LPS30D för aktiva kampanjpriser att läggas ut till POS, Breece, Lexmark och Pricer. Till Lexmark läggs också framtida kampanjpriser ut med LPS30D.

Export av medlemserbjudande till Pricer

(RTC-49856)

Vid utlägg till Pricer kommer inte kampanjpriser högre än ordinarie pris att läggas ut till Pricer. Istället kommer endast gällande ordinarie pris att läggas ut.

• Vid utlägg av kampanjpris (Discount2) eller medlemserbjudande (Member2) kommer gällande erbjudandepris alltid att läggas ut i fält 25 (om lägre än ordinarie pris).
• Ifall en vara har både kampanjpris och medlemserbjudande så kommer bara posten med lägsta erbjudandet att läggas ut, då Pricer bara kan ta emot och visa 1 aktivt erbjudande.
• Om medlemserbjudande är lika med kampanjpris kommer kampanjpris (Discount2) att läggas ut.

Utlägg av mixmatch-information till Pricer och Breece

(RTC-51025)

Vara i aktiv mixmatch läggs ut till både Pricer och Breece, om vald mixmatchtyp satts upp för detta.      

De elektroniska hyllkantsetiketterna kan bara visa ett värde per vara. I de fall varan ingår i olika samtidiga erbjudanden, där mixmatchtyperna ska läggas ut, visas därför bara det första erbjudandet som hittas med uppfyllda villkor.

Information som visas:

• Mixmatchtyp
• Antal
• Belopp
• Medlemsmix

Annullering av vara

(RTC-45902)

Annullering av vara via RIGAL kan samtidigt innehålla andra VPI-ändringar, som egentligen inte är önskvärda på annullerad vara. Vid uppdatering av återinförande av annullerad vara kan det då skapas oönskade framtida prisändringsposter som ingen har kontroll på. För minsta möjliga avvikelser i denna process finns en valmöjlighet som överstyr varianter på detta, med några enkla och konsekventa regler.

1. Vid uppdatering av flera annulleringsposter för samma vara, inskickade samtidigt, behandlas endast 1 post per vara i VPI.
2. Uppdatering av annulleringspost, eller återinförande (borttagning av annullering), med eller utan andra ändringar, accepteras. 
3. Vid uppdatering av annulleringspost, eller återinförande, kommer gällande pris i fil att användas och alla framtida prisändringar tas bort.
4. All uppdatering av annulleringsposter eller återinförande, sker alltid direkt på dagens datum, oavsett vilka andra ändringar som finns i posten från RIGAL.
5. Vid annullering ändras alltid framtida borttagningspost till datum från dagens datum med tillägg för parameterstyrt antal dagar framåt i tiden.

Säkerhetsrapport endast för Excel

(RTC-51037)

I fliken "Alternativ" kan Säkerhetsrapporten väljas för visning endast i Excel-format.
Varje butiks kassörer visas på en egen rad med totaler per butik.

Visa kampanjgrupper i rapport for "Lokala kampanjer"

(RTC-50260)

Rapporten "Lokala kampanjer" visar vanligtvis alla lokala kampanjpriser, oavsett om de skapats i kampanjgrupp eller är skapade som manuell prisändring.
Med valet "Endast utskrift av varor från kampanjgrupper" valt i fliken "Alternativ", kommer endast kampanjpriser från lokala kampanjgrupper att visas i rapporten.
Dessutom kommer denna rapport att visa tre extra kolumner: "Kampanjgrupp information", "Skapad datum" och "Lagersaldo (disponibelt för försäljning)".

Rapporten är gjord för att användas i Excel-formatet.

Kalkylering av lägsta pris på framtida erbjudanden

(RTC-51831)

När framtida erbjudanden skapas och funktionalitet för lägsta pris används, visas det lägsta kända priset som har använts i förhållande till angivet antal dagar bakåt i tiden.
Om det framtida erbjudandet har startdatum längre fram i tid än antal dagar, kommer LPS30D att sättas till gällande ordinariepris.
Under tiden kan nya re-kalkyleringar ske, som förändrar LPS30D så länge startdatum inte har inträffat, när det sker prisändringar på aktuell vara under tiden. 

Knappar för åtkomst till Internet i webbläsare

(RTC-50247)

De markerade knapparna kan anpassas med sökväg till olika webbsidor i standard webbläsare.
Efter att Microsoft Internet Explorer har gått ut på datum måste därför ny standard webbläsare installeras, till exempel Microsoft Edge.

VPI rabattorsakskoder från ERP

(RTC-51051)

Rabattorsak 99 är avsedd för att kunna skapa giltiga undantag för erbjudanden som inte ska ingå i beräkning av "Lägsta pris sista 30 dagar".
Vanliga rabattorsaker som används på HK eller av butiker har generellt orsakskoder < 99. ERP kan använda 3-siffriga orsakskoder för att skilja dessa från de "lokala" rabattkoderna. 

• I registervårdsprogrammet för "VPI rabattorsaker" går det bara att skapa/ändra/radera rabattorsakskoder < 99.
• Rabattorsakskoder > 99 som ska användas från ERP måste skapas/ändras/raderas i Systemalternativ 1096, antingen manuellt eller uppdatering via filer.

Sätt order till "Mottagen" i varumottagning

(RTC-46813)

De olika sätt som kan användas för att färdigställa en varumottagning är genomgångna, och ordern ska bara kunna sättas till status "Mottagna" när alla beställda varor är behandlade och uppdaterade mot lager. 

Uppdatering av Tokheim POS vid deaktivering av kund i Cloud 

(RTC-52117)

Det går inte att ta bort kund i Cloud, istället deaktiveras aktuell kund.
I Chain Classic kommer flaggan för "Överförs till kund" slås av och därefter lägga ut en borttagningspost till kassorna.
Efter mottaget borttagningsmeddelande från Chain Classic, kommer kunden att tas bort i Tokheim POS. 

Ska kund senare aktiveras från Cloud, sker detta på samma sätt.
Utlägg till kassa kommer återigen att aktiveras i Chain Classic och kundinformation sändas vidare för uppdatering i Tokheim POS.

Information om tillåtet antal decimaler till Tokheim POS

(RTC-49795)

Vid utlägg till Tokheim POS i ART_MUT- formatet ska nu fältet "QUADECS", för max antal decimaler, läggas ut direkt efter fältet "QUAUNIT". 

• När QUAUNIT=1 (Stk.vara), läggs QUADECS=0 ut (inga decimaler tillåtna)
• Annars, oavsett värde i QUAUNIT, läggs QUADECS=2 ut (upp till 2 decimaler tillåtna)

Chain Classic version 2.1.1.0.46

26 Mar 2025 

Förutsättningar för uppgradering

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

Förbättringar

Automatisk korrigering av LPS30D vid fel utpris från RIGAL

(RTC-46650)

Om det vid ett fel sänds in ett alltför lågt utpris, kan detta få olyckliga konsekvenser när detta används som LPS30D för ett annat kampanjpris på samma vara.
Det är därför möjligt att korrigera detta automatiskt via insändning av korrekt utpris via en ny RIGAL-fil.
Villkoren för detta är att det måste i en ny parameter anges maximal tidsgräns för när korrigeringen måste sändas in och uppdateras.
Dessutom måste det i samma parameter vara angivet en minimum %-vis ökning av utpris.
Om båda dessa villkor uppfyllts, kommer det alltför låga utpriset att märkas som "används ej" i prishistoriken, och kommer inte att användas vid beräkning av lps30d för nya kampanjpriser på samma vara.

Manuell korrigering av "felskapat" lägsta pris i prishistorik

(RTC-46789)

Vid användning av funktionalitet för lägsta pris, kan det hända att någon skriver fel och startar ett kampanjpris med alltför lågt försäljningspris.
Detta låga kampanjpris blir underlag för beräkning av lägsta pris för andra kampanjpriser på samma vara de påföljande 30 dagarna.

Användare med behörighet kan korrigera ett sådant fel genom att använda programmet Korrigering av prishistorik, som finns under System>Administrativa rutiner>Diverse hjälprutiner. 
När en post korrigeras, kommer fälten för rabattorsak att (ändras till 99). Användare som gjorde ändringen och datum/tid fylls i och färgas gula, medan raden i övrigt färgas grå.

Rabattorsak 99 betyder att "Nytt utpris", i denna post, inte används i beräkningen av lägsta pris och kommer därför heller inte att visas i loggen för lägsta pris.

Kunna se lägsta pris och rabattorsak  

(RTC-47555)

Med "Lägsta pris senaste 30 dagar" och tillhörande "Rabattorsaker" påslagna, kommer det att visas egna kolumner för dessa värden.
Aktuella värden visas i varuköposter för kampanjpriser i:

• "Varuregister" i fliken "Pris"
• "Prisregister" i fliken "Prisregister"

I programmet "Butiksrutiner" (endast för butiksanvändare) är det lite annorlunda.
Här visas "Lägsta pris senaste 30 dagar" och tillhörande "Rabattorsak" (nummer och text) för kampanjpriser för både aktiva och senaste avslutade kampanjpriser. 
Det har därför lagts till 4 nya kolumner i detta program. 

Efter "Kampanjpris" visas:

• "Lägsta pris (K)" för kampanjpris
• "Rabattorsak (K)" för kampanjpris

Efter "Medlemserbjudande" visas:

• "Lägsta pris (M)" för medlemserbjudande
• "Rabattorsak (M)" för medlemserbjudande

Användning av ursprungligt lägsta pris vid förlängning av profilerbjudande

(RTC-47547)

Om ett profilerbjudande ska förlängas, måste ursprungligt LPS30D (lägsta pris senaste 30 dagar) behållas för att underlaget för det nya erbjudandet är det samma.
Det är parameterstyrt när det nya erbjudandet senast måste starta i förhållande till när det ursprungliga erbjudandet blev avslutat.

Villkor:

• Ursprungligt profilerbjudande kan vara både kampanjpris och medlemserbjudande.
• Nytt, förlängt erbjudande kan vara kampanjpris och/eller medlemserbjudande.
• Nytt erbjudande kan läggas upp på ursprungligt profilerbjudande eller på butikspris på samma profil.
• För nytt erbjudande skapat via RIGAL gäller samma regler som ovan.

Lägg ut lägsta pris = ? (okänt värde) när detta inte ska användas i POS

(RTC-47041)

Om POS inte ska använda LPS30D som läggs ut från Chain Classic, sätts fältet till ? (okänt värde) i filformaten som används.
Då kommer POS att beräkna rabatter enligt gällande ordinarie pris. 

Krypterad e-postlösning i Cloud

(RTC-47159)

Om kryptering av e-post i Cloud ska användas vid sändning av EOD-rapporter och meddelanden via kundorder, kan inte standardlösning via SMTP användas. 
Istället skickas meddelanden med bilagor via web service (WS) till POS Services och därifrån till e-postlösningen i Cloud (MDS). 

Skicka redovisningsrapporter i Excel-format som bilaga i e-post

(RTC-47960)

PDF-formatet har alltid använts när redovisningsrapporter sätts upp för att skickas med e-post via EOD-rutinen.
Om EOD-rapporterna skickas via web service (krypterad e-postlösning i Cloud), och "Skicka e-post" valts, är det möjligt att välja mellan tre olika inställningar för format i bilagor:

1. Endast PDF (standard)
2. Både PDF och Excel
3. Endast Excel

När e-post ska skickas från kundorder via webservice måste fälten "Ämne" och "Meddelande" alltid fyllas i.
Det har därför lagts upp parameterstyrda standardtexter för detta. Dessa texter kan anpassas om det finns behov för det.

Borttagning av lokala butikspriser efter lokala erbjudanden

(RTC-45832)

Vid användning av funktionalitet för borttagning av lokala butikspriser efter avslutat lokalt kampanjpris eller medlemserbjudande, gäller följande:

1. Funktionaliteten används för att det är önskvärt att butikerna primärt ska använda profilpris.
2. Kampanjpris som skapas för butik, kommer alltid få en borttagningspost i varukön som tar bort det lokala priset efter att kampanjperioden avslutats.
3. Borttagningsposten kommer alltid att ligga bakom det längst varaktiga kampanjpriset för butikspriset.

Förhindra att ogiltiga momsgrupper kan skapas vid RIGAL-uppdatering

(RTC-45847)

Ny momsgrupp skapas om ett nytt värde sänds in.
Det kontrolleras om nytt värde är giltigt och om det finns en ledig momsgrupp inom de 9 giltiga värdena. Det kontrolleras på: 

• Momssatser över 99 % ignoreras.
• Det finns bara plats för 9 momsgrupper i registret. Därefter måste ev. manuell registrering användas för att anpassa till önskat behov.

Chain Classic version 2.1.1.0.45

Dokument status: 

Datum: 01 Nov 2024

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

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

Dokument status: 

Datum: 30 Apr 2024

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

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

Dokument status: 

Datum: 29 Feb 2024

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

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

Dokument status: 

Datum: 08 Dec 2023

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

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.

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. 

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

Dokument status: 

Datum: 31 Oct 2023

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

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.

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

Dokument status: 

Datum: 01 Sep 2023

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

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.

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

Dokument status: 

Datum: 22 Jun 2023

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. 

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

Dokument status: 

Datum: 02 Jun 2023

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

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

Dokument 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

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

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

Dokument status: 

Datum: 20 Feb 2023  

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

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. 

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

Dokument status: 

Datum: 19 Jan 2023  

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

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

Dokument 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

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

Dokument status: 

Date: 07 Nov 2022 

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

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

Dokument status: 

Datum: 03 Oct 2022 

Förutsättningar för uppdatering

Med uppgradering til Chain Classic version 2.1.1.0.32 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.1.1.0.31

Dokument status: 

Datum: 08 Jul 2022 

Förutsättningar för uppdatering

Vid uppdatering till Chain Classic version 2.1.1.0.31 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.  

Beställning av endast hela förpackningar från InStore App

(RTC-23459)

Det är möjligt att parameterstyra om endast hel förpackningar ska gå att beställa när kross inte är tillåtet på varan. 

1. Beställning i InStore App med antal som är lägre än angivet i (små) förpackningar ändras upp till "antal i förpackning"
2. Beställning i InStore App med antal som är högre än angivet i (små) förpackningar, men inte motsvarar ett helt antal förpackningar, ändras ned till det som motsvarar närmsta antal hela förpackningar.
3. Logg kan skapas under: "Rapporter"/"Loggar"/"Loggutskrift": Loggtyp 27 "Ändrat antal i beställning från ISA". Det är parameterstyrt om denna ska visas för butiksanvändare. 

Tandemnummer i beställning från InStore App

(RTC-23885)

Vid inläsning av beställning i Chain Classic, från InStore App, fångas också vara med tandemnummer upp, om den används i beställd paketvara.

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.

Utskrift av etikett vid användning av Paket-ID

(RTC-23684)

Det är möjligt att skriva ut etiketter från elektronisk varumottagning även vid användning av paket-ID tillsammans med ordernummer.

Behandling av antal = 0 vid import av beställning via RIGAL-fil

(RTC-22349)

Standard är att rader med antal = 0 avvisas vid RIGAL-import. Det går att parameterstyra funktionaliteten så att inskickad beställningsrad med antal = 0, i RIGAL I-fil, inte avvisas.

Utlägg av inventeringsunderlag för butiker utan lagerstyrning till Chain Web 

(RTC-23050)

Det går att lägga ut inventeringsunderlag även för ej lagerstyrda butiker, via "Lagerinformation till fil". För att skapa inventeringsunderlaget måste varan vara aktiv och ha pris på butik eller profil.

Lägg ut 20-kod utan kontrollsiffror i RIGAL

(RTC-23176)

På viktvaror används EAN med 20 koder, till exempel 2000123400000 där de 5 sista siffrorna = 0 för att ställa in pris/vikt efter vägning och utskrift av prislapp. Vid utlägg av dessa till RIGAL är det trots allt standard att koden räknas om och att en kontrollsiffra sedan skapas så att koden kan skannas om den är tryckt på en etikett. Det är möjligt att parameterstyra att 20-kod alltid ska läggas ut med 0 som sista siffra i RIGAL-formatet.

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.

Externt ordernummer och externt radnummer i varumottagning

(RTC-23180)

Chain Classic kan kommunicera externt order- och radnummer via RIGAL I-fil.

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.

Programmet "Radera/Ta bort från kassa"

(RTC-22976)

Möjligheterna till loggning har utökats, men framförallt är prestandaförbättringarna betydande i programmet "Radera/ta bort från kassan", som består av två behandlingsvarianter:

• Ta bort vara från kassa
• Radera varor/priser

"Ta bort vara från kassan" innebär att det läggs ut avaktivering av artikelurval till POS. Detta är en varuuppdatering som därför gäller ALLA prisprofiler. Detta innebär att alla profiler måste kontrolleras på eventuella lagervärden, försäljningar efter angivet datum som kan förhindra att varan tas bort från POS.

• Observera att vissa parameterinställningar kan åsidosätta detta och sedan avaktivera endast objekten på den valda profilen, se tekniska utgåvor.

"Radera varor/priser" betyder att de varor (priser) som faller inom kriterierna ska raderas, vilket är mer prestandakrävande. 

• Loggen i rapportlistan visar nu antal varor och den tid det tar.
• Det är möjligt med mer detaljerad loggning, precis som för "Uppdatera vara", "Slutför varukö" och "Snabb prissättning".

Undvik deadletters när Chain Web tar över som kassörmaster

(RTC-23612)

Chain Classic måste anpassas när Chain Web tar över som master för kassör. 

Chain Classic version 2.1.1.0.30

Dokument status: 

Datum: 07 May 2022 

Förutsättningar för uppdatering

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

Förbättringar 

SKU-fält för Chain Web i vara.99900

(RTC-18501)

Fältet "SKU" läggs ut blankt från Chain Classic till totalbutiken i följande två format, vara.99900 där det är fält 92 som används och tandem.99900 där fält 5 används. I Chain Web kan fältet ha upp till 50 tecken, men kommer alltid vara tomt när det läggs ut från Chain Classic.

POS-användare kan använda detta fält till gemensam funktionalitet vid uppdatering både från Chain Classic och Chain Web. 

Fabrikat i rapport "Åldersfördelat lagervärde"

(RTC-21047)

Rapporten "Åldersfördelat lagervärde" visar nu också "Fabrikat" för varor i en ny kolumn.

Ogiltiga tecken i känsliga textfält

(RTC-21344)

I "Vara", "Kund" och olika registerprogram kan det få konsekvenser om det lagras ogiltiga tecken i känsliga namnfält. 

Osynliga tecken, som av misstag kommer med i text vid exempelvis kopiering, tas bort automatiskt vid lagring i användargränssnittet eller RIGAL VPI-import. Utöver detta kan andra tecken som upptäcks läggas till i en lista för att undvika framtida problem.

Nettopriskontroll med profilprisändringar

(RTC-21684)

Om nettopriskontroll utökas med utpriskontroll som tillägg, kommer profilpris att föreslås som utpris. Detta gäller både för butiker som har lokalt butikspris sedan tidigare och de som inte har lokalt butikspris förut. Vid standard "Nettopriskontroll" kommer butiker som har lokalt butikspris att få gällande butikspris som förslag på utpris, och för de butiker som inte har lokalt butikspris föreslås gammalt profilpris i utprisfältet. 

Borttagning av gamla loggposter i databas

(RTC-22696)

Det rekommenderas att löpande radera utdaterade statistik- och registerposter via EOD. Om inte kan datamängden efteråt riskera att nå maximal gräns och då kraschar databasen.

Då gammal loggdata också byggs upp, kan också detta raderas via EOD för register-registrering. 

Borttagning av tvättprogram i Tokheim POS

(RTC-22804)

Varje butik med tredjepartssystemet Tokheim POS och biltvätts-anläggningen har lagt upp egna poster för varje tvättprogram under "Fältvärden för butik", för motsvarande vara. Det är denna tvättprogramspost som ska raderas om butiken önskar att ta bort ett tvättprogram. Utlägg som tar bort tvättprogrammet från kassan skickas därefter till Tokheim POS.

Alternativ metod för uppdatering av fastprisflagga på nytt butikspris

(RTC-22907)

Generellt uppdateras markeringen för "Fast pris" via standard fält i VPI. Det är också möjligt att sätta upp systemet för att alltid sätta "Fast pris" som inställningen för profilpris, när nytt butikspris skapas eller vid ändring av existerande butikspris, via RIGAL VPI.

Rapporterna "Varukölogg" och "Logg el. hyllkantsetiketter"

(RTC-22924)

Rapportunderlaget lagras i databasen, oavsett om rapporterna används eller inte. Det betyder inte att det måste finnas bra rutiner för registrering och borttagning av gammal data. Rapporterna "Varukölogg" och "Logg el. hyllkantsetiketter" är viktiga rapporter för de som använder dessa, men de är av en typ som genererar stora mängder data. Denna datamängd kan givetvis registreras med goda borttagningsrutiner, men om rapporterna inte används är det onödigt att lagra så mycket data, bara för att ta bort dem efteråt.

Om registrerings-rutinerna inte är på plats kan det leda till överfylld databas och systemproblem som följd av detta. Det rekommenderas därför att parameterstyra om loggning ska ske för någon av dessa rapporter. Om man önskar köra rapporterna under en period är det enkelt att slå på loggning och senare slå av den igen. 

Ta bort ej aktiv butik

(RTC-22966)

När en butik avslutas sätts kommunikationstyp = 1 och "Stängt datum" med avslutningsdatum för butiken i butiksregistret. Detta leder till att en del register raderas, men butiken visas fortfarande i butiksregistret. Om butiken ska raderas från butiksregistret måste support/konsult köra rensningsprogram för detta så att resterande data för statistik och register raderas tillsammans med butiken.

Borttagning av gammal statistik och register

(RTC-23165)

Det är bra att ha en rutin för att radera gammal statistik (försäljningssiffror) och register, annars riskerar man att fylla på databasen med tiden vilket kan leda till totalstopp i alla uppdateringar. Det kommer då att krävas omfattande radering av gammal data, ett jobb som är helt onödigt då det går att lägga upp kontinuerlig radering varje dag. Exempelvis kan gränsen för radering sättas till 90 dagar, för varje ny dag kommer dag 91 att raderas så att det alltid finns statistik och register 90 dagar tillbaka.

Chain Classic version 2.1.1.0.29

Dokument status: 

Datum: 10 May 2022 

Förutsättningar för uppdatering

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

Förbättringar 

Referenstext i beställning

(RTC-21928)

Det går att se, sortera och filtrera på "Referenstext" vid sökning i "Beställning", "Varumottagning" och "El. varumottagning".

Det är möjligt att ta bort raden "Vår ref." med denna referenstext i rapporten "Utskrift av beställning".

Ny priskanal i kampanjgrupp

(RTC-20975)

Ny priskanal i kampanjgrupp läggs upp i systemalternativ. Därefter kan de läggas ut till POS via kampanjgruppsutlägg.

Alternativa utlägg till Breece och Pricer

(RTC-20390)

1. Det går att förhindra utlägg av erbjudande från Kampanjgrupp om annan priskanal än "Alla" har valts.
2. Det är möjligt att välja en inställning så att varor med angiven etikettyp byter plats på enhetspris och ord./kampanjpris vid utlägg till Breece/Pricer. Gäller både huvud-EAN och tandem.

Viktkod på nytt butikspris när värde saknas i VPI

(RTC-22344)

Saknad viktkod i VPI för nytt butikspris sätts normalt med hänsyn till inställning i VPI-mall. Men det är möjligt parameterstyra detta så att man istället hämtar aktuellt värde för varans viktkod (enhet) från aktuellt profilpris.

Chain Classic version 2.1.1.0.28

Dokument status: 

Datum: 08 Apr 2022 

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 

Ändra grossistpris per butik

(RTC-21699)

Grossistpris kan ändras genom att läsa in en fil med namnet "inkopspris.butnr.csv", där innehållet i filen bara är alfanumeriskt varunummer och nytt grossistpris. För ändring krävs det att butikspris finns sedan tidigare. Vid användning av denna funktion kommer endast aktivt ordinarie pris att uppdateras med det nya grossistpriset, medan framtida ordinarie prisändringar inte förändras.

Inläsning av denna fil kan antingen göras manuellt via program: "System"/"Administrativa rutiner"/"Diverse hjälprutiner"/"Uppdatering av grossistpris", eller genom att sätta upp ett jobb för EOD-körning.

Medlemserbjudande i kundorder vid användning av CoopID

(RTC-21569)

• Om CoopID används kan status "Medlem" sättas när ny kundorder skapas innan varorna läggs in.
• Det går inte att ändra status "Medlem" efter första lagringen av kundorder. 
• Extern uppdatering av kundorder kan heller inte påverka denna status.
• Varor som inte visar medlemspris, kan raderas och läggas in på nytt för uppdatering av pris.
• Ett skript har skapats för uppdatering av status "Medlem" på kundordrar med värde i CoopID, som inom det angivna tidsintervallet, antal dagar kvar.

E-postadress på kassörer

(RTC-21407)

I registret för kassörer kan e-postadress läggas upp för utlägg till POS.

Markera flera rader i priskontroll 

(RTC-22008

Innan godkännande/avvisande av varor i priskontroll är det möjligt att välja flera rader samtidigt.

• Flera rader kan väljas genom att trycka CTRL + klick på önskade varor.
• Rader kan tas bort från urvalet för godkännande/avvisning på samma sätt.
• Markering av sammanhängande rader väljs enklast genom att klicka på första eller sista varan och SHIFT + klick på varan som avslutar det sammanhängande urvalet som önskas.

Varutyp i RIGAL

(RTC-21716)

Varutyp är normalt ett urval av varutyper som läggs upp i RIGAL V- och J-fil. Det finns en möjlighet att inte använda dessa och istället sätta upp egna varutyper. Det är inte möjligt att kombinera dessa två alternativ.

Fastpris

(RTC-20814)

Funktionaliteten "Fast pris" sätts i priskalkylprogrammet i "Varuregistrering" eller "Prisregistrering". Att fastpris har satts visas också i prisfliken i de andra modulerna, men kan inte ändras där.

Avvikande radnummer i varumottagning

(RTC-21285)

Vissa leverantörer kan inte returnera ursprungligt radnummer, från beställning i Chain Classic, i levererad varumottagningsfil. Det är möjligt att parameterstyra så att EAN används istället för radnummer för att matcha mottagningsrader med rader i ursprunglig beställning.

• Om samma EAN finns på flera rader i varumottagsfilen kommer samtliga att avvisas.
• Vara i varumottagning som inte finns i ursprunglig beställning, läggs till i både beställning och varumottagning. 

Skillnad mellan kundorder/webborder och serviceorder

(RTC-20752)

När Chain Web blir master för kundorder/webborder ska detta inte läggas ut från Chain Classic till POS, men det kommer fortfarande att finnas ett behov av att lägga ut information om serviceorder. Kundorder/webborder och serviceorder delas därför upp så att detta enkelt kan ändras när behov uppstår.

Etikett med registreringsdatum

(RTC-20948)

Kundspecifik etikettdesign med nytt fält i stylecode 1.

Varutyp för "Lokal vara" till Tokheim kassasystem

(RTC-21737)

Vid användning av utlägg till tredjepartssystemet Tokheim sätts alltid varutyp till värde 1, "Butiksvara", när en ny "Lokal vara" skapas.

Chain Classic version 2.1.1.0.27

Dokument status: 

Datum: 16 Mar 2022 

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 

Varuköbehandling 

(RTC-20054) 

Behandling av varuköposter (t.ex. prisändringar) som inkluderar användning av tredjepartssystemet Lexmark innebär omfattande kontroll av varje post, men sker med närmast samma prestanda som motsvarande icke-Lexmarkrelaterade köposter.

Om det upplevs att inköpsvaror behandlas långsammare, kan loggning via post aktiveras för att ta reda på om det finns något som bevisar denna upplevelse. Obs: Dessa loggar kan ta mycket plats och funktionaliteten bör därför endast användas under en kort period.

Lexmark etikettflagga på kampanjvaror

(RTC-19633)

Vid användning av tredjepartsystemet Lexmark för etikettutskrift, ska etikett skrivas ut för kampanjvara oavsett om det förut har varit försäljning på varan eller inte.  

Utökad lösning för visning för CoopID

(RTC-20481) 

Det är parameterstyrt om CoopID ska visas på kundorder, och om medlemsnummerfältet ska visas i Kundregistrering. Del 1 av parametern öppnar för att uppdatera de nya Loyalty fälten (inkl. CoopID) från POSLog. CoopID visas i "Kundorder".

Del 2 av parametern används när koppling av kunder till S-lagsnr/medlemsnr ska raderas. Detta görs via script där man kan välja om utbetalning ska ske omgående till POS eller inte, samtidigt tas fältet för S-lagsnummer / medlemsnummer i "Kundunderhåll" bort.

Ändra grossistpris per butik

(RTC-19844)

Grossistpris kan ändras genom att läsa in en fil med namn "inköpspris.butnr.csv", som innehåller endast alfanumerisk varunummer och nytt grossistpris. Notera: grossistpris MÅSTE skrivas med punkt, som exempelvis 3.44, om kommatecken används blir nytt grossistpris 344.

För ändring krävs det även att butikspris finns från förut. 

Inläsning av denna fil kan antingen göras manuellt via program: "System" / "Administrativa rutiner" / "Olika hjälprutiner" / "Grossistprisuppdatering", eller genom att sätta upp ett jobb för EOD-utförande.

Grundetikett i "Varukölista" 

(RTC-19495) 

Om etikett skrivs från varukö visas information om att etikett ska skrivas i fältet för "Grundetikett" i "Varukölista". Det är första viktiga orsak till att etikett som använts skrivs, exempelvis prisändring.

Uppläggning av ny vara via RIGAL från ItemMaster

(RTC-19281)

Uppläggning av en ny vara i Chain Classic via RIGAL V-filer från ItemMaster sker i två omgångar. Först skickas en fil med artikelinformation och sedan en fil med prisinformation. Dessa slås samman till en ny vara, i VPI-underhåll där de importeras till Chain Classic vid godkännande.

Uppdatera butiker via JSON-import

(RTC-19018)

Chain Classic kan nu skapa och uppdatera butiker via JSON-inläsning från Store Service.

Loggning av "ej önskade" Breece-utlägg

(RTC-20799)

Antal fält som läggs ut till tredjepartsleverantören Breece kontrolleras via systemalternativ 125, rad 9 (Breece) och värden i fältet "Integer". Det läggs endast ut poster med rätt antal fält per post. Det uppstår situationer där andra format försökt läggas ut med fler eller färre fält. Dessa raderas och kommer inte vidare till Breece, men loggas innan borttagning med filnamn "breece_feil. butnr. yyyymmdd" i backup-katalogen.

Loggning aktiveras genom att sätta ett värde >0 i fältet "Decimal" i systemalternativ 125, rad 9 för Breece.

"Verkställ vara" lägger ut alternativt pris till Breece

(RTC-20728)

Vid användning av "Alternativt pris", för att äta ute/inne, läggs detta ut till Breece vid körning av "Verkställ vara". 

Varutyper för "Spelvaror/Elektronisk produkt/MBXP webbhandel"

(RTC-20062)

Dessa varutyper visas i "Varuregistrering, men kan bara registreras via RIGAL-import. Det finns följande varutyper för "Spelvaror/Elektronisk produkt/MBXP webbhandel" som kan vara i bruk: 

• eSale_NT - Spelvara från Norsk Tipping.
• eSale_Goyoda - Elektronisk produkt från Goyada, alternativt eSale_MBXP - elektronisk produkt från MBXP.
• MBXPwebsale - MBXP webbhandelsprodukt.  

Endast ordinarie pris på etikett från InStore App

(RTC-19894)

Etikettyp kan sättas till att alltid visa ordinarie pris, trots aktivt kampanjpris, när etiketten skapas från InStore-appen eller etikettlistan i Chain Classic. Detta görs genom att kryssa i "Visa alltid ordinarie pris" i "Underhåll av etikettdesign".

Retur av svarspost till InStore App

(RTC-20151)

Om butik och vara finns i Chain Classic kommer det alltid att läggas ut ett svarsmail till InStore-appen. Detta gäller även i de fall varumottagnings- eller butikslokala värden av särskild grupptext eller ordertyp på varorna saknas.

Det betyder att det returneras data även om det inte har gjorts varumottagning på varan, så att man fortfarande får information om exempelvis "beställningstyp" i InStore App. 

Beställningar: Visa alla öppna i InStore App och radera utgångna via EOD i Chain Classic

(RTC-17671)

Genom att "skicka" EAN från InStore App hämtas alla öppna (ej mottagna) beställningsrader från Chain Classic till InStore App.

Utgångna beställningar kan, efter att ha blivit äldre än angivet registreringsdatum, raderas i Chain Classic: automatisk via EOD eller manuellt via programpunkt - 
"System"/"Administrativa rutiner"/"Diverse hjälprutiner"/"Ta bort öppna beställningar".

Rensning vid EAN/PLU-nummerbyte

(RTC-16355) 

För att slippa avvikelser mellan Chain Classic och POS vid en EAN/PLU-nummerändring, läggs ett borttagningsmeddelande för den gamla EAN/PLU (som kommer att bli en ny tandem) upp i den totala butiken i artikel.99900. POS raderar sedan artikel- och prisinformation på varan.

Därefter läggs alla gällande och framtida prisändringar, erbjudande och annat ut för uppdatering i POS. Detta så att båda plattformer har samma information på gällande EAN/PLU och tandemnummer.

Uppdatering av hel kampanjgrupp i priskontroll

(RTC-19717)

Vid användning av standard priskontroll och godkännande/avvisning av hel kampanjgrupp behandlas alla poster som tillhör kampanjgruppen.

Dessa visas därefter inte under mixmatch eller kampanjpriser. Behandling av enstaka varor eller mixmatcher måste därför ske innan hela kampanjgruppen behandlas. 

Inställning av "menytillgång" via skript från "Admin- server"

(RTC-19732)

Standardsättet att ändra menyval i Chain Classic är att dölja eller visa dessa på enstaka användare eller användargrupp i programmet "Behörighetskontroll". Det går också att sätta upp denna menytillgång, på olika Chain Classic-servers, via skript som körs från "Admin-server".

Nytt EAN-nr blir huvud-EAN vid samma varu- och variantnummer

(RTC-18853) 

NOTERA: Kundanpassad specialfunktion!

När en vara skickas in via RIGAL V-fil kontrolleras det om det redan finns en vara med samma varunummer (alfanumerisk) och variantnummer i Chain Classic.

Om varan finns och EAN-numret i RIGAL V-fil antingen är ny eller är tandemnummer till gällande vara utförs det ett EAN/PLU-nummerbyte. Sedan skickas den nya huvud-EAN-koden och den aktuella EAN-koden flyttas till tandemnumret för den befintliga artikeln.

Chain Classic version 2.1.1.0.26

Dokument status: 

Datum: 11 Jan 2022  

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 

 Loggning av varukorgskontroll i självbetjänad kassa

(RTC-17044)

Vid manuell kontroll av varukorg i självbetjänad kassa loggas detta i rapporterna "Butiksredovisning total" och "Butiksredovisning per kassör".

Två nya poster i dessa rapporterna:

• Totalt antal kontrollerade kvitton
• Antal godkända kontroller, samt godkänningsprocent av totalt antal kontroller

Kundspecifik identifierare i kundorder

(RTC-18347)

Det är möjligt att ange en kundspecifik identifierare i "Kundorder" för medlemmar, som sedan överförs till POS. Det gamla fältet slagnr/mednr raderas när nytt identifikationsfält börjar användas.

Borttagning av medlemslänk i Chain Classic

(RTC-18211)  

Denna patch raderar alla spår av data av kombinerat medlemsnummer och s-lagsnummer som tidigare visades i fältet medlemskortnummer i kundorder i Chain Classic.

Förbättrad plocklista för E-handel/webborder

(RTC-17040)

• Denna variant av plocklistan kännetecknas av att ett externt ordernummer med streckkod, hyllplats och leveranssätt visas högst upp. Visningen har vidareutvecklats med följande:
• Kundnamn skrivs med stor text 
• Varorna listas upp per varugrupp
• Varugrupperna är sorterade i bokstavsordning
• Varorna är också sorterade i bokstavsordning
• Leveransmetod kommer alltid längst ned

Nettopriskolumn i elektronisk varumottagning

(RTC-18206) 

Det har utvecklats funktionalitet för vilken typ av "inpris" som ska visas i Elektronisk varumottagning.

Följande varianter används:

• Nettopris hämtas från beställning, grossistpris från beställning kan inte ändras. (Standard)
• Grossistpris hämtas från ordinarie priskalkyl i Chain Classic och , grossistpris från beställning kan ändras.
• Nettopris hämtas från ordinarie priskalkyl i Chain Classic och, grossistpris från beställning kan ändras (nytt alternativ).

Automatisk uppdatering av HK-styrda prisfältsändringar

(RTC-17617)

Det har skapats möjlighet för att ange vilka HK-styrda prisfält som alltid ska uppdateras från "Pris" vid ändring till nya värden.
Dessa fält är följande:

• Konfigurerad funktionalitet gäller alla befintliga aktiva och framtida prisändringar (prisändring, kampanjpriser och medlemserbjudanden) som redan skapats i varuköerna. För valda fält hämtas sedan värde från "Pris" och för ej valda fält finns det ursprungliga värdet kvar.
• Detta gäller också vid kopiering av gammal kampanjgrupp. För utvalda fält hämtas värde från "Pris" och för ej valda fält hämtas värde från gammal kampanjgrupp. 

Godkännande av mixmatch i priskontroll

(RTC-14416)

Vid användning av priskontroll och den har satts upp för godkännande av mixmatch har stora förbättringar gjorts. Tidigare räckte det med att godkänna en valfri artikel i en mixmatch för att godkänna hela mixmatchen, detta gjorde det hela svårt att kontrollera. Ny funktionalitet samlar alla mixmatch på sin egen flik och det är själva mixmatchen som godkänns, inte varan. Genom att dubbelklicka kan mixmatchen öppnas (se bild nedan) och kontrolleras innan godkännande. Det är möjligt att godkänna eller avvisa en enstaka mixmatch utöver att godkänna alla mixmatcher med ett tryck.

Kampanjgrupp i priskontroll

(RTC-14744)

Kampanjgruppskontroll i priskontroll har förbättrats. Kampanjpriser visas under en separat flik där de kan godkännas och avvisas.

• Dessutom finns en parameterstyrd möjlighet att sätta upp fliken "Kampanjgrupper" där även hela kampanjgruppen kan godkännas eller avvisas.
• Genom att dubbelklicka på kampanjgruppen, under fliken kampanjgrupper, öppnas den i ett separat fönster för enklare överblick.
• Enskilda varor kan godkännas/avvisas under fliken "Kampanjpriser" och sedan godkänns eller avvisas hela kampanjgruppen under fliken "Kampanjgrupper". Detta så att endast de varor butiken verkligen vill ha, till kampanjpris, skickas till POS .
• Om kampanjgrupp godkänns, kan tillhörande poster fortfarande ligga kvar under flikarna kampanjpris/mixmatch. Detta korrigeras med uppdatering av skärmbild, markera valfri post och tryck "F5". I annat fall kommer godkänn/avvisa att ge följande meddelande: Köstatus blev inte satt (IP:181), här betyder detta att posten redan har behandlats och borde varit dold.  

Beställningar från InStore App ska inte hamna i Elektronisk varumottagning

(RTC-18899)

Beställningar från InStore-appen kan avslutas automatiskt och göra ett utlägg till RIGAL I-filen. För att förhindra påverkan av annan funktionalitet har ett hittills oanvänt fält "besthode.lukket" använts för att indikera att beställning från InStore-appen automatiskt har avslutats. Alla beställningar med detta meddelande filtreras bort i "Kvitto för elektroniska varor".

Parameterstyrning av ej lagerstyrd flagga vid export av inventeringsunderlag till Chain Web

(RTC-17977)

Det har skapats ett nytt fält i export till Chain Web, som anger om en vara är lagerstyrd eller inte. Detta fält läggs bara ut om funktionaliteten är aktiverad. 

Val av om huvud-EAN ska bytas vid RIGAL-uppdatering på tandem-EAN eller ny EAN

(RTC-17621)

Det går att styra om huvud-EAN ska ändras från huvud-EAN till tandem-EAN när det via RIGAL kommer in varu-/prisändringar på existerande tandem-EAN eller på ny EAN/PLU som inte existerar i Chain Classic. Detta är standard.

Ny lösning innebär att huvud-EAN aldrig ändras vid varu-/prisuppdateringar via RIGAL, när existerande tandem-EAN eller nytt EAN används. Varu- och prisinformation uppdateras på original huvud-EAN och vid ny okänd EAN läggs denna in som tandem-EAN på befintlig huvudvara.

Detta gäller både vid användning av RIGAL V-fil och Excel VPI.

Export av nonsaletyp

(RTC-18342)

Det har skapats nytt registreringsprogram för nonsaletyp,  System > Kassa > Nonsaletyp.

Här kan det för nonsaltyp:

• Läggas upp ny
• Ändras
• Raderas

För sådan verksamhet sker direkta utbetalningar via filen tekster.butnr. Dessutom kan icke-försäljningstyper läggas upp från programmet Texter till kassan via filen tekster.butnr. Sedan finns det ett komplett utlägg av alla icke-rea-typer till specificerade butiker.

Förstör inte lokala varor

(RTC-16270)

Vid användning av funktionaliteten "Lokala varor" har det säkerställts att man inte förstör dessa varor genom att använda EAN/PLU-ändring i "Varuregistrering". Detta genom att inaktivera EAN/PLU-knappen när lokala varor har valts och gäller både HK- och lokala användare.

Import av vattenmängd via PU-fil till Tokheim

(RTC-18575)

Förbättringar har gjorts som nu uppdaterar både vattenkoderna WAT (vattenstånd) och WATQUA (vattenmängd), vid import av PU-formatet från tredjepartssystemet Tokheim till Chain Classic.

Chain Classic version 2.1.1.0.25

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

Förbättringar i Chain Classic

Varufil till Lexmark

(RTC-16793)

Utläggen till tredjepartssystemet Lexmark är förbättrat för att förhindra att onödiga data läggs ut.

Utlägg av kampanjgrupp med priskanal till Lexmark

(RTC-16790)

Der är nu möjligt att lägga ut priskanaler till tredjepartssystemet Lexmark.  

Ny mixinformation till Lexmark

(RTC-16786)

Tre nya fält har skapats för utlägg av mixmatch till tredjepartssystemet Lexmark. De nya mixfälten "Tilläggstext", "Utpris från mixhuvud" och "Flagga för självskanning" 
fylls i när data är tillgänglig. 

Centralt kampanj-ID på lokala kampanjvaror

(RTC-17890)

Tidigare levererad funktionalitet var svår att överföra till POS. Det skapades därför ett "fiktivt" kampanjgruppshuvud för butik, när central-ID ska användas inom lokal kampanjperiod, något som hjälper POS att hålla koll på byte till centralt kampanj-ID på vara i lokalt kampanj-ID.

Inaktivering av nonesale-varor med försäljning

(RTC-17450)

Det har lagts till en kontroll på försäljning av nonesalevaror så att inaktivering inte sker om försäljningen är inom det antal dagar tillbaka i tid som är angiven försäljningsintervall där inaktivering ska förhindras.

Webborder från EG POS - Automatisk internöverföring från centrallager till butik

(RTC-17256)

Vid försäljning av vara i butik som bara finns på centrallager. Kund betalar vara i kassa, försäljning slutförs i kassa, via ny funktionalitet för användning av leverans från webbutiken. Webborder skickas till Chain Classic där order skapas och en internöverföring av vara från centrallager till butik. Varan levereras så till kund.

Utlägg vid ändring av uppskattat självkostnadspris

(RTC-16633)

Vid användning av uppskattat självkostnadspris läggs ändringar av uppskattat självkostnadspris i Chain Classic ut till POS i nettoprisfältet. Detta gäller alla, aktiva och framtida, erbjudanden och prisändringar som tidigare har lagts ut till POS.

Extra decimaler i "Receptvara"

(RTC-16642)

Vid användning av "Servicehandel" är det i "Receptvara" möjligt att använda upp till 4 decimaler i fälten för Netto- och Brutto-antal och fast respektive beräknat nettopris på "Receptvara".

Ny kolumn i receptvara för beräknat nettopris per ingrediens

(RTC-16629)

Vid användning av servicehandelsfunktion visas nu ny kolumn, under fliken "Receptvara" i "Varuregistrering", med beräknat nettopris per ingrediens. Pris beräknas på följande sätt "Ingrediensens nettopris * antal". Summan av alla ingrediens-varuradernas nettopris är lika med receptvarans nettopris.
Vid ändring av profil /butik omberäknas fälten. Om en enstaka ingrediens saknar profil-/butikspris, hämtas detta från närmaste profilpris så att priset kan beräknas.

Nya fält i programmet "Lokal vara"

(RTC-16643)

I specialprogrammet "Lokal vara" kan "Momsgrupp" och "DUN-nr" läggas upp på nya lokala varor. Värdena visas tvärs över "Varuregistrering" och "Lokal vara" och kan administreras på båda platserna. I VPI-mall kan standardvärde för moms sättas om så önskas.

Ny huvudvara ersätter "Lokal vara"

(RTC-16146)

Detta gäller vid användning av funktionaliteten "Lokal vara". Lokal vara har ett PLU-nummer inom angiven nummer-serie. På lokalt PLU kan tandem läggas upp, så kallad butikslokal tandem, något som ofta är en reell EAN-kod. I de fall då HK väljer att lägga upp en ny huvudvara med samma EAN som redan har använts till butikslokal tandem på en lokal PLU, kommer det komma ett meddelande om det. Dessutom kommer en fråga om den lokala varan ska konverteras till central vara. Vid bekräftelse slutförs upplägg av ny huvudvara med rätt info och profilpris. Vid konvertering blir då tidigare "buttandem" ny huvudvara, PLU-nummer blir tandem till ny huvudvara och pris på lokal vara kopieras in som nytt butikspris på huvudvaran. Därefter raderas tidigare lokal PLU från programmet "Lokal vara".

Nya obligatoriska fält i "Lokal vara"

(RTC-16144)

Ny funktionalitet i programmet "Lokal vara" i "Prisregistrering" är parameterstyrning av standardvärde i fälten "Enhetstext" och "Mängd". Normalt är dessa fält blanka när lokal vara skapas. 

• Vid ny vara hämtas standardvärdena för dessa fält från VPI-mall. Om inget standardvärde har angivits används värde 1. Om värden för "Mängd" har decimaler måste detta anges med decimaltecken.
• Inget tvång i ändring av fälten för existerande poster, men om man ändrar ett av fälten, måste båda sättas med aktivt värde innan varan kan sparas.

Nya meddelanden vid användning av EAN i "Lokal vara"

(RTC-16143)

Vid skapande av nya varor i programmet "Lokal vara" har funktionaliteten förbättrats. Om EAN/Streckkod som ska skannas finns, börja alltid med att lägga in detta i fältet för EAN/PLU direkt, tryck INTE på "Ny":

1. Om EAN är okänt i varuregistret föreslås det att lägga upp en ny lokal vara, och som följd av detta läggs använd EAN upp som "Buttandem", tandemvara till butiken på den nya lokala varan.
2. Om EAN finns i Chain Classic föreslås det att använda existerande huvudvara.
3. Om EAN finns som tandem till annan huvudvara föreslås det att använda existerande huvudvara.
4. Om EAN finns som tandem till annan lokal vara föreslås det att använda existerande lokal vara. Butiken lägger upp eget pris och får angivet EAN som buttandem, tandem till lokal vara.

Kontroll över lagerstyrning i "Lokal vara"

(RTC-16142)

I programmet "Lokal vara" går det nu att sätta önskad typ av lagerstyrning. I fält för "Lager" kan önskat alternativ för detta väljas vid nyskapande av lokal vara om standardval inte är aktuellt. Det är också möjligt att ändra detta fält på existerande varor.

Chain Classic version 2.1.1.0.24

Dokument status: 

Datum: 03 Nov 2021 

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. 

Förbättringar i Chain Classic

Begränsa val av kampanjtyp