Hab's gerade mit 18.29 getestet, keine Probleme:
Gib 'mal im Hauptteil
\$NEWLINE <epcqr_box="4;\$USER_VAR_GIROCODE_TEXT;\$MANDANT_BANKVERBINDUNG1_BIC;\$MANDANT_BANKVERBINDUNG1_IBAN;\$MANDANT_FIRMA;\$AUFTRAG_BETREFF \$AUFTRAG_VORGANG Nr.: \$AUFTRAG_NUMMER vom \$AUFTRAG_DATUM Kundennummer: \$KUNDEN_NR"></epcqr_box>
ODER:
\$NEWLINE <epcqr_box="4;TESTOMAT;\$MANDANT_BANKVERBINDUNG1_BIC;\$MANDANT_BANKVERBINDUNG1_IBAN;\$MANDANT_FIRMA;\$AUFTRAG_BETREFF \$AUFTRAG_VORGANG Nr.: \$AUFTRAG_NUMMER vom \$AUFTRAG_DATUM Kundennummer: \$KUNDEN_NR"></epcqr_box>
ein.
Es funktioniert derzeit nur bei Rechnungen und Mahnungen und es muss ein Rechnungsbetrag ungleich 0 vorliegen.
Irgendwelche Punkte die ich übersehen habe?
Ohne genauere Angaben dazu, wie Du versucht hast den Girocode in Dein Formular einzubauen, kann man kaum sagen, ob etwas vergessen wurde.
Hast Du die Variable im Objekt "Hauptteil" eingefügt? Oder was für ein Objekt hast Du benutzt?
Hallo zusammen und ein frohes neues Jahr!
Die Variable habe ich in der Druckvorlage einer Rechnung in einer Fußzeile, zusammen mit der Bankverbindung, eingetragen. Das scheint offensichtlich nicht zu funktionieren.
Füge ich die Variable - wie vorgeschlagen - im Hauptteil ein, wird der EPC-QR Code ausgegeben. Das aber nur, wenn ich eine Rechnung erstellt habe und in dieser Ansicht die PDF-Rechnung erstellen lasse (auch in der Vorschau). Im Vorlageneditor wird der EPC-QR Code in der Vorschau NICHT mit angezeigt.
Das wirft bei mir die Frage auf, ob das gewollt ist, und warum die Variable nicht in einem beliebigen Objekt, z.B. einer Fußzeile, ausgegeben wird.
Hat mich jetzt einiges an Zeit und Nerven gekostet, aber vielleicht kann da ja noch etwas nachgearbeitet werden 
.
Danke für die Hinweise. Ich werde es in Kürze testen.
Im Vorlageneditor wird der EPC-QR Code in der Vorschau NICHT mit angezeigt.
Im Vorlageneditor unter "Ausgabe testen" erscheint der QR-Code bei mir-
Meinst Du eine andere Art der Vorschau?
Wie gesagt, bei mir ist der Code auch in der Vorschau.
Auch unter V 19.00 (Bilanz, Portable) wird bei mir der EPC-QR Code auf der Rechnung, in der Rechnungsvorschau und in der Vorschau aus dem Vorlageneditor per "Ausgabe testen" ausgegeben.
Tatsächlich funktionieren der GiroCode als auch die Girocode-Box wohl nur in einem Objekt vom Type "Hauptteil".
Das schränkt die Gestaltung stark ein, weil der Hauptteil üblicherweise die gesamte Breite einnimmt, und wenig Spielraum für eine freie Platzierung der verschiedenen Inhalte lässt.
Dazu kommt, dass bei der Box keine Formatierungs-Tags im Girocode-Text verwendet werden können.
Die Anwendung Quittiert den Versuch mit einem kritischen Java-Fehler fo.inline is not a child of fo.table.
Wenn man die Formatierung (z.B. kleinere Schrift oder Farbe) außerhalb der Girocode-Box setzt, so gelten diese entsprechend für den gesamten Text. Zum Beispiel ist eine Kleinere Schrift ab Zeile 2 so unmöglich bei Verwendung der Girocode-Box.
Sich eine eigene Box zusammenzubauen, scheidet ebenfalls durch die Beschränkung auf den "Hauptteil" aus. Sonst könnte man ja mit Hilfe des Nur-Code Elements etwas basteln.
Durch Ausnutzung eines weiteren Fehlers kann man allerdings etwas Tricksen.
Die Girocode-Box verschiebt die aktuelle Y-Position im Dokument NICHT, wenn man um die Box herum zwei verschachtelte Formatierungsanweisungen gesetzt hatte, wie z.B. <small><color="black"> hier der Boxcode </small></color>
Ein Text, der nach der Box noch kommt, überlagert dann die Box anstatt sich darunter zu setzen.
Auf diese Weise ist es möglich, einfach eine Box mit "leerem" eigenem Text zu erzeugen, un dann den tatsächlich gewünschten Text (fehlerhafterweise) darüber zu legen.
Das ist keineswegs eine dauerhafte Lösung und wird in dem Moment auch das Layout zerstören, wenn hier der eigentliche Bug gefixt werden würde.
Ganz allgemein ist das mit dem QR Code ja ganz nett gemeint, aber leider so ziemlich halbgar.
Auch für entsprechende Lokalisierung des Box-Textes muss man einen ganz schönen Umweg beschreiten, der aber wie dokumentiert funktioniert und deshalb völlig in Ordnung ist.
Hallo reddig.hamburg
danke für Deine für Deine Experimente und die Ausführungen dazu.
Ich verstehe nicht, wie diese dem TE bei seinem Problem "Girocode wird auf Rechnung nicht angezeigt" helfen können, abgesehen davon, dass der Code wie vorgesehen auf der Rechnung erscheint, wenn er gemäß Anleitung eingefügt wird.
Bei neuen/anderen Erkenntnissen oder Kritik, die Du im Forum mitteilen willst, bitte nicht an bestehende Fragestellungen anhängen, wenn die Erkenntnisse dazu keine Hilfe bieten.
Für Kritik und Vorschläge an/zu Programmfunktionen bietet sich das Unterforum Verbesserungsvorschläge an. Vielleicht stellst Du Deinen Beitrag besser dort neu ein und vergibst einen Titel, der Deinem Beitragsinhalt entspricht. Wofür die "Ausnutzung eines weiteren Fehlers" dienlich sein soll habe ich nicht verstanden und könnte bei der Gelegenheit erkennbarer werden.
Taxoloop es ist bedauerlich, dass du den Zweck des Beitrags nicht verstanden hast.
Aus dem Eingangspost war ganz klar erkennbar, dass der Fragesteller den Girocode in einem Objekt "Fußzeile" platzieren wollte.
Ich hätte wohl auch einfach schreiben können "geht nicht", hielt aber eine ausführlichere Ausführung für hilfreicher.
Der beschriebene Fehler erlaubt hier zumindest - wenn auch so nicht vorgesehen - etwas mehr Gestaltungsfreiraum bei der Platzierung des QR Code, zumindest so lange, bis der zu Grunde liegende Programmfehler behoben wird.
PS:
Ich habe leider - so auch hier - häufig den Eindruck, dass ihr vor Lauter Buchhalterdenke den Fokus aufs Wesentliche verliert. Das hier ist ein Forum, und keine Aktenablage. Auch hat in ein "wie vorgesehen [..] erscheint" wenig mit Nutzerfreundlichkeit zu tun. Wenn ein bestimmtes Layout "vorgesehen" ist, dann braucht man keinen Vorlageneditor.
Aus dem Eingangspost war ganz klar erkennbar, dass der Fragesteller den Girocode in einem Objekt "Fußzeile" platzieren wollte.
Richtig ist, dass von der Fußzeile im Eingangspost keine Rede ist. Viel mehr war gefragt, den Girocode überhaupt (irgendwo) auf der Rechnung erscheinen zu lassen. Modular hat es ebenso verstanden, dazu Beispiele geliefert und klar beschrieben "im Hauptteil".
Ich habe erahnt, dass entgegen den Anleitungen nicht der Hauptteil verwendet wurde und extra noch nachgefragt. Siehe #3.
Ab #4 hat Frank erkannt, dass der Hauptteil zu verwenden ist und damit der Code auch auf der Rechnung erscheint.
Füge ich die Variable - wie vorgeschlagen - im Hauptteil ein, wird der EPC-QR Code ausgegeben.
Problem aus #1 gelöst.
In #4 dann ein neues Problem: Der Code erscheint bei Frank nicht in der Vorschau. Allerdings bei anderen Usern schon.
Jetzt taucht auch der Verbesserungswunsch auf, den Code auch in anderen Teilen einsetzen zu wollen.
Grundsätzlich rate ich immer dazu, Verbesserungsvorschläge im entsprechenden Forenbereich unterzubringen und zwar gerade weil solche nebenbei erwähnte Wünsche in anderen Forenbereichen leicht übersehen werden. So war es wohl auch bei diesem Vorschlag.
Warum das nicht genutzt wird verstehe ich nicht.
Das Problem mit der Darstellung in der Vorschau konnte ich nicht nachstellen, weshalb ich darauf nicht weiter eingehen konnte. Auch andere User hatten das Problem nicht und auch Du hast dazu nicht beitragen können/wollen.
Was der Zweck Deines Beitrags ist, habe ich durchaus erkannt. Du möchtest eine flexiblere Platzierung des QR-Codes erreichen und lieferst eine Möglichkeit, die das Programm so eigentlich nicht vorsieht. Dafür habe ich mich bedankt, wenn auch das Problem von Frank mit der Vorschau sich damit nicht lösen lässt. Dass auch die gewünschte Fexibilität der Code-Platzierung nicht sicher/dauerhaft erreicht wird hast Du ja selbst schon angemerkt.
Du hast aber vielleicht den Zweck der Forenaufteilung nicht verstanden. In den Forenbereichen unterhalb "Programm-Menü" sind Hilfestellungen zu den Funktionen des Programms gefragt, so wie die, dass der Code eben im Hauptteil einzusetzen ist. Selbstverständlich sollten bei solchen Hilfen die gegebenen Funktionen des Programms vorrangig genutzt werden. Tricks, die auf Lücken/Fehler im Programm aufbauen, dürften in einem Programm, dass dem User eine korrekte Buchhaltung und korrekte Rechnungsstellungen (samt Dokumentation) ermöglichen soll, eher nicht helfen den Zweck des Programms zu erreichen. Jedenfalls sollten Rechnungen besser nicht mit undokumentierten Mitteln gestaltet werden, da kaum abzusehen ist, wie lange diese funktionieren und welche Konsequenzen der Trick evtl. auf andere Bereiche des Programms hat. Ich denke hier z. B. an die E-Rechnung oder an weitere Vorgaben gemäß GoBD.
vor Lauter Buchhalterdenke den Fokus aufs Wesentliche verliert.
Bitte bedenke, dass das Wesentliche eines Buchhaltungsprogramms seine Möglichkeiten in Bezug auf eine korrekte Buchhaltung sind. Hierzu sind - bei allen Versuchen, eine userfreundliche Umsetzung zu erreichen - zuerst buchhalterische und gesetzliche Vorgaben einzuhalten. Gleiches gilt für die Faktura, bei der die wünschenswerte Flexibilität der Formulargestaltung nicht ohne Rücksicht auf die unterschiedlichen Anforderungen an die damit erstellten Belege zu sehen ist.
Anders gesagt: Userfreundlichkeit oder Gestaltungsmöglichkeiten sind Nice-to-have und nicht das Wesentliche einer Buchhaltungs- oder Fakturalösung.
Das Forum wiederum dient in erster Linie der Hilfestellung zu den gegebenen Programmfunktionen. Die in den Forenbereichen zum Programm-Menü gegebenen Hilfen und Beiträge sollen es den Usern ermöglichen bei Fragen/Problemen zu einem Menüpunkt im Programm unter dem selben Forenbereich ggf. bereits gegebene Antworten/Hilfestellungen zu finden. Wenn man es so nennen will, eine "Aktenablage" der Hilfen zu bestehenden Funktion in Taxpool-Buchhalter.
Wenn ein bestimmtes Layout "vorgesehen" ist, dann braucht man keinen Vorlageneditor.
Dass ein Vorlageneditor das Layout nur in gegebenen Grenzen beeinflussen kann dürfte klar sein. Man braucht ihn trotzdem. Die Nutzerfreundlichkeit von Hinweisen zu Programmfunktionen im entsprechenden Forenbereich liegt insbesondere darin, dass dem Nutzer nur solche Hinweise helfen, die im Programm gegebenen Möglichkeiten anzuwenden, soweit sie auch gegeben sind. Wünsche zu äußern (auch solche die ich nachvollziehen kann) und (auch berechtigte) Kritik am Vorlageeditor helfen dem Nutzer nicht, ein Problem zu lösen. Einzig der Hinweis den Girocode im Hauptteil anzuwenden zeigte die Lösung um den Girocode auf die Rechnung zu bringen.
Ob das Darstellungsproblem in der Vorschau bei Frank noch besteht, weiß ich nicht. Frank hat seither nichts mehr dazu geschrieben. Ich gehe davon aus, es hat sich erledigt.
Für die weiteren Wünsche bitte beachten
Für Kritik und Vorschläge an/zu Programmfunktionen bietet sich das Unterforum Verbesserungsvorschläge an. Vielleicht stellst Du Deinen Beitrag besser dort neu ein und vergibst einen Titel, der Deinem Beitragsinhalt entspricht.
Das ist euer Forum, also bitte nutzt den Input auch bei der Weiterentwicklung!
Machen wir doch - am besten geht es, wenn der Input in den Verbesserungsvorschlägen landet.
Ich kann mich nicht erinnern, in irgendeinem Gesetz oder irgendeiner Norm eine Vorschrift zur Platzierung von QR Codes auf Rechnungen gelesen zu haben.
Und nein, rein technisch betrachtet hätte ein Vorlageneditor so rein gar keine Grenzen, außer die, die vom Entwickler gesteckt werden.
Ich habe die Aufteilung sehr wohl verstanden (es wird ja auch oft genug von euch darauf hingewiesen)
Ich hatte allerdings gar keinen Verbesserungsvorschlag im Sinn, sondern habe lediglich auf einen Beitrag geantwortet. Ob es nun der erste oder vierte Beitrag im Thread war, ist doch völlig unerheblich.
Ich verstehe nicht, warum sich compliance und usability gegenseitig ausschließen müssen.
Im Gegenteil fördert eine gute intuitive Benutzbarkeit sogar die Einhaltung der Richtlinien, denn eine Software kann ja pauschal nicht von sich aus eine Norm einhalten. Die Norm gilt für das, was der Anwender damit tut.
Ich nutze Taxpool tatsächlich auch nach so langer Zeit nur deswegen, weil die Buchhaltungsfunktionen hervorragend sind und das zu einem vernünftigen Preis.
Ich verstehe auch, dass hier der Fokus liegt, und alles andere mehr oder weniger "Beiwerk" ist.
Ich würde mir ja nur wünschen, dass ihr einfach mal ehrlich damit umgeht, und ggf. sogar Dinge lieber gar nicht anstatt halbherzig implementiert.
Eine ordentliche Programmierschnittstelle z.B. würde all dies lösen, denn dann könnte die visuelle Erzeugung der Rechnung ganz bequem extern erledigt werden, von jemandem, der vielleicht weniger von Buchhaltung aber sehr viel mehr von Vorlageneditoren versteht, und ihr hättet jede Menge Zeit gespart.
Ich würde mich unendlich gerne an der Entwicklung von Erweiterungen für Taxpool beteiligen, aber leider geht das (noch) nicht.
Ich wünsche mir als Nutzer mehr Lösung und weniger Rechtfertigung.
Ich kann mich nicht erinnern, in irgendeinem Gesetz oder irgendeiner Norm eine Vorschrift zur Platzierung von QR Codes auf Rechnungen gelesen zu haben.
Ob die Platzierung des QR-Codes gesetzlich geregelt ist oder nicht, war nicht mein Punkt. Eine Rechnung hat mehr als nur gesetzliche Vorgaben umzusetzen. So orientiert sich eine Vorlage zu Belegen z. B. auch daran, dass eine Rechnung ggf. per Post versendet werden kann und folglich ein demnach zweckmäßig gestaltetes Anschriftenfeld möglich sein muss.
Derlei praktische Notwendigkeiten stehen bei einer Vorlage zu Belegen im Vordergrund und daraus entwickelte sich der Vorlageneditor. Ein grenzenloser Vorlageneditor ist daher sicher nicht das Ziel gewesen und die darin enthaltenen Grenzen sind für eine Rechnung und die weiteren in Taxpool zu erstellenden Belege sind dafür nicht nur akzeptabel, sie sorgen teils auch dafür, dass nicht unzweckmäßige Einstellungen vorgenommen werden können. Die Aufteilung in belegtypische Bereiche und nicht etwa grenzenlos mögliches platzieren von Inhalten hilft dem User entsprechende Vorlagen zu erstellen.
Dem Wunsch einen EPC-QR-Code aufzuführen wurde nachgekommen und dies in einer m. E. akzeptablen Form, wie er auch in anderen Faktura-Programmen darstellbar ist. Wie er einzusetzen ist und in welchen Bereichen (Hauptteil) er nutzbar ist wurde klar, und ehrlich dargestellt.
Ich würde mir ja nur wünschen, dass ihr einfach mal ehrlich damit umgeht, und ggf. sogar Dinge lieber gar nicht anstatt halbherzig implementiert.
Und was soll jetzt mit dem EPC-QR-Code Deinem Wunsch nach geschehen? Soll die bisherige Umsetzung wieder herausgenommen werden? Soll der Code überall platzierbar werden, ggf auch über Bereiche, die notwendige Rechnungs inhalte verdecken?
Nutzt Du den Code eigentlich, wenn Du doch nur die Buchhaltungsfunktion von Taxpool verwendest?
Mir scheint, Deine Kritik am Programm konzentriert sich vor allem darauf, leichteren Zugang für die Programmierungen von Erweiterungen zu erhalten. Dazu würde ich empfehlen, den Hersteller direkt zu kontaktieren und ein entsprechendes Angebot auszuarbeiten auf dass Du sicherlich eine ehrliche Antwort erhälst. Das Forum ist - trotz Deiner gegenteiligen Auffassung - nicht der geeignete Ort dafür.
Ob es nun der erste oder vierte Beitrag im Thread war, ist doch völlig unerheblich.
Es war so unerheblich, dass Du vom "Eingangspost" gesprochen hast und darüber hinwegtäuschen willst, dass Fragen des Eingangsposts schon längst erledigt waren.
Ich habe die Aufteilung sehr wohl verstanden (es wird ja auch oft genug von euch darauf hingewiesen)
Dann verstehst Du gewiss, dass die am Thema "Girocode wird auf Rechnung nicht angezeigt" vorbeigehende Diskussion über Deine Wünsche zur Mitarbeit an der Programmierung in diesem Forenbereich deplaziert ist.
Don’t have an account yet? Register yourself now and be a part of our community!
