Hallo Gert (@xrech_user),

herzlich willkommen im Forum und vielen Dank für das Lob!

Meine (Entwicklungs)Codebase ist zwar nicht(mehr) 100% identisch zur 2.1.4, sollte aber bezüglich der Beantwortung deiner Fragen keinen Unterschied machen; also los ...

Ich hänge Dir hier mal meine Entwicklungs-/Referenz-/Testvorlage "PlaceholderReference_DE_v213GS.ott" an. Die enthält alle verfügbaren Platzhalter und Parameter samt Hinweisen und zeigt im daraus erstellten Dokument die Realdaten des aktuellen Dokuments.
Ist wie jede Andere Fakturama Dokumentvorlage zu verwenden - ins betreffende Verzeichnis kopieren und beim Drucken auswählen.

!!! musste die Vorlage wg. "nicht zulässigem Typ" umbenennen - also einfach wieder auf ...GS.ott umbenamsen.

A) nix falsch ... es gibt dafür keinen Platzhalter. Die "am nächsten" sind die ...CODE2 (<ADDRESS.COUNTRY.CODE2>/<BILLING.ADDRESS.COUNTRY.CODE2>/<DELIVERY.ADDRESS.COUNTRY.CODE2>) also 2-stelliger Ländercode.
Wenn es (wie ich annehme) eine "überschaubare" Anzahl relevanter Länder sind, so würde ich dies mit dem Parameter $REPLACE:{#liste} (Info und Beispiel siehe erwähnte PlaceholderReferenz_...) zur spezifischen Ersetzung nutzen.
Beispiel: <ADDRESS.COUNTRY.CODE2$REPLACE:
{DE,D;AT,A;IT,I}> (Schweiz/CH muss nicht gelistet werden, da 'CH' ja unverändert bleibt)

B) jupp, <ITEM.QUANTITYUNIT> geht nur im Kontext der Artikeltabelle.
Was ist da dein Anwendungsfall? "Pau." als Einheit (beim Artikel) geht ja.

C) hab's grad mit der Testvorlage probiert (an beiden Stellen dort) und hat funktioniert.

D) (hab im Code für die X-Rechnung ne ganze Weile nix mehr gemacht - insofern hoffe ich, dass ich auf die Schnelle dort die richtigen Stellen interpretiert habe 😉

- BT-44: müsste dem Wert von Platzhalter <(BILLING.)ADDRESS.FIRSTLINE> entsprechen (bei mir jedenfalls) - vergleich das mal mit der Ausgabe in der Testvorlage.

- BT-84: (die scheint zugunsten der BIC herausgenommen worden zu sein [ich war's nicht! ;-)]

- "Hinweis" unter Extras: dieser wird (wenn nicht leer) nach der Erstellung einer e-Rechnung als Popup-Dialog angezeigt (incl. der Felder "per e-Mail an" und "Portal/URL")
Usecase: nachdem (zumindest bei uns) irgendwie jeder der e-Rechnungsempfänger seine eigenen Wünsche hat, wie ihm diese zukommen soll (per Mail, Upload in ein Portal, ...), hat man damit die Möglichkeit die Information genau dann "geliefert" zu bekommen, wenn man sie dann mal braucht.
Die beiden anderen Felder werden dabei als Textfelder dargestellt, um die e-Mail bzw. URL bequem kopieren zu können. Grundsätzlich war/ist da angedacht, dass dies mal klickbare Links werden und auch hier bei e-Mail die XRech-Datei gleich als Attachment in den Entwurf kommt.
Wg. BT-22 hab ich zugegebenerweise (noch) nicht geguckt.

Zum letzten Punkt wg. "Rechnungs-File automatisch geladen" kann ich wohl nur wenig geistreiches beitragen - als Linuxer würde ich bei 'kein Zugriff möglich' auf ein Berechtigungsthema tippen.
Werden die PDFs überhaupt erstellt, oder gibt's da im Vorfeld schon Probleme?
Gedankenfetzen: bei der Templating-Überarbeitung habe ich auch eine strikte Syntax-Prüfung der Vorlagen eingebaut; z.B. unbekannte (vertippt?) Platzhalternamen und/oder Parameternamen u. -attribute. Aber wenn's daran liegt bzw. infolge dessen das Dokument nicht erstellt werden konnte (und somit kein Zugriff) müsste zuvor eine ausführliche Meldung (Popup-Dialog) auf das Problem hinweisen.

Ich hoffe, das hilft Dir schonmal weiter.

Liebe Grüße von einem Gerd mit "d" 🙂

Hallo Gerd,

vielen Dank für die ultraschnelle und ausführliche Antwort. Hier die Ergebnisse meiner Bemühungen:

A) gelöst, funktioniert jetzt bestens!

B) war so gemeint, daß in einer Position eine individuelle Leistung mit Pauschbetrag abgerechnet wird. Z.B. "Beratung zu Projekt XY und Unterweisung/Schulung von Herren Maier, Müller, Schulze am Standort Z" etc. Wenn ich das als Artikel anlege, kommt's in dieser Form mit diesem Betrag wahrscheinlich kein 2. Mal mehr vor. Vllt. lege ich mir einige "Varianten-Artikel" mit Leistungs-Grundtypen an, wobei ich dann den Artikeltext jeweils überschreibe. Damit vermeide ich "Wildwuchs" in der Artikel-Datenbank. Jetzt habe ich zwei verschiedene OTT-Templates mit Festtexten für "Stk." und "Pau." (mehr brauche ich nicht), das ginge im Prinzip auch.

C) Klappt jetzt auch, habe nochmals in der Steuersätze-Datei nachgebessert. Allerdings hatte das Programm trotz <Speichern> die neue Steuersatz-Beschreibung nicht übernommen. Erst nach kompletter Beendigung und Neu-Start ging's dann. freu

D) In der .OTT-Vorlage steht jetzt <BILLING.ADDRESS.FIRSTLINE> und wird auch so übernommen, im BT-44 der X-Rechnung jedoch nicht, da bleibt's beim myteriösen Kombi-Eintrag aus "Firma, Name", also z.B. "Testcompany GmbH, Gert Mustermann". Ich rätsle noch, wo er das ausliest, aus den Debitorendaten auf jeden Fall nicht und auch nicht aus dem "Billing Address" Feld. Anschrift, Rechnungsanschrift und Lieferanschrift sind im "Dokument" identisch ...

Das Problem mit dem Zugriff auf die PDF ist übrigens "verflogen", jetzt hat's plötzlich geklappt, vllt. entstand es seinerzeit durch das abwechselnde "Rumspielen" in den Versionen 2.1.3 und 2.1.4.

Folgende Fragen haben sich noch ergeben (ich hoffe, ich nerve nicht):

E) Ich steh' irgendwie auf dem Schlauch, was die ausgepackte "PlaceholderReference_DE_v213GS.ott_.txt" ZIP-Datei betrifft. Darin befindet sich eine Ordner-Struktur mit mehreren XML-Dateien. Wie nutze ich das für mich?

F) Wo kann ich die "Firma" eines bereits angelegten Debitors nachträglich ändern (der Name, der im Tabellenreiter erscheint)?

G) Gibt es auch die Platzhalter <BILLING.ADDRESS.SECONDLINE> und <BILLING.ADDRESS.THIRDLINE>? Momentan habe ich in meinem OTT-Template ein bißchen einen Mischmasch in der Adresse (s. Anlage). Funktioniert zwar, ist aber vllt. nicht optimal.

Vielen Dank für Deine tolle Hilfe!

Gert

Hallo Gert (@xrech_user),

In der .OTT-Vorlage steht jetzt <BILLING.ADDRESS.FIRSTLINE> und wird auch so übernommen, im BT-44 der X-Rechnung jedoch nicht,

was in den .ott Vorlagen steht hat keinen Einfluss auf die X-Rechnung - dachte mir nur, das müsste/sollte der gleiche Wert sein, was das Mysterium hätte klären können.
Tut zwar nix zur Sache, aber bzgl. der e-Rechnungen habe ich eh noch eine Idee (im Ansatz schon getestet) die Erstellung selbiger auch über anpassbare Templates (XSLTs) zu steuern.

E) einfach nur Datei herunterladen und umbenennen. Dabei auf die Erweiterung ".ott" achten, das ist der entscheidende Punkt, also z.B. "PlaceholderReference_DE_v213GS.ott" damit müsste sie auch Windoof (wieder) als LibreOffice Writer Vorlage erkennen. Diese Datei ist nix anderes als die anderen Fakturama Vorlagen. Wenn Du die dann z.B. in den Vorlagenordner für Rechnungen (zu den anderen .ott) legst, zeigt Fakturama beim nächsten Klick auf "Drucken" diese dann in der Auswahl an.
.OTTs und .ODTs (alle LO Dokumente) sind Archive, das passt schon; entpacken musst Du die aber nicht.
PS: das Umbenennen war nur nötig, weil eine .ott hier als Anhang nicht akzeptiert wird. - genaugenommen ist's ja Blödsinn, da sich am eigentlichen Dateiformat mit dem Umbenennen nichts ändert ... naja, ist halt so.

F) hmm ... bin mir jetzt nicht sicher, was genau Du hier meinst.
1. Bei den Debitoren (Stammdaten) ist jedes Feld änderbar
2. Falls Du die Debitorendaten in einem Dokument meinst: dies sind Kopien der Adressen aus den Stammdaten (sollen sich ja nachträglich nicht automatisch ändern). Einfach den (in der Debitorenliste zuvor geänderten) Datensatz erneut auswählen/zuweisen.

G) die gibt's nicht und eigentlich wären sie auch unnötig, da der gesamte Adressblock eigentlich fix-und-fertig bereitstehen sollte ... 2x "eigentlich" ... da sind aber noch ein paar Kleinigkeiten, damit das 100% passt, was mich zum Hinweis auf das "Beta" der Version bringt:

Die Anpassungen (v.a. Adresshandling und X-Rechnung) waren zwingende Voraussetzung um bei uns Fakturama nutzen zu können, was nach-wie-vor (sehr intensiv) der Fall ist (also "praxiserprobt").
Um (erstmal) Datenbankstrukturkompatibel zur "offiziellen" F. Version zu bleiben, habe ich mir mit ein paar Workarounds behelfen müssen. z.B. die Daten des "Extra" Tabs sind per speziellem Markerblock im Kundennotizfeld hinterlegt (das sieht man in der Datenbank).
Für eine nicht-mehr-Beta möchte ich diese Workarounds noch bereingen (z.B. durch die zusätzlich benötigten Felder in der DB). Dazu muss ich mich aber mit Ralf (@rheydenr) abstimmen, wozu ich noch nicht gekommen bin.
zurück zu G): das betrifft u.a. auch zwei Platzhalter für das Adressformat (in den Einstellungen).

Was heißt das nun für die Beta? Erstmal "nur", dass für die "richtige" Version (wahrscheinlich, aber nicht sicher) z.B. die Daten bei "Extras" nicht 1:1 übernommen werden (können) und somit nachbearbeitet werden müssen. Allerdings werde ich nach Möglichkeit versuchen, dies automatisch machen zu können. - das brauchen wir hier ja auch; bei 1000+ Debitoren macht händisch nicht so Laune 😉

So, hoffe ich habe für mehr Klarheit als Verwirrung sorgen können 😉

Gerd

Hallo Gerd,

bis zur confusio mentalis dauert es bei mir hoffentlich noch. Danke für die Hinweise. Das mit der Placeholder-ZiP Datei hat jetzt mit vorheriger Umbenennung in .OTT funktioniert, die Endung ".ZIP" hatte bei mir einfach einen Pickreflex ausgelöst, von wegen die .OTT im ausgepackten ZIP zu suchen ... Werde mir den Inhalt in einer ruhigen Minute zu Gemüte führen.

Zu F): In den Debitoren-Stammdaten kann ich jedes Feld ändern, das ist richtig, auch Anrede und "Firma". Der Tabellenreiter und die Inhaltswiedergabe in der Spalte "Firma" in der Debitorenübersicht bleiben davon aber unberührt (s. JPG in Anlage).

Zu G): Ich lasse es einfach so wie's ist. Ich hatte auch schon einmal den kompletten Adressblock als Ganzes verwendet, dann gab's bei mir aber im PDF-Ausdruck sehr große Zeilenabstände zw. Firma, Namenszusatz, Straße und Ort, so daß ich daraufhin auf die separaten Einzel-Platzhalter übergegangen bin, mit denen ich die Standard-Zeilenabstände erhalten habe. Und so funktioniert's ja auch gut.

Ich weiß, ihr habt einen Haufen Arbeit zu erledigen, deshalb fasse ich mich heute kurz.

Gert