Abschluss der Aktion „Erwartete Zahlung generieren“ (Den Kunden der erwarteten Zahlung entnehmen Sie dem Zusatzfeld statt dem Feld „Kunden verarbeiten“.

[quote] Alexander Pereginyak schrieb/a: Um dies zu tun, müssen Sie der Tabelle der erwarteten Zahlungen ein Feld hinzufügen, das die Kontakt-ID der erwarteten Zahlung speichert [/quote] Was ist der Zweck davon? (um den Umfang des Refactorings zu verstehen)

[quote] Maxim Tyndyk Administrator schrieb: Was ist der Zweck davon? (um den Umfang des Refactorings zu verstehen) [/quote] Am Ende sollten die Daten aus dem Zahlungstatbestand, der durch den erwarteten Vorgang mit dem Vorgang verknüpft wird, in die Kontaktkarte geladen werden. Wenn es in der erwarteten Zahlung keinen Kontakt gibt und wir ihn immer aus dem Prozess nehmen, wird der Prozess der Kontaktsuche zu verwirrend und unlogisch, in den die Daten geladen werden sollten ... und es ist nicht logisch zu bilden die erwartete Zahlung für den Kunden des Prozesses, wenn ein Dritter für das Kundengesicht bezahlt.

[quote] Alexander Pereginyak schrieb: Am Ende sollten die Daten aus der Zahlungstatsache, die durch die erwartete an den Prozess gebunden werden, in die Kontaktkarte geladen werden. wenn es in der erwarteten Zahlung keinen Kontakt gibt und wir ihn immer aus dem Prozess nehmen, dann bekommen wir einen zu verwirrenden und unlogischen Prozess, einen Kontakt zu finden, in den Daten geladen werden sollen ... [/quote] Das ist eine Krücke, und sehr verwirrend. Warum einen Kontakt in einem zusätzlichen Feld im Prozess suchen und ihn in die erwartete Zahlung für 1 Projekt hacken, wenn es am Endpunkt der Datenerfassung möglich ist - eine Einstellung vornehmen, damit nicht der Kontakt der erwarteten Zahlung process schreibt Felder, aber der Kontakt aus dem zusätzlichen Feld des erwarteten Zahlungsvorgangs - und Sie erhalten mehr offensichtlich. [quote] Alexander Pereginyak schrieb/a: und es ist nicht logisch, die erwartete Zahlung für den Kunden des Prozesses zu bilden, wenn ein Dritter für den Kunden bezahlt. [/quote] Jeder hat je nach Bedarf seine eigene Logik. Es macht für mich keinen Sinn, eine erwartete Zahlung für einen Kunden in der Bestellung eines anderen Kunden zu erstellen.

[quote] Maxim Tyndyk Administrator schrieb: Jeder hat seine eigene Logik, abhängig von seinen Bedürfnissen. Es macht für mich keinen Sinn, eine erwartete Zahlung für einen Kunden in der Bestellung eines anderen Kunden zu erstellen. [/quote] Ja, noch einen Moment. In Zukunft sollte auf der Grundlage dieser Überarbeitung die folgende Funktionalität implementiert werden: Nehmen Sie den EDRPOU-Code des Zahlers der Zahlung, finden Sie den Kontakt in der Box mit diesem Code, erhalten Sie eine Liste aller erwarteten Zahlungen davon kontaktieren und alle gefundenen erwarteten Zahlungen mit dieser tatsächlichen Zahlung "bezahlen" (die Hauptzahlung wird virtuell markiert, und für jede erwartete wird eine echte Teilzahlung erstellt). Wenn die erwartete Zahlung keinen eigenen Kontakt hat, scheint es mir ziemlich problematisch, eine solche Suche durchzuführen - Sie müssen die ganze Zeit in die Prozesse "schauen", schauen, in welchen Prozessen sich der Zahlungskontakt befindet der Zahler, eine Liste der zu erwartenden Zahlungen von ihm bekommen und ihn dann „ausgeben“. Obwohl, wer weiß ... es könnte wirklich einfacher sein, diese Logik in einer Aktion zu "nähen", anstatt die vorhandene Systemlogik zu bearbeiten. Gleichzeitig ist die Möglichkeit, die Person, von der das Geld tatsächlich erhalten werden soll, getrennt vom Kunden des Prozesses festzulegen, sehr verlockend, da dies die Möglichkeiten des Boxens erheblich erweitert und die Genauigkeit bei der Verwendung des Belegkalenders erhöht für d / s (natürlich ist dies bei weitem nicht für alle Benutzer des Systems relevant) insgesamt ... wenn Sie der Meinung sind, dass die angeforderte Überarbeitung dem Boxentwicklungsplan widerspricht oder nicht interessant ist, können Sie sie ablehnen. In diesem Fall gehe ich den anderen Weg.