Ook voor deze moet je denk ik bij Extendis zijn. Zijn sturen immers TWEE berichten om hetzelfde Faktuurnummer toe te voegen. Tsja... de eerste zal dus netjes aangemaakt worden, de tweede leidt dan ongetwijfeld tot jouw melding 'bestaat al' !
Zie regel 2 en 3 in de afbeelding hieronder:
Aanvullend nog even een theorie van mij zelf (jullie hoor ik er niet over), maar weet even dat zodra een Order of een Kostenfaktuur is ingelezen, Profit een SQL Update teruggeeft aan de SQL Server waarbij ze in de betreffende tabel een veld GEEXPORTEERD met 1 vult (vraag me niet waarom dat veld zo heet, want voor Profit betekent die 1 juist dat Profit het geļmporteerd heeft). Hoe dan ook, wij lezen alleen berichten in uit VW_ProfitInlezenOrders en VW_ProfitInlezenKosten zodra deze geexporteerd indikator op 0 staat.
Een situatie als deze zou dus in theorie ook kunnen ontstaan doordat de PC waarop je de berichten inleest, te weinig rechten heeft op je SQL Server. Wij geven die SQL UPDATE opdracht, maar zo te zien wachten we niet het antwoord af. Wij hebben als uitgangspunt dat die PC voldoende rechten heeft. Als ze dat NIET heeft, en SQL de UPDATE opdracht afkeurt bij gebrek aan mutatierechten, dan blijf het bericht in de SQL Database staan, en wordt ze een volgende keer weer opnieuw inlezen!
Merk op dat ik in VW_ProfitInlezenOrdersTest noch in VW_ProfitInlezenKostenTest records heb aangetroffen waarbij die geexporteerd indikator op 1 staat; ofwel, grote kans dat dit kwa rechten niet juist is ingericht!
Nb: Dat neemt overigens niet weg dat het NOOIT zo mag zijn dat Extendis die tabel vult met een tweede record, als er al een in staat met een geexporteerd waarde van 0.
(Ik ben nu van jullie systeem af, jullie mogen er weer bij).
