Itgensgr140 Een duplicaat van een eerdere rij werd gevonden als rij #39 op VismaNet.CustomerPayment.CustomerPaymentLines

Bij het inlezen van CustomerPaymentLines krijg ik de foutmelding:

itgensgr140
Een duplicaat van een eerdere rij werd gevonden als rij #39 op VismaNet.CustomerPayment.CustomerPaymentLines.

De query is:

select t.[documentType], ...
from   VismaNet.CustomerPayment.CustomerPaymentLines@vnt t

Hebben jullie reeds een update over dit issue?

Als workaround kan gedurende de analyse van dit omgevingsspecifieke probleem een instelling toegevoegd worden aan de verbindingsspecificatie van de datacontainer:

duplicate-row-mode=keep

De betekenis van duplicate-row-mode is:

Gedrag Dubbele rijen
Configureer het gedrag wanneer meerdere rijen worden ontdekt tijdens een beperkte zoekopdracht op basis van een vingerafdruk gegenereerd uit de primaire sleutelwaarde, of alle kolomwaarden wanneer er geen primaire sleutel bekend is.
De volgende waarden kunnen worden gebruikt: “error” om een foutmelding te geven bij dubbele vingerafdrukwaardes in een API-pagina met rijen, “keep” om dubbele vingerafdrukwaardes stil te negeren, “skip” zoals “keep” maar met logging naar trace om dubbele waardes op te sporen of “null” voor standaardgedrag (meestal “error”).

De datacontainer kan gevonden worden door bij de database de button “Datacontainers” te selecteren.

Merk op dat individuele instellingen in de verbindingsspecificatie gescheiden moeten zijn door een puntkomma (“;”).

Uit analyse van de Visma.net API-berichten is gebleken dat het gaat om een betaling met referentienummer 405812 van bedrag X. Onder deze betaling zitten ter onderbouwen twee regels in het Visma.net API-bericht, elk voor hetzelfde bedrag X (totaal dus 2X). Deze twee regels zijn volledig identiek in alle velden:

[
  {
    "type":"VoidPayment",
    "refNbr":"405812",
    "status":"Closed",
    "hold":false,
    ...

    "paymentLines":[
      {
        "documentType":"Invoice",
        "refNbr":"987654321",
        "amountPaid":1234.7700,
        "cashDiscountTaken":0.0,
        "balanceWriteOff":0.0000,
        "writeOffReasonCode":{
          "id":"BK01",
          "description":"DESC"
        },
        "date":"2023-12-31T00:00:00",
        "dueDate":"2021-07-23T00:00:00",
        "cashDiscountDate":"2023-12-31T00:00:00",
        "balance":0.0,
        "cashDiscountBalance":0.0,
        "description":"FAKTUUR ORDER456",
        "currency":"EUR",
        "postPeriod":"202106",
        "customerOrder":"ORDER456",
        "crossRate":1.0
      },
      {
        "documentType":"Invoice",
        "refNbr":"987654321",
        "amountPaid":-1234.7700,
        "cashDiscountTaken":0.0,
        "balanceWriteOff":0.0000,
        "writeOffReasonCode":{
          "id":"BK01",
          "description":"DESC"
        },
        "date":"2023-12-31T00:00:00",
        "dueDate":"2021-07-23T00:00:00",
        "cashDiscountDate":"2023-12-31T00:00:00",
        "balance":0.0,
        "cashDiscountBalance":0.0,
        "description":"FAKTUUR ORDER456",
        "currency":"EUR",
        "postPeriod":"202106",
        "customerOrder":"ORDER456",
        "crossRate":1.0
      },
      {
        "documentType":"Invoice",
        "refNbr":"987654321",
        "amountPaid":1234.7700,
        "cashDiscountTaken":0.0,
        "balanceWriteOff":0.0000,
        "writeOffReasonCode":{
          "id":"BK01",
          "description":"DESC"
        },
        "date":"2023-12-31T00:00:00",
        "dueDate":"2024-01-01T00:00:00",
        "cashDiscountDate":"2023-12-31T00:00:00",
        "balance":0.0,
        "cashDiscountBalance":0.0,
        "description":"FAKTUUR ORDER456",
        "currency":"EUR",
        "postPeriod":"202312",
        "customerOrder":"ORDER456",
        "crossRate":1.0
      }
    ],
    ...
]

Dit oogt als een bug in het achterliggende Visma.net-platform waarvoor de itgensgr140-controle bedoeld is om te detecteren.

Via een ander kanaal zal contact gezocht worden om de in Visma.net getoonde informatie te matchen tegen de resultaten van de Visma.net API.

Op basis daarvan kan besloten worden of een databasespecifieke workaround de oplossing is, of een workaround voor alle Visma.net-databases.

Bij nadere analyse bleek dat in Visma.net zelf drie regels zichtbaar zijn, maar dat o.a. het veld batchnummer ontbreekt in de kolommenlijst van de API, waardoor in dit geval de inhoud wel anders zou zijn.

Meer essentieel is dat er een unieke sleutel ontbreekt in de Visma.net tabel CustomerPaymentLines op de betalingen, hetzij een ID, een GUID of bijvoorbeeld een volgnummer zoals regelnummer binnen de debiteurenbetaling.

Hierdoor is de reeks geen “verzameling” uit de zogenaamde “verzamelingenleer” waar SQL op gebaseerd is, maar een “bag”. Dit zal problemen veroorzaken bij financiele analyses en integriteitscontroles, en is exact de reden dat deze controle is toegevoegd. Hier kan Invantive helaas geen invloed op uitoefenen; cijfers uit CustomerPaymentLines moeten daarom met een korreltje zout genomen worden qua betrouwbaarheid.

Het probleem is bij Visma gemeld, maar het is onbekend of en wanneer een bugfix zal plaatsvinden.

Voorlopig is voor alle Visma.net-gebruikers de controle op deze tabel uitgezet.

Deze vraag is automatisch gesloten na 2 weken inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.

Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.

Dit topic is 7 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.