Chain Classic version 2.2.0.0.15
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.2.0.0.15 ska POS alltid leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Lager | Lageruppdatering av beställd paketvara (RTC-40732) Paketvaror innehåller ofta mer än en vara. |
Lageröversikt | Lagerloggen visar alla ändringar på lager i "Lageröversikt" (RTC-40438) I programmet "Lageröversikt" kan alla ändringar på lager kontrolleras i vald butik under knappen Lagerlogg. |
Varor | Tandem för varianter på modellvara med samma färg (RTC-40558) Vid användning av endast en huvudvara med kombinationen modell/färg, har bara tandemnummer på huvudvaran synts i fliken för tandem. |
Varumottagning | Utökad loggning vid manuell varumottagning (RTC-37621) Vid en manuell varumottagning som inte kopplas till en redan existerande beställning/varumottagning, kommer det endast att loggas "Manuell" i Transtext-fältet i tillhörande varutransaktionspost. |
Varutransaktioner | Uppdatering av varutransaktioner på receptvaror och butiksvaror i samma POSLog (RTC-43995) Det går uppdatera varutransaktioner på både receptvaror och på vanliga butiksvaror i samma POSLog. Skillnaden är att varutransaktionsposterna uppdateras på butiksvaran, medan det för en receptvara skapas varutransaktioner på råvarorna som ingredienserna i receptvaran skapats ifrån. |
Weborder | Säkerställa unikt jobbnummer när plocklista skapas för en weborder (RTC-41864) När Plocklista ska skrivas för en weborder, behövs ett unikt jobbnummer. Detta hämtas från ett löpnummer i Chain Classic. |
Lägsta pris senaste 30 dagar
(RTC-40443, RTC-41092, RTC-41093, RTC-41714, RTC-42197)
Lägsta pris senaste 30 dagar (LPS30D) är en funktionalitet som skapats för att visa kunderna i butiken vad det lägsta försäljningspriset har varit de senaste 30 dagarna. Detta beräknas av alla pristyper oberoende av hur prisändringarna skapades, av nytt pris, kampanjpris eller ordinarie prisändring. Alla varianter kan ingå i beräkningen av periodens lägsta pris.
Det är också LPS30D som ska användas när ett rabattbaserat kampanjpris beräknas av en angiven kr- eller %-rabatt.
Detta kan innebära att butiker med en lägre LPS30D än vad profilpriset har, kommer att få ett lägre kampanjpris jämfört med de andra butikerna.
Prisändringar som gör att LPS30D ändras till ett lägre värde, kommer att medföra en automatisk omberäkning av framtida, ej aktiva kronor- eller procentbaserade kampanjpriser.
Vid kopiering av kampanjpriser baserat på kronor- eller procentrabatt kommer gällande LPS30D att användas och försäljningspriset blir beräknat från detta.
För avslutade kampanjgrupper visas LPS30D som användes när kampanjen var aktiv.
Utlägg av LPS30D sker endast för kampanjpriser, och då till POS och 3:e-partssystemen Pricer, Breece och Lexmark.
I Chain Classic visas LPS30D för kampanjpriser i alla prisunderhållsprogram.
På en varurad i en profilkampanj kommer knappen "Butikslokala kampanjpriser" (nedan) att visa eventuella butiker som kommer att få ett lägre kampanjpris än profilkampanjen.
Knappen "Ändringar av lägsta pris" (nedan) är en god hjälp för att följa historiken för LPS30D-ändringar över tid. Utpriset i dessa prisloggposter visar vad nästa kampanjpris använder som LPS30D. Lägsta priskolumnen kommer alltid att vara 0 för prislogg-poster för nytt pris eller ordinarie prisändringar.
- För profilanvändrare visas alltid poster med profilpris.
- För butiksanvändare visas profilpris och eventuella prisloggposter för egen butik (se bild nedan).
- För teamanvändare visas profilpris och eventuella prisloggposter för team-butiker.
| Expand | ||
|---|---|---|
| ||
|
När kampanjpriser inte ska använda LPS30D eller ska beräknas på ordinare pris
(RTC-42538, RTC-43245, RTC-43249, RTC-44071, RTC-44075, RTC-44387)
Rabattorsaker kan användas för både manuella kampanjpriser skapade i Prisändring och priser i Kampanjgrupp. Dessa kan användas till att överstyra beräkning av allt för lågt LPS30D.
En kronor- eller procentrabatt baserat på kampanjpris beräknas då från ordinarie pris istället för LPS30D.
Dessutom går det för en given rabattorsak att undanta att ett kampanjpris ska ingå i beräkningen av LPS30D för ett annat kampanjpris. Detta är i överenstämmelse med myndighetskrav.
Programmet "VPI rabattorsaker" har gjorts för att enkelt kunna underhålla dessa val.
Vid utlägg av kampanjpriser till POS och 3:e-partslösningarna är rabattorsakerna alltid ifyllda. För ordinarie priser är fältet alltid 0.
Val av rabattorsaker på kampanjpriser i en kampanjgrupp kan ske på olika sätt:
- Skriv rabattorsaksnummer direkt i fältet för rabattorsak i varubrowsern.
- Genom att dubbelklicka i fältet för rabattorsak kommer dialogen "Välj rabattorsak" att öppnas (se nedan).
- Genom att dubbelklicka på annat fält på varuraden så kommer full priskalkyl att öppnas där rabattorsaken också kan ändras.
| Expand | ||
|---|---|---|
| ||
|
Softpay terminaltyp och korttyper
(RTC-44405, RTC-44745, RTC-44864)
Vid användning av SoftPay betalningsmedel, kommerl finanstransaktioner för alla korttyper som använts, att bli uppdaterade.
Detta förutsätter användning av en dedikerad lösning för näthandel.
Dessa finanstransaktioner:
- Uppdateras per kassa/kassör
- Läggs ut i RIGAL F-fil
- Visas i rapporten "Omsättning per korttyp"
| Expand | ||
|---|---|---|
| ||
|
Öppna kampanjgrupp på vara från Prisregister
Kampanjgrupp kan öppnas direkt från Prisändring för erbjudandepriser som skapats i en kampanjgrupp. Välj varuköposten för kampanjen och knappen "Kampanjgrupp" blir aktiv. Knappen är en genväg till att öppna upp Kampanjgruppsregistret på varuköpostens kampanjgrupp.
Godkännande av priser i "Priskontroll"
I "Priskontroll" kan priser godkännas på olika sätt:
- På knappen "Godkänn märkta poster" kommer bara märkta poster att godkännas.
- På knappen "Godkänn urvalet" kommer som standard de 50 första, ej godkända prisändringarna att behandlas.
När dessa kontrollerats godkänns dessa via knappen "Godkänn urvalet".
Om det fortfarande finns flera poster kvar att godkänna, kommer nästa batch att hämtas in för kontroll och nytt godkännande tills alla poster är behandlade. - Knappen "Komplett godkännande" används om alla prisändringar är kontrollerade och ska godkännas.
Alla aktuella prisändringar inklusive de som ännu inte är inhämtade för kontroll i gällande flik, kommer då att godkännas direkt.
"Mall-butik" i "Beställningskriterier"
Normalt skapas beställningskriterier för vanliga butiker med "Kommunikationstyp" = 11 och "Beställning" påslagen.
Det går också lägga upp beställningskriterier för så kallade "mall-butiker" som bara används till detta ändamål.
Vanliga butiker som använder en mallbutik i "Mall för beställningskriterier", kommer att använda dennas beställningskriterier om det inte finns beställningskriterier på egen butik.
| Expand | ||
|---|---|---|
| ||
|
Visa inte vara som saknar både profilpris och butikspris
Det finns tre alternativ för hur vara utan giltigt pris ska visas i Varu- och Prisregister:
- 0 = Alla användare kan se alla varor även de som inte har ett giltigt pris. Dessa kommer att visas med markeringen "Inget pris".
- 1 = Varor utan giltigt pris är dolt för profilanvändare.
- 2 = Varor utan giltigt pris är dolt för både profil- och butiksanvändare.
| Expand | ||
|---|---|---|
| ||
|
Utlägg av drivmedelsändringar till Reporting
Vid ändringar av gamla värden i programmen för "Fyllning", "Tankstatus" och "Manuell tankstatus", eller vid utlägg av gamla poster via "Data till Reporting", kommer detta att kunna leda till omfattande omräkningsjobb i Reporting.
För att slippa att det sänds för mycket data, bör det därför sättas upp hur många dagar bakåt i tiden det ska vara möjligt att lägga ut till Reporting.
| Expand | ||
|---|---|---|
| ||
|
Skapa underlag för massrensning av varor
Vid massrensning i stora varuregister är det viktigt att göra detta kontrollerat med begränsade urval i flera omgångar.
På generellt underlag rekommenderas det att inte rensa 100-tusentals (eller miljoner) varor på en gång. Detta tar alltid mycket kapacitet och använda lång tid som kan påverka andra uppgifter.
Programmet "Uppdatering av rensningslista" används för att skapa underlaget för programmet "Rensning av varor" i den speciella varulistan (listnr 100000002) som är avsedd för detta ändamål.
Detta underlag kan skapas genom att begränsa på olika urval eller använda varulistor, varugruppslistor eller modellistor.
Vid körning kan det väljas mellan att endast skapa en rapport som visar varor som kan rensas, eller att både skapa rapport och uppdatering av varorna i den speciella varulistan.
När underlaget är på plats, kan "Rensning av varor" göras, manuellt eller automatiskt via EOD,
Då kommer alla varor som ligger i den speciella varulistan att rensas.
Varulistan töms efteråt.
| Expand | ||
|---|---|---|
| ||
|
Behandling av paketvaror i beställning
En paketvara består ofta av flera varor eller antal > 1 av varan som ingår.
Vid beställning går det beställa endast paketvaran.
Både vid beställning och varumottagning är det lager för innehållsvarorna som uppdateras.
Paketvarorna är inte lagerstyrda.
| Expand | ||
|---|---|---|
| ||
|
Överstyrning av fasta dagar för beställningsförslag
Vid användning av beställningsförslag går det att parameterstyra genereringen av beställningsförslag till en fast veckodag per butik.
Detta kan överstyras manuellt i programmet så att alla butiker, oavsett veckodag, ska behandlas samtidigt.
Det går även lägga upp ett EOD-jobb för detta om det finns behov av att generera beställningsförslag för butiker en fast gång per vecka.
| Expand | ||
|---|---|---|
| ||
|
Utlägg av RIGAL-VPI till butik
I "Verkställ vara" kommer det vid val av endast "RIGAL VPI", att läggas ut RIGAL V-fil och D-fil till vald butik.
Innehåll i V-fil kommer att vara alla varor inom urvalet, med lokala butikspriser där dessa existerar, medan det för övriga varor används profilpris.
D-fil kommer att innehålla alla varor med tillgänglig profil "varuinformation". Där det finns butiksspecifik varuinformation används denna.
Om valet "Endast butikspriser" läggs till, kommer samma filformat som ovan att skapas, men bara innehålla varor med lokalt butikspris för vald butik.
Detta innebär att inga varor med endast profilpriser exporteras.
Butiksspecifik varuinformation på varor med endast profilpris kommer heller inte att läggas ut.
Detta kommer bara att ske vid generellt RIGAL VPI-utlägg på hela profilen.
...
Chain Classic version 2.2.0.0.14
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.2.0.0.14 ska POS alltid leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Elektroniska etiketter | Utlägg till elektroniska etiketter vid förlängning av erbjudanden (RTC-39381) Vid förlängning av ett erbjudande (kampanjpriser eller medlemserbjudanden), nytt slutdatum på aktivt erbjudande, ska det alltid läggas ut uppdaterade poster med erbjudanden till Lexmark. Elektroniska etikettlösningar däremot behöver inte denna uppdatering då dessa får egna utlägg när erbjudanden avslutas. |
Kampanjgrupp | Kopiering av kampanjgrupp för "Team" (RTC-39969) När en team-kampanjgrupp kopieras, går det kopiera denna till en kampanjgrupp för butik eller profil. |
RIGAL | Framtida prisändring och utgången vara (RTC-39744) Om en vara utgår via RIGAL, sätts sortimentskod till "Utgången" och beställningsnummer nollställs på pris. Det skapas också en borttagningspost med parameterstyrt rensningsdatum X dagar framåt i tid. Om det efter detta kommer nya eller framtida prisändringar för samma vara, kommer datum för borttagningspost att flyttas fram i tid i förhållande till det nya prisändringsdatumet, medan sortimentskod "Utgången" och nollställt beställningsnummer behålls. |
Tankstatus | Registrering av flera tankstatusposter på samma dag (RTC-39257) Det går registrera flera tankstatusar på dagens datum, så länge de registrerade mätningarna har en unik tidpunkt. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.2.0.0.13 ska POS alltid leverera kvitton i POSLog version 81.
Förbättringar
| Modul | Beskrivning |
|---|---|
Elektronisk varumottagning | Varusökning i elektronisk varumottagning (RTC-38982) Om det upplevs problem med standard varusökning i order i elektronisk varumottagning, prova då följande rutin: 1. Sortera först beställningsrader på EAN/PLU, (tryck på kolumnrubrik), så att lägsta nummer är överst. 2. Öppna standard sökprogram "Sök vara", antingen genom att trycka på "Kikaren" eller bara skriva EAN/PLU-nummer direkt.
1. Hittat EAN/PLU hämtas in på första orderrad, med efterföljande EAN/PLU nedanför. 2. För att ta bort filter som döljer ovan liggande orderrader:
|
EOD-rapport | Meddelande när E-post felar i EOD-Rapport (RTC-36556) Om meddelande inte kan levereras när EOD-rapport (som också ska skickas som E-post) skapas (nätverksproblem eller annat problem), så kommer detta att loggas direkt i Status- fältet i Rapportlistan.
|
RIGAL | Varutyp till RIGAL och loggning av uppdatering från RIGAL VPI (RTC-36476) Chain Classic lägger alltid ut "Varutyp" i RIGAL V-fil. |
Varor | Ta bort "Stoppa försäljning av vara" i POS (RTC-38072) I Chain Classic kan en vara som har blivit spärrad, senare öppnas för försäljning på kassorna igen. Detta sker antingen genom att använda knappen "Aktivera vara" i " Varuregister eller genom att välja "Aktivera vara" vid utlägg av varan från "Verkställ vara". |
Varu-/kundgruppsrabatt | Användning av varulistor i "Varu-/kundgruppsrabatt" (RTC-34434) Vid uppläggning och underhåll av varurabattposter i "Varu-/kundgruppsrabatt" kan varulistor med varulistnummer upp till 8 siffror användas. |
Varutransaktioner | Kvittonummer och kundordernr/radnr i "Varutransaktioner" (RTC-36528) För ökad spårbarhet och enklare uppföljning uppdateras "Kvittonummer" alltid när "Varutransaktioner" uppdateras från POSLog, och kundordernr/rad uppdateras också när detta är tillgängligt. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.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. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
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". |
Lager | Uppdatering av lager efter retur av samma vara på flera varurader i samma kvitto (RTC-34933) Om samma vara ska returneras flera gånger, matas vanligtvis antal in på befintlig varurad. Lagret uppdateras då med totalt antal. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.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)
|
Lager | Se lager i andra butiker (RTC-32343) Med funktionsknappen "Lagerinformation" i Varu- och Prisregister visas lagersaldo för butiksanvändaren om butiken har lagerpost på varan. Utan lagerpost på varan är knappen deaktiverad. Med åtkomst till andra butikers lagersaldon kan butiksanvändaren se lagersaldon i dessa butiker förutom egen lagerstatus. Om egen butik inte har lagerpost på en vara, kan butiksanvändaren ändå se lagersaldon i de andra butikerna. |
Utlägg till POS | Korrekt användning av av punkt som decimaltecken vid export av mixmatch till POS (RTC-32523) När en lokal butiksmixmatch eller kampanjgrupp skapas i Chain Classic efter att ha importerat en RIGAL X/J-fil och nyskapade butikspriser som saknas, används punkter alltid som decimaltecken i kassautlägg till POS. |
VPI-Sync | VPI-Sync och flera obehandlade ordinarie prisändringar i varukö (RTC-31186) Det händer att Chain Classic och POS "inte är eniga" om vad som gäller ordinarie pris. För att VPI-Sync inte ska visa onödiga avvikelser, kommer senast "godkända" pris i Chain Classic skickas till POS och användas för sammankoppling för motsvarande pris där. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.2.0.0.09 ska alltid POS leverera kvitton i POSLog version 81.
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
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. |
Rapporter | "Fråga på pris" i rapport (RTC-31806) I många omsättningsrapporter för kassörer går det se antal förfrågningar på pris som gjorts i kassan. Det är totalt fyra varianter av detta som kan medföra att räknaren ökar: 1. Kvitto med bara fråga på pris 2. Annat makulerat kvitto med fråga på pris (t. ex. parkerat kvitto) 3. Offert med fråga på pris 4. Vanlig varuförsäljning med fråga på pris |
Varuregister | Lagerinformation i varu- och prisregister (RTC-30139) Genom att använda knappen "Lagerinformation" i "Varu- och Prisregister" visas lager på varan som är i fokus i en söklista för alla butiker som användaren har tillgång till och som har lagerpost.
|
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
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. |
RIGAL | DUN-nummer i RIGAL VPI (RTC-30127) Uppdatering och ändring av DUN-nummer kan kommuniceras via, fält 7.1.56, i RIGAL V-fil. |
Inventering | Utlägg till 3:e-part av inventerade varor med resultat = 0 (RTC-30681) Vid utlägg av svinnposter til 3:e-part efter inventering kan det finnas tillfällen då inventerade varor med 0 som resultat också ska läggas ut. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
Datum:
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.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. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
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. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
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. |
...
Dokument status:
| Status | ||||
|---|---|---|---|---|
|
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". |
...
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". |
...
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. |
...