Informizely customer feedback surveys




Se de seneste forbedringer




Medtag leveringsadresse fra ORDRE til leverandørbestilling

0
Når man på en ordre vælger konverter til leverandørbestilling har man mulighed for at vælge Medtag debitorleveringsoplysninger
Medtag debitorleveringsoplysninger.jpg

Herved får man den leveringsadresse kopieret med som står på debitorstamkortet !!

Jeg forstår ikke hvorfor den ikke medtager den leveringsadresse der står på ordren ??  

Når man opretter en ordre (og man på debitorstamkortet har sat en fast leveringsadresse) kommer denne leveringsadresse automatisk med på ordren.
Det giver derfor ingen mening, at man ved konverteringen bruger det der står på stamoplysningerne.
Tager man i stedet den leveringsadresse der står på ordren - får man både muligheden for at få stamoplysningernes leveringsadresse med (den kopieres jo automatisk når ordren oprettes) OG man kan manuelt tilpasse leveringsadressen fra ordre til ordre

De som bruger funktionen - som den fungerer i dag - vil dermed ikke være berørt af ændringen, men man vil gøre systemet meget mere åbent og logisk.

René Arpe It-konsulent
lukket med noten: Er løst i markedspakke
i Forslag » Andet af (17.3k points)
lukket af

3 Svar

Hej René

Det er dejligt at blive udfordret i sin tankegang - og min første indskydelse var også at det virkede totalt ulogisk at den opførte sig sådan - men som så mange gange før viser det sig at vores udviklerteam har tænkt over tingene inden implementeringen...

Dit ønske er relevant nok når vi taler om én ordre til én bestilling - men hvad så når du har tre ordrer med tre forskellige leveringsadresser som bliver samlet til én bestilling?? Hvad er så kriteriet for den valgte leveringsadresse?

Så selvom det i en til en situationen virker lidt irriterende er det simpelthen den eneste leveringsadresse som er fast da den ligger i debitorens stamoplysninger.

Så hvor logisk det end virker i dit eksempel - så er det en velovervejet beslutning der ligger til grund herfor.

Og da jeg nævnte at man kunne lave en if definition i koden som tog højde for om der var en eller flere ordrer i systemet fik jeg kort fortalt at det vil give en meget stor kode for området og øge fejlrisikoen væsentligt.

Så i grove træk ender vi på:

Det er overvejet og bevidst fravalgt som værende for risikofyldt og for svært definerbart i forhold til den effekt det har hos slutbrugeren.

Jeg vil ikke totalt afvise det, da det, som ovenstående også viser, er med i udviklernes overvejelser, men det vil ikke være en ændring der bliver lavet blot for at ændre det, men nok mere som følge af en evt. rekonstruktion af hele strukturen.

Men det blev en lang smøre -   

Som altid - tak for input.

Med venlig hilsen Lasse Bager Online regnskabsprogram   e-conomic support -  Din vej til vores support e-copedia - Opslagsværk om e-conomic e-conomic blog - Hold dig opdateret
Forslag af 🔒 (34.9k points)
Hej Lasse

Tak for svar

Man kan så altid diskutere hvor gennemtænkt det har været af udviklerteamet når alle efterfølgende undrer sig over virkemåden og finder den ulogisk......   

Mit korte svar:
Jeg synes her et logisk valg ville være, at samles flere odrer på en bestilling kan du ikke sætte flueben i medtag leveringsadresse.

Mit lange svar:
Generelt er konceptet for e-conomic jo keep it simpel og at programmet henvender sig til mindre virksomheder.
Jeg synes kæder hopper lidt af når man laver nogle samle-funktioner - som bestemt er smarte og anvendelige - men måske ikke bruges så tit af den almindelige e-conomic kunde...

Jeg synes udgangspunktet skulle være, at vælger man 1 til 1 (den simple udgave) så burde systemet fungere optimalt. Vil man benytte de mere smarte funktioner, så vælges de positivt til og så har det nogle konsekvenser.

Jeg har mange kunder der brokker sig over at de ikke kan få overført odrenr til fakturaen
- igen fordi man kan samle flere odrer på 1 faktura - hvilket ordrenr skal den så vælge....
Man blokerer for en normal ting fordi man har lavet en samlefunktion

Jeg kan godt følge udfordringen når man snakker om at samle flere odrer til en bestilling.
Det samme gælder når man samler flere ordrer på en faktura.
Hvad skal være gældende ?

Jeg synes det er her man må tage et valg og sige - hvis du anvender samlefunktionen - så er konsekvensen det og det.

- Samler du flere odrer på 1 bestilling bliver leveringsadressen den på sidste ordre - eller den fra stamoplysningerne - eller ingen !.... det valg må tages. Så ved de der anvender samlefunktionen konsekvensen.
Alle andre får et normalt/logisk 1-1 forløb = leveringsadressen overføres

- Samler du flere ordrer på 1 faktura overføres ordrenummer ikke
Alle andre får et normalt/logisk 1-1 forløb = ordrenr overføres.

min pointe er:
- den logiske simple udgave skal være den styrende
- de der anvender smart funktionalitet må leve med at nogle sammenhænge mistes af helt logiske årsager

René Arpe It-konsulent
Forslag af (17.3k points)
Hej René

Som altid har jeg den største respekt for både din indsigt og tilgang til tingene.

I dette tilfælde lander vi i kategorien af ting som er en god idé, men af prioriteringsmæssige årsager ikke er nært forestående - som altid i vores udviklingsproces er der ikke et endeligt nej, ligesom vi aldrig svarer 100% ja før det er implementeret.   

Så kort og lang version - det er noteret, men ikke umiddelbart i pipelinen.

Keep up the good work!!   

Med venlig hilsen Lasse Bager Online regnskabsprogram   e-conomic support -  Din vej til vores support e-copedia - Opslagsværk om e-conomic e-conomic blog - Hold dig opdateret
Forslag af 🔒 (34.9k points)