Chain Classic version 2.2.0.0.17
| Status | ||||
|---|---|---|---|---|
|
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.2.0.0.17 ska POS alltid leverera kvitton i POSLog version 81.
Förbättringar
Modul | Beskrivning |
Beställning | Borttagning av beställning (RTC-48979) Regeln för borttagning av godkänd beställning är att datum måste ha passerat angiven gräns för hur många dagar en beställning ska sparas. När denna gräns har passerats kan en godkänd beställning tas bort manuellt. Beställning som registrerats, men inte godkänts, kan alltid tas bort helt och påverkas inte av denna datumgräns. Borttagning av både beställningsrader och beställningshuvud loggas i logg-tabellen med "loggtyp 29" och kan skrivas ut i Loggutskrift. |
Etikett | Etikett i Lexmark på kampanj som avslutas och ersätts med retur till ordinarie pris (RTC-52084) När kampanjpris eller medlemserbjudande avslutas, sänds information till Lexmark med krav på etikett för gällande ordinarie pris. |
Kampanjgrupp | Saknad kampanj i POS, när ny vara läggs till i butikslokal kampanjgrupp (RTC-49800) Det har gjorts förbättringar som fångar upp det tillfälle när en vara läggs till som kampanjpris eller medlemserbjudande, i en aktiv butikslokal kampanjgrupp. Om denna vara saknar lokalt butikspris så måste det skapas och POS uppdateras med både nytt butikspris med ordinarie pris och nytt kampanj/medlemserbjudande från gällande kampanjgrupp. |
Kundorder | Nettopris i kundorder hämtas alltid från lägsta pris (RTC-50217) I kundorder hämtas varans lägsta gällande pris av ordinarie pris, kampanjpris och medlemserbjudande in när en varurad i kundorder skapas. Detta pris sparas på kundordern och kommer inte att ändras. Om kampanjpris är samma som ordinarie pris, men med lägre inköpspris, ska kampanjpriset alltid hämtas, så att det lägre nettopriset används när varan läggs till i kundordern. |
Pris | Uppdatering av rabattbaserade kampanjpriser baserat på ordinarie pris vid ändring av ordinare pris (RTC-50928) När det görs en ändring av ordinarie pris på en vara med rabattbaserat kampanjpris baserat på ordinarie pris (inkl. när rabattorsak anger användning av ordinarie pris vid användning av LPS30D), måste kampanjpriset räknas om baserat på det nya ordinarie priset. Detta gäller både aktiva och framtida kampanjpriser. |
Rapport | Rapport "Nyckeltal kassör" och urvalsalternativ (RTC-51460) Som i många andra rapporter kan data hämtas in till rapporten "Nyckeltal kassör", baserat på angivet intervall antingen som angivet datum, vecka, månad eller år. |
RIGAL | Uppdatering av två prisändringsposter från RIGAL V-fil (RTC-51261) Om en RIGAL V-fil importeras i Chain Classic och en vara är representerad med två ordinarie prisändringar, på olika datum, kommer det att skapas två olika prisuppdateringsposter för dessa. Om de två posterna har samma datum, kommer den sista posten att skriva över den första och det blir bara en prisuppdatering i detta fall. |
Servicehandel | Försäljning av samma ingrediens i olika receptvaror på samma kvitto (RTC-50006) Vid användning av Servicehandel kommer inte receptvarorna att vara lagerstyrda. |
Flaxlott premieutbetaling
Vid utbetalning av Flaxlottsvinster kommer detta att visas i butiksredovisningen med positivt värde på egen rad för: "Flaxlott vinstutbetalning".
Dessutom kommer detta att ingå som negativt belopp i summa för Nonsale.
Här används samma funktionalitet som för Pantutbetalning.
| Expand | ||
|---|---|---|
| ||
|
Startuppdatering för "Lägsta pris sista 30 dagar"
När funktionalitet för "Lägsta pris sista 30 dagar" aktiveras, kommer det inte att finnas värden för LPS30D bakåt i tid.
Då är det viktigt att alla aktiva och framtida kampanjpriser blir uppdaterade med korrekt LPS30D.
Programmet Uppdatering av LPS30D gör detta.
Detta kan först köras med endast listan för granskning.
Därefter kan programmet startas igen med "Uppdatera" som val.
Förutom uppdatering av angivna poster kommer LPS30D för aktiva kampanjpriser att läggas ut till POS, Breece, Lexmark och Pricer. Till Lexmark läggs också framtida kampanjpriser ut med LPS30D.
| Expand | ||
|---|---|---|
| ||
|
Export av medlemserbjudande till Pricer
Vid utlägg till Pricer kommer inte kampanjpriser högre än ordinarie pris att läggas ut till Pricer. Istället kommer endast gällande ordinarie pris att läggas ut.
- Vid utlägg av kampanjpris (Discount2) eller medlemserbjudande (Member2) kommer gällande erbjudandepris alltid att läggas ut i fält 25 (om lägre än ordinarie pris).
- Ifall en vara har både kampanjpris och medlemserbjudande så kommer bara posten med lägsta erbjudandet att läggas ut, då Pricer bara kan ta emot och visa 1 aktivt erbjudande.
- Om medlemserbjudande är lika med kampanjpris kommer kampanjpris (Discount2) att läggas ut.
| Expand | ||
|---|---|---|
| ||
|
Utlägg av mixmatch-information till Pricer och Breece
Vara i aktiv mixmatch läggs ut till både Pricer och Breece, om vald mixmatchtyp satts upp för detta.
De elektroniska hyllkantsetiketterna kan bara visa ett värde per vara. I de fall varan ingår i olika samtidiga erbjudanden, där mixmatchtyperna ska läggas ut, visas därför bara det första erbjudandet som hittas med uppfyllda villkor.
Information som visas:
- Mixmatchtyp
- Antal
- Belopp
- Medlemsmix
| Expand | ||
|---|---|---|
| ||
|
Annullering av vara
Annullering av vara via RIGAL kan samtidigt innehålla andra VPI-ändringar, som egentligen inte är önskvärda på annullerad vara. Vid uppdatering av återinförande av annullerad vara kan det då skapas oönskade framtida prisändringsposter som ingen har kontroll på. För minsta möjliga avvikelser i denna process finns en valmöjlighet som överstyr varianter på detta, med några enkla och konsekventa regler.
- Vid uppdatering av flera annulleringsposter för samma vara, inskickade samtidigt, behandlas endast 1 post per vara i VPI.
- Uppdatering av annulleringspost, eller återinförande (borttagning av annullering), med eller utan andra ändringar, accepteras.
- Vid uppdatering av annulleringspost, eller återinförande, kommer gällande pris i fil att användas och alla framtida prisändringar tas bort.
- All uppdatering av annulleringsposter eller återinförande, sker alltid direkt på dagens datum, oavsett vilka andra ändringar som finns i posten från RIGAL.
- Vid annullering ändras alltid framtida borttagningspost till datum från dagens datum med tillägg för parameterstyrt antal dagar framåt i tiden.
| Expand | ||
|---|---|---|
| ||
|
Säkerhetsrapport endast för Excel
I fliken "Alternativ" kan Säkerhetsrapporten väljas för visning endast i Excel-format.
Varje butiks kassörer visas på en egen rad med totaler per butik.
| Expand | ||
|---|---|---|
| ||
|
Visa kampanjgrupper i rapport for "Lokala kampanjer"
Rapporten "Lokala kampanjer" visar vanligtvis alla lokala kampanjpriser, oavsett om de skapats i kampanjgrupp eller är skapade som manuell prisändring.
Med valet "Endast utskrift av varor från kampanjgrupper" valt i fliken "Alternativ", kommer endast kampanjpriser från lokala kampanjgrupper att visas i rapporten.
Dessutom kommer denna rapport att visa tre extra kolumner: "Kampanjgrupp information", "Skapad datum" och "Lagersaldo (disponibelt för försäljning)".
Rapporten är gjord för att användas i Excel-formatet.
| Expand | ||
|---|---|---|
| ||
|
Kalkylering av lägsta pris på framtida erbjudanden
När framtida erbjudanden skapas och funktionalitet för lägsta pris används, visas det lägsta kända priset som har använts i förhållande till angivet antal dagar bakåt i tiden.
Om det framtida erbjudandet har startdatum längre fram i tid än antal dagar, kommer LPS30D att sättas till gällande ordinariepris.
Under tiden kan nya re-kalkyleringar ske, som förändrar LPS30D så länge startdatum inte har inträffat, när det sker prisändringar på aktuell vara under tiden.
| Expand | ||
|---|---|---|
| ||
|
Knappar för åtkomst till Internet i webbläsare
De markerade knapparna kan anpassas med sökväg till olika webbsidor i standard webbläsare.
Efter att Microsoft Internet Explorer har gått ut på datum måste därför ny standard webbläsare installeras, till exempel Microsoft Edge.
| Expand | ||
|---|---|---|
| ||
|
VPI rabattorsakskoder från ERP
Rabattorsak 99 är avsedd för att kunna skapa giltiga undantag för erbjudanden som inte ska ingå i beräkning av "Lägsta pris sista 30 dagar".
Vanliga rabattorsaker som används på HK eller av butiker har generellt orsakskoder < 99. ERP kan använda 3-siffriga orsakskoder för att skilja dessa från de "lokala" rabattkoderna.
- I registervårdsprogrammet för "VPI rabattorsaker" går det bara att skapa/ändra/radera rabattorsakskoder < 99.
- Rabattorsakskoder > 99 som ska användas från ERP måste skapas/ändras/raderas i Systemalternativ 1096, antingen manuellt eller uppdatering via filer.
Sätt order till "Mottagen" i varumottagning
De olika sätt som kan användas för att färdigställa en varumottagning är genomgångna, och ordern ska bara kunna sättas till status "Mottagna" när alla beställda varor är behandlade och uppdaterade mot lager.
| Expand | ||
|---|---|---|
|
Uppdatering av Tokheim POS vid deaktivering av kund i Cloud
Det går inte att ta bort kund i Cloud, istället deaktiveras aktuell kund.
I Chain Classic kommer flaggan för "Överförs till kund" slås av och därefter lägga ut en borttagningspost till kassorna.
Efter mottaget borttagningsmeddelande från Chain Classic, kommer kunden att tas bort i Tokheim POS.
Ska kund senare aktiveras från Cloud, sker detta på samma sätt.
Utlägg till kassa kommer återigen att aktiveras i Chain Classic och kundinformation sändas vidare för uppdatering i Tokheim POS.
Information om tillåtet antal decimaler till Tokheim POS
Vid utlägg till Tokheim POS i ART_MUT- formatet ska nu fältet "QUADECS", för max antal decimaler, läggas ut direkt efter fältet "QUAUNIT".
- När QUAUNIT=1 (Stk.vara), läggs QUADECS=0 ut (inga decimaler tillåtna)
- Annars, oavsett värde i QUAUNIT, läggs QUADECS=2 ut (upp till 2 decimaler tillåtna)
| Info |
|---|
Gäller bara för kunder med Tokheim POS! |
...
Chain Classic version 2.2.0.0.16
| Status | ||||
|---|---|---|---|---|
|
Förutsättningar för uppgradering
Med uppgradering till Chain Classic version 2.2.0.0.16 ska POS alltid leverera kvitton i POSLog version 81.
Förbättringar
| Modul | Beskrivning |
|---|---|
| Beställning | Behåll fokus/markör på aktuell varurad vid beställning (RTC-48363) När en beställning skapas, förväntas en genomgång av varuraderna för kontroll av antal beställda varor innan den godkänns. |
| Loggning | Loggning av ogiltig version av POSLog (RTC-45428) Om det skickas in en POSLog med ogiltig version till Chain Classic, kommer detta att visas i loggen för POSLog-import. |
| Rapporter | Logging av in- og avregistrering av priser (RTC-43630) Om det finns behov av att ta reda på vad/vem som har avregistrerat eller återinfört ett pris, finns det en loggrapport för detta. I rapporten "Loggutskrift" väljer man loggtyp "31 Av-/Inregistrering av priser" och önskat datumintervall. Rapporter visar SoftPay-betalningar (RTC-45199) När betalningstypen "SoftPay" används, visas detta i följande rapporter:
Rabattorsak i logg för lägsta pris senaste 30 dagar (RTC-46116) När det lagts in rabattorsak på ett kampanjpris, kan det undantas från beräkning av lägsta pris senaste 30 dagar (LPS30D) för senare kampanjpriser. Rapport för kampanjförsäljning med rabattorsak (RTC-46147) Vid användning av rabattorsak i kampanjpriser kan rapporten "Försäljningstatistik rabattorsak" användas till att visa omsättning per kampanjpris. |
| Varumottagning | Utlägg av okänd vara till ERP efter automatiskt godkännande i varumottagning (RTC-45218) Om automatiskt godkännande används vid varumottagning från InStore App (ISA) via POSLog, exporteras komplett varumottagning till ERP i RIGAL-format. Dessutom måste varan finnas i Chain Classic om lager ska uppdateras. Vid manuell varumottagning kommer en okänd vara att bli kvar obehandlad tills varuinformationen uppdateras i varuregistret. Varan kan då uppdateras mot lager och varumottagningen avslutas. Vid automatisk varumottagning måste den okända varan också behandlas genom att mottagningsposten "nollställs" och läggs ut i RIGAL I-fil med varutext "Okänd vara". |
Automatisk korrigering av LPS30D vid fel utpris från RIGAL
Om det vid ett fel sänds in ett alltför lågt utpris, kan detta få olyckliga konsekvenser när detta används som LPS30D för ett annat kampanjpris på samma vara.
Det är därför möjligt att korrigera detta automatiskt via insändning av korrekt utpris via en ny RIGAL-fil.
Villkoren för detta är att det måste i en ny parameter anges maximal tidsgräns för när korrigeringen måste sändas in och uppdateras.
Dessutom måste det i samma parameter vara angivet en minimum %-vis ökning av utpris.
Om båda dessa villkor uppfyllts, kommer det alltför låga utpriset att märkas som "används ej" i prishistoriken, och kommer inte att användas vid beräkning av lps30d för nya kampanjpriser på samma vara.
| Expand | ||
|---|---|---|
| ||
|
Manuell korrigering av "felskapat" lägsta pris i prishistorik
Vid användning av funktionalitet för lägsta pris, kan det hända att någon skriver fel och startar ett kampanjpris med alltför lågt försäljningspris.
Detta låga kampanjpris blir underlag för beräkning av lägsta pris för andra kampanjpriser på samma vara de påföljande 30 dagarna.
Användare med behörighet kan korrigera ett sådant fel genom att använda programmet Korrigering av prishistorik, som finns under System>Administrativa rutiner>Diverse hjälprutiner.
När en post korrigeras, kommer fälten för rabattorsak att (ändras till 99). Användare som gjorde ändringen och datum/tid fylls i och färgas gula, medan raden i övrigt färgas grå.
Rabattorsak 99 betyder att "Nytt utpris", i denna post, inte används i beräkningen av lägsta pris och kommer därför heller inte att visas i loggen för lägsta pris.
| Expand | ||
|---|---|---|
| ||
|
Kunna se lägsta pris och rabattorsak
Med "Lägsta pris senaste 30 dagar" och tillhörande "Rabattorsaker" påslagna, kommer det att visas egna kolumner för dessa värden.
Aktuella värden visas i varuköposter för kampanjpriser i:
- "Varuregister" i fliken "Pris"
- "Prisregister" i fliken "Prisregister"
I programmet "Butiksrutiner" (endast för butiksanvändare) är det lite annorlunda.
Här visas "Lägsta pris senaste 30 dagar" och tillhörande "Rabattorsak" (nummer och text) för kampanjpriser för både aktiva och senaste avslutade kampanjpriser.
Det har därför lagts till 4 nya kolumner i detta program.
Efter "Kampanjpris" visas:
- "Lägsta pris (K)" för kampanjpris
- "Rabattorsak (K)" för kampanjpris
Efter "Medlemserbjudande" visas:
- "Lägsta pris (M)" för medlemserbjudande
- "Rabattorsak (M)" för medlemserbjudande
| Expand | ||
|---|---|---|
| ||
|
Användning av ursprungligt lägsta pris vid förlängning av profilerbjudande
Om ett profilerbjudande ska förlängas, måste ursprungligt LPS30D (lägsta pris senaste 30 dagar) behållas för att underlaget för det nya erbjudandet är det samma.
Det är parameterstyrt när det nya erbjudandet senast måste starta i förhållande till när det ursprungliga erbjudandet blev avslutat.
Villkor:
- Ursprungligt profilerbjudande kan vara både kampanjpris och medlemserbjudande.
- Nytt, förlängt erbjudande kan vara kampanjpris och/eller medlemserbjudande.
- Nytt erbjudande kan läggas upp på ursprungligt profilerbjudande eller på butikspris på samma profil.
- För nytt erbjudande skapat via RIGAL gäller samma regler som ovan.
| Expand | ||
|---|---|---|
| ||
|
Lägg ut lägsta pris = ? (okänt värde) när detta inte ska användas i POS
Om POS inte ska använda LPS30D som läggs ut från Chain Classic, sätts fältet till ? (okänt värde) i filformaten som används.
Då kommer POS att beräkna rabatter enligt gällande ordinarie pris.
Krypterad e-postlösning i Cloud
Om kryptering av e-post i Cloud ska användas vid sändning av EOD-rapporter och meddelanden via kundorder, kan inte standardlösning via SMTP användas.
Istället skickas meddelanden med bilagor via web service (WS) till POS Services och därifrån till e-postlösningen i Cloud (MDS).
| Expand | ||
|---|---|---|
| ||
|
Skicka redovisningsrapporter i Excel-format som bilaga i e-post
PDF-formatet har alltid använts när redovisningsrapporter sätts upp för att skickas med e-post via EOD-rutinen.
Om EOD-rapporterna skickas via web service (krypterad e-postlösning i Cloud), och "Skicka e-post" valts, är det möjligt att välja mellan tre olika inställningar för format i bilagor:
- Endast PDF (standard)
- Både PDF och Excel
- Endast Excel
När e-post ska skickas från kundorder via webservice måste fälten "Ämne" och "Meddelande" alltid fyllas i.
Det har därför lagts upp parameterstyrda standardtexter för detta. Dessa texter kan anpassas om det finns behov för det.
| Expand | ||
|---|---|---|
| ||
|
Borttagning av lokala butikspriser efter lokala erbjudanden
Vid användning av funktionalitet för borttagning av lokala butikspriser efter avslutat lokalt kampanjpris eller medlemserbjudande, gäller följande:
- Funktionaliteten används för att det är önskvärt att butikerna primärt ska använda profilpris.
- Kampanjpris som skapas för butik, kommer alltid få en borttagningspost i varukön som tar bort det lokala priset efter att kampanjperioden avslutats.
- Borttagningsposten kommer alltid att ligga bakom det längst varaktiga kampanjpriset för butikspriset.
| Expand | ||
|---|---|---|
| ||
|
Förhindra att ogiltiga momsgrupper kan skapas vid RIGAL-uppdatering
Ny momsgrupp skapas om ett nytt värde sänds in.
Det kontrolleras om nytt värde är giltigt och om det finns en ledig momsgrupp inom de 9 giltiga värdena. Det kontrolleras på:
- Momssatser över 99 % ignoreras.
- Det finns bara plats för 9 momsgrupper i registret. Därefter måste ev. manuell registrering användas för att anpassa till önskat behov.
...
Chain Classic version 2.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. |
Förhindra erbjudandepriser på "fastpris"-varor
...
Meddelande ": IP 557 "Denna vara har "Fastpris" och kampanjpris/medlemserbjudande kan därför inte användas", att visas när EAN/PLU kan skrivas i EAN-fältet och lämnar detta eller trycker på sparaknappen.
| Expand | ||
|---|---|---|
| ||
|
Kontroll mot SAP om borttagningspost för vara ska köras eller inte
...
Det kan sättas upp ett jobb som varje natt kontrollerar, mot SAP, om aktiva borttagningsposter i varukön ska behandlas eller inte.
Om SAP har information om att vara fortfarande finns i lager, kommer borttagningsdatumet att flyttas X antal dagar framåt i tid, för ny kontroll senare.
| Expand | ||
|---|---|---|
| ||
|
Priskanal och utlägg till elektroniska etiketter
...
Vid användning av priskanal i kampanjgrupp är det parameterstyrt hur utlägg ska ske till Breece/Pricer.
Utlägg kan göras oavsett val av priskanal (standard) eller bara när det valts priskanal "Alla".
Om vald priskanal är "Alla", görs inga utlägg om priskanal till exempel = "Shop express".
| Expand | ||
|---|---|---|
| ||
|
Administration av kassörer och kund endast i Chain Classic
...
När kund eller kassör skapas/ändras är det normalt att lägga ut detta till POS. Men används 3:e-parts POS-lösning (t.ex. Tokheim POS), kan det vara önskvärt att detta inte sker.
Då går det parameterstyra detta så att onödiga köposter tas bort automatiskt.
| Expand | ||
|---|---|---|
| ||
|
Uppdatering av ny vara från Item Master
...
När varan kommer in i Varumottagning, aktiveras varan med profilpris inkl. aktiv profilkampanj för butiken.
När lager uppdateras, kommer lagerpost med kostpris att skapas och det skapas samtidigt nytt butikspris med kopia av profilkampanjen.
Vid utlägg till POS kommer alltid kostpris att användas som nettopris för alla pristyper.
| Expand | ||
|---|---|---|
| ||
|
Loggning av webservice
Loggning av vad som skickas till POS Services och vad som skickats tillbaka via en webservice är normalt avslagen.
Men det kan slås på vid behov under test av en ny webservice eller vid felsökning.
För närvarande är denna funktionalitet införd i webservice som används i RTC-34179.
| Expand | ||
|---|---|---|
| ||
|
Loggning av borttagning av orderrader och kompletta ordrar
...
När Chain Classic inte är master för lagerstyrning, kommer ERP att sända lageruppdateringar via RIGAL.
Det betyder att det kan dyka upp ändringar i lagerbehållningen som inte visas som registrerade aktiviteter i Chain Classic.
Chain Classic kan bara hålla koll på lagerbehållning mellan uppdateringarna från ERP.
Därför kommer alla ändringar av lagerbehållning att lagras i lagerdag-tabellen med en registrering per ändring.
| Expand | ||
|---|---|---|
| ||
|
Avsluta gamla beställningar/kundordrar
...
Standard antal dagar är parameterstyrt och kan överstyras vid programkörning från menyn.
| Expand | ||
|---|---|---|
| ||
|
Nollställning av kvittonr
...
I Chain Classic sparas de 10 senast inlästa kvittonumren per butik. Om support av någon orsak måste läsa in ett kvitto med ett kvittonummer i denna lista, kommer kvittot att avvisas med meddelande om att kvittonumret redan använts.
Den lagrade nummerserien måste därför raderas. Hjälpprogram för detta finns under "LRS- Korrigera/ändra data".
Med "Nollställing av kvittonr" raderas alla de 10 lagrade kvittonumren för butik(erna). Därefter kan det saknade kvittot läsas in på nytt.
| Expand | ||
|---|---|---|
| ||
|
Underhåll av beställningsrader i elektroniskt varumottagning
...
- Ska det gå att lägga in ny beställningsrad i existerande varumottagning?
- Ska det gå att ta bort en beställningsrad som inte är mottagen?
- Ska det gå att att ändra nettopris?
| Expand | ||
|---|---|---|
| ||
|
Kontrollera inställning av rensningsdagar för "Rensning av statistik"
...
Detta medför att innehållet i prislogg-tabellen växer snabbare om den inte är uppsatt med en förnuftig rensningsfrekvens i det automatiska jobbet för "Rensnings av statistik" som körs varje EOD.
Detta gäller inte bara prislogg-tabellen, det är också viktigt att mängden data i alla statistiktabeller hålls inom förnuftiga mängder, att man bara sparar det man har användning för.
| Expand | ||
|---|---|---|
| ||
|
...
Chain Classic version 2.2.0.0.13
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. |
...
| Expand | ||
|---|---|---|
| ||
|
Loggning av RIGAL X-filer i VPI-logg
...
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". |
Användning av lägsta nettopris i "Beställningsfördelning Excel"
Standard funktionalitet i programmet "Beställningsfördeling Excel" är att nettopris ALLTID uppdateras från kalkylarket om detta har ett värde > 0.
...
Alla butikspriser ska ha samma värde på viktkod och fastpris
Det går att alltid ha samma värde på viktkod och fastpris på profilpris och alla butikspriser på samma profil, också när ändringar sker via RIGAL-uppdatering.
...
Beställningsfördelning Excel och lägsta nettopris från priskalkyl, vid manuell varumottagning
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.
...
Behandling av Coopay reservlösning i finansredovisning
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
Det är standard att avvisa hel mixmatch när det finns en eller flera okända varor. Det går välja de mixmatchtyper, där det ska vara möjligt att bortse från standarden och istället skapa en mixmatch med endast de kvarvarande kända varorna i RIGAL-filen.
...
Alternativ borttagning av mixmatch
Standard för borttagning av varurad i mixmatch, från ERP via RIGAL-utlägg, är att lägga ut komplett mixmatch till Chain Classic med alla varurader, och med aktivt borttagningsmeddelande på varje mix-varurad som ska tas bort. Det finns också ett inställningsalternativ där det blir går att endast lägga ut de varurader som ska vara kvar i mixmatchen, resterande varurader raderas då från aktiv mixmatch. Om utlägget saknar varurader leder det till att hela mixmatchen avslutas/raderas.
...
Inläsning av JSON-fil från StoreMaster
Vid inläsning av JSON-fil från StoreMaster ingår också dessa fält:
...
Wet Stock - justering av tanknivå
"Justering av tanknivå" väljs vid manuell justering av tanknivå i programmet "Leverans". Justerade poster visas i en egen kolumn i programmet. Information om justering av tankstatus läggs ut till "Reporting". Funktionen är bara tillgänglig när ny post skapas. Leveransnummerserien för detta är paramaterstyrd och uppdateras automatiskt vid val av "Justering av tanknivå".
Om användare ångrar val av "Justering av tanknivå" och tar bort notering eller avbryter hela registreringen, så kommer räknaren för leveransnummer att räknas tillbaka igen för att slippa att det skapas "oanvända" hål i nummerserien.
...
Wet Stock och temperaturkompenserat mängd i "Tankstatus"
Temperaturkompenserad mängd "L15" visas i eget fält i program för "Tankstatus".
...
Uppdatering av tankstruktur till Tokheim
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.
...
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. |
...