...
Forbedringer
| Modul | Beskrivelse | |||||
|---|---|---|---|---|---|---|
| Vare | Servicehandel og relasjon antall/pris (RTC-22910) Ingredienser, resept og pris er sammenskoblet sammenkoblet i "Servicehandel". Som følge av dette vil for eksempel tilsvarende pris oppdateres korrekt også i "Resept" og "Pris" hvis antall endres på noen post poster i "Ingredienser". | |||||
| RIGAL | Oppdatering av pris via tandem i RIGAL-VPI (RTC-22919) Tandemnummer kan benyttes til prisendring, hvis dette sendes inn som hovedvare og skjer via PRI-post i RIGAL V-fil. | |||||
| Rapport | Makulerte bonger i "Butikkoppgjør total" (RTC-22956) POS-bonger med kundeordre kundeordre og varesalg som makuleres i kassen registreres korrekt i Chain Classic og oppdaterer raden "Mak. av bong" i rapporten "Butikkoppgjør total". | |||||
| Kampanjegruppe | Se profilkampanjer som butikkbruker (RTC-23239) Det finnes mulighet å åpne for at butikkbruker også ser profilkampanjegrupper. Dette kan være fornuftig da disse også gjelder egen butikk. For butikkbruker er det da mulig å se, men ikke å endre noe, i profilkampanjegruppen. Det er mulig å kopiere slik at butikken får en egen kopi av profilkampanjegruppen. Denne kan deretter kompletteres og endres hvis butikken ønsker å gi bedre tilbud, innenfor samme periode.
|
...
Feltet "SKU" legges ut blank fra Chain Clasic Classic til totalbutikken i følgende to formater, vare.99900 hvor det er felt 92 som benyttes og tandem.99900 hvor felt 5 benyttes. I Chain Web kan feltet ha inntil 50 tegn, men vil alltid være tomt når det legges ut fra Chain Classic.
...
| Expand | ||
|---|---|---|
| ||
|
...
Rapporten "Aldersfordelt lagerverdi" viser nå også "Fabrikat" for varene i i en ny kolonne.
Ugyldige tegn i sensitive tekstfelt
...
I "Vare", Kunde" og forskjellige registerprogrammer kan de det få konsekvenser hvis det lagres ugyldige tegn i sensitive navnefelt.
Usynlige tegn, som ved "uhell" kommer med i tekst ved for eksempel kopiering, fjernes automatisk ved lagring i GUI brukergrensesnittet eller RIGAL VPI-import. Utover dette kan andre tegn som oppdages underveis legges til i en liste for å unngå fremtidige problemer.
| Expand | ||
|---|---|---|
| ||
|
Nettopriskontroll med profilprisendringer
...
Hvis nettopriskontroll utvides med utpriskontroll i tillegg, vil profilpris bli foreslått som utpris, . Dette gjelder både for butikker som har lokal butikkpris fra før og de som ikke har lokal butikkpris fra før. Ved standard "Nettopriskontroll" vil butikker som har lokal butikkpris få gjeldende butikkpris som forslag på utpris, og de butikker butikkene som ikke har lokal butikkpris blir foreslått gammel profilpris foreslått i utprisfeltet.
| Expand | ||
|---|---|---|
| ||
|
...
Det er anbefalt å løpende slette utdaterte statistikk- og registerposter via EOD. Hvis ikke kan datamengdene datamengden etterhvert risikere og nå maksimal grense og da krasjer databasen.
Da gammel loggdata også bygger seg opp, kan også dette slettes via EOD for registervedlikehold.
| Expand | ||
|---|---|---|
| ||
|
Sletting av vaskeprogram i Tokheim POS
Hver butikk med tredjepartssystemet Tokheim POS og bilvaskanlegg har lagt opp egne poster for hvert vaskeprogram under "Feltverdier for butikk", for tilsvarende vare. Det er denne vaskeprogramsposten som skal slettes hvis butikken ønsker å fjerne et vaskeprogram. Utlegg som fjerner vaskeprogrammet fra kassen sendes deretter til Tokheim POS.
...
Generelt oppdateres merknaden for "Fast pris" via standard felt i VPI. Det er også mulig å sette opp systemet for å alltid sette "Fast pris" likt oppsett for profilpris, når ny butikkpris lages eller ved endring av existerende eksisterende butikkpris, via RIGAL VPI.
| Expand | ||
|---|---|---|
| ||
|
Rapportene "Varekølogg" og "Logg el. hylleforkanter"
Rapportgrunnlag lagres i databasen, uansett om rapportene er i bruk eller ikke. Det har ikke mye å si hvis det er gode rutiner for vedlikehold og sletting av gamle data. Rapportene "Varekølogg" og "Logg el. hylleforkanter" er viktige rapporter for de som bruker disse, men de er av en type som genererer store mengder data. Denne datamengden kan selvfølgelig vedlikeholdes med gode sletterutiner, men det er direkte unødvendig lagre hvis rapportene ikke er i bruk er det unødvendig å lagre så mye data, kun for å så slette den etterpå, hvis rapportene ikke er i bruk. dem etterpå.
Hvis vedlikeholdsrutinene ikke er på plass kan det føre til overfyllt overfylt database og systemproblemer som følge av dette. Det er derfor anbefalt å parameterstyre om logging skal skje for noen av disse rapportene. Hvis man ønsker å kjøre rapportene i en periode er det enkelt at slå på logging og senere slå av denne igjen.
| Expand | ||
|---|---|---|
| ||
|
Slett ikke-aktiv butikk
Når en butikk avsluttes settes kommunikationstype = 1 og "Stengt dato" med avsluttingsdato for butikken i butikkregisteret. Dette fører til at en del register slettes, men butikken vises fortsatt i butikkregisteret. Hvis butikken skal fjernes fra butikkregisteret må support/konsulent kjøre oppryddingsprogram for dette slik at resterende data for statistikk og register fjernes sammen med butikken.
...
Sletting av gammel statistikk og registre
Det er lurt å ha rutine for sletting av gammel statistikk (salgstall) og registre, ellers er det risiko for å fylle opp databasen over tid, noe som kan føre til totalstopp i all oppdatering. Det vil da kreves omfattende sletting av gammel data, en jobb som er helt unødvendig da det er mulig å sette opp løpende sletting hver dag. For eksempel kan grensa for sletting settes på 90 dager, for hver ny dag vil dag 91 slettes slik at det alltid finnes statistikk og registre 90 dager tilbake.
...