You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Chain Classic version 2.2.0.0.12

Dokument status: RELEASED

Datum:  

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Kassör

Antal siffror för kassörnummer (RTC-34270)

Kassörnummer kan ha upp till 9 siffror i Chain Classic.

Webbläsare

Webbläsare i Chain Classic (RTC-35855)

Knappar som öppnar webbläsaren i Chain Classic kommer alltid att använda Microsoft Edge.

Uppdatering av varutransaktioner på receptvaror

(RTC-36584)

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

Teknisk information
Servicehandel: Systemparameter 9003=1

Rapport Varutransaktionslista för receptvaror

(RTC-36584)

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

Teknisk information
Servicehandel: Systemparameter 9003=1

Rapport över försäljning på ingredienser

(RTC-36949)

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

Teknisk information
Detta rapportval kan bara väljas när Servicehandel används (systemparameter 9003 är påslagen).

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. 

Teknisk information
I systemparameter 357 kan kriterier sättas för att få kontroll över antal etiketter som skrivs ut.

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.

Teknisk information
Systemparameter 511 = 1.
Varje varutransaktionstyp som ska läggas ut i RIGAL finansfil per transaktionstyp och orsakskod, måste anges med "Integer" = 1 i Systemalternativ 5

Lagring av försäljningsdata för receptvaror

(RTC-36577)

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

Lagring av försäljningsdata för ingredienser 

(RTC-36815)

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

Teknisk information
Systemparameter 1003 styr om denna försäljning ska lagras totalt på råvara eller per ingrediens, men i första hand "förutsätts" det att lagringen sker totalt per råvara. 

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

(RTC-36848)

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

Teknisk information
Det går att spara försäljning på ingredienser per ingrediensnr genom att aktivera systemparameter 1003.
Tills vidare är det endast totalt per råvara (och systemparameter 1003 = 0) som det kan rapporteras på.

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.

Teknisk information
Detta gäller speciallösning för varumottagning med systemparameter 528 = elmottakw.



Chain Classic version 2.2.0.0.11

Dokument status: RELEASED

Datum:  

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Beställning

Spara varurad vid registrering av Beställning (RTC-35375)

Spara ny/ändrad varurad är optimerat för förbättrad prestanda när många användare jobbar med detta samtidigt.

Beställning/Varumottagning

Antal varurader i beställning och varumottagning (RTC-35812) 

Det går använda 5-siffrigt antal varurader i både beställning och varumottagning. Det betyder att det kan vara > 1000 varurader i en och samma order när nästa tilldelade radnr ökas med 10.

Kampanjgrupp

Meddelande på skärm när importerade varor sammanfaller i olika kampanjgrupper (RTC-35734)

När två kampanjgrupper har samma startdatum/tid eller slutdatum/tid och innehäller samma varor, avvisas varorna i den andra kampanjgruppen för att de sammanfaller. Meddelande om detta visas på skärmen. Detta gäller även vid användning av knappen "Hämta nya varor".
Om det hämtas in ett stort urval av varor där många varor avvisas av olika orsaker, kommer meddelandet i användargränssnittet att vara oöversiktligt. Då är det enklare att visa avvisningsorsakerna via knappen "Avvisade varor i kampanjgrupp".
Vid användning av knappen "Snabbprisändring" kommer endast avvisade varor att visas i denna logg.

Lager

Uppdatering av lager efter retur av samma vara på flera varurader i samma kvitto (RTC-34933)

Om samma vara ska returneras flera gånger, matas vanligtvis antal in på befintlig varurad. Lagret uppdateras då med totalt antal.
Om returerna skannas var för sig, kommer varje varurad att behandlas var för sig, men påverkar lagret på samma vis.

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.

Teknisk information

De som använder denna rapport i dag, måste kontrollera värdet i systemparameter 964. Giltiga värden är:

  • Värde = 0/39 (39 fält)
  • Värde = 53 (53 fält)
  • Värde = 58 (58 fält) 

Alla andra värden tolkas som 39 fält.

Systemparameter 692 anger VPI-mallar som används vid import av VPI från Excel.

Systemparameter 694 anger profilnummer som används vid import av VPI från Excel.

Beskrivning av skillnaden i innehållet i de 3 alternativen är bifogat i testdokumentationen.

Streckkodslösning i rapport

(RTC-35633)

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

Teknisk information
Utveckling av Chain Classic 2.2 är baserat på OpenEdge 11.7 från Progress.
I denna version har det tagits i bruk en ny version av den komponent som skapar och skriver ut streckkoder, inkl. i denna rapport


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.

Teknisk information
Systemalternativ 1000 = 1 stoppar möjlighet för nyupplägg/kopiering av varutransaktioner manuellt i Chain Classic.

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.

Teknisk information
  • Butiken måste ha "Lager" aktiverat i butiksregistret.
  • Innehållsvaror i paket måste vara lagerstyrt.
  • Råvara måste vara lagerstyrt.
  • Receptvara och paketvaror ska inte vara lagerstyrda.

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.

Teknisk information

Vanligtvis hämtas alltid försäljningsbelopp från "ExtendedAmount/Amount" (i POSLog). Detta avrundas på normalt sätt (t.ex. 21.68).
Vid uppdatering av kreditförsäljning till kundförsäljningsstatistiken hämtas försäljningsbeloppet från "ExtendedAmountRounded/Amount" (21.67).
Detta är gjort för att säkerställa överensstämmelse mellan total försäljningssumma och summan av varuraderna vid överföring till Cash Settlement.

Nedan visas ett exempel på detta:

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

Teknisk information

Teknisk information

I systemparameter 1001 sätts värde för vilken av flikarna 1-5 som ska vara öppningsfönster i "Priskontroll".

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.

Teknisk information

Systemparameter 987 = 1 - För att söka fram rätt vara i Chain Classic vid import av VAR-post utan prisinformation i RIGAL VPI. 


Om tandemnummer används rekommenderas följande inställning vid användning av tandemnummer. (Hämtat från RTC-34465 )

Systemparameter 425 = 2 - Vara söks upp via alla tandem/huvudvara-kopplingar

Systemparameter 632 = 1 - Tandem från RIGAL VPI används och tar bort ev. avvikelse i Chain Classic.

Systemparameter 491 = 0 - Om unikt varunummer används.

Systemparameter 669 = 1 - Unikt varunummer uppdateras från ny vara i RIGAL VPI och ev. samma varunummer raderas från befintlig vara i Chain Classic.

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.

Teknisk information

För optimal användning av tandem rekommenderas följande inställning:

Systemparameter 425 = 2 Vara söks upp via alla tandem/huvudvaru-kopplingar

Systemparameter 632 = 1 Tandem från RIGAL VPI används och raderar ev. avvikelse i Chain Classic.

Systemparameter 491 = 0 Om unikt varunummer används.

Systemparameter 669 = 1 Unikt varunummer uppdateras från ny vara i RIGAL VPI och ev. samma varunummer raderas från existerande vara i Chain Classic

Se även (RTC-34131) för ytterligare informaton om inställning av parametrar vid uppdatering via RIGAL-VPI.

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.

Teknisk information
Systemparameter 675 styr om lokala butikspriser ska tas bort bort vid profilprisändring via RIGAL VPI. Det är här möjligt att förskjuta borttagningsdatumet framåt i tid.

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. 

Teknisk information

Namn på loggfil: %%\LRS\logg\"bestill_mmåååå.butnr"

I loggtexten visas användarnamn, datum/tid, om det gjorts godkännande eller bekräftelse eller upphävande av detta. 

För att skilja ut beställningar som skapats från "Beställningsfördelning Excel", sätts ett märke i fältet besthode.frigruppe3 (visas endast i editor).
Beställningar skapade från "Beställningsfördelning Excel" får värde 1 medan varumottagning skapat från samma program, får värde 2.


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.

Teknisk information
Butiker måste ha kommunikationstyp 11 och dessutom vara inställda med lagerstyrning genom att kryssruta för "Lager" markerats.

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.

Teknisk information
Systemparameter 1002 Styr om pris ska läggas ut till Tokheim POS för mixgrupp 1 för mixtyp 35.

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.

Teknisk information

Funktionaliteten är parameterstyrd och bestäms av tre viktiga element i systemparameter 537:

  1. Frigrupp
    Sätts för att exkludera varor som inte är kompletteringsvaror, och därför inte ska använda denna funktionalitet.
  2. Antall dagar kvar på kampanj
    För en vara med aktivt kampanjpris används nettopris från kampanjkalkyl om det återstår minst X dagar av kampanjperioden.
  3. Antal dagar framåt i tid
    För varor där det finns en framtida kampanj som startar innan Y dagar, används nettopris från den framtida kampanjkalkylen.

Andra förutsättningar:

  • Om "Beställs till" har angivits i fliken "Tillägg vara" i "Varuregister" för en vara, men denna är äldre än dagens datum, används ordinarie nettopris.
  • Det kontrolleras både på kampanjpris och medlemserbjudande. Om båda typer finns inom angivet intervall, används nettopris från medlemskampanj som antas vara fördelaktigare än ett kampanjpris under samma tidsperiod.


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. 

Teknisk information

Alla konsulter bör vara uppmärksamma på om CPU-användningen är hög (100%) under lång tid. Då måste följande ändringar övervägas:

  1. Antal CPU'er i förhållande till antal användare och inställningar (samma numa-nod)
  2. MHz på CPU'ene (gärna 4 GHz)
  3. Minne (måste ha tillräcklig plats att kunna cacha "minst" halva databasen)

Användning av indexet jobbhodeidx8 (endast jobbstatus) och kassdagidx6 (endast datum) är i stor grad ersatt med användning av bättre index som kan förbättra användarupplevelsen.
Men det är viktigt att förstå att detta inte räcker om det upplevs kritiska prestandaproblem.
måste det göras ett eller flera av nämnda förslag på serveruppgradering.

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

(RTC-29779)  

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

Teknisk information
Med programmet "Godkänn kampanjgrupp" (LRS > Korrigera/Ändra data) kan en kampanjgrupp sökas fram och godkännas på nytt.
Det resulterar i nytt komplett utlägg till POS och eventuella 3:e-partslösningar. 



Chain Classic version 2.2.0.0.10

Dokument status: RELEASED

Datum:

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Beställning

Behandling av varor märkta "Ej beställning" i Beställningsmodulen (RTC-31342)

  • Försöker man lägga in en vara markerad "Ej beställning" i programmet "Beställning" kommer varan att avvisas med meddelande om att varan inte kan beställas.
  • I programmen "Beställningsförslag" och "Beställningskriterier" kommer alla varor markerade "Ej beställning" i "Varuregister" eller som butikslokalt värde för butiken att avvisas.
  • Vid uppdatering av RIGAL I-fil kommer även varor märkta "Ej beställning", att avvisas. Det är som utgångspunkt avsänderens ansvar, men Chain Classic måste korrigera om dessa sänder fel data.
  • Vid uppdatering av beställningsrader från POSLog, kommer varor som inte kan beställas att avvisas.

Lager

Se lager i andra butiker (RTC-32343)

Med funktionsknappen "Lagerinformation" i Varu- och Prisregister visas lagersaldo för butiksanvändaren om butiken har lagerpost på varan. Utan lagerpost på varan är knappen deaktiverad.

Med åtkomst till andra butikers lagersaldon kan butiksanvändaren se lagersaldon i dessa butiker förutom egen lagerstatus. Om egen butik inte har lagerpost på en vara, kan butiksanvändaren ändå se lagersaldon i de andra butikerna. 

Utlägg till POS

Korrekt användning av av punkt som decimaltecken vid export av mixmatch till POS (RTC-32523)

När en lokal butiksmixmatch eller kampanjgrupp skapas i Chain Classic efter att ha importerat en RIGAL X/J-fil och nyskapade butikspriser som saknas, används punkter alltid som decimaltecken i kassautlägg till POS. 

VPI-Sync

VPI-Sync och flera obehandlade ordinarie prisändringar i varukö (RTC-31186)

Det händer att Chain Classic och POS "inte är eniga" om vad som gäller ordinarie pris. För att VPI-Sync inte ska visa onödiga avvikelser, kommer senast "godkända" pris i Chain Classic skickas till POS och användas för sammankoppling för motsvarande pris där.
Detta tar bort avvikelser som kan bero på att butiken inte har skrivit ut en etikett eller godkänt prisändring om denna används.  

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

Teknisk information

Systemparameter 645 innehåller en lista över aktuella rabattprislappar, medan 647 gör det möjligt att skriva rabattprislappar.

Systemparameter 688 öppnar för att kunna använda 3 rabattalternativ för små rabattprislappar med 21 tecken (typ LRS-21).

Beskrivning av koden ovan:

  • 1-4 = Index för rabattyp: 2207 för procentrabatt. 2221 för kronrabatt och 2222 för rabatterat pris.
  • 5-17 = 13 siffror för EAN.
  • 18-19 = Värde (%/kr) för vald rabattyp.
  • 20-21 = Orsakskod.   

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.
Teknisk information

Systemparameter 992 = 1 öppnar för användning av förenklad lösning för "Excel online".

Notera att om OneDrive används, kommer "Dokument" katalogen under denna användas.

Användare som fortfarande har Excel lokalt på PC kommer inte märka någon skillnad om den nya parametern är på.

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.

Teknisk information

Systemparameter 716 aktiverar funktionalitet för "Utlägg till extra POS Server", som kommer visas i fliken "Generellt" i programmet "Utlägg till ny butik".

  • Om "Värde" i systemparametern inte har angivits, kommer val för detta extra utlägg inte visas.

  • Observera att poster under "Alternativ" inte kommer läggas ut till den extra katalogen, om det finns post i Systemalternativ 208 eller Systemalternativ för butik 208 som stoppar utlägget.

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.
Teknisk information
  • Krav till e-postadress för kassör aktiviseras när systemparameter 988 = 1.
  • Loggning av avvisade poster sker som standard fel-katalog (errMMDD.butnr) i loggkatalogen.

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.

Teknisk information
Raderingspost för tandem i RIGAL V-filen har "S" i fältet framför tandem som ska raderas. Detta gäller fält 7.1.61 och 7.1.63.
Vanligvis innehåller dessa E/P för att beskriva om tandem i nästa fält är ett EAN eller en PLU.

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.

Teknisk information

Systemparameter 112 = 1
Systemparameter 491 = 1
Systemparameter 985 = 1 (eller 2)

Förutsättningen för denna funktionalitet om EAN saknas i en RIGAL PRI-post, är att det finns ett profilpris för varan med en unik kombination av varunummer och viktkod. Då kan nytt lokalt butikspris skapas med rätt EAN.

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.

Teknisk information

När systemparameter 302 = 1 döljs "bekräftelseknapparna" i "Beställning".
Då behöver användaren bara förhålla sig till "godkänn knapparna".

Systemparameter 989 ger möjlighet till att exportera ändrad beställning till ERP i RIGAL I-format.  

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.

Teknisk information
Detta gäller standard priskontroll, och det är den två-delade systemparameteren 990 som öppnar för denna funktionalitet.

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.

Teknisk information

Systemparameter för standard priskontroll:

  • Systemparameter 308: Välj om nya priser, ordinarie prisändringar och/eller kampanjpriser ska visas och om användaren kan ändra utpris för nya varor/ordinarie prisändringar.
  • Systemparameter 616: Ska mixmatch kontrolleras
  • Systemparameter 936: Ska kampanjpriser och/eller mixrader i en kampanjgrupp kunna godkännas eller avvisas.
  • Systemparameter 990: Ta bort möjlighet för att kunna "Återställa" tidigare avvisade profilprisändringar, och ge möjlighet att kunna analysera bruttovinst vid en prisändring innan den godkänns och försvinner från listan. Denna möjlighet är nu också tillgänglig i standard priskontroll, I "Nettopriskontroll" har detta alltid varit standard.     

Systemparameter 890: Ska inte användas i standard priskontroll. Ska bara fungera vid användning av "Nettopriskontroll", och för detta ska alla parametrar ovan inte användas.

Layout för VPI-mallar

(RTC-30541)

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

Teknisk informasjon

VPI-mall nr 1, som alltid är standard, kan inte tas bort. Fält som tillhör denna VPI-mall kan heller inte tas bort. 
Alla andra VPI-mallar (> 1) kan raderas i fliken "VPI-mall".
I fliken "Fält i mall" kan också enskilda rader tas bort i vald VPI-mall.
Vid kopiering av en VPI-mall som inte innehåller alla fält, kommer även kopian få samma, begränsade innehåll av fält.  

Underhåll av mixmatchtyper

(RTC-31184)

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

Det nya menyvalet är endast tillgängligt i Chain Classic version 2.2 .

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.

Teknisk information

Utlägg av uppdaterat lager till JSON-format utförs när:

  • Fältet "Logisk" i Systemalternativ 193 för post markerad "Lager" är påslagen.
    eller
  • Fältet "Parmlog" i Systemalternativ 193 för butik för post med "Parmnr" = 1, är påslagen.

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.

Teknisk information
Denna funktionalitet kräver att systemparameter 185 inte används.

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.
Teknisk information
Aktiva butiker måste ha kommunikationstyp = 11.

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.

Teknisk information

Det är fält 7.1.5 i RIGAL V-fil som gör detta möjligt:

Värde A = Borttagning av kampanjpris (start- och slutdatum måste anges i fält 8 och 9).
Värde B = Borttagning av medlemspris (start- och slutdatum måste anges i fält 8 och 9).
Värde C = Borttagning av framtida prisändring (framtida ändringsdatum måste anges i fält 8).

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"
Teknisk information
Tandem kan tas bort via RIGAL V-fil genom att sätta "S" i fältet före tandem-EAN.

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.

Teknisk information
I intern test upptäcktes problem med att uppdateringsprogrammet hängde sig med status "LOCKED" för appserveragenterna.
Ett samarbete mellan Chain Classic teamet och InStore App teamet har löst låsningsproblemet.
Generella förbättringar i InStore App minimerar motsvarande problematik vid användning av andra proxy-uppdateringar. 



Chain Classic version 2.2.0.0.09

Dokument status: RELEASED

Datum:   

Förutsättningar för uppgradering

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

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

(RTC-32054)

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

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

Förutsätter att det finns Lexmark-butiker definierade i systemet, dvs. att butiksnummer satts upp i systemalternativ för butik 717.

Vid ändring av EAN/PLU blir nu följande utlagt till Lexmark:

  • Varufil till totalbutik:

o    Borttagningspost för gammalt EAN/PLU-nummer (Lexmark kötyp 2, repeterat om antal tandemar är > 1)

o    Ny post för nytt EAN/PLU-nummer (Lexmark kötyp 1, repeterat om antal tandemar är > 1)

  • Prisfil til vanliga butiker:

o    Borttagningspost för gammalt EAN/PLU-nummer (Lexmark kötyp 2, repeterat om antal tandemar är > 1)

o    Ny post för nytt EAN/PLU-nummer (Lexmark kötyp 1, repeterat om antal tandemar är > 1)

o    Poster för pågående kampanjer och framtida prisändringar (Lexmark kötyp 6-8, repeterat om antal tandemar är > 1).
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).

Teknisk information

Förutsätter att det finns Lexmark-butiker definierade i systemet, dvs. att butiksnummer satts upp i systemalternativ för butik 717.

Följande utlägg  görs:

  • Lexmark varuformat (libitemlex):

o    Borttagningsposter för tandemar på gammal vara (inkl. den som flyttas).

o    Varuändringsposter för alla tandemar på ny vara (inkl. den som är flyttad).

  • Lexmark prisformat (priceitemlex):

o    Borttagningspost för tandemar på gammal vara (inkl. den som flyttas).

o    Nyupplägg av tandem till ny vara (inkl. den som är flyttad).

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

Teknisk information

Förutsätter att det finns Lexmark-butiker definierade i systemet, dvs. att butiksnummer satts upp i systemalternativ för butik 717.

Följande utlägg görs:

  • Lexmark varuformat (libitemlex):

o    Borttagningsposter för alla tandemar på huvudvara (inkl. tandem som ska tas bort).

o    Nya varuposter för återstående tandemar på huvudvara.

  • Lexmark prisformat (priceitemlex):

o    Borttagningsposter för alla tandemar på huvudvara (inkl. tandem som ska tas bort).

o    Nya varuposter för återstående tandemar på huvudvara.

o    Poster för aktiva kampanjer, samt för framtida kampanjer/prisändringar.

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.

Teknisk information

Systemparameter 878 är ändrad och måste vara satt till gällande omsättningskrav för Lexmark-etikett:

  • Värde 1 = Max antal dagar bakåt i tid (senaste försäljning), vid varuändring/ord. prisändring.
    Värde 2 = Max antal dagar bakåt i tid (senaste försäljning), vid ändring av kampanjpris och medlemserbjudande.
  • Antal dagar = 0, betyder för båda parametrer att det inte sätts krav på omsättning.

Värdena i systemparameter 878 gäller generellt för alla butiker med Lexmarkutlägg (alla butiker i systemalternativ för butik 717).

Systemalternativ för butik 878 öppnar för att butiksanvändare själv kan sätta dessa värden. "Användarstyrt" och "Tillåtet att ändra för butiksanvändare" måste båda vara valt för detta.

I Help-katalogen finns skriptet "lagbutparmrad_878.p" som kopierar värden från systemparameter 878 till "Systemalternativ för butik 878" för ALLA "Lexmark-butiker". Om endast vissa butiker ska ha denna åtkomst läggs dessa upp manuellt. Omsättningskraven kan då ändras av de butiker som har åtkomst om det är önskvärt med avvikande värden.



Chain Classic version 2.2.0.0.08

Dokument status: RELEASED

Datum:   

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Kampanjgrupp

Borttagning av hel mixmatch i kampanjgrupp (RTC-32186)

Det går radera en komplett mixmatch i kampanjgrupp. Det görs då ett utlägg till POS av endast en post för borttagning av mixhuvud.
I POS raderas därefter alla relationer till de varor som från början var kopplade till mixmatchen.   

Rapporter

"Fråga på pris" i rapport (RTC-31806)

I många omsättningsrapporter för kassörer går det se antal förfrågningar på pris som gjorts i kassan. Det är totalt fyra varianter av detta som kan medföra att räknaren ökar:

1.       Kvitto med bara fråga på pris

2.       Annat makulerat kvitto med fråga på pris (t. ex. parkerat kvitto)

3.       Offert med fråga på pris

4.       Vanlig varuförsäljning med fråga på pris

Varuregister

Lagerinformation i varu- och prisregister (RTC-30139)

Genom att använda knappen "Lagerinformation" i "Varu- och Prisregister" visas lager på varan som är i fokus i en söklista för alla butiker som användaren har tillgång till och som har lagerpost. 

  • Fält som är knutna till centrallager (saldo och beställda) döljs när användarens butik inte har referens till butiksnummer för centrallager.
  • Eget butiksnummer markeras i listan med grön bakgrund för alla varianter så att det tydligt kommer fram vad som är eget lager.

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.

Teknisk information

Etikettyp väljs enligt specifikation på varans prispost, och skrivare väljs automatiskt som ett resultat av att skrivaren har installerats. Väljer man en specifik etikettyp, kommer det att sökas efter en skrivare för butik/etikettyp. Finns skrivaren, föreslås denna.

Notera

"Etiketter från varumottagning" kräver att vald etikettyp är definierad som prislapp, se systemparameter 222

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.

Teknisk information

Med aktiv systemparameter 983 förhindras utlägg av recept- och ingrediensinformation.

  • Ingredienser kommer istället att inkluderas i [SHOP_UPDATE] där varje ingrediens blir definerad för en råvara. Ingrediensenrna kommer efter varuutlägget och med "dummy" EAN-nummer i en bestämd nummerserie.
  • För receptvaror läggs inte receptinnehållet ut. Det innebär att hela sektionen [COMPOSITIONS_UPDATE] tas bort.

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.

Teknisk information

Systemparameter 986 öppnar denna funktionalitet.

I Leverantörsregisteret markeras de leverantörer detta gäller genom att kryssa i "Använt antal i förpackning".

Observera!

Denna funktionalitet fungerar som beskrivet bara vid godkännande av varumottagning i Chain Classic. 
Vid automatisk uppdatering av varumottagning som gjorts i InStore App, förutsätts att antalet är korrekt för alla varor.

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

Teknisk informtion
Uppdatering av beställningskriterier från Excel aktiveras genom att lägga in utvalda butiker i systemparameter 869.
Då kan knapparna för import/-export från Excel visas i programmet.
Detta måste användas när systemparameter 984 används för uppdatering till fritt valda butiker. 

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.

OBS!

OBS! PRI-post med okänt EAN, i Chain Classic, avvisas.

Teknisk information

Viktigt att följande systemparameterar har rätt värde:

112 = 1 (användning av alfanumeriskt varunr)
219 = 1 (sök via varunr vid okänt EAN)
491 = 1 (påslagen betyder inte krav på unikt varunr)

Huvudparameter här, för att hitta vara via unik kombination varunr och försäljningsenhet:

Systemparameter 985 kan ha 3 värden:

o    0 = Används ej

o    1 = Bara för PRI-poster

o    2 = Både VAR- och PRI-poster

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.

Teknisk information

Förutsättningar: 

  • Gäller bara "Elektronisk varumottagning" baserat på existerande beställning.
  • Paketvara ska ligga i beställningen.
  • Vid uppdatering av RIGAL I-filen som skapas, görs det varutransaktioner med antal för innehållet i paketvaran.

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.

Teknisk information
Systemparameter 953 gör att orderrader med antal = 0 behandlas.

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

Teknisk information
"L15-värdet " hämtas från fältet "Kompmängd".

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.

Teknisk information

Systemparameter 185 = 0
Systemparameter 191 = 0
Systemparameter 987 = 1

I VPI-mallen måste värde för "utpris" i kolumn "Nollställa" att sättas till "Ja".
Detta öppnar för direkt behandling av poster med endast varufälten ifyllt (pris = 0).

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.

Teknisk information
Programmet "Ta bort tandem som huvudvara" under "LRS"/"Korrigera/ändra data" är som standard uppsatt med endast loggning (i txt-loggen).
Detta kan utan risk köras som en hälsokontroll.
Om txt-loggen visar att det finns avvikelser, kan programmet körs igen utan markering för loggning.
Resultatet blir då att avvikande tandem tas bort och läggs ut för borttagning till POS. Det läggs också ut borttagningspost till Chain Web vid behov.

Kontroll av fel i JSON lagerformat

(RTC-30567)

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

Teknisk informtion

För att slippa att filkön fylls på med prioriterade lagerposter med fel format, så kommer nu alla sådana poster med < 7 fält att avvisas.
De loggas innan de tas bort från filkön.

För prioriterat lagerutlägg i JSON-format:

  • Slå på "Logisk" i Systemalternativ 193, alternativt skapa butikspecifik post i Systemalternativ för butik 193.
  • Fel loggas till filen lrs\logg\jsonerrMMDD.txt.
  • JSON utläggsfil hamnar i sendes-katalogen om inte en alternativ katalog är angiven med komplett sökväg i systemparameter 798 (till exempel. C:\lrs\json_stock).

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.

Teknisk informasjon
I systemalternativ 1019 är det värde i fältet "Logisk" som avgör om ett fältnamn ska visas eller inte.

Borttagning av Chain Classic användare

(RTC-31487)

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

Teknisk information

Systemparameter 993 öppnar för möjlighet att utvecklinganvändare kan få behörighet att ta bort annan utvecklingsanvändare.
Det rekommenderas att detta kan slås på vid extraordinara behov.

Om alla utvecklingsanvändare tas bort, blir det svårt att rätta problem som kräver en användare med rättigheter på högsta nivå.

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

(RTC-31530)

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



Chain Classic version 2.2.0.0.07

Dokument status: RELEASED

Datum:  

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Lexmark

Lexmark uppdatering när erbjudande = ordinariepris (RTC-29650)

I situationer då kampanjpris/medlemserbjudande = normalpris och normalpris ökas under kampanjperioden kommer detta inte att skapa etikett.
Om kampanjpriset därefter ökas så att det återigen blir lika med normalpris kommer det att skapas etikett till Lexmark märkt som prisändring istället för kampanj/medlemserbjudande.
Det är bara ändring av utpris på erbjudanden lägre än ordinariepris som skapar etikett märkt kampanjpris/medlemserbjudande. 

RIGAL

DUN-nummer i RIGAL VPI (RTC-30127)

Uppdatering och ändring av DUN-nummer kan kommuniceras via, fält 7.1.56, i RIGAL V-fil. 

Inventering

Utlägg till 3:e-part av inventerade varor med resultat = 0 (RTC-30681)

Vid utlägg av svinnposter til 3:e-part efter inventering kan det finnas tillfällen då inventerade varor med 0 som resultat också ska läggas ut.
När detta används läggs dessa 0-poster ut vid alla typer av inventering.  

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

Teknisk information
Programmet som ska användas är: "LRS"/"Parameter"/"Slå på kampgrutlägg till POS" 
Funktionaliteten kan slås på manuellt genom att sätta systemparameter 750 = 1, men då måste kampanjerna konverteras manuellt genom att kopiera, avsluta och godkänna de kopierade kampanjgrupperna.
Genom att använda anpassat program för detta inkluderas kontroll av varuköposter och borttagning i POS. Kampanjgrupperna startas om på nytt före nytt utlägg i kampanjgruppsformatet.  

VPI-mall för etikett

(RTC-30032)

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

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

Teknisk information

VPI-mallar har nu av nummer 1-99, medan etikettmallar har nummer från 100 och uppåt.
Detta gör att när denna funktionalitet tas i bruk och VPI-mall för Lexmark har ett nummer lägre än 100, MÅSTE skriptet "flyttetimal.p" i katalogen "Help" köras.
Då kommer nummerserien att uppdateras och ny etikettmall skapas med detta nummer.

Dessutom uppdateras motsvarande värde i systemparameter 876, där nummer för Lexmark etikettmall är angiven, från "X" till 100.
Avvikelse i denna parameter förhindrar etikett.

I kolumnen "Filutlägg" betyder "Ja" att ändring av aktuellt fält medför utlägg till Lexmark-fil.
För att kontrollera vilka fält som leder till/inte leder till utlägg, tryck på kolumnrubriken för att sortera på innehåll, 

I kolumnen "Etikettutskrift" betyder "Ja" att ändring i detta fält aktiverar etikett, genom att setta fält 7 (Etikett) i Lexmark-utlägget till "Yes".
Standardvärde är "Ja" för ändring av Utpris, Kampanjpris och Medlemspris. I detta program kan detta enkelt ändras eller kompletteras med andra alternativ.

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.

Teknisk information
Vid butiksnummerbyte ändras det i gammal butikspost i butiksregistret till nytt butiksnummer.
Om gammalt butiksnummer ska behållas, skapas en ny post med gammalt butiksnummer, profilnummer behålls, kommunikationstyp sätts = 1 och butiksnamn sätts till: "Old store no. för store xxxx (nytt butiksnr).
Annars är inställningsdata blankt.

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

Teknisk information

Systemparameter 982 måste sättas upp med sökväg (path) till katalog för kundrelaterade JSONL-filer, till exempel: json_cust\, denna måste också skapas manuellt i LRS-katalogen.

  • Detta är en första utgåva som troligen måste ändras tillsammans med lösningarna som ska motta detta format.

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. 

Teknisk information
Det måste manuellt skapas en katalog, under LRS-katalogen, med samma namn som använts i fältet "Värde" i systemparameter 982.

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.
Teknisk information

På grund av begränsning i 3:e-parts programmet "vsView", är rapportgenereringen begränsad til max 200.000 lokala prisposter. Om antal är större än detta, är risken för hängning i programkörningen stor. Nu är det förmodligen inte aktuellt att läsa en rapport med så många varurader. 

  • Systemparameter 997 finns för att ange max antal poster varor som kan skrivas ut i rapport. Maximalt 200.000 og 0 = används ej.
  • "Skapa inte rapport" är ett val i fliken "Alternativ" som inte skapar någon rapport oavsett antal varor i urvalet. Detta bör användas när du vet att det är många lokala butikspriser som ska raderas och/eller att rapport är onödig.
  • Om hittade antal poster överskrider värdet i systemparameter 997 eller 200.000 stk., kommer det heller inte att skapas någon rapport.
  • Om rapport inte skrivs, visas detta som: "Ingen rapport" först i kolumnen "Resultat" i rapportlistan för antal varor. 

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.

Teknisk information

Loggfilen har följande innehåll:

  - Beskrivande text
  - Butiksnr
  - Ordernr
  - Ordertyp
  - Sändstatus
  - Datum/tid för när mottagningen registrerades
  - Kollinr
  - Lagerplats  

Vad som triggar loggning:

  - Ingen kontakt med webservice
  - Weborder mottagen i butik
  - Överföring via webservice misslyckades
  - Weborder EJ mottagen komplett i butik

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. 

Teknisk information
  • Fullformat Sortimentlista Excel aktiveras genom att sätta systemparameter 964 = 1.
  • Skapad Excel-rapport representerar det fullformat som ska användas för VPI-import via excelvpi.csv.
  • Det är ENDAST fält från standardformatet som uppdateras, inte de nya fälten.

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.

Teknisk information
Aktiv systemparameter 983 medför att fältet COMP_TYPE i utlägg av receptvara till Tokheim POS ska ha värde "3" istället för "2".



Chain Classic version 2.2.0.0.06

Dokument status: RELEASED

Datum:   

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Etikett

Etikett skrivs inte utan ändring av utpris (RTC-29332)

Om nytt kampanjpris är samma som utpriset eller om kampanjnettopriset, men inte utpriset, ändras på aktiv kampanj då skrivs det ingen etikett vid något av dessa tillfällen.

Kampanjgrupp

Borttagning av mixmatch från ej godkänd kampanjgrupp (RTC-29477)

Vid uppläggning av ny kampanjgrupp med flera mixmatch kan användaren ta bort både en och flera mixmatch innan själva kampanjgruppen godkänns.    


Samma vara i multipla mixmatcher i samma kampanjgrupp (RTC-27651)

Det går ha flera mixmatch, med samma vara i en kampanjgrupp, utan risk för komplikationer på grund av identiska start- och/eller slutdatum.  

Mixmatch

Hämtning av nya varor i redan godkänd mixmatch (RTC-29815)

I manuell mixmatch eller mixmatch i kampanjgrupp kan hämtning av nya varor göras på flera sätt. Oavsett metod kommer både automatiskt och manuellt godkännande/lagring att skapa varuköposter med samma butiksnummer som är gällande i nämnda erbjudandetyper.

Rapporter

Antal sålda varor i grafisk varugruppsförsäljningsrapport (RTC-29486)  

Vid användning av grafisk varugruppsförsäljningsrapport kan det öppnas ett fönster för "Fördelning per butik". Generellt kommer denna "pop-up" att ha en kolumn för antal, men i tabeller för varugrupp- och undergruppsförsäljning är det ingen mening att lagra antal (av oidentifierade varor). För att undvika missförstånd exkluderar dessa försäljningsrapporter kolumnen "Antal", istället för att visa värde 0 på alla poster.  

Varumottagning

Utskrift av prislappar i varumottagning (RTC-28791)

Vid användning av  parameterstyrd speciallösning för varumottagning (ej standardlösningen el. varumottagning), går det skriva ut etiketter via knapparna "Prislapp" och "Prislapp lager". Funktionen ger prislappar för nya varor och i programmet utförda prisändringar på både befintliga och nya varor.


Uppdatering av nettopris i existerande el. varumottagning vid manuell varumottagning (RTC-28081)

Om det uppdagas en vara med fel nettopris i elektronisk varumottagning, kan detta korrigeras genom att skapa en manuell varumottagning och sätta rätt pris på varan där. Det skapas då en varutransaktionspost som har rätt värde och lagret uppdateras. Om man, som riktigt är i detta fall, väljer att uppdatera mot befintlig order blir motsvarande orderrad i elektronisk varumottagning uppdaterad med nytt värde på nettopris och även data i orderhuvudet blir omräknat i förhållande till nytt värde från manuell varumottagning.

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.

Teknisk information
I systemparameter 101 anges antal dagars fördröjning vid borttagningsposter från leverantör.

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.

Teknisk information

Mixmatchtyper som ska ta hänsyn till undantagslistan med varugrupper är angiven i systemalternativ 132.
Den "Speciella varugruppslistan", undantagslistan, har listnr: 100000001.

Under LRS-menyn ligger programmet "Kampanjgr och mix till POS" för att köra denna uppdatering manuellt. Här kan anges om alla aktiva och framtida kampanjgrupper och/eller mixmatch ska läggas ut till POS. Dessutom kan bestämmas om endast kampanjgruppshuvud eller mixhuvud ska läggas ut.

Detta är samma program som körs direkt efter att underhåll av "Speciella varugrupper" har sparats, men då är det bara berörda mixhuvud-poster som läggs ut, för mixtyper angivna för att ta hänsyn till 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. 

Teknisk information

Finanstransaktion med transtyp 891 fångar upp belopp som representerar köp av presentkort, betalt med presentkort och/eller tillgodokvitto. Fältet antal räknas upp med 1 för varje kvitto där denna kombination finns.

Utlägg av RIGAL finans-fil (F-fil) är utökad med ny transaktionskod IGG som innehåller data beskriven ovan.

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. 

Teknisk information

Standardlösning med bildbank på lokal server, med inställning i systemparameter 68, till exempel  "\lrs\bilder", kan fortfarande användas som alternativ. Men systemparameter 68 ska inte användas om kund övergår till annan bildbankslösning.

Vid övergång till bildbankversion "Q-bank":

  • Systemparameter 972 aktiveras.
  • Dessutom måste skriptet "Nullstillbilde.p" i hjälp-katalogen köras för att ta bort alla gamla bildkopplingar.
  • Det förutsätts initialt att det är "png-filer" som används. Med EAN = filnamn blir det "EAN.png". Det är dock möjligt att öppna för användning av andra bildformat.
  • Vidare används https-anrop till kundens bildarkiv:
    Till exempel:  https://media."kunde".no/butikkflater/pos_button/

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.

Teknisk information
Systemparameter 977 styr hur nettoprisändringar ska uppdateras via RIGAL/POSLog.

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

Teknisk information
Det är programmet "Nollställning av försäljningsdag", som utför detta. Varutransaktioner, inom datumintervall, märkta "Kassa" raderas och lagerantal räknas ned med motsvarande transaktions värde. Detta för att det inte ska bli dubbel registrering på lager. Svinnposter, i varutransaktioner, skapade i Chain Classic påverkas inte av detta. 

Ä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".

Teknisk information

Systemparameter 980 aktiverar denna funktionalitet, och nettoprisfältet öppnas för redigering. Det är ett kalkylerat fält (ej lagrat i databasen) och kan inte uppdateras direkt. Vid nettoprisändring sker därför följande:

  • Nytt skärmvärde läggs in i grossist-fältet.
  • Ev. kalkylrabatter sätts till 0.

Det betyder att om ursprungligt parti är 100 och rabatt 1 = 10 %, kommer nettopris att visas som 90. Genom att använda detta sätt att ändra nettopris, överskriver användaren ursprungligt kalkylerat värde, med till exempel 95. Resultatet blir parti = 95 och alla rabatter = 0.

Notera!

Ny parameter kan inte användas tillsammans med systemparameter 799, som är en specialinställning för Coop Svalbard där partipris kan ändras direkt i samma skärmbild.

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.

Teknisk information

Med aktivering av systemparameter 810 tillåts det att också inventering blir med bland de transaktionstyper som kan läggas upp/kopieras/motposteras i Chain Classic.

Det rekommenderas inte att aktivera denna parameter för lagerstyrda butiker, då en del av funktionaliteten för modellvara inte är optimal i detta sammanhang, samt att det finns ett dedikerat program för registrering av dessa.

Systemparameter 394 anger om "reklamation till leverantör" används i Chain Classic, ingen pennningtransaktion, endast varor ut från lager. Om <> "", är reklamation till leverantör tillåtet.

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

Teknisk information

SSO för AD-användare aktiveras genom att lägga in aktuell domän i systemparameter 90, och blir då gällande för alla användare som loggar in via denna domän. Detta parameterval öppnar också för att lägga in en "okänd" domän i parameter 90 som då kan användas även i domänfältet för enstaka användare, om inte alla ska ha denna funktionalitet.  

För "silent upgrade modus" vid uppdatering av klientfiler är det två alternativ att välja på. Värdet "CUOnly" läggs in i filen "client_update.xml", i "FIX-katalogen", på något av följande sätt. 

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.

Teknisk information

Denna funktionalitet förutsätter användning av systemparameter 9003.

Systemparameter 981 kan då användas för att ange de antal dagar bakåt i tiden man får ange vid registrering av ny post i drivmedelsprogrammen.

Med standardvalet, systemparameter 981=0, är det ingen begränsning. 

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.

Teknisk information
Alla "NAM"- poster, oavsett typ, trunkeras efter 20 tecken om varunamn i Chain Classic innehåller flera än dessa 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. 

Teknisk information

Om StoreIDToCreateCustomerOrdersIn > 0 men butik saknas i Chain Classic, loggas felmeddelande i standard LRS\logg\"POSLog*.butnr"

Kvitton som loggas måste behandlas manuellt i efterhand.

Övergång till kampanjgruppsutlägg  

(RTC-28386)  

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

Teknisk information

Programmet som ska användas är: "LRS"/"Parameter"/"Aktivera kampgrutlägg till POS"

Funktionaliteten kan aktiveras manuellt genom att sätta systemparameter 750 = 1, men då måste kampanjerna konverteras manuellt genom att kopiera, avsluta och godkänna de kopierade kampanjgrupperna. Genom att använda anpassat program för detta inkluderas kontroll av varuköposter och borttagning i POS, kampanjgrupperna startas också om innan nytt utlägg i kampanjgruppsformatet.

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

(RTC-27990)

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

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

Teknisk information

För typ 3 och 4 sker ENDAST HK-utlägg, det är allmän information. Det bör därför värderas om dessa ska begränsas som standard, om utlägg är det som önskas. Informationstexter som skapas av butiksanvändare kan bara användas som infokälla i detta program i Chain Classic.

Systemparameter 974 = 0,0,1,1 visar inställningar för att nya varunoteringar av typen 3 og 4 i "Varuinformation", bara kan skapas som allmänna informationstexter för HK-utlägg (profil 0/butik 0).

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.

Teknisk information

Plats för export av dessa JSON-filer sätts upp i systemparamater 978. Standardförslag är "json_proc", oavsett katalognamn måste katalogen skapas manuellt under LRS-katalogen.

Om systemparameter 312 är aktiv, skapas också backup-filer i katalogen LRS\sendes\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

Teknisk information
I systemparameter 206 - anges numret på den VPI-mall in som representerar ny vara och de standardvärden som ska användas. Vid okänt VPI-mallnummer, kommer alla fält att bli blanka när "Ny vara" skapas.



Chain Classic version 2.2.0.0.05

Dokument status: RELEASED

Datum:   

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 
Etiketter från varukö

Skriva varuköetiketter från InStore App (RTC-26686)

Det finns stöd för att skriva ut etiketter, från varukö i Chain Classic, direkt från InStore App. De som inte kan skrivas ut visas också i "Varukölista" med etikettflagga = "Nej", och betyder att de inte är utskrivna.

RIGAL

Mixmatch och kampanjgrupp sänds alltid med referens via RIGAL (RTC-28418)

Kampanjhuvud och mixmatchhuvud måste ha referens till varona i erbjudandet. Kundspecifika inställningar ger olika lösningar på detta. Dels kan kampanjgruppsnr och/eller mixmatchnr användas, om dessa nummer inte används gäller "Kampanj-ID" och "externt mix-ID".

Utläggen sker i RIGAL-filer för kampanjgrupp (J) och mixmatch (X).   

Varuinformation

Varuinformationstext (RTC-27650)

När det gäller beskrivning av vara i varuinformationstext, finns ingen begränsning i textlängd.

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.

Teknisk information

Systemparameter 973 kontrollerar vilka ändringar i kundorder som ska loggas.

Notera

 Det finns redan en annan standardlogg för prisändringar i kundorder som loggar alla prisändringar som utförs oberoende av belopp och storlek på prissänkning till loggfil "kordMMDD.butnr".

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. 

Teknisk information

Systemparameter 776 aktiverar denna funktionalitet.  Denna parameter bör vara aktiverad som standard, då loggning bara gäller internöverföringar, små mängder data.

För bästa loggning vid användning av denna funktionalitet, rekommenderas inställning med systemparameter 289 = IBK. Det är inte troligt att någon kund använder IFA numera, därför bör IBK vara standardinställning för alla.

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.

Teknisk information

För begränsning av kampanjgruppsfunktioner:

Systemparameter 975 har fyra värden som kan kombineras.

  • Viktigt! Efter satt värde måste appserver asLRS startas om.


Samma kampanjID för alla butikslokala kampanjer:

I systemparameter 976 anges önskad kampanjID, som kan vara både numerisk och alfanumerisk.

·         Med denna funktionalitet kan INTE systemparameter 496 och systemparameter 685 vara aktiva.

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

Teknisk information

Dokumentation för RIGAL I-fil är uppdaterad i portalen: 

  • "Meddelande till leverantör" läggs ut i fältnummer 30.56
  • "Referenstext" läggs ut i fältnummer 30.57

Varutransaktionslista Excel

(RTC-26927)

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

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



Chain Classic version 2.2.0.0.04

Dokument status: RELEASED

Datum:   

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning 

Etikett 

Beställ etikettutskrift med olika etikettyper (RTC-27262)

Det går beställa och skriva ut etiketter med olika etikettyper i samma etikettbeställning från InStore App. 

Lager

Utlägg av lagerfil till Chain Web (RTC-27548)

Vid utlägg av lagerfil till Chain Web från Chain Classic kommer alltid tidigare exporterad fil, "StockBasis.butnr", att skrivas över, om den inte hämtats.


Optimering av utlägg vid lagerändring (RTC-27423)

Generellt läggs inte lagerändringar ut till POS, detta ska bara ske vid ändring av pris eller kostpris. Varumottagning är därför enda anledning för filutlägg, med lagerändringar, till POS och ev. annan 3:e part.   

Rapporter

Leveransdatum i rapporten "Underlag beställning" (RTC-27033)

När specialfunktionalitet för att visa leveransdatum i "Beställning" används, visar detta leveransdatum på orderrad i rapporten "Underlag beställning".

RIGAL

Utlägg av leverantörsorder-ID efter varumottagning (RTC-27182)

Leverantörsorder-ID är ett fält som inte visas i Chain Classic men som kan användas när leverantör sänder in varumottagning via RIGAL I-fil. När varumottagning är godkänd läggs leverantörs-ID ut i RIGAL I-formatet, detta gäller oavsett om varumottagning görs i InStore App eller i Chain Classic.


RIGAL V-fil och kampanjgruppsdata (RTC-27899)

Vid utlägg av RIGAL V-fil, från "Verkställ vara", läggs det ut kampanjgruppsinfo för kampanjgruppsnummer, kampanj-ID, namn på kampanjgrupp tillhörande formaten "K" (kampanjvara) och "M" (Medlemserbjudande). Dessutom läggs det ut RIGAL J-fil med motsvarande information.

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.

Teknisk information
Systemparameter 838 öppnar för denna funktionalitet.

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.

Teknisk information
Val av VPI-mall görs i systemparameter 741.

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*.*) 

Teknisk information
Systemparameter 969 = 1 slår på denna funktionalitet.

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

Teknisk information

Denna funktionalitet är en kundspecifik lösning! Övriga kunder ska inte använda dessa parametrar.

Utvalda varugrupper och producenter sätts upp i systemparameter 967 och 968.

Systemparameter 707 = 1 gör att avvisning loggas i filen VPI-err*.* och om systemparameter 707 = 0 loggas det i filen err*.*

Vid avvisning skrivs följande till loggarna:

  • Avvisning pga varugruppe - "Varugrupp är spärrad för vpi-mottagning:"" + varugrupp och varugruppstext.
  • Avvisning pga producent - "Producent är spärrat för vpi-mottagning:" + producentnr och namn.

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.

Teknisk information

För att sätta upp "Skriv streckkod" som standard måste systemalternativ 1072, kod 1 - "xfeillip", anpassas till detta, genom att sätta "yes" som 2:a värde i fältet "Värde2":

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.

Teknisk information

För denna funktionalitet gäller:

  • Systemparameter 477 = 1
  • Systemparameter 860 = 1 (utlägg vid mottagning i POSLog)

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.
Teknisk information

Butiker som ska använda denna funktionalitet måste vara upplagt med en post i systemalternativ för butik 2003. 

För att lägga upp dessa finns två möjligheter:

  1. Lägg upp butikerna manuellt.
  2. Använda skript "lagchliste2003.p", i help-katalogen. Alla butiker med kommunikationstyp  = 11 (aktiva butiker), läggs då upp i systemalternativ 2003. 
  • Radera sedan de butiker som inte ska använda L15 kompenserade värden.

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.

Teknisk information

Egen exportkatalog måste skapas under %%:\LRS\. Denna sökväg måste dessutom specificeras i systemparameter 970.

Det görs även backup av denna JSON-fil, i %%:\LRS\Sendes\Backup om systemparameter 312 är aktiv. 



Chain Classic version 2.2.0.0.03

Dokument status: RELEASED

Date:  

Förutsättningar för uppgradering

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

Förbättringar

Modul 

Beskrivning

Beställning

Butik utan "Beställning" (RTC-19163)

Det rekommenderas att alla butiker har "Beställning" påslaget i butiksregistret. Men från patch 32 bör det kontrolleras att butiker som inte har beställning, då faktiskt inte har "Beställning" valt i butiksregistret. Detta för att säkerställa att beställningar inte skapas på dessa butiker per automatik i till exempel Kundorder och Varumottagning från POS eller InStore App. 

Lexmark integration

Utlägg av kampanjposter till Lexmark (RTC-26601)

Utlägg av kampanj- och medlemserbjudandeposter till 3:e-partssystemet Lexmark är begränsat till endast de som är nödvändiga för Lexmarks funktionalitet. Det finns inte samma behov som vid motsvarande utlägg till POS.  

Rapporter

Urval i rapporten "Nonsalerapport per nonsaletyp" (RTC-26418)

Vid beställning av rapporten "Nonsalerapport per nonsaletyp" går det att ange olika urval, till exempel varugrupp. 

RIGAL 

RIGAL-uppdatering av "Fastpris" (RTC-26656)

Flaggan "Fastpris" uppdateras via RIGAL-fil. Värdena F, "P eller Y sätter fastprisflaggan aktiv. Alla andra bokstäver deaktiverar fastpris. Om värde saknas, sker ingen förändring av "Fastpris". 

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.

Teknisk information

I listregister finns programmet "Speciella varugrupper" med listnr 100000001. Angivna varugrupper i denna lista kommer att exkluderas vid snabbprisändring (Hämta varor via urval) till mixmatch. Det är bara innehållet i denna lista som ska registreras från denna meny.

Förutsättningar:

Systemalternativ 121:

  • Kod 3 för mixmatch ska ha "Integer" = 48, för utlägg av nytt fält som innehåller varugruppsnr som ska exkluderas, i mix.butnr-utlägg till.
  • Kod 34 för kampanjgrupp ska ha "Integer" = 64, för utlägg av nytt fält som innehåller varugruppsnr som ska exkluderas, i kampgr.butnr-utlägg till.

I systemalternativ 132 måste de mixmatcher som denna regel ska gälla för, väljas genom att bocka i "Används undantagsvarugrupper".

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.

Teknisk information

Funktionaliteten används endast för typen webshop, med inställning: systemparameter 610 = 1.

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

Teknisk information
Systemalternativ 1093 innehåller de kundfält som kan aktiveres för loggning. För loggning MÅSTE logisk markeras på varje post det önskas uppföljning på.

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.

Teknisk information

Transaktionstyp "IPE" i RIGAL F-fil till EG Cash Settlement innehåller totalsumma och sammanlagd moms för sålda varor i provisionsvarulistan.

Intervall för nummerserie för provisionsvarulistan är angiven i systemparameter 965 och bör inte ändras, om kedjan inte har mer än 1000 butiker. 

"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 
Teknisk information
Om det inte kommer meddelanden loggas det i loggrapport under loggutskrifter. Loggtyper som ska användas måste vara aktiva i systemalternativ 1034 till exempel 9, 25 och 26 som används för mixmatch/kampanjgrupp.

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

Teknisk information
Denna funktionalitet gäller vid användning av "Beställningsfördelning Excel", och både systemparameter 843 och 818 måste vara aktiva.

Sortimentslista Excel

(RTC-25218)

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

Teknisk information
Systemparameter 964 = 1 slår på utökat format i rapporten "Sortimentslista Excel".

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.  

Teknisk information

Systemparameter 963 = 0 - Prioriterar gällande mixvara när motsvarande vara kommer i mixmatch via RIGAL, med samma start- eller slutdatum/tid.

Systemparameter 963 = 1 - Prioriterar mixvara via RIGAL. Detta gäller dock ENDAST för de mixtyper som har värde "Integer" = 1 i systemalternativ 132. För mixtyper med "Integer" = 0 kommer fortfarande konflikter via RIGAL att avvisas. 

Motsvarande funktionalitet för kampanjpris/medlemspris sätts upp i systemparameter 877.



Chain Classic version 2.2.0.0.02

Dokument status: RELEASED

Datum:  

Förutsättningar för uppdatering

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

Förbättringar 

Modul 

Beskrivning

Wet Stock 

Wet Stock mängder (RTC-24636)

För att göra det lättare att förstå att de mängder som används i Wet Stock-projektet kan vara i både liter eller kilo, visas dessa med enhet "Liter/Kilo".

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.

Teknisk information
Systemparameter 962 aktiverar valet av lägsta nettopris i priskalkylen för både "Beställningsförslag" och "Varumottagning" i programmet "Beställningsfördeling Excel", när nettopris = 0 i kalkylarket.

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.

Teknisk information

Denna funktionalitet kräver att systemparameter 640 = 1

Dessutom måste fälten "Fastpris" och "Vikt", i systemalternativ 1091, ha logisk-flagga aktiverad. Eller bara för det ena värdet av "Fastpris" eller "Vikt" som ska vara lika på alla butiker. 

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.

Teknisk information

Utökad kontroll av nettopris vid "Manuellt varumottagning" och användning av "Beställningsfördelning Excel" aktiveras med systemparameter 962.

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.

Teknisk information

Denna funktionalitet aktiveras med systemparameter 960.

Inställning för inkluderade mixtyper sker per mixtyp via systemalternativ 132 där värdet "Integer" > 0.

Vid avvikelse loggas detta i loggtabell loggtyp 15.

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. 

Teknisk information

Systemparameter 961 aktiverar denna funktionalitet.  

Dessutom är det krav på att systemparameter 684 = 1.

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.


Teknisk information

Teknisk information

Innehållet i det sista fältet (andra butiker med lager som denna butiken kan se) är resultatet av inställningen i Systemalternativ för butik - 2. 

Wet Stock - justering av tankni

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

Teknisk information

Vid utlägg till Reporting "MÅSTE" systemalternativ 800 uppdateras, "Påfyllning" ska ha värde "Integer" = 11.

Startnummer för leveransnummerserie måste sättas i systemparameter 995.

Leveransnummer i systemparameter 995 används första gången manuell justering av tanknivå görs för butiken. Samtidigt skapas automatiskt ny butikspost för nästkommande leveransnummer i systemalternativ för butik 2002. I dessa poster uppdateras så leveransnummer, per butik, med +1 för varje ny post som skapas.

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.

Teknisk information
För att lägga ut L15-värdet till "Reporting" måste systemalternativ 800 sättas med "Integer" = 11 innan ett nytt 11:a-fält i läggs ut för tankstatus.

Uppdatering av tankstruktur till Tokheim

RTC-24058)

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



Chain Classic version 2.2.0.0.01

Dokument status: RELEASED

Datum:  

Förutsättningar för uppdatering

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

Förbättringar 

Modul 

Beskrivning

Rapporter 

Beställningsnummer i rapporten "Självbetjänade varor"  (RTC-23516)

Rapporten "Självbetjänade varor" har utökats med kolumn för "Beställningsnummer" där stöd för alfanumeriska eller numeriska beställningsnummer finns.

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.

Teknisk information

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

VPI-mall måste skapas, en för våg och en för Breece/Pricer. Dessa VPI-mallar sätts därefter upp för att uppdatera de fält som finns i respektive utlägg.

Det är skillnad på Pricer och Breece. Vid användning av båda måste man också kontrollera de fält som avviker så att båda uppdateras i detta fall. Alla andra fält ska vara satt till "Nej".

För att aktivera funktionalitet anges värden i systemparameter 957, som är tvådelad och första värde är VPI-mallnummer för vikt och andra värdet är VPI-mallnummer för el. etikett (Breece/Pricer).     

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.

Teknsisk informasjon

Systemalternativ 125, kod 17: "priceitemlex" - måste sättas till Integer = 52.

Systemalternativ 125, kod 21: "priceitemlex" - måste sättas till Integer = 48.

Detta för utlägg till tredjepartssystemet Lexmark.

Som tillägg har ny post skapats i VPI-mall, post 1007 i standardmall.

RIGAL-dok och systemdok har uppdaterats när det gäller länkobjekt 2.

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.

Teknisk information
Vid borttagning av pris skapas det alltid utlägg till Lexmark itemprice-fil. När det sista priset, enda återstående på varan tas bort, ska också själva varan tas bort från Lexmark. För detta skapas utlägg till Lexmark item-fil.

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.

Teknisk information

Systemparameter 958 = 1

Butik som ska lägga ut ekologisk märkning till viktformat XML, MÅSTE dessutom sättas upp för detta genom att markera "Debio" i butiksregistret.

Borttagning av pris via RIGAL

(RTC-24622)

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

Aktivt varukönr i "Varu- och Prisregister"

(RTC-24541)

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

Återställ saknade varuköposter

(RTC-24400)

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

Skapa lokal kampanj från InStore App

(RTC-18658)

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

Lägg inte ut borttagna varor till POS 

(RTC-23707)

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

Teknisk information
Systemparameter 906 måste vara rätt inställd för "Borttagning av varor" från speciallista 100000002.

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.

Teknisk information
För denna funktionalitet krävs att systemparameter 536 = 0, dvs. "Kupongkod används ej".

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.

Teknisk information

För inläsning av JSON-filer måste dedikerad katalog för dessa filer vara angivna i systemparameter 946.

Inte alla JSON-filer har prefix som anger vilken tabell som ska uppdateras (anges i systemalternativ 216). Tills vidare måste därför detta prefix-värde tas bort: "Värde1" = blank, så att samtliga data från input-katalogen läses in.

  • Om profil som angivits i ny butik saknas, skapas den i Chain Classic.
  • Profil kan inte ändras på existerande butik.
  • RIGALnr och postnr kontrolleras mot tillåtet format i Chain Classic.

Alla punkter här loggas i ny logg lrs\logg\jsonerr.txt.

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.

  • No labels