@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

Da stimme ich vollkommen zu, solange AW Next nicht alles kann was der alte konnte, ich aber nicht mehr zurück wechseln kann, habe ich keine andere Wahl. Also entweder warten und hoffen oder wechseln. Das entscheidet sich dann Anfang des Jahres. ... Mehr anzeigen

Naja, das Problem von Auftragswesen Next ist ja dass damals bei Auftragswesen (ohne next) das Plichtenheft klar war und alles gepasst hat.   Durch die Pflichtumstellung ist das alles nicht mehr gegeben. Meine für mich fehlenden Funktionen waren im alten Programm nicht perfekt aber durchaus ok.   jetzt darf ich jede Rechnung nachträglich per Pdf-writer anpassen.  das zum Thema E-Rechnung, gobd und zugferd. Manuelle nervige Arbeit von dessen Ergebnis Datev nichts mitbekommt.   ich weiß ich hätte bis Dezember warten können aber ende des Jahres habe ich anderes zutun als mich mit so ner Umstellung rumzuschagen.   mein Plan ist es das jetzt erstmal auszusitzen und Anfang des Jahren neu zu entscheiden. Vielleicht schafft es ja Datev bis Dezember alles was auftragswesen (old) schon lange konnte auch in Next wieder einzubauen. ... Mehr anzeigen

Für solche Fälle gibt es in großen ERP Systemen ja eigentlich eine "Customer Product ID" Also eine interne Artikelnummer, welche dann für Lagerbestand, Auswertung, etc. genutzt wird und dann eine externe Nummer welche auf den Belegen ausgewiesen wird. Entweder stehen dann beide auf dem Beleg oder wenn gefüllt nur die Customer Product ID mit Fallback auf die interne. Da das den Rahmen von Datevs System hier sprengen würde, wäre eine Freigabe der Artikelnummer wohl der einfachste Workaround. ... Mehr anzeigen

Gleich das nächste: Neue Rechnung -> Auswahl eines Kunden -> Der Auftrag ist aber von einer anderen Kontaktperson ausgelöst worden, hierfür konnte man vorher im Kundenfeld einfach die Kundendaten ändern und man wurde gefragt, ob diese in die Stammdaten übernommen werden sollen. Das Menü gibts nicht mehr. Nach Auswahl des Kunden sind die Felder grau und man muss Änderungen über den Kundenstamm machen. Hat man jetzt Kunden die regelmäßig bestellen aber unterschiedliche Besteller, muss man den Kundensatz entweder doppelt anlegen oder immer erst vorher bearbeiten. ... Mehr anzeigen

Ne nen externes Tool ist nicht nötig. Aber es wäre einfach schön die Rechnungsnummer vor Fertigstellen/festschreiben der Rechnung zu sehen. Wir generieren die Seriennummer ja selber und binden hierfür die Rechnungsnummer mit ein. Ist einfach ein über Jahre gewachsenes System und man kann kurzfristig die Rechnungsnummer aus der Seriennummer erkennen. Bei Auftragswesen war das möglich, jetzt leider nicht. ... Mehr anzeigen

Heute eine "neue" geänderte Funktion im Next gefunden. Früher wurde bei einer Rechnung vorab eine Rechnungsnummer vergeben. (vor Festschreiben) Diese habe wir unter anderem für die Erstellung der Seriennummer des verkauften Produktes genutzt. Jetzt wird allerdings keine Nummer mehr vergeben, bzw. erst nach Fertigstellung der Rechnung, dann kann natürlich nichts mehr geändert werden um die Seriennummer auf auf der Rechnung auszuweisen. Warum wurde das geändert? Gibt es irgendwo eine Liste mit Änderungen, also welche Bugs sind bekannt, welche Änderungen sind vorgemerkt und bis wann diese so ca. erledigt sind. Oder zumindest ne Liste mit Prios um zu sehen woran gerade gearbeitet wird? ... Mehr anzeigen

Es ist einfach schade, dass diese offensichtlichen fehlenden Funktionen nicht vorher kommuniziert werden. Ich hätte ja noch bis Dezember beim alten bleiben können. Ich habe nun gewechselt und stehe da und muss entscheiden, ob ich jetzt die Rechnungen manuell mit dem PDF Editor einzeln manuell anpasse oder ob ich das Briefpapier mit Extra Werten Fülle um alles das was fehlt zu korrigieren. Beides Widerspricht sich mit E-Rechnungen etc. Da das alles nur Bildinformationen ohne Zusammenfang mit dem echten Feld sind. Aber leider ist ja das Zugferd auch nur wieder typisch Datev und typisch deutsch nur sehr engstirnig umgesetzt. Oder ob ich, da ich jetzt ja es sich jetzt anbietet direkt auf ein komplett anderes Produke setzt. ... Mehr anzeigen

Ja genau, ich habe gestern auf Next umgestellt, der aktuelle Funktionsumfang ist absolut nicht ausreichend. Wir schreiben zu 90% Rechnungen außerhalb DE und somit muss der Kunde verstehen, was wofür steht. Ich selber habe da vermutlich keine Rücksetzungemöglichkeiten oder? Ich werde mit unserem Steuerberater reden. Weiß der Steuerberater direkt was zutun ist oder soll ich irgendwo drauf hinweisen damit die richtige Funktion direkt gefunden wird? Aktuell auf Grund von Urlaub leider erst Montag erreichbar. ... Mehr anzeigen

Es muss dringend die Möglichkeiten geben, selber Einfluss auf die Gestalltung der Belege zu erhalten. 1. wie in meinem separaten Beitrag muss die Sprache der Festen Felder zu ändern sein. Also Invoice ID statt Rechnungsnummer etc. 2. Wer hat sich überlegt, die Zahlungsbedingungen im Text zu überschreiben? Stelle ich einen Kunden auf "8 Tage Netto", so steht in der Rechnung:   "Bitte beachten Sie unsere Zahlungsbedingung: Ohne Abzug bis zum 05.07.2024."   Wo kommt dieser "Bitte beachten..." Text her? Warum wird Ohne Abzug und ein Datum genannt? Was soll denn dieses Zwangsübernetzen ohne dass ich da Einfluss drauf habe? Wenn ich könnte würde ich sofort zurück zu Unternehmen online Ohne NEXT wechseln. Da lief alles. ... Mehr anzeigen