Hej Kim, Christian (og Steffen, ikke at forglemme)
De to ovenstående svar var både hurtige og præcise. Jeg ser det sådan, at I nu har løftet jer betydeligt, sådan rent supportmæssigt. Bliv ved med det, tak. Og for nu at undgå misforståelser: Dette er ros, ikke hverken sarkasme eller ris
Argumenterne om at få mest bang for the buck og at flest muligt skal tilfredsstilles er brugt flere gange, men det gør dem ikke hverken dårligere eller mindre rigtige. Det er jo netop dét hele e-conomics ideen går ud på, sådan som jeg har forstået det. Ret mig hvis jeg tager fejl, men jeg mener at e-conomics er rettet mod mindre virksomheder der skal have deres første administrationssystem, eller mod mindre/mellemstore virksomheder der er groet ud af regnskabet i små billige programmer (eller elendige, begrænsede versioner af store programmer, ingen navne nævnt...).
Det betyder at der (og nu gætter jeg bare) tit og ofte sidder en regnskabsansvarlig som måske ikke ligefrem er en ørn til regnskaber, og som i øvrigt har andet at bruge tiden på hvis der f.eks. er tale om en enmandsvirksomhed. Som følge heraf skal regnskabssystemet være enkelt at gå til, uden overflødige features og stort set til at bruge lige ud af boksen. Omvendt skal det, set fra udbyderens side (altså jeres), også for at holde prisen nede, være minimalt supportkrævende og det skal kunne bruges af flest muligt uden specielle tilpasninger. Alt det kan jeg sagtens forstå og acceptere, det er sådan set lige min måde at tænke på.
Der er bare to ting man skal huske på:
1) Det som var en helt og aldeles overflødig ting sidste år, er ikke nødvendigvis overflødigt næste år. Det er derfor vigtigt at genoptage feature requests med jævne mellemrum for at revurdere overflødigheden/nødvendigheden. Som eksempel kan nævnes debatten om serie/batch numre, en feature der godt nok har været i e-conomics tidligere, men som nu er ude og ikke vil blive genindført. Her vil jeg påstå, at det er en ting man skal overveje meget nøje igen i meget nær fremtid, alene fordi krav til sporbarhed skærpes inden for et stigende antal brancher. Så, Kim, du hører nok fra mig igen om noget tid, lige netop om det punkt
2) De feature requests som kommer fra en enkelt person kan lige så godt være bugs der er fundet, men som ingen har opdaget eller bare har valgt at leve med. Jeg mener eksempelvis helt seriøst, at det at man ikke kan sætte et start-nummer for indkøbsordrer, må være en bug, en simpel forglemmelse. Og netop for den knap så kyndige regnskabsansvarlige er det helt umuligt at tage indkøbsordresystemet i brug, hvis der eksisterer en nummerrække fra tidligere. Det er ganske enkelt drøn-vigtigt, at dette nummer kan sættes til at fortsætte, der hvor de gamle slap. Efter min ringe mening behøver man end ikke at spørge, om der er flere der har samme ønske. Jeg er overbevist om, at hvis muligheden er der, så vil den også blive brugt.
Teknisk set er den af Christian nævnte metode helt konventionel og korrekt. Det kan foregå enten ved brug af systemets indbyggede logik eller ved at et ID felt i databasen (auto-) incrementeres, sådan i store træk. Men i begge tilfælde må det være muligt at fortælle systemet, at man godt vil starte på nummer 4321 i stedet for 1. Og hvis I vurderer at det ikke er noget at afsætte en ressource til, så vil jeg faktisk næsten påtage mig at gøre det for jer. Som Christian er inde på, så er det en meget beskeden programmeringsopgave der skal til, og det er også nogenlunde til at overskue hvad det har af følger for det øvrige system.
Æv, nu brød jeg mit tidligere løfte om ikke at skrive så lange indlæg Men jeg vil så p...... gerne have de sidste knaster høvlet af systemet, sådan at jeg kan vejlede vores regnskabsdame uden at få alle de der spørgsmål om hvorfor kan man ikke... ?.
med venlig hilsen,
Thomas Knudstrup
Lite Flite ApS