Smart inbox - betalingsdato

Question

Vi har modtaget en mail, der oplyser, at Smart Inbox nu kan aflæse betalingsdatoen på fakturaen. Og hvis den ikke kan læse datoen, henter den det fra oplysningerne på leverandøren. Vi har oprettet samtlige leverandører med de aftalte betalingsbetingelser. Det skal altid være oplysningerne på leverandørkortet i systemet, der afgør betalingsdatoen. Såfremt en leverandør ændrer betalingsbetingelserne eller har oprettet os forkert i deres system, bør det ikke kunne glide igennem vores system. Vil det kunne det, sådan som Smart Inbox nu fungerer?

Answer 1

Hej Gitte :)

Du har forstået det helt rigtigt.

Smart Inbox vil scanne dokumentet og bruge de informationer, som den kan finde. Hvis der står andet på leverandøren, så vil det være de oplysninger på fakturaen, som er gældende, hvilket jeg også vil opfatte som den rigtige måde at betragte det på. Det er den dato leverandøren skriver på, som er gældende. Det må her være leverandørens ansvar at oprette deres faktura korrekt.

Hvis du vil bruge de oplysninger, der er på leverandøren, så kan du ikke få det til at overrule det som står på fakturaen. Kun hvis de oplysninger på fakturaen ikke kan aflæses.

Løsningen på dette ville være, at leverandøren gensender fakturaen med den rigtige forfaldsdato.

En anden løsning kunne også være, at rette det manuelt i kassekladden, når de ligger derinde.

Så for at svare kort på dit spørgsmål. Det vil altid være de oplysninger på fakturaen som bestemmer forfald og ikke dem leverandøren.

 

Answer 2

Hej,

 

Jeg har lige været inde i Smart Inbox - jeg kan altså slet ikke få øje på at Inbox foreslår noget som helt vedr. bataling !!

Hilsen Susan

Comments

Hej Ted og mange tak for det uddybende og fyldestgørende svar.

Hvis man bruger dit setup med store skærme, der kan vendes om, så har du helt sikkert ret i, at det virker bedre med de ting du beskriver. Jeg er helt enig i, at tidsbesparelsen gør op for de ekstra omkostninger, der kan være ved anskaffelsen. Selv om jeg er enig i det, så skal vi trods alt tage hensyn til, at ikke alle har det setup, men det er en fair pointe du kommer med.

I forhold til det du skriver her, så er der to ting, som jeg lige vil knytte en kommentar til.

Du skriver du kun kan sende bilag op til 1 MB. Jeg har lige prøvet med et på over 2 MB. Det røg helt fint gennem. Hvis du ikke kan sende bilag ind på over 1 MB, så er der noget vi skal kigge på. Har du eksempler på noget, der fejler nu og her? Så vil jeg meget gerne teste det gennem.

I forhold til betalinger, så er jeg ikke helt med her. Hvis du bruger funktionen til eksport af betalinger, så kan du vælge, hvilken dag de skal betales i banken. Den dato vil også blive brugt på selve betalingen, så det stemmer overens. Du kan endda vente med at bogføre dem, da de ligger sig som kladder efter eksporten. Jeg håber du kan få det maksimale ud af den her funktion. Det lyder allerede som om den sparer dig for meget tid, hvilket er mega fedt, men derfor er det altid fedt, hvis du kan sparer endnu mere tid!

Jeg ser frem til at høre fra dig :)

---

Lige kort, så gælder upload kun her i forum. Ikke ellers.

---

Hej igen,

Du har ret i det kun er 1 MB er på forum.

Vi har i fremtiden planer om at ændre nogle ting her på vores forum. Det her er helt sikkert værd at overveje. 1 MB er nemlig ikke ret meget :)

---

Hej,

Det kunne være dejligt hvis jeg endelig kunne blive hørt, det har jeg faktisk opgivet for længe siden.

Jeg kan stadig ikke forstå hvorfor man ikke kan implementere fordelingsskabelonen i overførsel fra bankafstemning og i snart inbox, man har jo de parametre modulet skal kaldes med. Hvis programmerne er bygget rigtigt op så vil jeg stadig hævde at det er så let som at klø sig selv i nakken. Ydermere når man i daglig kladde har brugt fordelingsskabelon, så kan bankafstemning ikke finde ud af at udligne selv.

Jeg forstår heller ikke hvordan man kan køre videre med et system som smart inbox hvor fortegnet vender forkert på kreditnotaer der kommer fra EAN - man kan da for pokker se at det er en kreditnota og så bør det da være en let sag at vende fortegnet rigtigt i beløbsfeltet i bogføringen. Jeg er principielt modstander af at man kører rundt med kendte fejl i systemet og det bør prioriteres over "nye fede features"

Jeg hylder at vore kunder er mest muligt selv-hjulpne, men det er altså svært at få en bruger til at forstå at først skal du føre over i kladden uden at sætte konto på, derefter gå over i kladden og flytte bankkonto op som primære konto og vende fortegnet og derefter bruge fordelingsskabelon.

Ligeledes hvis man har brugt smart inbox og der har været kreditnotaer, ja så stemmer kreditorkontoudtog ikke med det vi får fra leverandøren fordi kreditnotaer er bogført med forkert fortegn.

Hilsen Susan

---

Hej Susan, 

Jeg er klar over, at langt de fleste forslag herinde ikke bliver til noget i første omgang. Jeg prøver virkelig at forventningsafstemme på den del. Det kan sagtens være at du føler dine forslag ikke bliver hørt, men det er forkert. Jeg læser og vurdere rigtig meget på alle forslag, men alle forslag bliver vurderet individuelt. Det vil altså sige, at dit indlæg nummer to ikke tæller mere fordi du har lavet et før. Alle indlæg bliver alene set i sammenhængen med de andre forslag vi har. 

Nu kan jeg ikke huske alle dine indlæg, men den generelle vurdering er, at forslag enten er meget store, eller der er andre forslag, som skaber mere værdi for flere kunder. Det er den måde vi vurderer det. Det er ikke sikkert du er enig og jeg er altid åben for en snak omkring, hvorfor vi gør det på den måde og evt. en anden måde at gøre det på, hvis du har et bedre forslag. Jeg prøver at forbedre alle processer og arbejdsgange. Om det er i applikationen eller i den måde vi gør tingene på, så er jeg åben for det. 

Når det er sagt, så er de ting du beskriver nye features. Det er ikke fejl, at fordelingsskabelonen ikke er der. 

Kreditnota som EAN kan du argumentere for ligner en fejl. Hvis systemet blandede rundt og tilfældigt byttede rundt på kreditnota og faktura, så havde det havde en fejl. At systemet ikke kan læse en kreditnota vil jeg give dig ret i er en mangel, men det er ikke fejl. 

Derfor vil processen for at imødekomme dit behov være at fokusere på nye features og ikke fejl som du beskriver. 

Dermed ikke sagt, at fejl ikke skal rettes. Selvfølgelig skal de det. Det her er bare ikke en fejl. 

Det er lidt en afstikker i forhold til det oprindelige indlæg. Jeg ville blot lige svare på det. 

Rigtig god weekend