Hallo,
unsere Mandanten senden uns ihre Kassenerfassungen per E-Mail zu. Diese Datei öffnen wir und kopieren die Spalten mit deren Inhalte und fügen Sie in unsere gespeicherte Datei ein. Jedoch wenn ich es so mache, werden aus welchen Gründen auch immer, die Tabellenlinien nicht mit kopiert. Bei der vorherigen Version konnte ich durch Rechtsklick - Zellen formatieren die Tabellenlinien wieder einfügen. Bei der neuen Version 3.0 benötige ich ein Kennwort; wie kann ich das umgehen?
Vielen Dank für eure Hilfe
Warum stellen sie ihren Mandanten nicht die originale Exceltabelle zu Verfügung?
Die Kassenerfassung wurde bei den Mandanten installiert.
Warum müssen sie dann die Daten umkopieren?
Besser wäre es, wenn der Mandant direkt die Exportfunktion verwenden würde.
Wir haben es bisher immer so gehandhabt, dass wir die Konten in die Excel-Datei eintragen und dann die Datei exportieren und im REWE einspielen.
Aber warum exportieren Sie es dann nicht aus der Datei des Mandanten?
Wenn ich den Export von Buchungsvorschlägen für Rechnungswesen im DATEV-Format mache, kann ich die Zahlungen nicht mehr aufteilen oder gibt es hierzu eine alternative? Falls es da was gibt, könnte ich es gleich exportieren und im Rechnungswesen auseinanderteilen, falls ein Belege zb. 7 % und 19 % Ausgaben hat.
Hallo Herr Brandl,
es gibt in Kanzlei-Rechnungswesen eine Aufteilungsfunktion, die genau für solche Rechnungen und Belege bestimmt ist. Unter der Buchungszeile finden Sie ganz links einen Link "Aufteilung starten".
Viele Grüße,
BF
Vielen Dank für die Info. Jetzt habe ich einfach mal Probezeilen exportiert und bin auf Aufteilung starten gegangen --> folgende Fehlermeldung kommt dann
Welche Export Variante wählt ihr aus?
Lassen Sie mich raten - Sie haben den Stapel über "Mandant ergänzen" >> "Stapelverarbeitung" importiert, oder?
Ich importiere über
Buchungsvorschläge bearbeiten
ASCII-Importieren
dann werde ich gefragt "wollen sie in die Stapelverarbeitung wechseln" bestätige ich mit ja
DATEV-Format
importieren
Hm. OK. Dann weiss ich auch nicht weiter.
Hallo,
beim Datevformat sind Aufteilungsbuchungen nicht möglich, siehe https://www.datev-community.de/message/17831#17831.
Wie schon von anderen geschrieben, lassen Sie sich am besten vom Mandanten die CSV-Exportdateien senden. Oder, wenn's dem Mandanten zu kompliziert ist oder Sie die Kasse zum Abstimmen vor Ort haben möchten, dann einfach monatlich die komplette XLSM-Kassendatei senden lassen.
VG
Alles klar, dann werde ich meine Konten einfach bei der vom Mandanten zur Verfügung gestellten Datei eintragen und dann den Export machen.
Macht ihr dann von jedem Monat eine Speicherung der Excel-Datei auf eurem System oder reicht euch die Eingabe im Kanzlei-Rewe?
Ich speichere es immer noch mit in die DMS-Belege. Ob man das muss, weiß ich nicht. Theoretisch muss ja der Mandant den täglichen Export in Form der PDF mit der angehängten CSV (Tagesbericht) durchführen ...
wenn die gegenkonten nicht im originalen kassenerfassung eingegeben werden und dieses system nur dazu dient, vor zu erfassen, würde ich überlegen, ob ich dem mandanten nicht gleich nur eine excel-tabelle geben würde, weil das programm seinen zweck nicht erfüllt und nicht erfüllen kann.
das diese methode für sich genommen voll an den GoBD vorbei schießt, brauche ich nicht extra zu erwähnen, oder?
mir erschließt sich der sinn nicht, warum das so gemacht wird. es werden doch sämtliche vorgaben nicht eingehalten.
Nun, laut Datev - https://www.datev.de/dnlexom/client/app/index.html#/document/1080608/D1283612299 - mit Zusatzarbeiten ja schon. Und ja, zumindest eine meiner Mandantinnen ist so vorbildlich, und hat mittlerweile ein zugriffsgeschütztes Win10 ...
Bei der neuen Version 3.0 benötige ich ein Kennwort; wie kann ich das umgehen?
Gar nicht (Brute Force vorbehalten). Das ist ja Sinn u. Zweck der 3.0 einschließlich Folgeversionen.
Bis mir jemand hier glaubhaft das Gegenteil darlegt (noch nicht geschehen), halte ich die 3.0ff immer noch für voll GoBD-konform (mit vernünftigem DaSi-Konzept). Daher sollte man, wenn man den Mand. schon damit ausstattet auch alle diesbezüglich wichtigen Funktionen (Export-, Festschreibe-, Doku-Funktionen) nutzen.
Die DATEV verspricht keine vollständige Konformität mit der GOBD, da es viele Stimmen auf Seite von verschiedneen FA's bzw. Ministerien gibt, welche Office-Dateien per se als nicht konform betrachten.
Die DATEV verspricht keine vollständige Konformität mit der GOBD, da es viele Stimmen auf Seite von verschiedneen FA's bzw. Ministerien gibt, welche Office-Dateien per se als nicht konform betrachten.
Die GoBD erlauben, wie oben schon erwähnt, durchaus explizit die Nutzung von Office-Dateien (Verfahrensdok. + DaSi-Konzept).
Was die 3.0ff anbetrifft, werde ich mit Sicherheit in absehbarer Zeit jedem Prüfer (der zweifelt) erklären können, dass Manipulationen nur mit sehr sehr viel Aufwand u. krimineller Energie durchführbar sind
Meine Einschätzungen diesbezüglich sind identisch mit denen der Datev (mit der Entwicklung besprochen).
Die DATEV verspricht keine vollständige Konformität mit der GOBD, da es viele Stimmen auf Seite von verschiedneen FA's bzw. Ministerien gibt, welche Office-Dateien per se als nicht konform betrachten.
die stimmen von FAs und Ministerien, die dieses Monstrum eingeführt haben (und den Praxiswert nicht vorher getestet haben) haben zwar ein Ideal an Idee eingebracht, meiner Meinung nach ist es aber bei diesen Personen eher der Trend, dass so lange ALLES nicht konform ist, bis das Bargeld endgültig abgeschafft und jede Person mit einem Chip im Arm herumläuft.
Man kann definitiv nicht alles kriminelle ausschalten. Zumal diese Herrschaften immer einen Schritt voraus sind.
die stimmen von FAs und Ministerien, die dieses Monstrum eingeführt haben (und den Praxiswert nicht vorher getestet haben) haben zwar ein Ideal an Idee eingebracht, meiner Meinung nach ist es aber bei diesen Personen eher der Trend, dass so lange ALLES nicht konform ist, bis das Bargeld endgültig abgeschafft und jede Person mit einem Chip im Arm herumläuft.
Diesen Trend sehe ich auch, keine Frage. In den GoBD manifestiert er sich allerdings nicht. Die GoBD sind 'weich'. Ob dies aufgrund von IT-Vorgaben (bspw. BSI) u. Umsatzbarkeit, Lobbyarbeit oder politischen Prämissen so formuliert wurde, vermag ich nicht zu beurteilen.
Es wäre ein leichtes gewesen, sie 'kugelsicher' zu machen - bspw. vorgegebene Hashroutinen + Uploadmöglichkeit / Uploadverpflichtung. Ich denke dies war aber nicht gewollt.
Man kann definitiv nicht alles kriminelle ausschalten. Zumal diese Herrschaften immer einen Schritt voraus sind.
Sicher ist das. Hier wird über Insika diskutiert. Die Damen u. Herren die sich seit Jahren schon erfolgreich professionell mit der Manipulation von Smartcards u. dergleichen beschäftigen, lachen sich darüber schlapp. U. planen das nächste lukrative Geschäftsfeld
Mal ganz abgesehen von den großen Bösewichten, die, selbst wenn sie zur Rechenschaft gezogen werden, kaum ein Jahr hinter den Schwedischen verbringen und sich danach an genau die gleiche Position setzen, an der sie vorher waren ...
Betroffen sind ja vor allem die KMUs, die nicht schon ohnehin (wie die Größeren) aus betriebsinternen Gründen über technische Kontrollmechanismen verfügen. Sie haben zumeist weder das Wissen derartige Manipulationen auf technischer Ebene vorzunehmen, noch die Mittel, dieses Wissen einzukaufen. Leider haben sie aber ebenso oft ebenso wenig das Wissen und die Mittel, Sicherungsmaßnahmen einzuleiten gegen: (mögliche) Manipulationen, für die sie weder das Wissen noch die Mittel haben
Leider haben sie aber ebenso oft ebenso wenig das Wissen und die Mittel, Sicherungsmaßnahmen einzuleiten gegen: (mögliche) Manipulationen, für die sie weder das Wissen noch die Mittel haben
Naja, ich fahre ein altes Schmuckstück, bei dem man für den Tacho noch den Schraubenzieher rausholen müsste (um die € 25, können aber wahrscheinlich nur noch die alten Hasen).
Die Geschichte mit den Smartcards (mind. 3 bei 'Premium-Modellen') haben alle drauf.
Wird auch bei Kassen so sein. dafür leg ich n Fuffi ins Glas!