Verwiesen an Support Billpay und Shop 3.20/5 - Zinsaufschlag/Bearbeitungsgebühr - Re. erstellen n. mgl.!

[L.Mechler]

Hallo zusammen,

Wir haben unsere Wawi am 12.12. von 0.99923 auf 1.1.4.10 und gleichzeitig den Shop von 3.19 auf 3.20 geupdated, seitdem massive Probleme mit Billpay. Das ganze fällt jetzt erst auf da nach dem Shop update Billpay als Zahlungsart im Shop deaktiviert war (!?).

Komischerweise haben wir Billpay bei dem Update im Shop nicht deaktiviert, sondern es hat sich "von selbst" deaktiviert, ein Kunde hat uns darauf aufmerksam gemacht dass wir mit "Billpay" werben, diese Zahlungsart jedoch im Bestellabschluss nicht zur Verfügung steht. Wir haben daraufhin die hinterlegten Einstellungen zu Zahlungsart Billpay im Shop geprüft (KEINE Änderungen vorgenommen) und siehe da, nach Sichtung der Einstellungen und klick auf "speichern" ging es wieder.

Aber zum eigentlichen Thema:
Wir haben nun das Problem dass, sobald es in einem Auftrag die Position Zinsaufschlag und/oder Bearbeitungsgebühr gibt, d.h. sobald der Rechnungsbetrag vom eigentlichen Bestellwert abweicht, keine Rechnung mehr erstellt werden kann.

Die Wawi stürzt dann mit einer Fehlermeldung ab:

"Fehler: Der Betrag der Bestellung bei der manuellen Aktivierung der Forderung hat sich gegenüber der Vorauthorisierung geändert"

Ein ähnliches Problem wird auch in diesem Thread behandelt:
https://forum.jtl-software.de/threads/release-jtl-wawi-1-0-9-2-version-fehler-billpay.85202/

Das ganze ist in sofern extrem Problematisch da der Auftrag dann zwar ausgeliefert werden kann (LS und Versandlabel wird trotz Absturz im Hintergrund erstellt), jedoch nach Rücksprache mit der Buchhaltung die Forderung gegenüber Billpay erst mit Erstellung der Rechnung aktiviert wird?!

 

[L.Mechler]

Anbei Fehlerprotokoll:

Unbehandelte Ausnahme #2559D38FDA8AECA3 vom Typ jtlCore.Classes.jtlDBClassesEx.RechnungErstellenException in Void tkt0KKaTlV(jtlDatabase.classes.jtlDBClasses.jtlBestellung)
jtlCore.Classes.jtlDBClassesEx.RechnungErstellenException: Es konnte keine Rechnung zur Bestellung 113987AT erstellt werden (ModulId: za_billpay_jtl): Fehler: Der Betrag der Bestellung bei der manuellen Aktivierung der Forderung hat sich gegenüber der Vorauthorisierung geändert ---> jtlCore.Classes.dbeS.WebSyncRemoteErrorException: Fehler: Der Betrag der Bestellung bei der manuellen Aktivierung der Forderung hat sich gegenüber der Vorauthorisierung geändert
   bei jtlCore.Classes.dbeS.WebSyncXml.CreateInvoice(Int32 kBestellung, Int32 kSprache, String& puiZahlungsdaten)
   bei jtlCore.Classes.jtlDBClassesEx.RechnungCreator.tkt0KKaTlV(jtlBestellung )
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei jtlCore.Classes.jtlDBClassesEx.RechnungCreator.tkt0KKaTlV(jtlBestellung )
   bei jtlCore.Classes.jtlDBClassesEx.RechnungCreator.BpX0LLKOrj(jtlBestellung , jtlRechnung& , String , Boolean )
   bei jtlCore.Classes.jtlDBClassesEx.RechnungCreator.TryCreate(Int32 kBestellung, jtlRechnung& rechnung, String cRechnungsnummer)
   bei jtlCore.Classes.Versand.Auslieferung.AuslieferungAusliefernContext.OAtizE7a4g()
   bei jtlCore.Classes.Versand.Auslieferung.AuslieferungAusliefernContext.Commit()
   bei jtlCore.Forms.Versand.Auslieferung.AuslieferungAusliefernControllerBase.Save()

Unbehandelte Ausnahme #11CBB2E811ACA235 vom Typ jtlCore.Classes.dbeS.WebSyncRemoteErrorException in Void CreateInvoice(Int32, Int32, System.String ByRef): Fehler: Der Betrag der Bestellung bei der manuellen Aktivierung der Forderung hat sich gegenüber der Vorauthorisierung geändert

2017-01-02T09:46:22 DEBUG - [SQL] Dauer: 3ms
2017-01-02T09:46:22 DEBUG - [SQL] SELECT * FROM [tlieferant] WHERE [kLieferant] = @kLieferant
      @kLieferant = 118
2017-01-02T09:46:22 DEBUG - [SQL] Dauer: 5ms
2017-01-02T09:46:27 DEBUG - [SQL] SELECT * FROM [tFormular] ORDER BY tFormular.nTyp, tFormular.nStandard DESC, tFormular.kFormular
2017-01-02T09:46:27 DEBUG - [SQL] Dauer: 1ms
2017-01-02T09:46:27 DEBUG - [SQL] SELECT cWert FROM [tUserClientLayout] WHERE kBenutzer=@kBenutzer AND cRechnername = @cRechnername AND cName = @cName
      @kBenutzer = 1,
      @cRechnername = 'LUKAS-PC',
      @cName = 'jtlCore.Forms.Versand.Auslieferung.Auftrag.Ausliefern.FormsAuslieferungAuftragAusliefernOptionenForm'
2017-01-02T09:46:27 DEBUG - [SQL] Dauer: 1ms
2017-01-02T09:46:31 DEBUG - [SQL] SELECT cWert FROM [tUserClientLayout] WHERE kBenutzer=@kBenutzer AND cRechnername = @cRechnername AND cName = @cName
      @kBenutzer = 1,
      @cRechnername = 'LUKAS-PC',
      @cName = 'jtlCore.Forms.Versand.Auslieferung.Auftrag.Ausliefern.FormsAuslieferungAuftragAusliefernOptionenForm'
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 1ms
2017-01-02T09:46:31 DEBUG - [SQL] BEGIN TRANSACTION
IF EXISTS(SELECT cWert FROM [tUserClientLayout] WHERE kBenutzer=@kBenutzer AND cRechnername = @cRechnername AND cName = @cName)
BEGIN
UPDATE [tUserClientLayout] SET cWert=@cWert WHERE kBenutzer=@kBenutzer AND cRechnername = @cRechnername AND cName = @cName
END
ELSE
BEGIN
INSERT INTO [tUserClientLayout] (kBenutzer, cRechnername, cName, cWert) VALUES (@kBenutzer, @cRechnername, @cName, @cWert)
END
COMMIT
      @kBenutzer = 1,
      @cRechnername = 'LUKAS-PC',
      @cName = 'jtlCore.Forms.Versand.Auslieferung.Auftrag.Ausliefern.FormsAuslieferungAuftragAusliefernOptionenForm',
      @cWert = '{}'
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 2ms
2017-01-02T09:46:31 DEBUG - [SQL] EXEC Auslieferung.spPicklistenUebernehmen
      @Bestellungen = '<Bestellung>
  <kBestellung>106089</kBestellung>
</Bestellung>',
      @kBenutzer = 1,
      @nSplitAuftrag = 0,
      @kSessionId = 1330,
      @xResult = ''
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 8ms
2017-01-02T09:46:31 DEBUG - [SQL] SELECT * FROM [tWorkflow]
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 1ms
2017-01-02T09:46:31 DEBUG - [SQL] EXEC Auslieferung.spPicklistenAusliefern
      @xHinweise = '',
      @Pakete = '<Paket>
  <kBestellung>106089</kBestellung>
  <kVersandart>35</kVersandart>
  <fGewicht>0</fGewicht>
  <dVersanddatum />
  <cTrackingId></cTrackingId>
  <cHinweis></cHinweis>
</Paket>
<Paket>
  <kBestellung>106089</kBestellung>
  <kVersandart>35</kVersandart>
  <fGewicht>0</fGewicht>
  <dVersanddatum />
  <cTrackingId></cTrackingId>
  <cHinweis></cHinweis>
</Paket>',
      @nOptions = 0,
      @kBenutzer = 1,
      @kSessionId = 1330,
      @xResult = ''
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 681ms
2017-01-02T09:46:31 DEBUG - [SQL] UPDATE dbo.tbestellung SET tRechnung_kRechnung = @kRechnung WHERE dbo.tbestellung.kBestellung = @kBestellung AND dbo.tbestellung.tRechnung_kRechnung <= 0
      @kBestellung = 106089,
      @kRechnung = 1167901487
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 1ms
2017-01-02T09:46:31 DEBUG - [SQL] SELECT tRechnung_kRechnung FROM dbo.tbestellung WHERE tbestellung.kBestellung = @kBestellung
      @kBestellung = 106089
2017-01-02T09:46:31 DEBUG - [SQL] Dauer: 0ms
2017-01-02T09:46:32 DEBUG - [SQL] EXEC dbo.spBestellungAendern
      @xBestellung = NULL,
      @kBestellung = 106089,
      @kRechnung = 0,
      @kBenutzer = 1,
      @kAdresse = 0,
      @kText = 3,
      @kKunde = 95302,
      @cBestellNr = '113987AT',
      @cType = 'B',
      @cAnmerkung = '',
      @dErstellt = '2016-30-12 10:34:53' -- 30.12.2016 22:34:53,
      @nZahlungsziel = 0,
      @kVersandArt = 35,
      @fVersandBruttoPreis = 0,
      @fRabatt = 0,
      @kInetBestellung = 7001,
      @cVersandInfo = '',
      @dVersandt = NULL,
      @cIdentCode = '',
      @cBeschreibung = 'N',
      @cInet = 'N',
      @dLieferdatum = NULL,
      @kBestellHinweis = 0,
      @cErloeskonto = '4400 Umsatzerlöse',
      @cWaehrung = 'EUR',
      @fFaktor = 1,
      @kShop = 1,
      @kFirma = 2,
      @kLogistik = 0,
      @nPlatform = 2,
      @kSprache = 1,
      @fGutschein = 0,
      @dGedruckt = NULL,
      @dMailVersandt = NULL,
      @cInetBestellnr = '17347',
      @kZahlungsArt = 14,
      @kLieferAdresse = 106088,
      @kRechnungsAdresse = 110067,
      @nIGL = 0,
      @nUStFrei = 0,
      @cStatus = '',
      @dVersandMail = NULL,
      @dZahlungsMail = NULL,
      @cUserName = '',
      @cVerwendungszweck = '',
      @fSkonto = 0,
      @kColor = 0,
      @nStorno = 0,
      @cModulID = 'za_billpay_jtl',
      @nZahlungsTyp = 0,
      @nHatUpload = 0,
      @fZusatzGewicht = 0,
      @nKomplettAusgeliefert = 1,
      @dBezahlt = NULL,
      @kSplitBestellung = 0,
      @cPUIZahlungsdaten = '',
      @nPrio = 0,
      @cVersandlandISO = 'DE',
      @cUstId = 'XXXX',
      @nPremium = 0,
      @kRueckhalteGrund = 0
2017-01-02T09:46:32 DEBUG - [SQL] Dauer: 4ms
2017-01-02T09:46:32 DEBUG - [SQL] EXEC dbo.spBestellungAendern
      @xBestellung = NULL,
      @kBestellung = 106089,
      @kRechnung = 0,
      @kBenutzer = 1,
      @kAdresse = 0,
      @kText = 3,
      @kKunde = 95302,
      @cBestellNr = '113987AT',
      @cType = 'B',
      @cAnmerkung = '',
      @dErstellt = '2016-30-12 10:34:53' -- 30.12.2016 22:34:53,
      @nZahlungsziel = 0,
      @kVersandArt = 35,
      @fVersandBruttoPreis = 0,
      @fRabatt = 0,
      @kInetBestellung = 7001,
      @cVersandInfo = '',
      @dVersandt = NULL,
      @cIdentCode = '',
      @cBeschreibung = 'N',
      @cInet = 'N',
      @dLieferdatum = NULL,
      @kBestellHinweis = 0,
      @cErloeskonto = '4400 Umsatzerlöse',
      @cWaehrung = 'EUR',
      @fFaktor = 1,
      @kShop = 1,
      @kFirma = 2,
      @kLogistik = 0,
      @nPlatform = 2,
      @kSprache = 1,
      @fGutschein = 0,
      @dGedruckt = NULL,
      @dMailVersandt = NULL,
      @cInetBestellnr = '17347',
      @kZahlungsArt = 14,
      @kLieferAdresse = 106088,
      @kRechnungsAdresse = 110067,
      @nIGL = 0,
      @nUStFrei = 0,
      @cStatus = '',
      @dVersandMail = NULL,
      @dZahlungsMail = NULL,
      @cUserName = '',
      @cVerwendungszweck = '',
      @fSkonto = 0,
      @kColor = 0,
      @nStorno = 0,
      @cModulID = 'za_billpay_jtl',
      @nZahlungsTyp = 0,
      @nHatUpload = 0,
      @fZusatzGewicht = 0,
      @nKomplettAusgeliefert = 1,
      @dBezahlt = NULL,
      @kSplitBestellung = 0,
      @cPUIZahlungsdaten = '',
      @nPrio = 0,
      @cVersandlandISO = 'DE',
      @cUstId = 'XXXX',
      @nPremium = 0,
      @kRueckhalteGrund = 0
2017-01-02T09:46:32 DEBUG - [SQL] Dauer: 3ms
Zeitstempel: 2017-01-02T09:46:43
Locale: German (Germany)
Locale: German (Germany)
Version: 1.1.4.10
Plattform: Wawi
Versionshash: E6E6E43B
Prozessname: System.Diagnostics.Process (JTL-Wawi)
Physikalischer Speicher: 478732288 / Peak: 877355008
Basispriorität: 8
Prioritätsklasse: Normal
CPU-Zeit (User): 0:30:23,1524868
CPU-Zeit (System): 0:30:20,5784703
Page-Size (Sytem): 1858120 / Peak: 1038520320
Page-Size: 702607360 / Peak: 1038520320
Offene Handles: 1541

 

[L.Mechler]

Noch ein weiteres Problem mit Billpay, was jedoch nicht direkt mit o.g. Problem in Zusammenhang steht:

Sobald ein Auftrag Zinsaufschlag/Bearbeitungsgebühr enthält wird von der Wawi die Zahlung (Artikelpreis inkl. Versandkosten) automatisch gesetzt, jedoch ohne den Betrag der o.g. Positionen. (Was prinzipiell soweit auch korrekt ist, von der Wawi wird der Betrag als Zahlung gesetzt den wir von Billpay für die Bestellung erhalten)

D.h. der Auftrag ist mit einem "offenen Betrag" i.H. des ZA/Bearbeitungsgebühr im System. in der 0.99923 haben wir um dieses Problem zu "umgehen" bzw. um den Auftrag als "komplett bezahlt" abschließen zu können eine Zahlungsart "Billpay Ausgleich" eingeführt und dann den noch offenen Betrag einfach mit dieser Pseudo-Zahlungsart gesetzt, was auch soweit funktioniert hat. Sauber ist diese Vorgehensweise jedoch meiner Meinung nach nicht.

Wie wäre hier die korrekte Vorgehensweise? Oder bleibt der Auftrag auf ewig mit einem noch offenen Betrag im System?

 

[L.Mechler]

Ticket#108478987957

 

[JulianG]

Hallo L.Mechler,

das hier eine unbehandelte Ausnahme erscheint und in der Auftragsübersicht hinterher auch nichts mehr sichtbar sein dürfte, haben wir bereits an die Entwicklung weitergegeben.

An dem Verhalten können wir hier jedoch leider nichts ändern. Billpay-Aufträge dürfen nachträglich nicht verändert werden.
Die API/Schnittstelle lässt dies nicht zu. Die Fehlermeldung "Fehler: Der Betrag der Bestellung bei der manuellen Aktivierung der Forderung hat sich gegenüber der Vorauthorisierung geändert" kommt nicht von uns, sondern von Billpay, wird durch den JTL-Shop geschleust und in der JTL-Wawi, die dann damit nicht direkt umgehen kann, ausgegeben.