Neu Export Zahlungen - Bug oder nicht ?

[MichaelH]

Bei den Zahlungen kann die Option "Kein Export Ameise" angehakt werden.
Tatsächlich gibt es dadurch aktuell keine Möglichkeit diese Zahlungen zu exportieren.

Und mit keine meine ich keine - wie soll hier eine Kontrolle stattfinden ?
Nur über eine SQL-Abfrage ?

 

[Enrico W.]

Gegenfrage: Wenn Du eine Kontrolle möchtest - warum hakst Du das dann an?

 

[MichaelH]

Grundsätzlich kann man damit eine Zahlung vorgaukeln die erst in der FIBU sichtbar wird, da der OP bestehen bleibt.
Kontrolle ?
Abstimmung ?

Weiters gibt es Gründe warum keine Gutschrift erstellt wird und somit eine Rechnung über eine fiktive Zahlung aufgehoben wird - in der WAWI - und diese Zahlung auch nicht in die FIBU übergehen soll, da es eben keine Zahlung gab.
Oder wie willst du diese Zahlung sonst separieren ?
Oder möchtest du immer und ewig offene nicht bezahlte Rechnungen haben ?
z.B. nicht einbringliche Forderung

Und zum Thema Guthaben, das ist so eine Sache in der WAWI, müsste ich mir wieder mal ansehen, aber Guthaben, Gutschein ist in der WAWI kaum korrekt abbildbar, zumindest dann nicht, wenn man mehr als 1 Steuersatz bei den Produkten hat.

Es gibt also sehr wohl Gründe warum eine Datensatz der manuell erfasst wurde auch kontrolliert werden sollte.

Und Guthaben so wie du es meinst buchen wir so:
Mit Tagesdatum das Guthaben bei der einen Rechnung (die das Guthaben hat) mit Minus erfassen.
Mit Tagesdatum als Zahlung bei der anderen Rechnung erfassen.
Beide Zahlungen werden exportiert.
Das ist also eine Umbuchung.
So ist es korrekt und nachvollziehbar.

 

[Enrico W.]

Bitte nicht falsch verstehen - ich möchte die Sinnhaftigkeit klären.
Wieso bleibt der offene Posten bestehen, wenn Du eine Zahlung setzt?

Ich geh sogar so weit, direkt zu behaupten, dass es sich um keinen Bug handeln kann, wenn diese Option explizit gesetzt werden kann - und sie dann auch genau das macht, was sie besagt.

Die Frage müsste sein, wofür ihr diese Option dann benutzt.

 

[MichaelH]

Wieso bleibt der offene Posten bestehen, wenn Du eine Zahlung setzt?
- Da diese nicht exportiert wird, aber in der WAWI ist die Rechnung ausgeglichen

Ich schrieb ja nicht dass diese Option ein Bug ist, sondern dass die fehlende Möglichkeit MANUELL erfasste Daten nicht auswerten zu können ein Bug ist.
Es gibt in der Ameise keine Möglichkeit derart markierte Zahlungen mit ausgeben zu können, auch wenn man will.

Tatsächlich gibt es dadurch aktuell keine Möglichkeit diese Zahlungen zu exportieren.
Und mit keine meine ich keine - wie soll hier eine Kontrolle stattfinden ?
Nur über eine SQL-Abfrage ?

 

[Enrico W.]

Ein offener Posten heißt für mich, dass der Auftrag nicht bezahlt. Und da betrachte ich ausschließlich die JTL-Wawi. Wenn Du eine Zahlung setzt, dann ist der Auftrag bezahlt.

Wenn Du über eine separate Software die Fibu bedienst stellt sich mir nach wie vor die Frage, warum du diese Option aktivierst.

Und nein - die Option besagt, dass diese Zahlungen von der Ameise nicht berücksichtigt werden sollen. Somit ist das kein Bug der Ameise. Ich mag Dir Recht geben, dass es im Bereich der Zahlungen oder Statistiken eine Option geben sollte, das auszuwerten - aber die Ameise macht da genau das, was sie soll.

 

[MichaelH]

"Ein offener Posten heißt für mich, dass der Auftrag nicht bezahlt. Und da betrachte ich ausschließlich die JTL- Wawi. Wenn Du eine Zahlung setzt, dann ist der Auftrag bezahlt. "
Und wie löst du dann einen offenen Posten in der WAWI auf ohne eine Zahlung zu erfassen die keine Zahlung ist ?

Wir verwenden keine separate Software, sondern die CSV der WAWI aus dem Ameise Export. Und dort dürfen nur Zahlungen drin sein, was sonst ?
Keine Zahlungs-Zahlungen gibt es nirgends, nur in der WAWI.
Nutzt man aber die "keine Zahlungs-Zahlungen" nicht bleibt eine Rechnung in der WAWI für immer und ewig offen.

Letztlich:
Du kannst es drehen und wenden wie du willst - die WAWI arbeitet mit Zahlungen die keine Zahlungen sind.
Einem Missbrauch ist hier Tür und Tor geöffnet und zudem gibt es keine einzige Kontrollmöglichkeit.
Daher, da es die WAWI nicht anders kann, müsste es zumindest eine Kontrollmöglichkeit geben um den Bug zu umgehen.

 

[Enrico W.]

Ich glaube, wir reden aneinander vorbei.
Du setzt doch eine Zahlung. Damit ist der Auftrag bezahlt - fazit, keine offenen Posten - oder habe ich gerade ein Brett vor dem Kopf?

Edit: Oder stört es Dich einfach grundsätzlich, dass der Haken gesetzt werden kann?

 

[MichaelH]

Du musst eine Zahlung erfassen, aber es kam kein Geld dafür.
OP ist weg und die Kontrolle auch.

Und das ist dieser Konstruktion mit "Zahlung die keine Zahlung ist" geschuldet.

Einfach genug erklärt ?

Anders ausgedrückt:
Die nächste Rechnung von JTL werde ich auch mit einem Haken "ist bezahlt" begleichen und "kein Export" und somit nie ein Geld überweisen.
Da Zahlungskontrolle und das Mahnwesen über JTL-WAWI läuft wird das auch nie auffallen.

Und wenn du das über die FIBU abgleichen willst, dann wünsche ich dir viel Spaß und genug Zeit dafür.

Verstanden ?

 

[Enrico W.]

Nein, sorry, das kann ich nicht wirklich verstehen. Was du gerade bemängelst ist die grundsätzliche Funktion, die Zahlung zu setzen - denn das ist immer möglich, ohne dass es wirklich eine Zahlung gab.

Dein Beispiel hinkt da. Das wäre dann eher, als würden wir Deine Rechnung als bezahlt markieren, ohne dass es eine Zahlung gab. Schließlich sind es nicht Deine Kunden, die das machen sondern du selbst.
Damit Dein Beispiel stimmen würde müssten Deine Kunden Zugriff auf deine Wawi haben und dort die Zahlung setzen können.

Edit:
Ich frag noch mal ganz direkt:
Warum setzt Du eine Zahlung, obwohl kein Geld gekommen ist?
Warum sagst Du, dass die Zahlung von der Ameise nicht beachtet werden soll, wenn Du sie doch beachtet haben willst?
Warum nutzt Du nicht einfach eine gesonderte Zahlungsart für Deine Sonderfälle?

 

[MichaelH]

Oje, ich sehe du willst das Grundproblem nicht verstehen, noch einfacher kann ich es einfach nicht erklären ...
Ich lasse mir von einem SP ein SQL schreiben.


Abschließend:
Zahlung setzen die exportiert wird und die tatsächliche Zahlung sind über die Bank abzustimmen.
Dafür gibt es Kontoauszüge.

Eine Zahlung die keine Zahlung ist, nicht exportiert wird und daher auch nicht existiert kann man nicht abstimmen - was ist daran immer noch nicht klar ?

Und das Beispiel JTL war nur ein Beispiel um dir das interne Beispiel darzustellen, aber auch dies hat offensichtlich nicht gefruchtet auch nach 5 Anläufen nicht.
Vielleicht muss ich eurer FIBU nur ein Geschenk senden und sie erfassen meine Zahlung "ohne Export".
Klick ?
Und nach ein paar Jahren fällt irgendjemandem auf, dass es noch FIBU-OPs gibt um die sich offensichtlich nie jemand gekümmert hat, weil sie unter 1.000en OPs keine Beachtung fanden.
Erfassungsfehler miteingerechnet, ist ja nur ein Häkchen das ohne Kontrolle gesetzt werden kann oder auch nicht.
Und dann lauf jedem alten OP hinterher und stelle fest ob es in den Jahren seit da viellleicht doch auf einer von 3 Banken + PayPal eine Zahlung gab oder nicht und der Haken nur falsch gesetzt wurde.

Viel Spaß !

Die Funktion ist unkontrolliert verwendbar und es gibt keine einzige Kontrollmöglichkeit.

Wo Menschen arbeiten passieren Fehler, muss also nicht böswillig sein.

 

[Enrico W.]

Wie bereits gesagt - dass es eine Auswertungsmöglichkeit geben sollte - da habe ich Dir bereits oben zugestimmt. Das kann ich gern intern weitergeben.
Das ist aber dann ein fehlendes Feature, kein Bug. Die Ameise macht da genau das, was die Option besagt.

 

[MichaelH]

Thema: "Export Zahlungen - Bug oder nicht ?"

 

[Björn Berger]

Egal ob Bug oder Feature, klar ist dir fehlt ne Auswertungsmöglichkeit.
Das weitere Vorgehen klären wir gerade.
Evtl hilft solange ja folgender Sql um die Zahlungen zu sehen die nicht im Export enthalten sind:
SELECT * FROM dbo.tZahlung WHERE tZahlung.nKeinExport = 1

 

[MichaelH]

Danke Björn, das ist ein Ansatz, aber da fehlt noch einiges an Daten.

Wenn die Option ergänzt wird, dann wird man diese explizit einschalten oder wählen müssen, damit nicht alle Vorlagen aller Kunden geändert werden müssen.
Also über "Filter" nicht machbar.