Datev hat Schwierigkeiten beim Drucken mehrseitiger Rechnungen

[#1]

Liebe Datev,

wann ist damit zu rechnen, dass wir, trotz der Verwendung von Grafiken unter 1MB, endlich problemlos Rechnungen mit vier oder 5 Seiten drucken können?

Liebe Kollegen,

der Entwickler sagte mir damals, wir würden zu ganz wenigen gehören, die dieses Problem haben, weil unsere Grafiken (zwei- oder dreistelliger KB-Bereich) so groß seien und das sich mit jeder weiteren Seite potenzieren würde, so dass bei 4 Seiten unser Hauptspeicher (ich glaube 12 oder 16 GB) nicht mehr ausreichen würde.

Wer hat hier noch Probleme?

Beste Grüße

Tobias Heinrich

[#2]

Mit welchem EO-Programm arbeiten Sie?

[#3]

classic.

Es hat sich damals extra ein Entwickler eingeschaltet und wir haben unsere Grafiken zumindest so klein gewandelt (teilweise auch Typ-Wandlung), dass wir nun 3 Seiten meistens drucken können.

Ich ärgere mich heute noch über die Erklärung, dass sei so ganz normal und wir sollendoch Verständnis haben. 

Die Datev hat ein eigenes Tool zum Rechnungen drucken geschrieben und das m.E. einfach total verbockt. Und statt das zuzugeben, wird erklärt, unsere Ansprüche seien zu hoch.

ganz ehrlich, da ziehe ich mir irgendeinen Studienabbrecher Informatik heran und bin mir sicher, der ist in der Lage ein PDF mit Grafiken und mehr als 3 Seiten zu fabrizieren!

Sorry, aber das ist ein Thema das uns selten trifft aber es ist echt eine Klatsche ins Gesicht, wie abhängig wir davon sind, dass Datev sich dazu herablässt, etwas als Fehler bzw. als erforderlich zu betrachten...

[#4]

EO eben. Uralter Code, wird auch nichts mehr gepflegt.

Einfach hier mal hartnäckig bleiben und den Beitrag immer mal wieder nach oben "schieben". Es gibt bestimmt Cracks die eine Lösung aufzeigen können. 

Haben Sie mal versucht, die Rechnungen "nur" als PDF auszugeben? Nein, das soll keine endgültige Lösung darstellen....

Der "Entwickler" kann da sicherlich nichts für. Die "Entwickler, die die EO-Reihe" "entwickelt haben, dürften so langsam alle in Pension sein. 

Gleichwohl ist die Aussage schon ein wenig "frech".

Viele Erfolg!

[#5]

Die PDF-Ausgabe im Druck ist ja das Problem. Auf dem Drucker kommt es raus, aber das PDF wird nicht angelegt und: Es wird keine Buchung erzeugt und: die Rechnung hängt als fehlerhaft im System.

Und die Rechnungsschreibung wurde gerade (also vor 1 oder 2 Jahren) neu gemacht...

aber danke, ja ich bleibe dran...

[#6]

Die "neue" Rechnungsdruck-Komponente ist aber noch "recht" neu. Sie sollte alle Probleme der "alten" beheben, hat aber imho viele neue Probleme geschaffen und ist weit weniger flexibel, wie die alte.

[#7]

PDF-Ausdrucke sind immer riesig groß, weil diese als PS-Dateien (Postscript) an den Drucker verschickt werden. Diese PS-Dateien sind im Grunde reiner Ascii-Code und daher riesig groß, da die gesamte PDF-Datei in ASCII codiert wurde.

Eventuell hilft es, wenn Sie die Rechnungen im Format MS-XPS ausdrucken. In Ihrem System sollte es einen Microsoft XPS Document Writer geben.

Gruß Achilleus

----

Nachtrag:

Ich vergaß, dass ja DATEV direkt die PDF-Rechnung erstellt und ins Archiv verschiebt. Da werden Sie wohl keine Chance haben, wenn DATEV sich nicht selbst darum kümmert. Man müsste in Erfahrung bringen, wie DATEV die PDF erstellt. Wird onFly erstellt oder gedruckt? 😕 Nobody knows.

[#8]

---

@tobias_heinrich  schrieb:

Die PDF-Ausgabe im Druck ist ja das Problem. Auf dem Drucker kommt es raus, aber das PDF wird nicht angelegt und: Es wird keine Buchung erzeugt und: die Rechnung hängt als fehlerhaft im System.

Und die Rechnungsschreibung wurde gerade (also vor 1 oder 2 Jahren) neu gemacht...

aber danke, ja ich bleibe dran...

---

Das ist doch eine Aussage, aus der etwas abgeleitet werden kann.

Der eingesetzte Reportgenerator nutzt SkyPDF zum erzeugen der PDF Datei, so weit, so gut. Es ist aber seit einiger Zeit aufgefallen, das die Implementierung gerne mal etwas eigenwillig mit den Zielordnern umgeht. So wir gerne einmal statt in das Verzeichnis "Dokumente" das Verzeichnis "\\Ordnerumleitung\Dokumente" gedruckt. Ebenfalls scheint es bei bestimmten Freigaben statt des geamappten Laufwerks der UNC Pfad zum Zuge zu kommen. Beim UNC Pfad können dann andere Rechte zurückgeliefert werden ohne das die Datei geschrieben werden kann.

Es sollte einmal geforscht werden, wie die Rechte in den beteiligten Verzeichnissen gesetzt sind und diese in der Umgebung eingebunden sind. Besonderes Augenmerk verdienen die Benutzerverzeichnisse wenn Ordnerumleitungen eingerichtet sind oder auch bei servergestützten Profilen. Auch das Verzeichnis "Benutzer\AppData\Local\Temp" sollte einmal untersucht werden.

Auch hier wird mit einer Logodatei gearbeitet die auf allen Seiten der Rechnung gedruckt wird; außer langsam keine Probleme (die Logodatei ist nicht das Problem).

[#9]

Dann gebe ich das ganze einfach nochmal an die Datev.

Würde es Ihnen etwas ausmachen, mir eine Musterrechnung zuzusenden? Damit ich ein Argument habe, dass die bisherigen Aussagen wohl nicht stimmen?

Oder das ich notfalls feststellen kann, dass Ihr Logi soooooo viel kleiner ist als unseres 🙂

Sie arbeiten auch mit EO classic?

Sie drucken erfolgreich auch 4 oder 5 seitige Rechnungen?

Die Lösungsansätze erscheinen mir nur bedingt vielversprechend, da wir ja normalerweise erfolgreich drucken. Bei einem Rechteproblem müsste der Fehler ja auch bei einseitigen Rechnungen auftauchen.

Sobald ich das Feedback habe, kann ich dann einen SK anlegen (bzw. den alten suchen gehen)

Danke!

[#10]

Da es sich ja um ein Speicherproblem handelt, kann ich mir vorstellen, dass es an der Grafik liegt. Sie müssen sich einmal vorstellen, was da alles im Hintergrund passiert.

Hier ein Beispiel einer PDF-Datei aus Word nur mit dem Wort ich.

Größe PDF-Datei: 21 KB  / PS-Datei: 289 KB (retrograd erstellt mit XPDF, da kein PS-Drucker mehr vorhanden)

Spoiler

%!PS-Adobe-3.0
% Produced by xpdf/pdftops 3.02
%%Title: untitled
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%DocumentMedia: plain 612 792 0 () ()
%%BoundingBox: 0 0 612 792
%%Pages: 1
%%EndComments
%%BeginDefaults
%%PageMedia: plain
%%EndDefaults
%%BeginProlog
%%BeginResource: procset xpdf 3.02 0
%%Copyright: Copyright 1996-2007 Glyph & Cog, LLC
/xpdf 75 dict def xpdf begin
% PDF special state
/pdfDictSize 15 def
/pdfSetup {
  3 1 roll 2 array astore
  /setpagedevice where {
    pop 3 dict begin
      /PageSize exch def
      /ImagingBBox null def
      /Policies 1 dict dup begin /PageSize 3 def end def
      { /Duplex true def } if
    currentdict end setpagedevice
  } {
    pop pop
  } ifelse
} def
/pdfStartPage {
  pdfDictSize dict begin
  /pdfFillCS [] def
  /pdfFillXform {} def
  /pdfStrokeCS [] def
  /pdfStrokeXform {} def
  /pdfFill [0] def
  /pdfStroke [0] def
  /pdfFillOP false def
  /pdfStrokeOP false def
  /pdfLastFill false def
  /pdfLastStroke false def
  /pdfTextMat [1 0 0 1 0 0] def
  /pdfFontSize 0 def
  /pdfCharSpacing 0 def
  /pdfTextRender 0 def
  /pdfTextRise 0 def
  /pdfWordSpacing 0 def
  /pdfHorizScaling 1 def
  /pdfTextClipPath [] def
} def
/pdfEndPage { end } def
% PDF color state
/cs { /pdfFillXform exch def dup /pdfFillCS exch def
      setcolorspace } def
/CS { /pdfStrokeXform exch def dup /pdfStrokeCS exch def
      setcolorspace } def
/sc { pdfLastFill not { pdfFillCS setcolorspace } if
      dup /pdfFill exch def aload pop pdfFillXform setcolor
     /pdfLastFill true def /pdfLastStroke false def } def
/SC { pdfLastStroke not { pdfStrokeCS setcolorspace } if
      dup /pdfStroke exch def aload pop pdfStrokeXform setcolor
     /pdfLastStroke true def /pdfLastFill false def } def
/op { /pdfFillOP exch def
      pdfLastFill { pdfFillOP setoverprint } if } def
/OP { /pdfStrokeOP exch def
      pdfLastStroke { pdfStrokeOP setoverprint } if } def


[Snip]


Q
showpage
%%PageTrailer
pdfEndPage
%%Trailer
end
%%DocumentSuppliedResources:
%%+ font NCJNBO+ArialMT
%%EOF

Und jetzt stellen Sie sich vor, was passiert, wenn eine Grafik in Form, Größe, Farbe und Auflösung, dargestellt werden muss. Dann kommen ganz schnell zig MB zusammen. Ich weiß auch nicht, ob die PDF-Erstellung wirklich optimiert erfolgt.

Früher hatte ich ein Tool programmiert, mit dem man PS-Ausdrucke (physikalischer Druck auf die Festplatte) mit Ghostscript/FreeePDF in eine PDF-Datei umwandeln konnte. Daher habe ich mich auch eingehend mit dem Zusammenspiel von PS und PDF beschäftigt.

Aber letztendlich kann hier eh nur die DATEV helfen, da nur die wissen, wie genau die PDF-Datei erstellt wird.

Gruß Achilleus

[#11]

Ganz ehrlich: Ne, ich muss mir nicht vorstellen was passiert, wen da eine Grafik dazu kommt.

hunderte, wenn nicht tausende andere Software-Lösungen schaffen es, ein PDF mit ein paar Grafiken zu drucken, da habe ich kein Verständnis dafür, wenn Datev hier voll scheitert.

Dann ist der Weg über PS vielleicht der falsche... aber Datev schafft es ja zeitgleich unsere Word-Dateien als notfalls auch 6-seitige PDF zu drucken (Versand als E-Mail)

[#12]

@tobias_heinrich, meine Logo Date ist als jpg mal gerade 700 KB klein. Sämtliche Textbestandteile habe ich mit der verwendeten Schrift als reinen Text in das Rechnungsformular eingebaut, der Font ist delbstverständlich gekauft. Dadurch wird das Design überall nutzbar und universell einsetzbar.

Falls dann alle Stricke reissen kann ich auch noch mit Druckeroverlay arbeiten, das sit hier ja nicht notwendig.

In Ihrer Situation sollten Sie einmal den Druckertreiber prüfen und evtl. auf eine neue Version heben, es gibt bei DATEV gelegentlich Probleme mit den PCL Versionen, die Version 5 geht immer. Meine Rechnungen drucke ich im Übrigen auf PS aus, das liegt aber an der Farbverwaltung des Druckers, die Farben kamen (neuer Treiber hat das Problem beseitigt) einfach besser heraus. Der Rest ist dann Gewohnheit. Die erzeugten PDF sind recht kompakt, je nach Seitenzahl 70 - 300 kb.

Da ich meine Berichte aus dem Auskunftssystem auch gerne mit meinem Logo verziere kommen da auch schon mal 20 Seiten raus, ohne Probleme und nicht übermäßig groß wenn das PDF Format gewählt ist.

Testweise würde ich auch einmal einen anderen PDF Drucker (auch gerne den Windows XPS) versuchen.

[#13]

Vielen Dank, mit dieser Info werde ich den SK reaktivieren. Wir haben uns wie gesagt auch unter 1 MB bewegt...

[#14]

Hallo tobias_heinrich,

da es sich in diesem Fall um eine komplexe Thematik handelt und diese auch bereits bei uns im Service und der Entwicklung bearbeitet wurde, macht es auf jeden Fall Sinn den Servicekontakt wieder zu öffnen und zur Prüfung zu uns senden.

Dafür an dieser Stelle vielen Dank.

Viele Grüße

Pia Auerochs-Rehlinger

[#15]

Liebe Pia Auerochs-Rehlinger,

das habe ich nun getan, allerdings ist das leider ein Musterbeispiel dafür, wie der Anwender oftmals bei der Datev behandelt wird und auch dafür, dass das Ticket-System der Datev subobtimal ist.

Wir hätten ad 1 damals nicht so abgespeist werden dürfen und ad 2 mittlerweile kontaktiert werden müssen, wenn das ein Thema in der Entwicklung ist.

Trotzdem: Danke!

Es ist halt traurig, Service-Kontakte über ein Forum besser angeschoben zu bekommen als auf dem vorgesehenen Weg (siehe auch das Thema mit dem Kontextmenü)

Viele Grüße

Tobias Heinrich

[#16]

---

@tobias_heinrich  schrieb:

....

Es ist halt traurig, Service-Kontakte über ein Forum besser angeschoben zu bekommen als auf dem vorgesehenen Weg (siehe auch das Thema mit dem Kontextmenü)

---

Man wundert sich dann schon über die Prioritäten mittlerweile, oder?

Aber so haben eben viele Nutzer fortan eine Handlungsvorgabe bei ähnlichen Problemen.

In Ihrem Fall dann leider allerdings ein SK zum Ende der Community-Diskussion....

Bitte lassen Sie uns dann mal wissen, wie es letztendlich ausgegangen ist. Denn das ist sicherlich auch förderlich für viele andere mit diesem evtl. auftretenden Problem....

[#17]

Meine Meinung: Das ganze Rechnungsprogramm ist eine Katastrophe. Vom schreiben bis hin zum Drucken. Das müsste echt langsam mal überarbeitet werden. 

[#18]

---

@Gelöschter Nutzer  schrieb:

Meine Meinung: Das ganze Rechnungsprogramm ist eine Katastrophe. Vom schreiben bis hin zum Drucken. Das müsste echt langsam mal überarbeitet werden. 

---

Was wäre es Ihnen denn Wert, wenn ein Anbieter mit einer schönen Lösung "um die Ecke" kommt?

Siegt die Bequemlichkeit des "alles aus einer Hand" oder der Mut eine saubere und individualisierbare Lösung mit Schnittstelle dazuzukaufen?

Solange die Anwender die 2. Frage mit "Ja" beantworten wird DATEV keine Veranlassung haben an dem Zustand etwas zu ändern.

[#19]

---

@Gelöschter Nutzer  schrieb:

Meine Meinung: Das ganze Rechnungsprogramm ist eine Katastrophe. Vom schreiben bis hin zum Drucken. Das müsste echt langsam mal überarbeitet werden. 

---

@Gelöschter Nutzer 

Es gibt einen Lichtblick: "KMnext"

Aber bis dahin...

Und: letztendlich kann man Rechnungen schreiben, die 95 %  der Anforderungen abdecken. Wenn nicht sogar noch mehr. Zumindest stimmt der Support. 

Man darf hoffen, ob der Nachfolger der EO-Programme dann auch eine Lebenszyklus von > 20 Jahren hat. Das bleibt spannend.....zumal ja niemand weiß, wann der neue Lebenszyklus beginnt...

[#20]

---

@einmalnoch  schrieb:

...

Was wäre es Ihnen denn Wert, wenn ein Anbieter mit einer schönen Lösung "um die Ecke" kommt?

Siegt die Bequemlichkeit des "alles aus einer Hand" oder der Mut eine saubere und individualisierbare Lösung mit Schnittstelle dazuzukaufen?

...

---

ich bin sicher , dass Viele auf Alternativlösungen ausweichen würden, wenn .... ja wenn man nur wüsste, ob es sowas gibt.

Dieses 'Fremdgehen' scheitert am Kennenlernen 

Bei Datev wird man keine Tipps erhalten, Kollegen sind i.d.R. ebenfalls voll in der Datev-Spur. Die Konkurrenten der Datev wollen den Kunden am liebsten komplett übernehmen und nicht nur 'zuarbeiten'.

Mir selbst wäre es sehr sympathisch, nur die Kernanwendungen (REWE, LOHN, STEUERN) von Datev einzusetzen und das ganze Drumherum inkl. Eigenorganisation, DMS, Rechnungsschreibung, Kommunikation usw. mit raffinierten, bewährten, professionellen, spezialisierten Produkten anderer Hersteller, natürlich nicht mehrgleisig, sondern Hand in Hand mit den Datev-Anwendungen über funktionierende bidirektionale Schnittstellen.

Sozusagen Software-Polyamorie in der Steuerkanzlei 😊

[#21]

---

@vogtsburger  schrieb:

---

Mir selbst wäre es sehr sympathisch, nur die Kernanwendungen (REWE, LOHN, STEUERN) von Datev einzusetzen und das ganze Drumherum inkl. Eigenorganisation, DMS, Rechnungsschreibung, Kommunikation usw. mit raffinierten, bewährten, professionellen, spezialisierten Produkten anderer Hersteller, natürlich nicht mehrgleisig, sondern Hand in Hand mit den Datev-Anwendungen über funktionierende bidirektionale Schnittstellen.

Sozusagen Software-Polyamorie in der Steuerkanzlei 😊

---

Viel Spass dabei! Vor allem bei den "professionellen, spezialisierten Produkten anderer Hersteller". Welche meinen Sie die konkret?

Allein der Gedanke an den Datenaustausch mit anderen "professionellen, spezialisierten Produkten anderer Hersteller" bereitet da schon Kopfzerbrechen.

Lustig wird es zudem, wenn "professionelle, spezialisierte Produkte anderer Hersteller" schon in der "Cloud" sind und die profanen Gegenstandswerte der DATEV-Kernanwendung dann z.B. an die "professionellen, spezialisierten Produkte anderer Hersteller" weitergegeben werden sollen. Hossa!

Und dann haben Sie in einer IT-Umgebung die "professionellen, spezialisierten Produkten anderer Hersteller" und in der anderen IT-Umgebung dann die DATEV-Kernanwendungen. Vielleicht dann Cloudübergreifen?

Da fällt mir das Sprichwort mit den vielen Köchen und der Suppe ein....

Nur zu, nur Mut. Bitte gern dann konkrete Erfahrungen. Dafür ist das hier der richtige Ort!

[#22]

es ist kein Geheimnis, dass die Kernkompetenzen der DATEV bei Rechnungswesen, Steuerprogrammen und Lohnabrechnungen liegen.

Es ist auch kein Geheimnis, dass es in der Datev-Welt auch Anwendungen gibt, die als Einzelanwendungen auf dem Software-Markt nicht 'überlebensfähig' wären.

Welches Unternehmen würde z.B. freiwillig "Datev Auftragswesen" einsetzen ?

Die einzige Motivation, "Datev Auftragswesen" einzusetzen, ist wohl die Hoffnung, dass man 'alles aus einer Hand' bekommt und dass die Daten gleich dort 'landen' wo sie weiterverarbeitet werden.

... als Datev-Kanzlei muss man wohl oder übel mehrere Kröten schlucken, die das "Menü" teilweise ungenießbar machen (um bei Ihrer Analogie mit den Köchen zu bleiben).

Übrigens, es sollen ja nicht mehrere Köche an einem gemeinsamen 'Brei' arbeiten, sondern jeder auf seinem Spezialgebiet, am Amuse Gueule,  an der Suppe, an der Vorspeise, am Fischgericht, am Fleischgericht usw.

... und die Datev wäre dann eben zuständig für das Hauptgericht.

Die übrigen Komponenten des Gourmet-Menüs würden dann nicht alle viel zu stark nach einem bestimmten Gewürz schmecken, nach den (Vorschuss-)Lorbeeren der Datev.

[#23]

@vogtsburger 

Sie sprachen aber von 

"das ganze Drumherum inkl. Eigenorganisation, DMS, Rechnungsschreibung, Kommunikation usw. mit raffinierten, bewährten, professionellen, spezialisierten Produkten anderer Hersteller,... "

beschränken sich nun aber auf auf das "DATEV-Auftragswesen".

Es gibt Mandanten, die sind sehr zufrieden mit dem "DATEV-Auftragswesen". Und kommen damit prima klar!

Wäre nur von Interesse,  wie Sie das andere konkret bewerkstelligen möchten, also "das ganze Drumherum inkl. Eigenorganisation, DMS, Rechnungsschreibung, Kommunikation usw. mit raffinierten, bewährten, professionellen, spezialisierten Produkten anderer Hersteller,... "

[#24]

Die Schnittstellen gibt es, so z. B. DATEV connect. Dort gibt es auf wundersame Weise tatsächlich Antworten auf Abfragen, die sich sogar sinnvoll verwerten lassen.

Es gilt allerdings, den Mut und das Geld aufzubringen sich zu verändern.

[#25]

---

@einmalnoch  schrieb:

...

Es gilt allerdings, den Mut und das Geld aufzubringen sich zu verändern.

---

Eben. Warum auch. Man ist dann noch mehr von der Technik abhängig, hat immer Anbieter , die bei Fehlfunktionen die Schuld dem anderen zuschieben wollen und werden.

Wer tut sich das an? Vor allem aber, viel interessanter: gibt es denn schon "Pioniere" die sich sowas  antun?

Auf früheren Veranstaltungen der Admin-Workshops gab es Admins aus größeren Kanzleien, die solche Konstellationen einsetzten (SAP als CRM, Rechnungswesen von DATEV).  

Nun ja...

[#26]

---

@andreashofmeister  schrieb:

---

@einmalnoch  schrieb:

...

Es gilt allerdings, den Mut und das Geld aufzubringen sich zu verändern.

---

Eben. Warum auch. Man ist dann noch mehr von der Technik abhängig, hat immer Anbieter , die bei Fehlfunktionen die Schuld dem anderen zuschieben wollen und werden.

Wer tut sich das an? Vor allem aber, viel interessanter: gibt es denn schon "Pioniere" die sich sowas  antun?

Auf früheren Veranstaltungen der Admin-Workshops gab es Admins aus größeren Kanzleien, die solche Konstellationen einsetzten (SAP als CRM, Rechnungswesen von DATEV).  

Nun ja...

---

Gerade bei DMS gibt es sehr starke Tendenzen nicht von classic auf neu umzusteigen und Alternativen einzusetzen. Wenn man aber mit der teilweise schlechten Prformance von DATEV zufrieden ist darf man aber auch nicht meckern.

[#27]

@

---

@einmalnoch  schrieb:

---

erade bei DMS gibt es sehr starke Tendenzen nicht von classic auf neu umzusteigen und Alternativen einzusetzen. Wenn man aber mit der teilweise schlechten Prformance von DATEV zufrieden ist darf man aber auch nicht meckern.

---

Vor allem gibt es Überraschungen bei der Lizenzgebühren.....

[#28]

Hi,

ein wenig "offtoppic", aber

---

Mir selbst wäre es sehr sympathisch, nur die Kernanwendungen (REWE, LOHN, STEUERN) von Datev einzusetzen und das ganze Drumherum inkl. Eigenorganisation, DMS, Rechnungsschreibung, Kommunikation usw. mit raffinierten, bewährten, professionellen, spezialisierten Produkten anderer Hersteller, natürlich nicht mehrgleisig, sondern Hand in Hand mit den Datev-Anwendungen über funktionierende bidirektionale Schnittstellen.

Sozusagen Software-Polyamorie in der Steuerkanzlei 😊

---

Bei meinem vorherigen Arbeitgeber haben wir den Teilbereich DMS bei einem Mitbewerber untergebracht. Klar konnten wir mit Aufwand eine Schnittstelle bauen, damit wir die zentralen Mandantenstammdaten im DMS nutzen konnten. 

Aber der Aufwand ist immens und nicht zu unterschätzen. Und dann mussten Umstände wie "Dokumente im Arbeitsplatz --> nicht möglich", "Ablage von Auswertungen aus Rewe & Co direkt in DMS --> nicht/nur schwer möglich" letztendlich schlucken. 

Das mag auch an der Schnittstellenpolitik der DATEV liegen, wobei da meines Erachtens ein deutliches Umdenken in den letzten Monaten/Jahren eingesetzt hat (connect & connect online). Aber wie schnell soll hier eine Entwicklung stattfinden, ohne dass die "Standard-DATEV-Anwender in Feld-Wald-Wiesen-Kanzlei" plötzlich nichtfunktionierende Anwendungen haben. 

Ganz ehrlich, der Orginalposter hat hier ein Problem, welches x-tausend Kanzleien anscheinend nicht haben. Natürlich Mist, keine Frage. Ob hier aber x-Fremdsysteme tatsächlich nicht auch ein Problem haben, wissen wir nicht. Umfangreiche Logos haben nunmal x-Millionen Pixel und die lassen sich mit keiner Konvertierung weg finden. Die zugrunde liegende Technik ist nun so und muss von allen genutzt werden. 

Zurück zum Problem:

Vielleicht würde es helfen, die Druckausgabe mit Logo (Kanzleibriefbogen) in einen extra PDF-Drucker auszulagern, welcher die kommende Drucke (egal aus welcher Anwendung) als Wasserzeichen einbringt. So erstelle ich meine Rechnungen. Das eigene Briefpapier in EO-comfort einzubasteln war mir einfach zu aufwendig, zumal hier eine Grafikerin Arbeit investiert hat und es keine "Word-Vorlage" gab, die ich ggf. in EO-comfort einpflegen hätte können.

In EO-classic haben wir zudem kein Word, welches die Druckaufbereitung erstellt. 

Also drucke ich aus EO quasi "nackig" auf einen PDF-Drucker (mit SkyPDF als zusätzliches Druckobjekt) der fest eingestellt ein Wasserzeichen hinterlegt hat. Der macht aber keinen Unterschied zwischen Seite 1 und folgenden Seiten (ist halt ein strunz-dämlicher-Drucker...). So hätte die Anwendung EO kein Speicherproblem und der PDF-Drucker packt die Wasserzeichenseite einfach auf jede Seite. 

Nachteil: Digitale Rechnungen mit Kanzlei-Logo gehen dann nicht direkt aus EO. Da muss dann auf das fertige Ergebnis im DMS zurückgegriffen werden (manueller Versand per Mail). Auch die Papierausgabe muss dann aus DMS erfolgen, da nur dort die fertige Druckausgabe ist. 

Aber testen würde ich es allemal...

Grüße

Chr.Ockenfels

[#29]

---

@einmalnoch  schrieb:

Die Schnittstellen gibt es, so z. B. DATEV connect.

...

Es gilt allerdings, den Mut und das Geld aufzubringen sich zu verändern.

---

Solche alternativen Produkte (DMS, Warenwirtschaft, CRM, Banking, Daten-Analyse etc) müssten allerdings schon existieren und bereits funktionieren.

Man will und kann als Kanzlei ja nicht das Rad neu erfinden, sondern will sich mit einem stabilen und verkehrssicheren 'Rad' fortbewegen.

Gibt es denn schon bewährte Produkte, die intensiv und bidirektional mit den Datev-Connect-Schnittstellen arbeiten ?

@tobias_heinrich , 

sorry für das Abschweifen vom eigentlichen 'Hauptproblem' in diesem Thread, dem Logo, das nicht so kann wie es müsste.

Da ich noch nie den Ehrgeiz hatte, im Datev-Rechnungs-Formular unbedingt ein eigenes Logo einzubauen, war ich bisher ahnungslos, welche Probleme es hier geben kann.

Bei anderen Dokumenten, bei denen Text und Grafik überlagert werden muss, nehme ich gerne das Tool "PDFTK", das (per Batch-Datei) die beiden separaten PDFs (Text und Grafik) zu einem einzigen PDF zusammenführt. 

[#30]

Danke 🙂 alles gut...

Wir haben nunmal unsere Briefköpfe neu designed und jetzt ist ein Logo drauf. Nix dolles, aber eben unser Name in einer bestimmten Schrift und Farbe...

Bin mal gespannt was aus dem wiedereröffneten SK wird...