Falscher Zahler für TTN-Lieferung

Die Daten im Block sind wichtiger als die Daten in den Aktionseinstellungen [file]18948[/file]

In MVP wurden diese Felder nie berührt, der Zahler in tn wurde basierend auf den automatischen Aktionseinstellungen angezeigt. Wenn es tatsächlich eine Wahl gibt, wer der Zahler ist, dann ist es irgendwie falsch, sie zu ignorieren. Aber für alle anderen Prozesse ist alles in Ordnung, obwohl der Zahler standardmäßig der Empfänger im Block ist. Prozessbeispiele: https://one-box.shine-bright.com.ua/290552/ Problem mit nur einem Prozess https://one-box.shine-bright.com.ua/290089/ [file]18958[/file] [file]18959[/file] [file]18960[/file] [file]18961[/file] [file]18962[/file] [file]18963[/file]

[quote] Rodion Farkhshatov schrieb: In MVP wurden diese Felder nie berührt, der Zahler wurde in TTn basierend auf den automatischen Aktionseinstellungen angegeben [/quote] Die Interaktionslogik zwischen dem Block und der automatischen Aktion änderte sich nicht zu os. [quote] Rodion Farkhshatov schrieb/a: Eigentlich, wenn es eine Wahl gibt, wer der Zahler ist, dann ist es irgendwie falsch, sie zu ignorieren. [/quote] Das ist deine subjektive Meinung, sie kann getrost umgedreht werden als "Wenn es im Block eine Auswahl gibt, ist es irgendwie falsch, sie zu ignorieren." Es gibt eine Logik, die ich oben beschrieben habe. Wenn es Ihnen nicht passt, kann ich die Kosten für die Überarbeitung an Ihre Bedürfnisse abschätzen.

[quote] bu OneBox production schrieb: Die Logik des Zusammenspiels des Blocks und der automatischen Aktion hat sich auf os nicht geändert. [/quote] Es ist gut, dass sich die Logik nicht geändert hat, aber das, wovon du sprichst, funktioniert nicht. Ich habe Ihnen Beispiele für Prozesse geschickt. Im IR-Block ist der Zahler standardmäßig immer der Empfänger, aber in den Phasen, in denen der Zahler die Aktion angibt, um den Absender auszuwählen, funktioniert es so. Hast du dir Beispiele angeschaut?

Ja, ich habe geschaut. Die Daten im Block werden ausgegeben, aber nicht gespeichert. Wenn die Daten nicht gespeichert werden, werden sie aus den Integrationseinstellungen übernommen. Sie werden gespeichert, wenn Sie den Prozess mit dem abgeleiteten Block speichern, wenn Sie auf Bearbeiten klicken. Diese. bei einer Bestellung mit "Fehler" werden die Daten des Zahlers gespeichert, im Rest nicht. [file]18969[/file]

Wenn Sie über die Bearbeitung der Payer-Felder sprechen, berühren wir sie niemals. In diesem Block werden nur die Stadt und die Branche ausgewählt. Integrationseinstellungen – was ist das? Parameter für die automatische Erstellung von TT einstellen?

[quote] Rodion Farkhshatov schrieb: Payer, wir berühren sie nie [/quote] gut, anscheinend berührt [quote] Rodion Farkhshatov schrieb: Integrationseinstellungen - was sind sie? Parameter für die automatische Erstellung von TT einstellen? [/quote] Persönliche Kontoeinstellungen im Boxen.

[quote] bu OneBox Produktion schrieb: gut, anscheinend berührt [/quote] 100% nicht berührt. Jetzt arbeiten nur noch 2 Personen mit dem System, mich eingeschlossen, und beide wissen, dass die ttn durch eine automatische Aktion erstellt wird und der Zahler anhand mehrerer Bedingungen festgelegt wird. Daher interagiert niemand mit diesen Feldern. [quote] bu OneBox Production schrieb: Persönliche Kontoeinstellungen im Boxen. [/quote] Getestet – der Zahler wird aus dem Abschnitt mit den Einstellungen für die Rücksendung gezogen. Ich habe alle tn seit Oktober überprüft, dieses Problem trat beim Übergang zum Betriebssystem auf. Jeden Tag wird ein TTN mit einem falsch angegebenen Zahlungspflichtigen erstellt. Вот список заказов: 09.01.2023 289916 07.01.2023 290275 06.01.2023 290142 06.01.2023 290126 06.01.2023 290262 06.01.2023 290029 05.01.2023 289924 03.01.2023 289657 30.12.2022 288113 26.12.2022 287891 25.12.2022 288274 Очень прошу verstehe das Problem, weil Ich werde mit den Händen des Payer-Feldes wiederholen, niemand hat jemals bearbeitet, bevor es mehrere Jahre lang kein solches Problem gab. Das Problem ist kritisch, weil es eine unangenehme Situation ist, wenn der Kunde für die Lieferung bezahlen muss, wenn der versprochene kostenlose Versand versprochen wird, und Zeit damit verbringt, es herauszufinden. Ist es möglich, zur Protokollierung die Beibehaltung dieser Felder für die Nachverfolgung hinzuzufügen? Oder verfolgen, wo genau der Zahler bei der Erstellung an das TTN übertragen wird? Von einer automatischen Aktion oder von diesem Block?

Ich habe Ihnen oben mehrmals geschrieben, dass der Lieferzahler aus dem Block genommen wird, wenn er nicht im Block ausgefüllt ist - aus der Aktion. Sie können eine Einstellung vornehmen, um außer Aktion zu treten und Blockierungseinstellungen zu ignorieren, es dauert 1 Stunde. Sie können auch die Einstellung oder "Rücksendeart, Rücksendezahler und Versandzahler aus Einstellungen verwenden ..." in Aktion setzen und passende Versandzahler in der Integration konfigurieren. Wenn die obigen Einstellungen ausgefüllt sind, haben sie Vorrang vor den Block- und Aktionseinstellungen. Wenn Sie möchten, dass ich nach welchem Ihrer Mitarbeiter suche und wie die Daten in den Block einzutragen sind, kann dies geschehen - es dauert ungefähr 3 Stunden. [file]18970[/file]

Ich habe es getestet, es funktioniert wie du sagst, aber mit einer kleinen Klarstellung: Der Zahler wird aus diesem Block gesetzt, wenn dieses Feld bearbeitet wurde, d.h. es wurde gepresst. Wenn Sie es nicht berühren, wird der Zahler aus den Einstellungen für automatische Aktionen festgelegt. Ich wiederhole, niemand berührt diese Felder, 2 Leute arbeiten jetzt mit dem System, mich eingeschlossen, und beide wissen, wie alles funktioniert. Dieser Block wurde von Beginn der Arbeit mit Boxen an in die Benutzeroberfläche eingefügt, seit mehr als 4 Jahren, und niemand hat jemals den Zahler in diesem Block bearbeitet. Und dieses Problem ist nicht aufgetreten. Aber trotzdem habe ich einen Ausweg gefunden, indem ich die Payer-Einstellung je nach Zahlungsmethode entfernt habe. Und jetzt sind die Felder Lieferzahler und Rücklieferzahler in diesem Block leer. Es wurde festgestellt, dass bei mehreren Bestellungen die Payer-Felder im Block ausgefüllt sind. Und beide Felder. Aber niemand hat sie bearbeitet. Der Zahler ist wieder falsch eingestellt. https://one-box.shine-bright.com.ua/291978/ https://one-box.shine-bright.com.ua/291513/ https://one-box.shine-bright.com. ua/291419/ Sehen Sie bitte, was los ist. Warum werden diese Felder ausgefüllt, wenn sie bei allen anderen Bestellungen leer sind? Vielen Dank. [file]19018[/file] [file]19019[/file] [file]19020[/file]

[quote] bu OneBox production schrieb: 1. Du beobachtest das Verhalten des Blocks und schaust, wie du es geschafft hast, ihn zu füllen. Lass es mich wissen, ich schaue mir an, wo und wie du es geschafft hast. [/quote]Lass uns erst einmal diesen Weg gehen

Guten Tag. Das Problem wiederholt sich täglich bei mehreren Bestellungen. Wir versuchen, alle im Auge zu behalten, aber erst heute ist es uns gelungen, den Moment des Ausfüllens der Felder in Echtzeit zu erfassen. Für diese Bestellung wurde nach dem Aufrufen der Bearbeitung der Bestellung am 3. Februar 2023 um 15:18:23 Uhr im IR-Block in den beiden Feldern Zahler und Rücksendezahler der Wert Empfänger eingetragen. Manuell in Absender geändert. https://one-box.shine-bright.com.ua/293031/ Bitte sehen Sie, was der Grund ist. [file]19146[/file]

Es ist mir gelungen, das Problem bei einer weiteren Bestellung in Echtzeit zu erfassen https://one-box.shine-bright.com.ua/293750/ Die Felder wurden ausgefüllt, als das Verfahren zur Überprüfung des Eingangs in der Phase Warten auf die Ware gestartet wurde. Bei anderen Bestellungen, mit den gleichen Aktionen, war es nicht möglich das Problem zu reproduzieren. Es tritt zufällig beim Stufenwechsel und beim Erarbeiten der Prozedur auf der Taste auf. [file]19158[/file]

Bitte teilen Sie mir mit, wann Sie das Problem beheben können. Wiederholt sich jeden Tag

Guten Tag. Oben habe ich Ihnen 4 Möglichkeiten gegeben, Ihr Problem zu lösen. Der zweite Punkt für Sie löst das Problem ein für alle Mal. Ich kann nur etwas "sehen", wenn Sie mir den genauen Algorithmus geben, wie ich in 100% der Fälle sehen kann, dass der Wert im Block gespeichert wird.

Ich habe dir geschrieben, wie es passiert. Du hast einen Bug, und ich muss noch einen Weg finden, wie er in 100% der Fälle reproduziert wird? Dies geschieht beim Aktualisieren des Prozesses, wenn Sie zu verschiedenen Phasen wechseln. Ich habe es persönlich gesehen: Da waren leere Felder, ich ging auf die Bühne, die Felder waren gefüllt. Reicht Ihnen das nicht, um diesen Fehler aufzuspüren? Du glaubst mir nicht oder was? Wir sind es schon leid, jeden Tag jede Bestellung zu überwachen, damit der Zahler richtig eingestellt ist. Natürlich kann ich mehr Zeit damit verbringen und den Bildschirm jedes Mal aufzeichnen, wenn sich die Prozesse ändern, aber ist das wirklich normal? Sind meine Worte nicht genug?

[quote] .dev OneBox production schrieb: Ich schrieb Ihnen, wie es passiert [/quote] [quote] Rodion Farkhshatov schrieb: Ich konnte das Problem bei anderen Bestellungen mit denselben Aktionen nicht reproduzieren [/quote] Ich kann es nicht wiederholen die Situation selbst, daher gebe ich Ihnen eine Lösung, wie Sie das Problem vermeiden können, oder ich bitte Sie, mir zu zeigen, wie ich den Fehler in 100% der Fälle wiederholen kann, damit ich ihn reproduzieren und beheben kann, wenn das Problem wirklich besteht. Ich glaube, Sie haben ein Problem. Es kann sich um den Code handeln, das Einrichten des BP, Ihre Aktionen, die Kombination der Ausgangsblöcke, die Kombination der Aktionen auf der Bühne usw., es gibt Hunderte von Optionen. Aber leider kann ich Ihnen hier nichts Neues erzählen: Ich brauche entweder einen Algorithmus, um den Fehler zu wiederholen, oder Sie können ihn vermeiden und keine Zeit damit verschwenden. Du wählst. Einen schönen Tag noch.

Ich verstehe einfach nicht, warum das die Position ist. Diese. irgendein fehler, der bei bestimmten aktionen nicht konsequent auftritt, aber zufällig nicht berücksichtigt wird? Sie können diese Felder auch protokollieren und sehen, was sie wann füllt. Bei MVP ist dieses Problem seit 5 Jahren nicht mehr aufgetreten.

+ Sie bieten an, die Zahlereinstellungen je nach Zahlungsmethode zu verwenden, dies ist jedoch eine sehr eingeschränkte Funktionalität. Wir legen den Zahlungspflichtigen abhängig von der Höhe der Bestellung fest. Nimmt man den Zahler aus dem Zusatzfeld, dann ist dieses Feld auch in dieser Aktion, die eine niedrigere Priorität als die IR-Sperre hat

Die Funktionsweise des Blocks hat sich während des Übergangs von mvp zu os nicht geändert. [quote] Rodion Farkhshatov schrieb / a: D.h. irgendein fehler, der bei bestimmten aktionen nicht konsequent auftritt, aber zufällig nicht berücksichtigt wird? [/quote] berücksichtigt [quote] Farkhshatov Rodion schrieb/a: Sie können die Protokolle auf diese Felder legen und sehen, was sie wann füllt. [/quote] Ja, natürlich - das steht auf der Liste meiner Vorschläge zur Lösung Ihres Problems. 4 Punkt.

[quote] .dev OneBox production schrieb: Ja, natürlich - es steht in der Liste meiner Vorschläge zur Lösung Ihres Problems. 4 Punkt. [/quote] Also machen wir es, nur verstehe ich nicht, warum ich dafür bezahlen muss, es ist ein Bug.

Ich habe hunderte Male gehört, dass etwas ein "Bug" ist, aber am Ende stellte sich heraus, dass jemand eine Aktion in die Phase gesetzt hat, die das ändert, was im "Bug" beschrieben wird, und es stellte sich heraus, dass der Fehler in den bp-Einstellungen lag . Lass uns das nochmal machen. Ich habe Ihnen einige Lösungen für Ihr Problem gegeben und die Kosten dort angegeben, wo sie sind. Sie haben eine Option mit einem Revisionsvoranschlag gewählt, ich habe sie Ihnen in Rechnung gestellt. Wenn Sie die Rechnung nicht bezahlen, wählen Sie einen anderen Weg, um Ihr Problem zu lösen. Ich habe Ihnen mehrere 100%ige Lösungen gegeben, um die oben beschriebene Situation zu vermeiden, die in 5 Minuten eingerichtet werden können. Wenn Sie sich mit mir darüber streiten wollen, ob das ein Bug ist, kein Bug, und wer wem was zu verdanken hat, dann habe ich dafür leider zu wenig Zeit. Wenn Sie Informationen haben, wie Sie den Fehler auf jeden Fall wiederholen können - ich kann es sehen, wenn Sie bereit sind, für die Protokollierung zu bezahlen - schreiben Sie einfach. Einen schönen Tag noch.

[quote] .dev OneBox production schrieb: Ich habe hunderte Male gehört, dass etwas ein "Bug" ist, aber am Ende stellte sich heraus, dass jemand eine Aktion auf die Bühne gebracht hat, die das ändert, was in dem "Bug" beschrieben ist, und es hat sich gewendet heraus, dass der Fehler in den bp-Einstellungen. [/ Quote] Niemand hat irgendwelche Aktionen eingestellt, das Problem trat nach dem Upgrade auf das Betriebssystem auf. Nur bei einer Ihrer Lösungen wurde der Zahler in der Anzeige angegeben. Feld. Und dies ist eine sehr seltsame Aktion der Aktion, wenn die Auswahl des Zahlers aus der Liste eine niedrigere Priorität hat als der IR-Block im Prozess und die Einstellung des Zahlers in der gleichen Aktion aus der Hinzufügung. Feld hat Vorrang vor dem NP-Block. Naja, mit so einer Krücke kommt man wenigstens um das Problem herum.

Ich freue mich, dass eine meiner Lösungen für Sie funktioniert hat.