ich denke wir nutzen den gleichen "Bastelweg" aber man kann leider nicht eigene Templates anlegen und einzelnen Kunden zuweisen, also bei jedem Wechsel die RG Belegvorlage anpassen 😄 ... Mehr anzeigen

Leider nicht möglich, ich warte auch drauf.  Umsetzung nicht geplant bzw. ist aufgenommen aber keine Info ob oder wann das erfolgt. ... Mehr anzeigen

Was ist eigentlich aus dem Motto: "Wir machen Datev zu einem Super Produkt" geworden? Alles was von meiner Seite, aber auch von den anderen hier angesprochen wurde, ist weiterhin nicht umgesetzt. Zahlungsbedingungen werden weiterhin manipuliert, Echtzeitüberweisungen nicht verfügbar. Neue Kundenanlage verbugged. Hat Datev jetzt offiziell aufgegeben? Keine neuen Funktionen mehr geplant?     Ah ok, gerade eine Ankündigung für den 30.06. gesehen -> Neue Designsprache, "modernes Design" Die haben es echt nicht gerafft! Wieder alles optisch ändern, alle suchen wieder die alten Ansichten und Button aber die wichtigen Funktionen? Dafür ist keine Zeit. 😄   ... Mehr anzeigen

@Leon_Hierhammer  Sorry, die Antwort ist absolut typisch Datev-Denke und sorgt für Kopfschütteln.   Die Bezeichnungen wurden im alten Auftragswesen aus den Stammdaten übernommen. Erst seit Next wird dieses ignoriert. Soviel zu "Das neue macht genau das was das alte kann, nur besser" Jetzt soll das so gewünscht sein?   it's not a bug it's a feature 😄   Das ganze ist unlogisch, wenn es doch weiterhin die Möglichkeit gibt, mehrere Zahlungsziele mit jeweils eigenen Texten anzulegen.     Eine Änderung ist aktuell nicht vorgesehen, weil diese Werte unter anderem in die Finanzbuchführung sowie in die strukturierten Felder der E-Rechnung einfließen. Individuelle Texte könnten nur als Freitext hinterlegt werden und würden nicht automatisiert verarbeitet.    Auch wenn es jetzt eher technisch wird, so sollte gerade DATEV wissen wie der Hintergrund der E-Rechnung aussieht.   E-Rechnung folgt einer genauen Definition. Hier gibt es jeweils Datumfelder mit Discount Angaben und der normalen Fälligkeit der Rechnung.   <udt:DateTimeString format="102">20230510</udt:DateTimeString> </ram:DueDateDateTime> <ram:ApplicableTradePaymentDiscountTerms> <ram:BasisAmount>166.4100</ram:BasisAmount> <ram:CalculationPercent>4.00</ram:CalculationPercent> </ram:ApplicableTradePaymentDiscountTerms> </ram:SpecifiedTradePaymentTerms> <ram:SpecifiedTradePaymentTerms> <ram:DueDateDateTime> <udt:DateTimeString format="102">20230531</udt:DateTimeString> </ram:DueDateDateTime> </ram:SpecifiedTradePaymentTerms>   Sicherlich gibt es auch Text-Felder. Diese können auf EDI-Basis nicht ausgewertet werden, da der mögliche Inhalt nicht definiert ist. Der Zusammenhang zwischen E-Rechnung und dem Vorschreiben des Text-Aufbaus ist also nicht korrekt und erst recht kein Grund die freie Text gestalltung zu sperren.     Der automatisch generierte Text stellt sicher, dass es keine Abweichungen zwischen dem sichtbaren Beleginhalt und den strukturierten Daten gibt. Dies muss nicht sichergestellt werden. Die Verantwortung das richtige Zahlungsziel zu wählen, besteht bei dem User der den Stammdatensatz bzw. die Rechnung anlegt. Aber auf gar keinen Fall bei dem Betreiber der Rechnungs-Stellungs-Software.   Aber genau das versucht Datev immer und immer wieder. Besserwisserisch den User zu erziehen, bloß die vordefinierten Textbausteine zu nutzen. Als wäre nur der Baustein das Richtige und alles andere falsch.   Das Datev AWN ist nur ein Werkzeug. Welcher Bohrmaschienenhersteller schreibt seinen Kunden denn vor in welche Wand er ein Loch bohrt?     Die Datev-Leute hier im Thread sind nur das Sprachrohr nach außen, bitte den Denkanstoß nicht persönlich nehmen. Lieber weiterleiten an die zuständige Person mit dem Hinweis, dass dieser Weg, Bugs als Wunder-Funktionen anzupreisen oder irgendwelche komischen Erklärungen zu liefern, nicht die Lösung ist. ... Mehr anzeigen

@Leon_Hierhammer  Was ist mit der fehlerhaften Umsetzung des Zahlungsziels auf der Rechnung?   Meine seit langem in den Stammdaten hinterlegten Zahlungsziele werden weiterhin ignoriert.   Egal ob ich da "14 Tage netto" oder "14 days net" im Kunden oder in der Rechnung auswähle, Datev rechtet einfach das Datum aus (also in diesem Beispiel heute + 14 Tage) und baut einen deutschen oder englishchen Textbaustein drum herum, den ich nicht konfiguriert habe. Also muss ich jede Rechnung anschließend per PDF writer wieder korrigieren, was dann ja zur Zerstörung der E-Rechnung führt.     Macht ja keinen Sinn mehrere Zahlungsziele anzulegen, bei denen man den Text selber definieret, wenn dies dann bei der Rechnung komplett ignoriert und einfach mit falschem Inhalt überschrieben wird.   Zur Erklärung: Fast alle meiner Kunden rechnen das Zahlungsziel mit Eingang der Rechnung.  Wenn diese also auf der Ware klebt oder erst später versand wird, dann ist das von Datev ausgerechnete Datum schlicht falsch. Daher die international gängige "30 day net" "90 days net" Bezeichnung, welche Datev seit Next nicht mehr zulässt. Da ist es schön wenn da "Entwicklung" reingesteckt wurde aber diese automatische Manipulation muss abschaltbar sein und dann der vom User ausgewählte Text da erscheinen.   ... Mehr anzeigen

Interessant finde ich den Zustand der Software 1 Jahr nach Zwangsumstieg. Vor einem Jahr hieß es noch Sinngemäß "bis zum Jahreswechsel wird es einige Updates geben und alles wird wie vorher funktionieren nur besser" Dann kam der Tag der Tage. Ich hatte schon vorher gewechselt aber irgendwann mussten alle ran. Es fielen massiv Fehler auf, große Teile die vorher da waren, waren einfach weg. Fehler über Fehler. Viel Schmerz und Aufwand auf Anwender-Seite.  Jeder fing an mit Work-Arounds, die, die konten sprangen ab und wechselten schnell in ein anders System. Andere hatten Hoffnung und warteten. Jetzt sind wir 1 Jahr nach dem "Bis zum Jahreswechsel wird alles gut" und bald auch 1 Jahr nach Umstieg. Wie sind denn jetzt die Funktionen? - Die Belge können jetzt Englisch *jipii* aber halt weiterhin nur hard-codiert ohne individuelle Anpassung. - Zahlungbedingungen sind auch weiterhin hard codiet. Wofür kann ich neue Zahlunsbedingungen anlegen wenn der Inhalt ignoriert wird? - Teil-Rechnungen Anzahlungen etc. sind teilweise umgesetzt aber wir merken immer wieder wie wir auf die Nase fallen, weil dann doch nur geflickt wurde. Keine klare Struktur, keine Lösungserarbeitung weiter nur Workarounds. Rechnung abschließen und löschen?!?! - Gutschriften weiterhin nicht richtig da oder? Wäre Auftragswesen Next eine zweckentfremdete Lösung ->ok. Aber diese Tool ist doch extra für die Auftragsabwicklung erstellt worden. Würde man versuchen mit Photoshop Lager-Inventuren durchzuführen. ok das kann nichts werden. Das ist einfach nicht dafür gemacht. ABER ernsthaft? DATEV schreibt sich auf die Fahnen tolle Lösungen anzubieten, stampfen ein funktionierendes Auftragswesel-old ein und zwingen alle auf ein neues Tool, das an auch 1 Jahr nach Wechsel an allen Ecken und Enden hinkt. Ich habe vor ein paar Wochen über das "neue" Kunden-Anlage Modul einen Kunden angelegt.  Bei dem folgenden Auftrag kamen Fehler über Fehler weil im neuen Kundenmodul ein Frage nach Kunde/Lieferant besteht, was direkte Auswirkungen auf Pflichfelder im Auftrag hat. Die Auswahl kann man noch ändern aber nicht mehr "nicht ausgewählt" lassen. Also einmal definiert, gibts kein zurück Also alles zurück, Kunde neu angelegt im alten Modul und den Auftrag wie gewohn erstellt und abgewickelt. 1 Schitt vorraus, 2 zurück  ... Mehr anzeigen

Datev hat ja die Tage per Mail angekündigt, dass bei SEPA Überweisungen zukünftig der Empfänger-Name abgeglichen wird. (Also per Gesetz gefordert) Da hier wohl das Bank-Modul angefasst wird und entsprechend angepasst werden muss, wäre schön wenn man dann gleich alle anderen Bank-Dinge wie diese neumoderne "Echtzeitüberweisung" auch mit aufnehmen würde. Ich weiß das ist Neuland und keiner weiß ob sich das wirklich durchsetzt 😂 Ich arbeite viel mit terminierten Überweisungen aber da lassen sich einige Banken noch immer 1-2 Tage Zeit. Das Echtzeitüberweisungs-Ding ist ja ne andere Art Überweisungs-Art. Viel Potenzial mal was gut umzusetzen. 👍 ... Mehr anzeigen

Oder aber es erhält alle Funktionen von Auftragswesen online. DAS wäre super    😂 Wenn nur die minimalste Chance da wäre, würde ich mich freuden aber da kauft wohl Datev alle Mitbewerber auf, als dass die Kunden erhört werden. ... Mehr anzeigen

Mit KI wird die Sau durchs Dorf getrieben.   überall wird jetzt KI eingebaut. Egal ob es was bringt, wenn KI in irgendeiner weise drin ist, wird damit geworben.  würde sich als werbung auch doof anhören “hey wir bei datev entwickelt das Produkt immer weiter, jetzt machen wir was ganz neues, wir beheben alt bekannte Fehler“ ... Mehr anzeigen

Hier wird schon mitgelesen aber sobald zu viele Negativ-Stimmen auf kommen, wird auf andere Wege verwiesen. Ich denke die meisten Probleme sind bekannt. Sie wurden ja schon unzählige Male gemeldet. Ob da noch was abgearbeitet wird oder ob man das Produkt jetzt sterben lässt kann ich leider nicht sagen.   Die Zahl der Nutzer, die bereits zu anderen Produkten umgestiegen sind oder gerade dabei sind, seigt stetig. ... Mehr anzeigen

@juliusbehr Ein Anfang wäre: eine Lösung die alles kann was das alte System auch konnte, 😄   Ich denke wir sind hier alle sehr weit weg von dem Wunsch nach neuen Funktionen. Das wäre der nächste Schritt aber würde das Team massiv überfordern. Das was man vorher lange gemacht hat und nun nicht mehr geht ist schon ärgerlich. Gerade nach dem Zwangs Umstieg. Das Formular war vorher weit freier zu konfigurieren, man konnte selber Textbausteine fest einstellen, die Position verändern, die Namensgebung von "Rechnung" zu "Invoice" ändern. All dies ist jetzt statisch hardcodiert.   Die Zahlungsbedingungen wurden so übernommen wie man die im Backend konfiguriert hat. Wenn man da im Textfeld geschrieben hat, "Das Zeug schenke ich dir, weil du so nen toller Typ bist" dann wurd das auch genauso auf der Rechnung ausgegeben. Eine Kopie der alten Rechnung führte nicht zur falschen Steuerberechnung. 0 Positionen waren kein Problem. Damals war einfach alles Besser 😄 Es ist und bleibt eine Neuentwicklung wo jemand beim Pflichtenheft massiv geschludert hat. ... Mehr anzeigen

Ich habe auch direkt ein neues Phänomen. Ich habe viele wiederkehrende Rechnungen, die ich aus dem Vorjahr kopiere. Eine Rechnung aus 2024 ohne Steuer (da drittland) kopiere ich, ändere das Datum und wenn ich nicht aufpasse haut Datev da die Steuer drauf. Der Kunde steht als Drittland, die alte Rechnung war ohne Steuer, ich habe lediglich eine Kopie erstellt. Irgendein Programmierer hat "Kopie" nicht verstanden. Es erfolgt also im Hintergrund irgendeine Berechnung oder Prüfung die mit fehlerhaftem Ergebnis endet. Im Next gibt es in der Rechnungsmaste einen Schiebeschalter (Mit oder ohne Steuer) den gab es damals glaube ich nicht. Vermutlich ist dieser einfach pauschal immer auf "ein" oder als Fallback auf "ein". Anders kann ich mir nicht erklären dass hier plötzlich mit Steuer berechet wird obwohl ich nur eine Kopie der alten Rechnung erstelle.   Ist schon sehr lustig mit anzusehen. Es wurde mit Gewalt darauf gedrängt auf Next zu wechseln und da viele grundlegende Dinge fehlten, wurden diese irgendwie kurzfristig reingebastelt. Hier trifft das Wort "Gebastelt" sehr gut. Anderes sprachige Belege: Belegvorlagen in anderer Sprache wurde einfach damit gelöst, dass jeweils ein englisches Formular hinterlegt wurde. Das ist aber genauso statisch und unattraktiv umgesetzt wie das deutsche vorher auch. Warum nicht die Vorlagen frei konfigurierbar? Warum habe ich nun Rechnung und Rechnung (englisch) warum kann ich mir nicht beliegieg Kopien davon erstellen und frei konfigurieren. 0 Positionen: Der Workaround soll hier sein man legt einen solchen Artikel nicht an sondern tippt ihn einfach und speichert? So wird die Pflichtfeld-Prüfung umgangen aber wehe man vertippt sich und verändert einen Wert dann muss man die Spalte wieder löschen und neu schreiben. Was denn das für ne flickel Lösung?   Zahlungbedingungen werden weiterhin manipuliert. Ich gehe da was ein und Datev macht daraus was er gerade für richtig empfindet. Das ist ein absolutes NoGo. Hier aber sehr offensichtlich, stellt sich die Frage wie oft noch Daten im Hintergrund manipuliert werden die der Nutzer aber nicht so offensichtlich sieht.   Next sollte die Neuentwicklung sein, eine Lösung die alles kann was das alte System auch konnte, alles sauber programmiert aber es wird seit Tag1 daran rum gebastelt, irgendwas irgendwie reingepopelt, hauptsache Datev kann sagen sie können E-Rechnung. Selten so ein undurchdachtes, fehlerhaftes Produkt gesehen. Kein Wunder dass die Leute nicht nur in andere Richtungen schauen sondern auch andere Richtungen einschlagen.   ... Mehr anzeigen

Bin nicht von Datev aber das kann man aus den erstellten PDFs auslesen ... Mehr anzeigen

Ich denke das wird dauern, wenn nicht sogar einfach ignoriert und nie umgesetzt.   ich behelfe mich damit, die Währung einfach im Template des Dokumentes zu überschreinben, also von EUR zu USD, passend dafür habe ich Textbausteine bei USD Kunden im Kundenstamm hinterlegt.   Ist natürlich nervig, wenn man oft hin und her wechseln muss aber dafür wenigstens machbar. Unser Steuerberater weiß das und beachtet das bei der Buchung im Hintergrund. Datev im Hintergrund kann ja andere Währungen. Und natürlich ist das für E-Rechnung inkompatibel, das ist aber zu vernachlässigen da USD Rechnungen bisher auch immer außerhalb EU sind und bei denen ist das Thema E-Rechnung eh unbekannt bzw. uninteresant. Da gälten dann eher Internatinale Standartformate wie edifact.   ... Mehr anzeigen

Was will (und wollte) man für diese monatlichen Überlassungsgebühr auch schon erwarten (ob zurecht oder nicht). Wobei zu beachen gilt, dass die Mitbewerber auch Module Anbieten und man dort nicht unbedingt teurer bei weg kommt. Dafür aber ein ausgereiftes funktionierendes Tool erhält. ... Mehr anzeigen

Jetzt stehe ich wieder vor dem Problem, dass DATEV die Zahlungsbedingungen ungefragt manipuliet. Ich benötige eine Rechnung für die ich als Gegenleistung eine Spendenquittung erhalten werde. Es wird also nie eine echte Zahlung erfolgen. Keine Skonto und auch sonst keine Rabatte oder sonst was. Also erstelle ich wie gewohnt eine Rechnung und im Kundenstamm ist als Zahlungskondition der Name "Spendenquittung" hinterlegt. Als Tage und %Werte steht natürlich 0.   DATEV ignoriert diese hinterlegen Stammdaten und mach ein sofort netto aus der Bedingung. Also wieder die PDF im Nachgang korrigieren. Das zum Thema E-Rechnung und der tollen Umsetzung von Next. Wie schon so oft gesagt, ist mir als Lieferant absolut egal was da steht. Solange das zwichen Lieferant und Kunde abgestimmt ist und sich beide daran halten. Wenn der Kunde da stehen haben muss "Zahlung erfolgt nach dem Frühstück" ist das etwas was Datev nicht zu intressieren hat. Bin ja gespannt ob das hier wieder igniriert wird oder ob hier wieder so ne absolute Krücke als Workaround angeboten wird. Stammdaten: So sieht es dann auf der Rechnung aus. ... Mehr anzeigen

Ich denke die Entscheidung eine Neuentwicklung umzusetzen kann nur 2 Gründe haben:   Option1: Die alte Version war auf einer nicht mehr aktuellen Programmierumgebung umgesetzt und man nutzt die Chance auf eine modernere Programmiersprache zu wechseln.   Option2: Der damalige Entwickler hat das Unternehmen verlassen, die hinterlassene Doku ist nicht so wirklich toll, Probleme und Erweiterungen sind nur schwer möglich, da ein neuer Entwickler nicht weiß wo er was im Code findet und dann die Entscheidung getroffen wurde neu anzufangen und komplett neu zu entwickeln.   Beide Optionen sorgen allerdings dafür, dass nichts einfach übernommen werden kann. Also Code per Copy Paste zu übernehmen, ist dann nicht so wirklich möglich. Was aber hätte gemacht werden müssen: - Project plan erstellen - Pflichtenheft erstellen - jede einzelne Funktion des alten Programms zu untersuchen und zu sehen, ob, wie oft jede einzelne Funktion genutzt wurde - Project start und Umsetzung - Alpha und Beta Phasen mit Mitarbeitern aber auch mit ausgewählten Kunden, quer durch die Branchen durch um zu sehen, was geht, was fehlt, was wurde evtl. übersehen. Naja was dabei raus gekommen ist, sehen wir ja. - Einen Project-Plan wird es gegeben haben, aber wir sehen ja wie fehlende Funktionen um Monate verschoben werden - Das Pflichtenheft wurde nicht vollständig erstellt oder aus Gründen zusammengestrichen - Die Umsetzung wurde gestartet aber auf Grund von platzenden Zeitplänen irgendwann einfach Live geschaltet - Beta Phasen wird es auch gegeben haben aber vermutlich wurde nur intern getestet. Eine User-Gruppe aus Kanzleien und Mandanten die ihre eingenen Prozesse testweise abbilden um zu sehen ob die einzelnen Geschäftsfälle funktionieren kann ja nicht stattgefunden haben. Oder wurde dann auch wieder gestrichen. In 1-2 Jahren wird dann gejammert, dass kaum einer das neue Tool nutzt, dass Kunden weglaufen und der Umsatz deutlich gesunken ist. Mitbewerber werden diese Foren, div. Berichte und die Entwicklung genau beobachten und die Kunden grinsend übernommen. Mein erster Kontakt mit den Vertretern aus Freiburg war sehr freundlich, offen und das Tool sieht super aus. Ich hatte innerhalb 10 min einen Artikel angelegt, einen Kunden angelegt, einen Auftrag erstellt und eine Englische Rechnung und das mit meinen eigenen Zahlungskonditionen erstellt. Sicherlich wird es da auch mal nen Problem geben aber die Software ist seit Jahren gereift. Natürlich muss man erst alles übernehmen und auch Templates korrekt einrichten aber das was da in 10 min alles schon ging sehr vielversprechend aus. ... Mehr anzeigen

Datev und seine "Wir sind die Meister und ihr müsst gefälligst tun was wir wollen"- Einstellung 😄 Die Pflicht-Feld einstellung bzw. die Sperrung von Sonderzeichen in der Kunden-Bestellnummer. Wurde damals eine Rechnung erfasst und dabei eine Kundenbestellnummer eingegeben, welche nun nicht mehr zum Syntax-Check passt, so landet man wieder im Deadlock. In meinem Fall habe ich eine Rechnung mit Aufragswesen(old) erstellt. Die Kundenbestellnummer hatte ein "-" (durchausüblich in Bestellnummern). "PO-123456" Beim Versuch diese Rechnung zu stornieren erscheint auch ein Fehler, aber kein Hinweis was/warum/wieso. Einfach nur "Pech-Fehler-geht-halt-nicht" Man sieht nicht mal im Ansatz was denn gerade das Wehwehchen ist. Erst mit dem Workaround kann man in die Rechnung schauen und da wird das Bestellnummernfeld nun als fehlerhaft angezeigt. Also werde ich gezwungen die Bestellnummern der Kunden zu manipulieren und sämtliche Sonderzeichen (bis auf die 5 freigegebenen) zu entfernern und dann hoffen, dass der Kunde das so akzeptiert und nicht einfach als "Nicht zuzuordnen" abweist. Warum wird so ein Feld bzw. die Syntax davon vorgeschrieben? Mir als Lieferant ist es doch total egal was da steht, hauptsache der Kunde kann die Rechnung zuordnen, ist glücklich und zahlt am Ende fristgerecht.   Auch wenn ein fehlendes "-" nicht die Welt ist, bei einem Datenbankabgleich ist PO-123456 ungleich PO123456. Also automatisch nicht zuzuordnen. Und wenn da nur Sonderzeichen drin sind, kann das Datev absolut egal sein welche Syntax da verwendet wird. ... Mehr anzeigen

Stellt sich die Frag ob die vermeintliche "Marktmacht" vorgeschoben wird um neue Dinge aufzuzwingen? Wäre ja nicht die erste Firma, die sich dabei massiv überschätzt.   Die Entscheidung E-Rechnung nur in Next umzusetzen und die Vorgabe zum 01.01.2025 dafür zu nutzen die User auf das neue System zu zwingen ist schon sehr sehr schlecht durchdacht.   Es wäre so einfach gewesen, die E-Rechnung auch im alten System einzubauen aber wie bekommt man dann später noch die Kunden dazu auf Next zu wechseln? Dann lieber mit Gewalt. 😄 Bei der Werbung für das neue System und auch beim Übertrag der Daten wurde in keinster Weise daraf hingewiesen, dass dies eine komplette Neuentwicklung ist. Hier fehlt es an allen Ecken und Enden an wichtigen Funktionen die wohl nicht im Pflichtenheft aufgenommen wurden. Oder wurden Punkte aus dem Pflichtenheft gestrichen um zur Geschäftsführung zu sagen "Alles fertig das Produkt ist super, die Kunden können umstellen, danke für meinen Bonus"?   Man wird vor ein Produkt gesetzt, welches unausgereift, fehlerhaft und stark eingeschränkt ist. - Neue Pflichfelder ->ok dann aber den Schmerz nicht auf den User übertragen sondern mit userfreundlicher Anpassungsmöglichkeit. Warum nicht die Möglichkeit geben fehlenden Felder live zu bearbeiten, statt einfach Fehler auszugeben und ins Deadlock zu laufen? - Man kann in der Kundenliste nicht mal mehr nach einzelnen Spalten sortieren um zu sehen ob irgendwo irgendwas fehlt. z.B. wie finde raus ich ob ein Kunde keine Kundennummer hat? Früher gab es dafür Spalten. Diese konnte man schnell sortieren. Die Lösung ist, alles exportieren und extern manuell reparieren und wieder importieren. - Warum muss ich beim einloggen den Zeitfilter immer neu setzten? Antwort von Datev, "Wir sind so toll und bilden dass als besonderes Update mit Cookies ab." Diese sind aber lokal auf dem User-Rechner. Warum nicht im User-Konto? Schonmal was vom löschen von Cookies per Gruppenrichtlinie gehört? - Weiterhin werden Zahlungsbedingungen willkürlich mit Textbausteinen überschrieben. Auch wenn Datev das nicht "manipuliert" nennen möchte, so darf das jeder gerne so nennen wir er will, es ändert nichts am Ergebnis. - Weiterhin sind nur € Rechnungen möglich. Die Welt ist aber größer als der Datev-Tellerrand. Andere Länder nutzen z.B. USD -Weiterhin ist das Formular nur deutsch. Rechnungsnummer statt Invoice-ID. etc. Früher konnte man das im Editor anpassen, warum sollte man User-Orientierte Lösungen anbieten. Das war ja alles schonmal da! Und es wird weiterhin behauptet, alles wäre toll und E-Rechnungskonform. Wenn ich jede Rechnung als PDF speichern und erst im externen PDF Editor verändern muss, hat ist das nicht mehr mit Konform zutun. Aktuell habe ich keine Zeit umzusteigen aber meine eigene Frist läuft bis Januar, dann schaue ich mir andere Lösungen an. ... Mehr anzeigen

Hier sehe ich das gleiche Problem welches @Benjamin_Haehner bereits angesprochen hat. Der Absender muss konfigurierbar sein. Große Firmen mit entsprechend hohen Rechnungseingangs-Volumen lassen nur vordefinierte und freigegebene Rechnungs-Absende-Email Adressen zu. Hier geht es schlicht und ergreifend um Spam-Filterung und unberechtigte nicht freigegebene Lieferanten.   ... Mehr anzeigen

Da die Zeit langsam drängt und wir unter anderem damit rechnen müssen, dass viele essentielle Dinge bis zum Jahreswechsel nicht erledigt sind, möchte ich vorbereitet sein. Für Kunden und Lieferanten gibt es eine Export-Funktion nach CSV (DTVF_kundenPRO.csv) Gibt es so eine Export Möglichkeit auch für Artikel aus Datev in ein standatisiertes Dateiformat? Also sei es dass man von Datev zu Lexware oder ähnlich wechselt? Frage natürlich für nen Freund 🙂   Viele der alternativen Lösungen bieten ja Schnittstellen in Richtung Datev, somit kann der Steuerberater weiterhin mit Datev arbeiten, der User aber aus einer Liste an Lösungen auswählen.   ... Mehr anzeigen

@Thorsten_JedlitzkeIch denke Sie verstehen nicht wo das Problem liegt.   In den Basisdaten werden Zahlungsbedingungen erstellt In den Kundenstammdaten wird dem Kunden ein Zahlungsziel zugewiesen. Dies ist vom Kunden vorgegeben bzw. mit dem Kunden vereinbart. Also nicht in der Zuständigkeit von Datev dies zu manipulieren.   Hier hat man 2 Möglichkeiten: 1. die Felder auf der linken Seite füllen und DATEV generiert mit "aus der Zahlungsbedingung übernehmen" eine Zahlungsbedingung 2. man nutzt das Feld auf der rechten Seite direkt und legt diese selber an.     Hinterlege ich beim Kunden nun diese Zahlungsbedingung Nr. 101 und erstelle einen Beleg werden direkt 3 Dinge verändert also folglich manipuliert.   Als ersten erfindet DATEV einen Text, der nirgends konfigurierbar ist mit dem Inhalt: "Bitte beachten Sie unsere Zahlungsbedingungen:"   Dann wird die in der Zahlungsbedingung hinterlegte Bezeichnung ignoriert und mit dem folgenden Inhalt ersetzt: "Ohne Abzug"   und als drittes wird ohne dass dieses gewünscht, ausgewählt oder konfiguriertbar ist einfach ausgerechnet und ausgewiesen "11.10.2024"   So sieht das dann aus: Der 11.10. ist hier aber einfach faktisch falsch, wenn die Rechnung erst 1-3 Tage nach Erstellung beim Kundne eintrifft.   Sie pochen so auf die einfache Matematik dahinter. Schön dass sich jemand eine Wenn-Dann Funktion ausgedacht hat aber das ist am Kunden vorbei, solche Automatiken umzusetzen ohne diese konfigurierbar zu machen.   Ich spreche nicht von unterschiedlichen Logiken bei EU oder nicht EU Kunden die unter Umständen auch Einfluss auf brutto/netto haben. Es geht um die Zahlungskondition auf der Rechnung, welche schon durch ausrechnen unter schlichtweg nicht mehr korrekt sind.   Selbst wenn ich eine Zahlungskondition vereinbare die lautet  "Nach dem 5ten Sonnenuntergang" so muss das auch so auf der Rechnung stehen. Dieses Beispiel mag heißen, dass es kaufmännisch "5 Tage netto" bedeutet aber wer gibt Datev das recht das manipuliert wiederzugeben? Datev darf da nicht manipulieren und einfach ungefragt irgendwelche Werte in Texte konvertieren, irgendwelche Summe oder Termine errechnen.   Wenn es Skonto gibt oder sogar noch mehrere Skonti, wir das ja immer schlimmer. Dann steht da sogar nen Aufsatz. Auftrag auf Kunden mit Zahlungsbedingung 320:   Sieht dann so aus: Für Datev kaufmännisch ausreichend und auch mit dem Kunden vereinbart wäre es: 30 days 5% 45 days 3% 60 days net   Ich will Datev nicht schlecht reden aber mit als Lieferant ist es doch total egal was da steht. Hauptsache der Kunde ist zufrieden und die Rechnung wird bezahlt. In Auftragswesen old war das problemlos so umgesetzt. Es wurde ganz simpel das dargestellt was auch in den Stammdaten in der Bezeichnung stand und alle waren glücklich. Wäre interessant zu erfahren wer sich überhaupt ausgedacht hat, das so manipuliert umzusetzen? Das war doch nie im Leben ein User-Request!   ... Mehr anzeigen

Hi@Thorsten_Jedlitzke    ich hoffe dieser Hinweis soll nur ein Not-Work-Around sein.   Allerdings wissen wir, dass mit der Zahlungsbedingung gerne auch die Informationen zur Zahlungsart (insbesondere Lastschriften) in der Rechnung aufgenommen wurden. ... Die Zahlungsbedingungen aus Auftragswesen online können Sie aber in Auftragswesen next nachbilden, indem Sie Textbausteine erstellen, die Sie beispielsweise als Abschlusstext in die Rechnung aufnehmen. Das hat mit weitere Informationen nichts zu tun. Die Zahlungsbedingungen sind ja zwischen Kunde und Lieferant ausgehandelte Bedingungen. Das was Datev macht ist manupulation der Daten.   1. Darf Datev diese nicht einfach ändern. Auch wenn das ausgerechnete Werte sind, so weicht das von den verhandelten Konditionen ab. Diese sind nunmal "10 Days net" oder so und nicht irgendein DEUTSCHER Text. Und vor allem weicht das von dem ab, was der Rechnungsersteller eingestellt bzw. gewählt hat. Somit faktisch falsch.   2. große Firmen rechnen grundsätzlich das Zahlungsziel ab Eingang der Ware bzw der Rechnung. Wenn wir also "10 days net" vereinbart haben, gilt nicht das Rechnungsdatum, welches Datev nutzt und erst recht nicht irgendein ausgerechneter Wert den Datev sich da zusammen sammelt. Auch wenn zwischen Rechnungsdatum und Rechnungseingangsdatum beim Kunden nicht die mega differenz ist, so ist das nicht automatisch das gleiche Datum.   3. Wenn schon irgendwelche Daten von Datev manipuliert werden, so muss das wenigsten Konfigurierbar sein, also ob man das möchte und wenn ja in welcher Sprache das überschrieben wird. Hierfür gab es ja bisher die Mögichkeit mehrere Zahlungsbedingungen anzulegen.   4. Gibt es in meinem Fall jeweils doppelte Zahlungsbedingungen, also 1x deutsch und 1x englisch. Jeweils beim Kunden hinterlegt, weil im normalfall fest mit dem Kunden vereinbart. Ein Textfeld zu missbrauchen ist eine Art Workaround aber das ist dann wieder ein Feld welches bei jedem Auftrag manuell ausgewählt bzw. manuell angepasst werden muss bzw. auch erstmal im Kundenstamm nachgesehen und dann im Auftrag angepasst werden muss. Manuelle Arbeit und dann die Frage wo das dann in der E-Rechnung steht und ob der Kunde dass dann überhaupt ausliest bzw. auswetet beim Einlesen der Rechnung. Die Felder müssen ja gemappt sein und wenn andere Lieferanten das im dafür vorgesehenen Feld übertragen, muss ich als Lieferant also erwarten, dass der Kunde das im Mapping extra für mich anpasst? Versuchen Sie mal einem großen Konzen beizubringen, dass extra für sie etwas angepasst werden muss. Das sieht im echten Leben genau andersrum aus.   Wäre ja auch Sinnlos, im Backend div. Zahlungsbedingungen zu pflegen, wenn diese dann von Datev konsequent ignoriert werden. Gleiches gilt für den Summen-Block auf der Rechnung und auch alle anderen Felder wie der Info-Block mit Rechnungsnummer etc.. Hier merkt man die sehr sehr strak auf deutsche Kunden fokusierte Denkweise von Datev. Hier müsste mal über den Tellerrand geschaut werden.   So wie Datev das ganze Tool hier umsetzt, bekommt man das Gefühl, dass Datev den Nutzer erziehen möchte, bzw. mit Nachdruck in Prozesse drängen möchte. Dabei ist das ganze nur ein Rechnungs-Tool. Nichts womit der User Geld verdient. Aktuell ist Datev nicht in der Lage konforme Rechnungen zu erstellen, erst recht nicht E-Rechungen. Hier muss dringend bis ende des Jahres nachgearbeitet werden.   Manuelle Nacharbeit in der PDF ist und bleibt hier ein Muss und führt zu Unstimmigkeiten mit der E-Rechnungs-Version.   Freundliche Grüße ... Mehr anzeigen

Dieses automatische Berechnen gab es glaube ich früher nicht. Aber auch wenn, dann muss man das ausschaltbar machen. Im alten System wurde einfach genau das übernommen was in der Bedingung stand. ... Mehr anzeigen

Hier noch ein Beispiel was aus der damals gut funktionierenden Zahlungsbedingung geworden ist: Die Felder können eingestellt werden, die Bezeichnung frei gewählt. Aber das wir dann einfach komplett ignoriert. Auf dem Beleg taucht weder die Bezeichnung auf, noch haben ich irgendwo gesagt, dass die Zahlung ausgerechnet werden soll. Wer hat sich denn so nen Schwachsinn ausgedacht? Wo kommt dieses: "Bitte beachten Sie unsere Zahlungsbedingung: " her und warum wird ein nicht DE-Kunde mit so nem Textbaustein voller Zahlen und nicht verständlicher Aufzählungen konfrontiert. Die eingestellte Bezeichnung ist so einfach zu verstehen. Muss man das dem Kunden kompliziert vorrechnen? Und warum kann ich das nicht ausschalten?   Aus:     Wird: ... Mehr anzeigen

Neues Problem bei der Auftragsabwicklung festgestellt 🙂 Bei der Rechnungserstellung gibt es das Feld "Kunden Bestellnummer". Dieses war früher in Auftragswesen (nicht Next) ein freies Text-Feld. Jetzt gibt es einen Syntax-Check und es sind keine Sonderzeichen und vorallem keine Leerzeichen mehr erlaubt.   Bei der Erfassung von neuen Rechnungen ist das schon doof aber handlebar. Wobei ich mich frage warum es bei einem vom Kunden vorgegebenen Inhalt einen Syntax-Check geben sollte?   Aufgefallen ist das nun, da ich eine Rechnung aus Zeiten vor "Next" stornieren wollte und der Stornierungsporzess fehlschlägt, allerdings ohne Meldung des echten Grundes. Erst durch die Funktion "Beleg weiterführen" wird die Rechnung wieder geöffnet und beim anschließenden Speichern wird man auf den fragwürdigen Syntax-Fehler hingewiesen.   Also kurz zusammengefasst, der Syntaxcheck macht in vom Kunden vorgegebenen Feldern absolut keinen Sinn und muss unbedigt freigegeben werden. Mir ist doch egal was da drin steht, hauptsache der Kunde kann die Rechnung (am besten automatisiert) zuordnen. ... Mehr anzeigen

Sowas könnte bestimmt programmiert werden aber wenn dann erst in 2025 oder 2026 Typisch Datev wäre aber keine Daten raus zu geben ... Mehr anzeigen

ich kann nur für mich sprechen, ich hatte vorher Auftragswesen *old* und nach dem Wechsel auf Next fehlt mir einiges was vorher da war. meine Erwartung nach dem „ihr müsst alles bis Dezember wechseln“ waren selbstverständlich, dass alles wie vorher geht. Aber es fehlt halt einiges, was jetzt hoffentlich kurzfristig kommt.   hätte ich das vorher gewusst, hätte ich erst viel später den Wechsel. so bin ich jetzt unfreiwilliger Beta-Tester und kann nicht mehr zurück. ... Mehr anzeigen

Ob ich da etwas unter laufe, und wie kritisch diese Änderungen sind, kann man, ohne ein Beispiel gesehen zu haben, nicht beurteilen. Keine Sorge, das ist alles abgestimmt. 👍 ... Mehr anzeigen