Foutmelding opgelost die kon optreden als je een webhook wilde annuleren, maar tijdens het autoriseren daarvoor de webhook alsnog werd afgerond waardoor het annuleren dus eigenlijk niet meer nodig was.

De autorisatiedialoog zal nu automatisch sluiten als de webhook op de achtergrond alsnog afgerond is.

De sender payload in webhook requests bevat nu de waarde hasReceiptPrinter die aangeeft of de werkplek een kassabonprinter geconfigureerd heeft.

De sender payload in webhook requests bevat nu de waarde hasReceiptPrinter die aangeeft of de werkplek een kassabonprinter geconfigureerd heeft.

Lost probleem op dat een webhook lineChange met een applyToQuantity de korting toch op alles toepaste ipv op het gespecificeerde aantal.

Lost probleem op dat een webhook lineChange met een applyToQuantity de korting toch op alles toepaste ipv op het gespecificeerde aantal.

Het session object bevat nu ook (indien van toepassing) een lijst van de betalingen die gedaan zijn op de sessie, inclusief evt. aanbetalingen.

Als er geen berichten meer in de webhook popup staan, wordt deze ook niet meer evt. met vertraging gesloten.

Als het webhook logboek uitgeschakeld is, klopte de waarde van event.eventTimestamp niet meer. Die werd dan gereset naar 1899. Dat probleem is nu opgelost.

Bij het verwerken van een webhook response wordt de kassastatus niet meer vergrendeld als er toch geen wijzigingen aangevraagd zijn.

De webhook completeSession wordt nu niet meer aangeroepen op deels betaalde kassabonnen, dit veroorzaakte namelijk een herhaling van de completeSession als de bon volledig betaald werd.

In het geval van een (tafel)bestelling werd er bij de lineChanges alleen gekeken naar reeds opgeslagen regels, nu wordt er ook naar net nieuw toegevoegde regels gekeken.

When performing an ExternalPayment (a payment through webhooks), we now also store the employee that performed the payment.

The given receiptTexts with the externalPayment request will be printed on the receipt printer of the used workplace. If a receiptTexts is provided and the workplace has not printers configuration you will be notified trough an error.

Webhooks: Je kunt nu via openUrl.minimumWidth en openUrl.minimumHeight bepalen hoe groot de browser popup in de Q-line minimaal moet zijn. Het standaardformaat is momenteel 800x500.

https://developers.mpluskassa.nl/webhooks/json-definitions/#openUrl

Webhooks: Er zijn een aantal nieuwe properties die je kan teruggeven in een externalPayment response, zoals externalTransactionReference en receiptTexts. Bekijk de documentatie voor een actueel overzicht: https://developers.mpluskassa.nl/webhooks/json-definitions/#externalPayment

Webhooks: Potentiële "Er is al een Qlib::QKassastatus weggegeven via GetVerkoopBase()" opgelost die kon optreden als je een bestelbon maakte.

Webhooks crash opgelost als je clearCustomerScreen=true meegaf.

Webhooks: sender.versionNumber bevat weer het juiste versienummer ipv. de waarde true.

Webhooks: De externalPayment-flow werkt weer goed. De webhook pollingExternalPayment wordt weer aangeroepen.

Webhooks: A new selectRelation webhook was added, which is fired when a relation is selected or deselected.

Webhooks: De performance van het webhooks logboek overzicht is verbeterd.

Webhooks: alle situaties waarin je message of customerMessage kan retourneren kun je nu ook alle overige message-gerelateerde properties gebruiken, zoals hideTimestamp.

De dialog popup die je kunt laten tonen vanuit een webhook-response heeft een design refresh gekregen, waardoor deze beter om kan gaan met verschillende inhoud en in lijn is met de nieuw design stijl. Ook overige popups die gebruik maken van hetzelfde dialoogscherm hebben dezelfde refresh gekregen, zoals prijsgroepkeuze en persoonsartikel.

Webhooks: Ook RFID/NFC scans worden nu afgevangen terwijl een webhook loopt. Voorheen kon je blijven scannen terwijl een webhook liep. Barcodescans werden al afgevangen.

Webhooks: Elke response kan nu weer customerMessage verwerken om een tekst op het klantendisplay te tonen. Enige uitzondering is het backgroundPoll event.

Extra instelling bij Webhooks: Annuleringsknop moet webhook geforceerd afsluiten

Normaal gesproken doet de annuleringsknop nog een stukje onderhandeling met het lopende webhookproces. Die onderhandeling levert echter in bepaalde, nog niet goed in kaart gebrachte, omstandigheden problemen op, waardoor de kassa vervolgens volledig blijft hangen in een tussen-staat.

Als je deze instelling nu inschakelt, dan wordt deze onderhandeling overgeslagen en wordt de lopende webhook altijd per direct afgesloten. Let wel op, als je dit gebruikt kun je het activeren van de annuleringsknop niet meer vertragen en wordt de webhook-popup ook altijd direct getoond.

Webhook bugfix: Dialoogkeuze (dialog.selectedDialogOptionIds) werkt weer. Je blijft daardoor niet in een oneindige dialoogkeuze hangen.

Je kunt een customAction knop nu instellen voor een specifieke "Webhook Application", zodat alleen de endpoint van deze Application wordt aangeroepen bij het drukken op de knop. Als je geen keuze maakt, zal de customAction nog steeds naar alle endpoints verstuurd worden, zoals ook nu al het geval is.

Daarnaast is de optie "Aanroepen bij opstarten" nu ook een dropdown (met Nee/Ja) ipv. een invoerveld waar je handmatig "Nee" en "Ja" in moet vullen.

Webhooks: Er wordt niet meer standaard een cURL log geschreven. Dit is nu in te schakelen onder Instellingen > Webhooks > Communicatie > Uitgebreid cURL logboek schrijven als dit nodig is voor ontwikkeling of probleemoplossing.

Bij "polling" webhooks kon het voorkomen dat er na enige tijd een StackOverflowException optrad. Deze is nu verholpen. Voornamelijk de backgroundPoll webhook had hier last van, omdat deze heel lang "polled".

Het backgroundPoll webhook-event werkt weer! Dit event werkte niet sinds v28 en leverde de volgende foutmelding op "Cannot call Start on a running or suspended thread".

Webhooks: Indien er een codefout (een Exception) voorkomt tijdens het uitvoeren van een webhook blijft de kassa nu niet meer hangen, maar kan er gewoon verder gewerkt worden.

Uiteraard is het wel mogelijk dat vanwege de codefout de webhook-response niet verwerkt is, er wordt daarom ook een kleine pop-up getoond en logregel weggeschreven met informatie over de codefout zodat deze vervolgens ook opgelost kan worden.

Probleem opgelost wanneer er op een tafel via de startSession webhook direct een nieuwe regel aan de bestelling toegevoegd werd. Dit veroorzaakte een !m_IsOpgeslagen foutmelding in de kassa die je wel kon doorklikken, maar die uiteraard niet de bedoeling was.

In the case of non-blocking webhooks, the session will now always be fully transmitted.

Webhooks: Bepaalde configuratie-items zoals de Endpoint URL worden nu ge-trim'd alvorens ze worden opgeslagen. Dit voorkomt vervelende storingen vanwege per ongeluk ingevoerde overbodige spaties.

Webhooks: Het is nu mogelijk om via { "version": "..." } een extern versienummer te retourneren dat wordt opgeslagen in het communicatielogboek. Dit kan helpen bij het controleren van versies en opsporen van problemen.

Webhooks: It is now possible to return a backgroundColor in any response that can also return a message. This can be used to emphasize an error or success message. To use the preset colors, red and green are available. It is also possible to return a hexadecimal color code. The background color can be returned to default by returning a response without a backgroundColor.

In the scenario that you are in the payment screen and doing multiple changes on the session through webhooks, and it a (table) order, you will no longer be confronted with an error message about !m_IsOpgeslagen.

Webhooks: Resolved an issue where it was impossible to cancel a running webhook in some cases, because every update caused the authorization popup to close immediately.

Webhooks: Added session.openAmount, session.paidAmount and session.prepaidAmount.

Webhooks: Resolved an issue where receiptFooters with printSeparate:false were no longer printed.

Webhooks: Het is nu mogelijk om via een instelling een polling-webhook stilletjes te laten re-pollen als er een time-out is opgetreden. Dit heeft niet de voorkeur, omdat we liever zien dat derde partijen periodiek (binnen het ingestelde timeout-window) zelf een status-update geven.

Webhooks: Een lege response wordt nu pas geïnterpreteerd als een time-out als de ingestelde time-out ook daadwerkelijk bereikt is.

Webhooks: Je kunt nu via displayBarcode een QR-code op het klantendisplay tonen. Daarnaast kun je de QR-code ook verbergen via hideBarcode.

Webhooks: When dealing with a required requestScanCode, it is now possible to cancel the whole webhook. Previously it was possible to keep the POS in an unending loop, because it kept asking for a code to be scanned.

Also the POS won't lock anymore when cancelling a non-required requestScanCode.

It is now possible to configure for every webhook event if cancelling the webhook requires authorization. This can also be used as an additional security measure to prevent a webhook from being cancelled prematurely.

Webhooks: Added the properties session.lines[].priceExcl, session.lines[].totalExclAmount and session.totalExclAmount.

Webhooks: The receiptFooter now has a max. length of 10,000 characters (previously 1000).

Webhooks: Solved an issue where the Webhook-popup would appear later than configured.

Webhooks: Solved a bug that would occur when trying to delete a text line while the removeSessionLine webhook was activated.

Webhooks: It is now possible to combine dialog and customerMessage in one response.

If a webhook indicates that a customerMessage should be displayed for a certain time, the message will remain in view for as long as indicated. Even when the POS wants to show a different text on the customer display. The only exceptions to this are when the POS is switching to open or closed mode, or when the POS wants to erase the text on the customer display.

Webhooks: It is now possible to request the running of a customAction from a backgroundPoll response. You can do this through requestCustomAction.

Webhooks: When calling a customAction, an already completed session is first cleared before calling the webhook.

Webhooks: It is now possible to clear the customer display of any messages with the clearCustomerScreen property. Messages on the customer display now also have a finite amount that they will be shown. This time defaults to five seconds and can be adjusted through the settings or by adding the property customerMessageDisplayTime to the webhook response that also contains the desired customerMessage.

Webhooks: A few improvements in the external payment flow (externalPayment). It is now also possible to confirm a payment directly from a startExternalPayment. When this is used, the payment process will never enter the pollExternalPayment phase.

Webhooks: Small tweaks in the communication log report, which makes it easier to see things like whether a request was cancelled, or timed out. Also the response time is displayed correctly again.

Webhooks: The communication log is written at an earlier stage, and ammended later. That is to say, the log is written as soon as the request is sent, and not after a potential response is received. This gives more insight into webhook requests that were sent, but were not received or replied to (in a timely manner) by the endpoint.

Webhooks: Four new webhooks have been added, namely startPOS, openPOS, closePOS and exitPOS. Respectively, these are called when starting the POS, opening the POS, closing the POS and exiting the POS. Usually, startPOS and openPOS are called together and in that order and the same goes for closePOS and exitPOS. When using the "POS closed mode", it is possible to call closePOS and openPOS while the POS keeps running, using the "POS closed" button in the POS menu.

Webhooks: customAction buttons are now authorizable per button. You have to use the button at least once to make it appear in the authorization list under Back-office > POS > Webhook customAction.

Webhooks: It is now configurable whether or not the text "(not blocked)" should be displayed when dealing with a non-blocked externalCardScan.

The Webhook icon in the top bar has been removed for now. The animation here could cause strange hangups on slow (?) systems.

Webhooks: The properties messageDisplayTime and customerMessageDisplayTime now also work with the scanCode response.

Webhooks: Solved an issue with the combination of removeSessionLine and lineDeletions.

Webhooks: It is now possible to send a customerMessage of two lines to the customer display. The second text line can be separated from the first by a newline-character: \n

Webhooks: It is now possible to respond with a prepayTable property. This can be used to do a prepayment on a table order.

Webhooks: It is now possible to respond with an externalCardScan property. This can "simulate" an actual card scan from the POS, with a specific balance and other card details. The card details will be displayed on the POS screen and the customer display, as part of the totals underneath the virtual screen receipt.

Webhooks: In case of a manual cancellation of an externalPayment flow, there will be no separate notification of this fact to the webhook endpoint. This is because as part of the externalPayment flow, there will always be a requestCancelExternalPayment that follows the manual cancellation, which basically carries the same message for the endpoint (namely that the payment should be cancelled).

It is now possible to lock the session solely for additions (you can still reduce amounts on the session). To trigger this behaviour, respond with the property lockSessionForAdditions in the JSON reply.

Webhooks: It is now possible, in a reply where you return a message or customerMessage, to use the property displayTime, messageDisplayTime or customerMessageDisplayTime to set a minimum amount of seconds that you want the message to stay on screen. This can be useful when the POS has been configured to remove the webhook popup as soon as possible, but you still want to display an important message to the user. This setting delays the hiding process with the set amount of seconds.

New webhook, backgroundPoll, which is called continously while the software is running.

New webhook, printBill, which is called when printing the bill of a table.

Webhooks: When an article with a question-price is added through lineAdditions, but a price is also included in the response, the price-popup will no longer be shown. wordt met een vraagom-prijs, maar er wordt ook direct een gewenste prijs meegegeven, dan wordt de vraagom-popup nu niet meer getoond.

Webhooks: In case of a manual cancellation of a webhook, there will no longer be an error message sent to the POS interface telling the user that the webhook is cancelled. Because the user already knows this, since they were the one that initiated the cancellation manually.

Solved an issue where the webhook popup would show earlier than expected (earlier than the configured delay time). The popup will now also be hidden when the webhook responds with a dialog. And after answering the dialog, it will be shown again only after the configured delay time has elapsed again.

When the externalPayment webhooks were used together with (table) orders, the POS would show an error message.

The POS no longer stays stuck in webhook communication when it receives lineDeletions in reply to a removeSessionLine.

With the webhook response vatMethodChange, it is now possible to change the current VAT method of the POS for the duration of the session. Valid values are: "inclusive" (VAT included), "exclusive" (VAT excluded) and "shifted" (VAT shifted).

The processing of webhook responses has become a bit more relaxed, because certain fields can now be returned in multiple ways. Eg. the title of a dialog can now be returned through both dialog.dialogTitle and dialog.title.

Added support for changing the caption of a customAction button, by responding with customActionChange.

Solved an issue where webhooks wouldn't work if the server returned headers more than once. E.g. Set-Cookie.

Webhooks: Where available, the kitchen events now also contain customer data, in the relation object.

Webhooks: It is now possible to adjust the final payment of an external payment. You do this by responding with an adjusted externalPayment.finalAmount. This is useful when a payment method has applied additional discounts on a receipt, or when you want to indicate that more has been paid than necessary which may mean the cash register should give change to the customer.

Webhooks: It is now possible to use an Endpoint URL without SSL (http instead of https), as long as the address is local or private, eg. http://localhost, http://127.0.0.1, http://192.168.*.*.

Webhooks: The following properties have been added to the relation data object:

• bankAccountNumber (het bankrekeningnummer van de geselecteerde klant)
• extRelationId (the external reference of the selected customer)
• address (the street name of the selected customer)
• zipcode (the zipcode of the selected customer)
• city (the city of the selected customer)
• country (the country of the selected customer)
• deliveryAddress, deliveryZipcode, deliveryCity,deliveryCountry (see above, but for the delivery address)
• vatNumber (the VAT registration number of the selected customer)
• commerceNumber (the Chamber of Commerce registration number of the selected customer)

Webhooks:

• Added support for external payments, with the following events:
  • startExternalPayment
  • pollExternalPayment
  • requestCancelExternalPayment
  • cancelExternalPayment
• Added updateSessionLine
• Added an article filter to add/update/removeSessionLine
• Added customAction toegevoegd
• Webhooks can now be Polling, which means they will keep running until confirmed or cancelled

Webhooks: It is now possible for lines to be deleted by a webhook that were not added by a webhook.

All webhooks now also send (if applicable) the currently signed in employee (through the field employeeNumber).

Webhooks: It is now no longer possible to mark an article as "Loss", when it has been locked by a webhook.

Webhooks: When opening a table order on a cash register, which was made through an handheld, you will no longer see the message "De aangeslagen artikelen worden opgeslagen op tafel x".

Solved an issue with Webhooks.

Small bugfixes.

Webhooks: When a webhook consumer locks a session (through lockSession), it is still able to modify the session through lineAdditions, lineChanges and lineDeletions.

Webhooks: In the sender-object you will now also be able to find whether or not the POS is currently in the payment screen. This is indicated by the property: paymentStarted: true of false

Webhooks: The event completeSession now also sends the property session.table when it was a table session that was completed.

Webhooks: session.table.subNumber is now always filled.

The Webhooks module is now available on Slaves.

Webhooks: It is now possible to add text lines through lineAdditions.

Webhooks: When a webhook adds a line to the session (through lineAdditions), this same webhook no longer receives an addSessionLine event about this. After all, the webhook should know that it added the line.

Webhooks: Table numbers are now correctly sent again. This was a temporary issue related to the transition to table sub numbers. When applicable, an additional subNumber property is now also sent.

Special change for Webhooks: When adding a line through lineAdditions, the supplied text, priceIncl, quantity and externalDiscount are now also used instead of ignored.

Special change for Webhooks: When adding a line through lineAdditions, the supplied text, priceIncl, quantity and externalDiscount are now also used instead of ignored.

Added support for webhooks.

With webhooks, information about the current receipt can be sent from the cash register to a configuratble URL. By replying to thist request, you can also do things like changing the contents of the receipt, or influencing the software flow. E.g. applying discounts, adding receipt lines, and printing additional information on the receipt. It is also possible to ask questions from the user.

See the Developers-site for a technical explanation.