Abonnementsgrupper

Question

Hej,

Vi ville gerne have at det var muligt at tildele et abonnement til en abonnementgruppe.

Endvidere ville vi gerne have det var muligt at vælge kun at køre en bestemt abonnementgruppe, når man laver en abonnementskørsel

Dette er nødvendigt, hvis forskellige abonnementer har forskellig indeksering (så vil man have forskellige grupper og så køre dem en af gangen og justere indekseringen)

Et work around kunne være at man kan ændre abonnementnummeret - så kunne man selv lave sine grupper (f..eks. 1-100 101-200 etc)

 

Lignende forslag, som omhandler det samme: 

18306

Answer 1

Hej og tak for dit forslag :)

I forhold til at kunne inddele i grupper, så vil jeg lade dit forslag stå åbent i et par uger. Det gør jeg for at give andre brugere mulighed for at byde med, hvad de mener. Det er vigtigt for at se på, hvad den brede mængde af brugere ønsker, så vi kan prioriteret rigtigt i et forsøg på at gavne flest mulige.

Jeg er helt enig i dit work around med at kunne inddele sine kundenumre på en måde, så det giver mening. Det kan være den næstbedste løsning, hvis ikke opbakningen er ret stor til forslaget om grupperne. Jeg vender tilbage.

Rigtig god weekend :)

Answer 2

Hej igen :)

Dit forslag har nu fået lov til at ligge i noget tid.

Efterspørgslen efter at kunne inddele i grupper er meget begrænset. Tanken omkring at kunne ændre nummer på abonnementet er noget jeg har hørt om før. Det var dog i forbindelse med, at man dengang ikke kunne spærre sit abonnement, og det skulle derfor bruges til at 'fjerne' de lukkede abonnementer. Det kan nu klares ved at spærre dem og derfor ser jeg ikke de forslag som gældende længere.

For at komme helt til bunds i om vi kan gøre andet med det nuværende setup, så vil jeg høre om du benytter indeksering ved selve ved kørslen? Det lyder nemlig som du gør dette. Det kan godt være du allerede ved dette, men du kan også angive et indeks på den enkelte abonnent. Her vil indekset blive divideret med prisen og herefter give en ny pris. Altså salgspris/indeks = ny salgspris.

Vil du kunne benytte dette?  Spørg endelig, hvis du er i tvivl om noget.

Comments

Hej Jesper

Yes - vi bruger indeksering ved kørsel - og vi angiver også en indeksering på selve abonnenten som du foreslår.

Sagen er dog at vores forskellige kontrakter(abonnementer) har forskellige indeks, da vores services leveres i forskellige lande.

Jeg har derfor brug for at kunne lave en kørsel med et indeks og derefter med et andet.

Eftersom abonnementskørsel ikke har nogen mulighed for at vælge en gruppering, så fungerer det ikke rigtig.

Hvis man som minimum kunne skifte gruppenumre, så kunne vi selv logisk lave nogle grupperinger og så blot køre fra nr. xxx til yyy.

---

Hej igen :)

Helt fair pointe med abonnementsnummeret.

Jeg havde tidligere i dag et møde med vores udviklere, hvor vi kiggede på forskellige numre i e-conomic, som jer brugere havde ønsker at kunne få ændret.

Her blev vi enige om, at abonnementsnummeret var det, der gav bedst mening at kunne ændre og derfor accepterede vores udviklere, at det ville give mening at kigge på dette. Det betyder ikke vi er i gang med at lave det, men forslaget er nu et sted, hvor det skal planlægges og så skal vi ellers i gang. Hvornår det bliver planlagt kan jeg ikke sige noget på nuværende tidspunkt men jeg vil ændre status til 'overvejes' her i første omgang. Jeg skal nok vende tilbage, når der er nyt i sagen :)

---

Fedt - så kommer der forhåbentligt et workaround vi kan bruge (selv om en reel gruppe ville være pænest).

Får vi besked når/hvis det bliver implementeret?

Når vi nu er igang med dette emne: kunne systemet ikke selv foreslå et abonnementsnummer som udgangspunkt (når man opretter et nyt abonnement), da de jo skal være unikke. Det er ret bøvlet at man selv manuelt skal sikre det....og det lever ikke op til hvad kan forvente at et moderne IT system som jeres

---

Vi valgte at gå efter nummer på den baggrund at flere brugere har efterspurgt nummer, hvor du umiddelbart er den eneste, som vil gå efter gruppe. Derfor håber vi at hjælpe flest kunder på denne måde.

Jeg skal nok skrive når vi kommer længere på dette indlæg.

Jeg kan sagtens følge din tankegang her. I først omgang kigger vi at kunne ændre det. Jeg vil gerne tilføje at muligheden for automatisk nummerforslag kan tages med, men jeg kan ikke love noget :)

---

Jeg har tidligere rejst ønsket om at kunne ændre i numre på abonnementer. Se eventuelt indlægget her: https://forum.e-conomic.dk/18306/aendre-abonnementsnummer

Når jeg har efterspurgt muligheden for at ændre i abonnementsnummeret, er det netop fordi abonnementsmodulet bliver et mere og mere vigtigt element i vores forretning. Da vi startede med at oprette abonnementer, var disse med 4 cifre i nummeret, men siden er vi blevet klogere. Forretningen har udviklet sig, og det samme har de produkter, vi sælger på abonnementsløsninger. Det betyder derfor også et løbende behov for justering og kategorisering, hvilket vil kunne løses, når vi kan ændre abonnementsnummeret.

Til eksempel anvender vi idag de sidste to cifre i abonnementsnummeret til at vise, hvorvidt et abonnement faktureres månedsvis, kvartalsvis eller årligt - og det fremgår ellers ikke andet sted, før man har valgt abonnementet når det tilføjes på kunden.

Som det er idag, bliver vi nødt til at oprette nye abonnementer i "den rigtige" struktur for efterfølgende at flytte abonnenterne hertil. Men med eksempelvis 100 abonnenter på et (af flere) abonnementer, er det både risikobetoner og besværligt. Hvad værre er, må vi forvente at senere igen bliver nødvendigt at foretage tilretning - hver gang med større og større mængde abonnenter, der skal flyttes.

---

Hej,

Hvornår kommer der noget nyt i denne sag, da vi står og har brug for denne relativt basale funktionalitet.

Som udgangspunkt burde i altid implementere CRUD (create, read, update, delete) i et professionelt stykke værktøj og det var ikke noget man burde oprette tickets for at få lavet....

---

Enig - glæder mig også til der (forhåbentlig snart) sker noget!

---

Hej begge to,

For at være helt ærlig, så er sagen ikke kommet længere. Den er stadig et sted, hvor det giver mening, at vi udbygger i den retning.

Vores udviklere har og er stadig presset af lidt større projekter og de her mindre forbedringer er derfor ikke blevet produceret i lige så grad. Der er dog kommet lidt, men det har været forslag, som har givet værdi til flere brugere.

Forslaget her ,er sammenlignet med andre forbedringsforslag vi har liggende, ikke et forslag, der skaber værdi for så mange brugere igen. Det giver dog meget værdi for dem det gælder.
Derfor har jeg fastholdt det på listen. Jeg kan se, at der i hvert fald frem til september er planlagt andre af de her mindre forbedringer. Det bliver i hvert ikke før det. Jeg skal dog sige, at det ikke er sikkert vi kommer ind på det til den tid. Der skal vi igen kigge på alle forslag og se, hvad vi skal arbejde med :)

---

Efter at have ventet i et par år, er jeg bestemt også tålmodig og kan vente til oktober.

---

Er der ikke en eller anden måde vi bag om systemet så kan få vores abonnementer opdelt i nogle nummer-serier, så vi kan styre?
Kan I ikke hjælpe os med det, hvis vi giver jer en liste over de gamle numre og de nye vi ønsker?

Jeres abonnementsmodul er næsten ubrugeligt for os, når man ikke kan styre hvilke abonnementer, der køres med hvilke indeks og tekster.

---

Vi kan desværre ikke gøre noget bag om systemet. Jeg kan, som tidligere nævnt, sagtens se udfordringen og derfor er den på listen. Der er dog ikke noget at gøre på nuværende tidspunkt.

---

Hej Jesper

Hvordan går det med at få ændringen implementeret? Der er nu gået godt og vel endnu et kvartal, og det er stadig ikke muligt at ændre på abonnementsnumre?

---

Hej Jesper,
Det er altså lidt besynderligt at noget så simpelt som at ændre et nummer ikke er understøttet.
Ærlig talt, så burde det være standard funktionalitet fra start at kunne oprette,ændre og slette ting.
E-conomic markedsføres som et produkt der er kommer over de mest basale børnesygdomme - men så er det ikke OK at man ikke kan ændre i ting.

Kunne I ikke tage og få lavet det nu ellers må vi finde en leverandør der har den meste basale funktionalitet på plads...som at kunne editere i noget man har oprettet

---

Jeg er enig med dig, MIW. Det virker som om, at man har brugt nummeret på abonnementet som den entydige nøgle i den bagvedliggende tabel, i stedet for at lægge en GUID på.

Ændringen i numre fungerer fint på debitorer, kreditorer og varenumre, så der er ingen fornuftig forklaring på, at det ikke også skulle være muligt på abonnementer.

Vi udvider løbende brugen af abonnementsmodulet, og derfor opstår der ikke overraskende behov for justeringer i måden at kategorisere abonnementer på. Som det er nu, er vi nødt til at oprette nye abonnementer og flytte alle abonnenter, for at få styr på det - det er en kæmpe opgave, med høj risiko for fejl.

---

Hej Jacob og MIW, 

I forhold til at få dette implementeret, så er det en sag, der ligger hos vores teknik. Den er kommet ret langt sammenlignet med andre forslag vi har fået, så det er ikke fordi vi har afvist at kigge på det. Tværtimod.
Hvorfor er det så ikke lavet? 
Det er altid et godt spørgsmål og svaret skal findes i prioritering. Der er ingen tvivl om, at dette giver mening, men hvis i hopper herind, så kan i se, hvad vi ellers har lavet. Det kan være, der er noget som skaber værdi for jer.
Jeg forventer ikke i er enige i, at de her forslag er mere akut eller vigtigere end jeres, men jeg håber i har forståelse for, at vi har rigtige mange andre brugere at tilgodese og det derfor ikke er fordi vi ikke vil give muligheden for at gøre det. Vi er bare ikke kommet dertil endnu.
Vi kan ikke implementere alle forslag fra den ene dag til den anden. Hvis vi havde valgt at bruge alt for fokus på det her forslag, så ville vi selvfølgelig have kunne nået det, men det er bare ikke tilfældet. Det kan lyde lidt hårdt, men det er sådan det hænger sammen. 

Hvis vi skal sætte det hele lidt på en spids, så er det her langt fra det mest efterspurgte forslag, men jeg synes det giver mening at kigge på fordi værdien i det er ret stor. Derfor er det her prioriteret højt sammenlignet med mange andre forslag og det er noget vi har tænkt os at kigge på. Det vil jeg fastholde. 

Jeg håber det kan være med til at belyse hele sagen. 

 

---

Nu har vi så også haft forståelse i et halvt års tid - og længere, hvis du ser på andre indlæg om det samme.

Hvad er tidshorisonten?

---

Jeg forstår der er en prioritering, men dette er så banalt at det må betragtes at være en fejl i jeres software.
Vi har købt jeres system i forventning om basale og banale ting fungerede og derfor må i prioritere det op nu.

Ellers må vi ganske enkelt skifte system med begrundelsen at de helt basale funktioner ikke er på plads

---

Hej igen,

For at være lidt firkantet, så er det ikke en fejl i den forstand. Jeg vil gerne medgive jer, at det er rigtig brugbar forbedring, som vi skal kigge på, men jeg er ikke enig i, at det er en fejl. Systemet fungerer som det er sat op.

I forhold til en tidshorisont, så kan jeg ikke give jer et præcis tidspunkt, men jeg skal nok opdatere jer, når de starter på at dykke helt ned i jeres forslag.

---

Jeg kan egentlig godt lide "firkantet". Jeg læser heller ikke at MIW skriver, at der er tale om en fejl i juridisk forstand - men om at det er så banalt, at det må anses for at være en fejl. Det er jeg enig med ham i.

Men, nu vi er ved firkantet, kan du så ikke prøve at trykke din udviklingsafdeling lidt på maven så vi kan få et firkantet svar på, hvornår vi kan forvente det implementeret? De her bløde udmeldinger har det med blot at sylte løsninger. Jeg tror der er større forståelse og tålmodighed, hvis vi ser en lang, firkantet, tidshorisont, end slet ingen ;)

---

Jeg vil gøre mit bedste! Af erfaring er jeg ikke meget for at komme med udmeldinger på tidshorisonter, da de har det med at ændre sig. Jeg kan godt give dig en horisont ud fra, at alt spiller og ingen problemer opstår, da forslaget her er planlagt til at skulle udvikles. 

Som jeg skrev, så er den her opgave allerede lagt hos vores udviklere, så mit svar vil bygge på, hvilke opgaver de har liggende og hvad estimatet på disse er. Det er så forbeholdt, at alle opgaver løses til tiden og der ikke opstår andre akutte ting. Det kunne blandt andet være en reel fejl 

Men ud fra de opgaver som er liggende til teamet, der skal løse dette, så har de lige nu til opgave at forbedre hele flowet omkring kreditnota, email skabeloner i brødteksten ved afsendelse af tilbud/ordre/faktura og gensend en faktura som EAN (selvom den var sendt på mail i første omgang). 
Det er de opgaver, som vi har givet videre ud fra feedback fra jer brugere.
Ved siden af det har de store projekter, som løber over et eller flere kvartaler, men det er større beslutninger, som ikke burdes påvirkes af disse 'mindre' forbedringer, medmindre de store projekter skaber problemer eller er mere tidskrævende end først antaget. 

Hvis jeg skal komme med et løst bud, og jeg må holde fast i, at det er et løst bud, så håber jeg at disse opgaver er klaret mod udgangen af året og at ændring af abonnementsnummer derfor kan komme i slutningen af året, hvis vi er heldige, ellers så i starten af næste år. 
Når vi løbende kommer gennem disse opgaver, så kan jeg blive mere præcis, men det er bud på en tidshorisont og derfor ikke en garanti. 

---

Hej Jesper

Tak for uddybende svar. Jeg håber at du vil tage den op og få ændret status fra "overvejes" til "planlagt". Hvis det rent faktisk kunne blive starten af næste år, ville vi kunne undgå meget dobbeltarbejde og risikoen for fejl i forbindelse med omlægning af abonnementer.

---

Jeg skal nok prøve at få det presset. Vi har mange abonnementer kører jo per måned, kvartal, årligt mm., så det ville være en klar fordel at få det klaret inde.

Lige så snart jeg kan komme med et mere præcis bud, så skal det nok opdateres til planlagt :)

---

Hej Jacob og MIW,

Vores udviklere har nu planlagt at kigge på dette.

De har oplevet nogle problemer med at skifte nummer. Vi er stadig i gang med at undersøge mulighederne og derfor vil jeg høre om i begge to kan bakke op omkring, at det bliver muligt at oprette grupper på abonnementer som dette indlægge bygger på og ud fra disse lave en kørsel?

---

Det vigtigste for os er at kunne lave forskellige grupper med forskellige indekseringer - og så køre en gruppe ad gangen og skifte indeks for hver kørsel.

Vi vil HELST have at man kan lave gruppe (for os er det bedre end at ændre nummer) - HVIS man så kan vælge at køre abonnementer kun for en gruppe.

Ideen med at skifte numre var et "workaround" fordi man så kunne lave nummer serier, og så blot køre abonnementskørsel for den nummerserie

 

---

Hej og mange tak for at følge op,

Som det ser ud lige nu, er det også den mulighed, der virker mest sandsynligt. 
Jeg vender tilbage når jeg har fået en klar melding fra de andre brugere og vores udviklere 

---

Gruppering er ikke en løsning for os. Vi har ubetinget behov for at kunne skifte nummer, idet nummeret for os er koblet til abonnementstypen og perioden. Gruppering vil ikke hjælpe på overblikket.

---

Hej Jacob,

Tak for at følge op. Det er selvfølgelig helt fair, hvis du ikke kan bruge det og så er det den information jeg giver med videre til vores udviklere. Af ren nysgerrighed, hvordan er jeres nummer koblet til typen og perioden? 

---

Hej Jesper

Abonnementer er struktureret i nummerserier efter typen af vare / tjenesteydelse. Derudover indgår abonnementsperioden som de sidste 2 tal i abonnementsnummeret, så jeg kan se når jeg lægger det på kunden, om det kører i 12 måneders intervaller, 3 måneders intervaller etc. Flere varer faktureres ikke kun på en måde.

I må kunne løse det og tilgodese flest mulige :)

---

Hej igen,

Vi har efterhånden haft gang i sagen omkring abonnementsnummer og grupper i lang tid.

Planen var at ændre abonnementsnummer, da det kunne tilgodese flest mulige. Vores udviklere har kigget på det i et stykke tid og jeg har i dag fået en tilbagemelding omkring, at opgaven er større end antaget dengang vi startede op. Det vil betyde, at vi ikke denne omgang ikke kommer til at give mulighed for at ændre abonnementsnummer.
Jeg er helt med på, at jeg har meldt ud, at vi ville kigge på det, men en gang i mellem, så er det svært at estimere en opgaven før vi rigtig kommer ned i koden.
Det kan virke som en simpel opgave, men der er nogle teknisle grunde, som gør, at det ikke er bare lige at rette. Hvorfor det er så svært er lidt over min forståelse af programmering og kode, men jeg har fået denne besked fra de folk, som ved hvad de snakker om.

Jeg beklager at sagen har trukket ud og vi så i sidste ende ikke kommer til at ændre det, men det var meldingen jeg fik i dag og derfor synes jeg også i fortjener den hurtigst muligt.

Jeg er klar over, at det vil betyde noget kritik fra jeres side og jeg kan sagtens forstå frustrationen, men nu har I fået den melding jeg fik tidligere i dag.

---

Det kan siges ganske kort: Det er ikke godt nok!

Manglende fleksibilitet, daglig tilfældig aflogning og generelt stigende priser gør det efterhånden snart svært at sige noget godt om e-conomic.

Løs det.

---

Jeg er enig i at det bare ikke er godt nok.

Det er dårligt at lave et system hvor dette ikke er muligt fra start - og at I ikke tager konsekvensen og får rettet på det er bare ikke i orden.

Der kan være tre forklaringer på hvorfor dette er svært:

1) Dårligt design af applikationen oprindeligt (mit gæt er I har brugt det ID som vises til også at være unikt ID i databasen, hvilket enhver programmør ved er no-go)
2) At de folk du tror har forstand på dette - reelt ikke har (at du siger de har forstand på software-udvikling gør det jo ikke til et fact)
3) At I bare har ned-prioriteret dette og bruger "det er svært" som undskyldning

Igen af de tre forklaringer er dog acceptable.

Vil I melde retur hvornår dette bliver lavet og/eller hvornår I indfører grupper på abonnementer, da vi eller vil skifte økonomisystem nu.

---

Jeg havde netop tanke på samme scenarier, dog med hovedvægt på at man har brugt abonnementsnummeret som den primære nøgle i databasen. Omvendt bør enhver programmør med blot halvanden colas erfaring vide, at det aldrig må ske.

Men nej, uanset hvilken af de tre årsager, så er det fluks tilbage til udviklerteamet og forklare dem, at det er en bunden opgave!

---

Det var det samme jeg mente (primærnøgle = unikt ID) - mon ikke det er årsagen.

Det er der trods alt metoder til at rette, men hvis det er det er programmører med samme erfaring som dem der lavede det, der nu skal rette det...så kan det selvfølgelig godt blive en uoverskuelig opgave.

Under alle omstændigheder er det en ommer!

---

Hej til jer begge to,

Jeg kan sagtens forstå jeres frustration og det var også mit håb, at vi allerede nu havde fundet en løsning. Omvendt må jeg give den feedback jeg har fået fra vores udviklere.

I går her ind i, hvor svært det er at rette. Jeg vil fastholde, at de folk vi har herinde ved, hvad de snakker om. De kender trods alt den bagvedliggende kode bedre end nogen af os her.
I kan selvfølgelig have en pointe i, at selvom det er svært, så kan det kan lade sig gøre at løse. Det er meget få ting, som er direkte umulige og det er heller ikke tilfældet her.

Valget fra udviklere er taget på baggrund af vurdering omkring, hvor meget de ellers kan nå ved ikke at investere rigtig meget tid i denne sag. Jeg er helt med på, hvor irriterende det kan være, at andre ting får en højere prioritering, men det er nu engang sådan det står til.

Jeg vil ikke permernent afvise, at vi aldrig kommer til at ændre det, men jeg vil også være ærlig omkring, at det ikke ligger i kortene lige nu.
I forhold til gruppering af abonnementer, så har jeg bedt dem om at kigge på, hvor meget arbejde, der vil være i den del og der venter jeg på svar tilbage.

Hilsen Jesper.

---

For os ville det være en kæmpe hjælp, hvis I kunne lave det med grupperne, da det er et stort problem for os at vi ikke kan indeksere forskelligt.

Det er selvfølgelige super irriterende for de andre der ønsker at ændre numre, men med den løsning ville i det mindste hjælpe os - så det er langt bedre end ingenting (for os).

Vil du prøve at tjekke om det kan komme igennem?

---

Ja, jeg venter stadig på svar fra udviklerne, men de er ved at kigge på omfanget af opgaven :)

---

Noget nyt omkring dette - de har jo kikket på det før, så det burde vel være til at estimere?

---

Tror bare vi skal skyde en hvid pind efter flere fejlrettelser.... jeg forstår simpelthen ikke, at det skal være så elendigt designet. Abonnementsmodulet er et tillægsmodul vi betaler for særskilt, og så bør det bare fungere! Det er ikke kun nice-to-have for de af os, der bruger det.

Lav nu den mulighed for at ændre i abonnementsnumre, så vi kan komme videre.

---

Det virker til at abonnements-modulet er et sted-barn, som aldrig rigtig er kommet ud over beta-stadiet og ikke rigtig er noget Economic vil investerer i at udvikle eller fejlrette i (for det må opfattes som en fejl at man ikke kan rette i nummeret, når andet vigtig funktion afhænger af nummeret)

Det virker som om planen er at tage penge for den funktionalitet der findes og så håbe kunderne er afhængige nok af resten af systemet til ikke helt at forlade dem.

Det virker som om at hvis man brug for lidt mere avancerede funktioner eller ønsker fejl bliver rettet, så skal man nok opsige Economic og finde sig et andet system, der tager disse dele alvorligt

---

Jeg er desværre alt for enig. E-conomic ved desværre, at det kræver store ressourcer at flytte til et andet ERP system, og udnytter det. Efter salget til kapitalfond og Visma er fokus på kunderne blevet mindre og prisen højere.

Brug ressourcerne på at løse fejlene, i stedet for at skifte skifte logo.

---

Hej igen, 

Sagen her har efterhånden kørt over et stykke tid og jeg kan sagtens forstå, at det er noget i gerne vil have ændret. 

De hypotetiske bemærkninger omkring, hvorvidt opkøbet fra Visma har indflydelse på om man kan ændre abonnementsnummer i produktet vil jeg ikke kommentere så meget på. Jeg vil dog sige, at Visma som koncern ingen indflydelse har på, hvordan vi arbejder med denne mulighed.

Vi tager de her forbedringer meget seriøst og et eller andet sted, så er det også baggrunden for, at det ikke er muligt at arbejde med ændring af nummer eller grupper endnu.
Vi havde forslaget oppe hos vores udviklere og vi arbejdede på sagen. Omfanget af det viste sig dog at være stort. 
Når et forslag når en vis størrelse, så skal vi vurdere om vi vil bruge mange ressourcer på at udvikle denne mulighed, eller fokusere på fx. at udvikle 3 andre forslag vi har fået. 
Netop fordi vi tager det meget seriøst og vil forsøge at skabe så meget værdi som muligt, så vurderede vi, at vi kunne gavne flere kunder ved at kigge i andre retninger og forsøge at løse andre udfordringer. 

At man ikke kan rette et abonnementsnummer er ikke fejl. Vi kan godt blive enige om, at funktionaliteten kunne være bedre, så det var en mulighed, men det er ikke fejl. 

Som jeg tidligere har ytret, så er det et forslag jeg ser en værdi og derfor vil jeg ikke afvise, at vi aldrig kommer til at lave det, men for nu har vi fokus mod andre muligheder i programmet, som rigtig, rigtig mange andre brugere vil sætte pris. 

God weekend 

---

Hej,

Hvad med grupperne som du havde lovet at I ville kikke på og måske lave.

Det er ikke en stor ting at indføre og lave så man kan køre en bestemt gruppe af abonnementer, når man laver sin kørsel.

---

Vores udviklere har kigget på det. At indføre et interval mere at lave kørsel vil ikke nødvendigvis være den største opgave. Der er dog noget i, at gruppering af abonnementer ikke findes i dag, så der skal bygges nye tabeller med data, hvis jeg forstod dem rigtigt og det er større end bare at indføre et interval at lave kørslen på.

Dermed ikke sagt, at det er umuligt. Det kan sagtens lade sig gøre. Det er bare ikke noget vi har på prioriteringen lige nu og her.

---

Jeg har brug for at forstå om dette er noget i vil prioritere og få lavet da vi ellers skal skifte økonomi-system, da dette er essentielt for os.

Det vil selvfølgelig være ekstremt frustrerende at skulle skifte økonomi-system - primært når det skyldes noget så banalt som at man ikke kan rette et nummer.

Som bruger og kunde opfatter jeg dette som en fejl.

---

Microsoft bruger ofte begrebet "by design". Det er, når noget virker tåbeligt eller uhensigtsmæssigt - eksempelvis når de har lavet en knap der ikke skal bruges til noget, eller ikke fungerer efter hensigten. For brugeren opleves det som en fejl, som Microsoft egentlig bare ikke har tænkt sig at rette.

Denne sag forekommer at have samme karakter; ud fra et bruger- og programmeringsmæssigt perspektiv har vi fået lavet noget pibekrads, men vi har ikke tænkt os at ændre det. Derfor anerkender vi det ikke som en fejl.

Selvom det kan være en strid om ord, synes jeg det er vigtigt at forstå, at det forekommer at være den gængse opfattelse, når MIW skriver, at det opleves som en fejl.

---

Hej igen, 

I forhold til at gøre dette muligt, så kan jeg ikke love jer noget. Jeg ville meget stille jer gode udsigter for at i ikke skal skifte system. Det ville rigtig ærgerligt, hvis det står og falder på lige præcis denne mulighed. 
Omvendt vil jeg hellere gå ud skrive noget, der er forkert. Derfor er status lige nu, at jeg fortsat vil holde et øje på muligheden, men samtidigt kan jeg love jer, at det vil være noget i kan få nytte af. 
Hvis I ønsker at skifte, så skal i selvfølgelig overveje om det er det værd. Hvis det er det værd, så er beslutningen i sidste ende være op til jer. Jeg er ikke interesseret i, at holde på jer, hvis i kan finde en løsning, der passer jer bedre.
Mit håb er, at I vælger vores produkt fordi det er den bedste løsning og ikke fordi I føler bundet ved ikke at kunne skifte. 

 

---

Hej Jesper,

Som jeg har givet udtryk for, så opfatter jeg noget så simpelt som dette som en fejl.

Den eneste grund til at vi ikke har skiftet endnu er du har givet udtryk for at det var igang med at blive ordnet.

Ville sætte pris på I fik det ordnet, så vi ikke skulle forlade jer igen med en rigtig dårlig oplevelse i bagagen

---

Jeg kan kun være enig.

Vi har flere kunder som gør brug af abonnementsmodulet, og som har svært ved at tage stilling til, hvordan de skal nummerere og opbygge abonnementerne. Det prøver vi at hjælpe dem igang med, men de "råber jo ikke op" i et forum som dette.

Jeg er meget sikker på, at der er et ret stort mørketal som også oplever det som en fejl.

---

Hej igen, 

Jeg har kommenteret på det andet indlæg omkring samme sag, men i får den også lige her.

Det er muligt at ændre abonnementsnummer, hvis i går ind under 'ændring af numre' og sætter flueben. Mange tak for kampen. Jeg håber i sætter pris på det nye tiltag.

Rigtig god weekend 

---

Det lyder rigtig positivt. Kunne du lige forklare hvor det flueben findes?

---

Det vil jeg meget gerne, men inden jeg siger det, så må jeg lige trække det lidt endnu. muligheden var lagt ud her til middag/eftermiddag, men efter vi har lagt denne og tre andre forbedringer ud, så er det sket en fejl med betalinger under banken. Derfor ruller vi det tilbage indtil vi har fundet fejlen. 

Det er selvfølgelig rigtig ærgerlig, når jeg endelig troede det var muligt. Det er dog blot en fejl, som skal findes. Ligeså snart vi har fundet og rettet den, så vil du under alle indstillinger -> kategorier og enheder -> ændring af numre, kunne aktivere muligheden. 

Jeg er rigtig ked af, at det ikke virker lige nu, men vi arbejder på sagen. Funktionen til at ændre nummeret er bygget og skal nok komme.