Neu Debitorennummern - die 2.

[Buinger]

Hallo, nochmal das leidige Thema "Debitorennummern". Es gibt dazu ja viele (teilweise alte) Beiträge, ich fange noch mal von vorne an.

Unsere Buchhaltung möchte für jeden Kunden der NICHT mit Secupay und NICHT mit PayPal bezahlt eine Debitorennummer, die vom Anfangsbuchstaben abhängt.

Also müsste man erst mal Secupay und beide PayPal Zahlungsarten ausschließen (Bedingung).

Wir haben aber auch Vereine & Firmen. Bei denen soll es dann nach dem Anfangsbuchstaben des Vereins bzw. der Firma gehen.

Müssten wir nun für alle Buchstaben je einen Workflow erstellen oder lässt sich das auch besser lösen? Wie ist die Bedingung mit den Firmen/Vereinen zu integrieren?

Vielen Dank.

 

[sjk]

Was sollen denn die Secupay/Paypal Kunden für eine Debitorennummer erhalten? Was ist, wenn ein Kunde zuerst mit Paypal bezahlt, dann per Überweisung, dann über Secupay?

Aus meiner Sicht ergibt es keinen Sinn Debitoren nach Zahlungsart zu ordnen und ich habe auch noch nie gehört, dass man das so macht. Die Debitorennummer ist ja gerade dazu da, alle Umsätze eines Kunden gegen alle Zahlungseingänge eines Kunden zu buchen. So ist auf einen Blick klar, ob alle Forderungen und Verbindlichkeiten zu einem bestimmten Kunden ausgeglichen sind.

Macht man das jetzt von der Zahlungsart abhängig wird sich immer ein unvollständiges Bild ergeben, oder im schlimmsten Fall wird eine Rechnung auf das eine und der Zahlungseingang auf ein anderes Debitorenkonto gebucht.

Verschiedene Zahlungsarten bildet man aus meiner Erfahrung besser über Zwischenkonten für jede Zahlungsart ab. Damit hat man dann sowohl die klare Zuordnung aller Vorgänge eines Kunden in seinem Debitorenkonto, und alle Salden je Zahlungsart auf Bank + Zwischenkonten für andere Zahlungsarten.

Ich kann dir deshalb nur raten dieses Thema nochmal von ganz vorne mit eurer Buchhaltung zu besprechen.

Davon abgesehen solltest du die technische Umsetzung aber in einem Workflow hinbekommen. Die Debitorennummer ist in der Wawi ein Textfeld, das du mit der Aktion Werte setzen beliebig befüllen kannst. Mit DotLiquid kannst du hier mit Filtern und Bedingungen beliebig komplex den Output bestimmen, von der Unterscheidung zwischen Kundengruppe bis zu bestimmten Werten für einen Anfangsbuchstaben des Kunden.

 

[Buinger]

Was sollen denn die Secupay/Paypal Kunden für eine Debitorennummer erhalten? Was ist, wenn ein Kunde zuerst mit Paypal bezahlt, dann per Überweisung, dann über Secupay?

Aus meiner Sicht ergibt es keinen Sinn Debitoren nach Zahlungsart zu ordnen und ich habe auch noch nie gehört, dass man das so macht. Die Debitorennummer ist ja gerade dazu da, alle Umsätze eines Kunden gegen alle Zahlungseingänge eines Kunden zu buchen. So ist auf einen Blick klar, ob alle Forderungen und Verbindlichkeiten zu einem bestimmten Kunden ausgeglichen sind.

Macht man das jetzt von der Zahlungsart abhängig wird sich immer ein unvollständiges Bild ergeben, oder im schlimmsten Fall wird eine Rechnung auf das eine und der Zahlungseingang auf ein anderes Debitorenkonto gebucht.

Verschiedene Zahlungsarten bildet man aus meiner Erfahrung besser über Zwischenkonten für jede Zahlungsart ab. Damit hat man dann sowohl die klare Zuordnung aller Vorgänge eines Kunden in seinem Debitorenkonto, und alle Salden je Zahlungsart auf Bank + Zwischenkonten für andere Zahlungsarten.

Ich kann dir deshalb nur raten dieses Thema nochmal von ganz vorne mit eurer Buchhaltung zu besprechen.

Davon abgesehen solltest du die technische Umsetzung aber in einem Workflow hinbekommen. Die Debitorennummer ist in der Wawi ein Textfeld, das du mit der Aktion Werte setzen beliebig befüllen kannst. Mit DotLiquid kannst du hier mit Filtern und Bedingungen beliebig komplex den Output bestimmen, von der Unterscheidung zwischen Kundengruppe bis zu bestimmten Werten für einen Anfangsbuchstaben des Kunden.

"Was sollen denn die Secupay/Paypal Kunden für eine Debitorennummer erhalten? Was ist, wenn ein Kunde zuerst mit Paypal bezahlt, dann per Überweisung, dann über Secupay?" - genau das war auch mein erster Gedanke!

Aber auch wenn ich Dir da generell zustimme - "Mit DotLiquid kannst du hier mit Filtern und Bedingungen beliebig komplex den Output bestimmen" klingt gut, aber wie würde das in der Praxis aussehen bzw. wo ist das alles dokumentiert?

 

[frankell]

klingt gut, aber wie würde das in der Praxis aussehen bzw. wo ist das alles dokumentiert?

Es gibt zwar eine Dokumentation zu DotLiquid im JTL-Guide (https://guide.jtl-software.com/jtl-wawi/vorlagen/), aber die gibt lediglich die Basics anhand nur sehr weniger Beispiele wieder. Da muss man sich schon mit viel "trial and error" reinarbeiten. Deinen Anwendungsfall wirst Du dort nicht mal im Ansatz finden. Aber das ist auch nicht überraschend, da er schon sehr speziell ist. Wenn Du ein guter Autodidakt bist, viel Geduld mitbringst und Dir manches von einer KI erklären lässt (dabei aber immer vorsichtig sein und lieber einmal mehr hinterfragen), kannst Du das auch selbst hinbekommen. Wenn nicht, lass es jemanden machen, der das bereits kann.

 

[MrM]

Sowas ähnliches habe ich auch schon gemacht. Problem ist dass man in den Workflow die Zahlart aus dem Kunden nicht im Standard als Wert bereitgestellt kriegt als Wert beim "Wert setzen" (merkwürdig ist aber so).

Hier der Wert zum setzen im Feld Debitoren (muss nach angepasst werden)

{% capture sqlAbfrage -%}
SELECT tz.cName
FROM dbo.tkunde t
JOIN dbo.tZahlungsart tz
    ON tz.kZahlungsart = t.kZahlungsart
WHERE t.kKunde = {{ Vorgang.InterneKundennummer }}
{% endcapture -%}
{% assign zahlart = sqlAbfrage | DirectQueryScalar -%}
{% if zahlart == 'Paypal' %}
P{{ Vorgang.Kundennummer }}
{% elsif  zahlart == 'Secupay' %}
S{{ Vorgang.Kundennummer }}
{% endif %}

Kann alles mit einem Update theoretisch kaputt gehen wenn sich das Datenmodell ändert.

 

[FOC Solutions]

Was sollen denn die Secupay/Paypal Kunden für eine Debitorennummer erhalten? Was ist, wenn ein Kunde zuerst mit Paypal bezahlt, dann per Überweisung, dann über Secupay?

Aus meiner Sicht ergibt es keinen Sinn Debitoren nach Zahlungsart zu ordnen und ich habe auch noch nie gehört, dass man das so macht.

Wir haben einige Kunden die es so machen. Der Sonderfall, dass innerhalb eines Monats der Kunde erst per PayPal und dann noch per Überweisung o.ä. zahlt, kommt selten vor und wird in der jeweiligen Buchhaltung händisch behandelt.

 

[Buinger]

Noch mal eine Frage dazu: Ein Workflow, der 5 Zahlungsarten ausschließt soll die Debitorennummer auf 15000 setzen, wenn der Kundennachname mit "F" beginnt.

Im Workflow-Test funktioniert es, in der Praxis aber nicht. Fehlt da noch was? Wo könnte das Problem liegen?