Forslag: Lægge start- og slut-dato ind i abonnementet - frem for kun i abonnenten

Question

Hej E-conomic

Det kunne være lidt smart, hvis det var sådan, at vi kun behøvede at lægge start- og slut ind i abonnementet - og ikke nødvendig behøvede at skulle rundt til samtlige abonnenter og styre deres datoer decentralt. Selvfølgelig kan man køre datoer ind kollektivt, når man importerer, men det kunne være meget bedre at nye abonnenter (herunder ved import) får datoen fra abonnementet.

Central styring af start- og slut-dato i abonnementet kunne være guld værd. Om det så skal være sådan, at en ændring i start- eller slut-datoen skal slå igennem hos alle de tilknyttede abonnenter (med tilbagevirkende kraft) eller om det kun er sådan, at start- og slut-datoen trækkes ind ved nye abonnenter, som kommer ind i systemet, vil jeg lade op til jer at afgøre :-)

Men en central styring af abonnements-perioden (inde i abonnementet) vil gøre arbejdet meget nemmere :-)

Answer 1

E-conomic - har I tid til at svare på denne? :-)

Answer 2

Jens,

Hvad er det mere præcise brugsscenarie her? At visse typer abonnementer, når der oprettes nye abonnenter på dem, altid starter på præcis samme periode? Dét må da over tid blive mere og mere... 'forældet'. Jeg synes umiddelbart, det er lidt 'imod', hvordan abonnement er tænkt :-)

I øvrigt: Hvis du ved import af abonnenter vil sætte 'faste' start- og slutdatoer på, kan disse allerede opsættes som faste værdier i en import-skabelon.

 

Mvh.

Comments

Hej Christian

Vi bruger jeres API og det er meget relevant at der i abonnementet er angivet start- og slut-dato. Den bliver ikke forældet hos os, fordi vi ændrer blot titlen på abonnementet, når tager hul på en ny periode samt ændrer start- og slut-datoen (hvis altså vi kunne inde i E-conomic).

Jeg ved godt, at jeg kan importere dem ind, men vi arbejder via API som sagt. Vores abonnenter kommer strømmende ovre fra andre systemer, og vi importerer aldrig noget. Det kører live hos os.

Så lige nu skal vi have den globale start- og slutdato liggende i et eksternt system, fordi E-conomic ikke understøtter det.

---

Hej Jens,

Så det vil kun fungere for jer, hvis der samtidig bliver tilføjet logik i API'et, som tillader oprettelse af abonnenter uden angivelse af start- og slutdato - i hvert fald, hvis der på det tilknyttede abonnement er defineret 'default-værdier'?

I så fald lyder det for mig umiddelbart som et scenarie, der er tilstrækkelig specielt til, at det netop bør håndteres internt i integrationen - frem for, at vi tilføjer to ekstra indstillinger på abonnementer, som for langt, langt de fleste brugere af vores abonnementsmodul vil være irrelevante.

- men dét er selvfølgelig en vurderingssag, og vi er da altid åbne for ændringer, som tilstrækkeligt mange kan få glæde af :-)


Mvh.

---

Hej Christian

Hos os går det ud på ikke at skulle definere noget i eksterne systemer, men at kunne holde så meget som muligt centralt styret i E-conomic. Fordi så kan bogholderiet selv styre det - og det skal kun styre det et sted.

Jeg har nu implementeret en workaround, hvor vi bruger Beskrivelses-feltet til at angive perioden (start- og slut-dato). Den kan de i bogholderiet selv opdatere, når de et abonnement "vender bøtten" og tager hul på et nyt år.

Jeg kan se store fordele i at abonnements-perioden sættes lokalt (som den gør nu på den enkelte abonnent) kombineret med at den kan sættes globalt, som vi så gør nu via omtalte workaround (beskrivelses-feltet).

Alle, som ikke har udfyldt start- og slut-datoen, når de importerer nye abonnenter kan få den globale start- og slut.

Har de angivet en start og slut-dato under importen, så skal den globale værdi ikke anvendes. Det må alle de få gavn af i stedet for at skulle importere den samme start- og slut-dato ind igen og igen og igen.

Nu bruger vi som sagt ikke importerings-muligheden, så vi får ikke gavn af det der, men så mange andre af jeres brugere ville gøre det :-)

---

Hej Jens,

Du undlader at svare på mit spørgsmål :-)

Er det ikke korrekt forstået, at i jeres scenarie vil det kun få værdi, hvis API'et ændres, så det tillader blank start- og slutdato ved oprettelse af nye abonnenter - i hvert fald, for så vidt angår abonnementer, hvor der er påført default-startdato og -slutdato?

I givet fald er det jo ikke 'nok' - ifald lige præcis _I_ skal have glæde af det - at vi blot tilføjer felterne på abonnementerne, og så justerer hhv. manuel oprettelse samt import af abonnenter. Dét kunne man så forestille sig, var værdifuldt for andre, som IKKE opretter abonnenterne via API'et - så det kunne jo være en mulighed at holde det ude af API'et i første omgang, og så prioritere dét særskilt. Så får _I_ så som sagt ikke glæde af det (hvis jeg forstår jeres arbejdsgang korrekt) - men dét kunne andre jo.

Uanset hvad, så er vi nødt til at have en del andre på banen med indspark til dette. Vi kan ikke forsvare at have funktionalitet - herunder indstillinger - som kun nogle ganske få har glæde af, og som derved for langt de fleste blot er 'bloat' :-)


Mvh.

---

Hej Christian :-)

Ja, API'en må gerne ændres, så der tillades blanke værdier for start og slut, men vi har løst det på en anden måde.

Vores system gør det, at det aflæser start- og slut-datoen fra Beskrivelses-feltet (som bogholderiet selv kan styre) og indsætter datoerne i abonnenten, når denne oprettes med data fra et eksternt system.

Ergo vi pusher datoerne ind i hvert eneste af abonnenterne fra beskrivelses-feltet for at komme uden om, at felterne ikke kan være blanke. Når vi arbejder via API’en er det jo bare en lille programmeringsting for at få realiseret det, som man gerne vil.

Men det vil da klart være bedre, hvis felterne gerne måtte være blanke, og hvis det nu var, at de var blanke (enten via import eller API), så skulle E-conomic blot trække den globale værdi ind og anvende den.

Men det gør ikke noget for nu (for os), fordi vi skubber blot start og slut datoen ind for hver ny abonnent, som køres ind via API’en. Det er jo ikke noget, som gøres manuelt.

Alt handler om globalt og lokalt værdiangivelse. Hvis objekters værdier er den samme, så er der store fordele i, at de ikke angives igen og igen (når vi taler om at mennesker skal angive det), men blot aflæses globalt.

Så vi er faktisk i mål med min workaround, men det kræver at bogholderiet indsætter start og slutdatoen helt 100% korrekt, fordi det er jo ingen dato-validering, når man bruger et streng-felt. Jeg er godt klar over, at hvis de angiver forkert, så må API-kodning melde fejl ved næste kørsel. Og det er derfor, at det er mere korrekt, at have en globalt sat værdi, som er rigtigt sat datomæssigt inde i E-conomic :-)

Den globalt satte værdi kan jo bare løftes til næste periode, når et abonnement "vender bøtten" og tager hul på næste periode. Ergo den globale værdi må ikke være statisk mht. igangtagelse af næste periode.

Det gør vores jo så ikke, fordi vi bruger jeres beskrivelses-felt. Og derfor har bogholderne også fået en vejledning om, at når de ”vender bøtten” skal de BÅDE  ændre titel på abonnementet SAMT indskrive ny start- og slut-dato (i beskrivelses-feltet), så den afspejler den nye periode.

Det kræver lidt mere programmering for mit vedkommende, da vi jo bruger E-conomic på den måde, men omvendt kommer vi i mål og mine kunder (primært webshops og kursusvirksomheder) er glade :-) Og så er jeg også glad - og jeg bliver endnu gladere, når jeg ikke behøver at gøre brug af workarounds længere :-)

---

Hej igen Christian

Og en globalt sat særpris (defineret inde i abonnementet) vil også være perfekt, så vi ikke skal rundt til måske alle abonnenterne og sætte en lokal særpris der.

---

Hej Christian :-) Hvad tænker du om det, som jeg har skrevet? :-)

---

Jens,

Abonnements-specifikke særpriser kan allerede løses vha. de priser, du opsætter på abonnementets varelinjer.

Særligt fsva. API'et gælder så, at den 'tekniske kontrakt' til oprettelse af abonnenter nu engang er defineret som krævende start- og slutdato udfyldt - så det vil faktisk kræve en ændring af denne, ifald integrationer også skal kunne nyde godt af den. For slet ikke at tale om, at Subscriber-entiteten grundlæggende er defineret med begge datoer obligatoriske, men at dette så specifikt skal være anderledes, når man OPRETTER abonnenter. Her ville vi potentielt kunne blive nødt til at skrue det sådan sammen, at abonnementet har en default-start- og slutdato, men at integrationen selv skal læse disse og anvende dem ved oprettelse af abonnenter.

Bottom line: Jeg tænker stadig, at det er et ret specielt scenarie - og at både automatik og logik, der er specielt for enkelte scenarier, netop hører hjemme i integrationen, frem for i e-conomic.
Når man selv skal bruge en specifik funktionalitet, kan man let falde i fælden med, at "de, der ikke skal bruge det, kan jo bare ignorere det" - men vi vil nødig tilføje alt for mange valgmuligheder, som kun de færreste bruger, men som alle ikke desto mindre skal forholde sig til, når de bruger funktionaliteten  :-)

Mvh.

---

Har I fundet ud af noget? Vi har stadig meget brug for muligheden :-)