Betaling af regninger fejler

Submitted by albib on 7 October, 2011 - 14:15

 

Her på Randers Bibliotek har vi haft det her problem med regninger som  bliver betalt via hjemmesiden, trukket i Dibs men ikke opdateret i DDELibra. Det ligner den her ticket på Lightouse men er mere alvorligt hos os. Det sker ca. 10 - 20 om måneden. Vi har nu løst problemet i hvert fald delvist (der kan være andre årsager som også giver fejl). Problemet skyldes at der er en trimning i DDELibra som heder CAnopay og så sådan ud hos os:

CAnopay <*** ALMARB IA,IG,Ia,MA,Ri,IB,ib

Den fortæller at hvis regningen er i de ovennævnte statuser så kan man ikke betale den via hjemmesiden. Hos så kommer regning i de her statuser sent i forløbet efter at der er udsendt 2 hjemkaldelser og en regning med posten.

Betalingerne bliver gennemført i Dibs uden problemer. Det er først når hjemmesiden prøver at opdatere DDELibra at betalingen fejler. Selve payment requesten til Alma returner ikke noget tilbage det er først når man laver en payment confirmation request som kommer tom tilbage at man kan opdage at der er en fejl.

Grupper:

Kommentarer

ewan7 years ago

Árni, kan du beskrive hvad I

Árni, kan du beskrive hvad I har gjort ved trimmeværdien i Randers som har løst problemet? Hvordan ser jeres trimmeværdi for CAnopay ud nu, og har det haft nogle utilsigtede konsekvenser at ændre den? Jeg er meget interesseret, da vi i Vejle har haft nøjagtig de samme problemer som jer siden vores ding-launch d. 12. august.

albib7 years ago

Ændring i trimmeværdi

Jeg hat slettet den ovennævnte linje:

CAnopay <*** ALMARB IA,IG,Ia,MA,Ri,IB,ib

så at det er default værdien som gælder:

CAnopay <*** dde

Den er tom så der er ikke nogen regninger som ikke kan betales via hjemmesiden. 

ewan7 years ago

Til andre, der følger denne

Til andre, der følger denne tråd: Árni nævner at han har slettet linien CAnopay, således at

CAnopay <*** dde

er den linie der slår igennem. Det betyder også, at hvis man har værdier i ovenstående trimmeværdi, så bruges de i forbindelse med alma, også når de ikke er hensigtsmæssige i forbindelse med ding.

I Vejle havde vi ingen CAnopay for ALMA, mens vores dde værdi er

CAnopay <*** dde Ri

Om det giver problemet for os, mangler vi at undersøge til bunds, men indtil videre sikrer vi os at ALMA og dde har 2 forskellige trimmeværdier for CAnopay - så vi kører nu med flg. trimmeværdier:

CAnopay <*** dde Ri

CAnopay <*** ALMAVE Ri

Så har vi mulighed for at blanke ALMAVE-værdien, hvis vi finder ud af at det er dét, der skal til for at løse vores problem med regninger.