Der Aufwand dafür hält sich in Grenzen, man muß halt nur die Datenbanktabellen erweitern und paar neue Maskenfelder hinzufügen. Kann ich ggf. mit der 2.2.0 machen.

@rheydenr 

Okay mir wären da noch ein paar andere Datenfelder eingefallen, die ggfs. interessant (oder z.T. notwendig) wären.

Ich schreib mir das mal alles zusammen.

LG
Jürgen

@rheydenr 

Folgende Felder wären mir eingefallen, und ich stelle diese hier mal zur Diskussion. Die Liste ist sicher nicht abschliessend und weitere Ideen sind gerne wilkommen.

Eigene Unternehmensdaten:

• Firmenbuch-/Handelsregister-Nummer
• Firmenbuch-/Handelsgericht
• EORI-Nummer
• GLN
• D-U-N-S ® - Nummer
•  

Firmenbuchdaten könnte man damit einfach in diverse Formulare übernehmen.
Die GLN ist in Österreich für die elektronische Rechnungslegung (XML-Rechnung) erforderlich.
D-U-N-S ® - Nummer ist ein 'nice to have' - ich stelle aber fest, dass diese immer öfter nachgefragt wird.

Daten von Debitoren/Kreditoren:

• EORI-Nummer
• PayPal-Adresse
• Social Media-Profile (Facebook, Instagram, etc.)
• Messenger ID (Skype, Threema, Wire, etc)
• SIP-ID (VoIP)
• D-U-N-S ® - Nummer
•  

Ich wickle viele Zahlungen über PayPal ab.
Social-Media Profile sind ebenfalls ein 'nice to have', dienen eher der Information; hier wären aber denke ich multiple Felder notwendig, weil man nicht alles von vornherein abdecken kann.
Messenger werden in der Kommunikation immer wichtiger, ob allerdings sehr viele eine reine SIP-ID benutzen weiß ich nicht.
D-U-N-S wie oben.

Beste Grüsse
Jürgen

Hallo,

leider war ich mit meiner Suche noch nicht erfolgreich - wo finde ich eine Aufstellung aller verfügbarer Formularfelder für die Verwendung in LibreOffice?

Danke

Konrad

@ktrojok 

Hallo Konrad,

Du findest alle verfügbaren Platzhalter im Handbuch [1] von Fakturama.

LG
Jürgen

https://files.fakturama.info/release/v2.1.2/Handbuch-Fakturama_2.1.2.pdf

Danke für die schnelle Antwort!

@microangelo 

Hallo,

ich möchte diesen ursprünglichen Vorschlag noch mal aufgreifen.

Könnte man das nicht lieber über ein variables editierbares Grid lösen?

Im Kundenstamm wie auch bei den eigenen Unternehmensdaten.

Dann hätte man die Wahl welche Felder man hinzufügt.

Und die Daten dazu in eine zusätzliche Tabelle anstatt die andere aufzubohren.

Um auf die Daten dann im Formulareditor zuzugreifen müsste natürlich eine eindeutige ID benutzt werden.

ADDRESS.CUSTFIELDITEM1  

ADDRESS.CUSTFIELDITEM2

.....

Anbei ein gebastelter Vorschlag im Gepa-Stamm

Viele Grüße

@pcheld24 

Danke für den Vorschlag.

Was sagt Ralf (@rheydenr) dazu? 😉

LG
Jürgen

Moin, klingt erst mal umsetzbar, bring aber einige Fragen mit sich:

1. welchen Datentyp sollen die Felder haben (nur Zeichen, nur Zahlen, nur Datum?)
2. Welche Feldgrößen sollen angesetzt werden?
3. Müssen die eingegebenen Daten irgendwie geprüft werden?

Ich nehm das mal mit. Wenn das ggf. mal jemand noch im Bugtracker beschreiben könnte wäre das auch nicht schlecht... 🙂

Ticket 0000994 ist erstellt!

Hallo Zusammen,

bezugnehmend auf Axels (@pcheld24) Idee weiter oben

Könnte man das nicht lieber über ein variables editierbares Grid lösen?

möchte ich meinen (bereits produktiv genutzen) Ansatz der "EmbeddedProperties" hier in die Ideenkiste einbringen.
Konkreten Kontext, Hintergrund und weitere Details habe ich in meinen Beiträgen zur XRechnung:  https://www.fakturama.info/community/fakturama-2/xrechnung/paged/5/#post-17892
schonmal beschrieben.

Kerngedanke war (ist): maximale Flexibilität mit kleinstem Aufwand und minimaler Abhängigkeit zur Datenbankstruktur, v.a. was Erweiterungen (aka "zusätzliche Felder") betrifft.

Kurzbeschreibung der technischen Basis

in nur einem zusätzlichen "TEXT" Feld (wie "Notiz") zum Contact in der DB werden Schlüssel-/Wertepaare im Java Properties Format abgelegt. (Bsp: social.telegram= https://t.me/EinBenutzerProfil)
Zur Bearbeitung im Programm werden diese extrahiert und z.B. als "variables editierbares Grid" aufbereitet dargestellt.
Schlüssel und Werte können jederzeit individuell für jeden Kontakt frei hinzugefügt, bearbeitet und entfernt werden.

Vorteile:
a) flexibel
b) keine Typisierung und pauschale Längenbegrenzung der Felder
c) weitere "Felder" ohne DB-Änderung jederzeit möglich
d) "große" Datenmenge (TEXT Feld)
e) nur beim jeweiligen Kontakt benutzte Felder in der Eingabemaske (Übersichtlichkeit)
f) !!! nur ein zusätzliches Feld in bestehenden DAOs, keine zusätzlichen Lese-/Schreibzugriffe/Joins/etc. erforderlich

a) bis c) könnten auch potenzielle Nachteile sein, welchen m.M. v.a. durch die UI Rechnung zu tragen ist.

Handling/UI/Anwendersicht

Auf dieser Basis würde ich per benutzereditierbarer Config (z.B. per XML-Datei) die "Felddefinitionen" machen, welche u.a. die möglichen Felder (=Schlüssel) definieren, aber auch weitere, v.a. UI-relevante Infos beinhalten, wie z.B. Feldbezeichnung (Label), Datentyp, Länge, Validierung, Eingabeformat, Werteliste, evtl. Gruppierung, etc.

Zum Thema Anwender: hier sehe ich lediglich bei der Config per XML-Datei eine (kleine) Hürde für den Laien, aber ...
wer benutzerdefinierte Felder benötigt ist evtl. schon etwas weiter in der Materie.
Außerdem würde ich mit der Installation bereits ein ganze Liste "üblicher" Felder (wie die hier von Jürgen (@microangelo) schon erwähnten) "beipacken".
Ggfs. auch zwei XMLs?: Systemdef (Finger wech von die!) und Userdef
In einer Ausbaustufe evtl. mit Config-Editor?

Datennutzung/Abruf

a) generische Bereitstellung für XSLTs zum Dokumentexport (v.a. E-Rechnung) -> siehe oben verlinkten XRechnung Beitrag
b) ebenso in Dokumenttemplates per generischem Platzhalter

Abschließende Hinweise

a) die Verwendung sehe ich v.a. für zusätzliche Informationen, welche zwar strukturiert behandelt werden sollen, aber keine besondere Rolle in Fakturama spielen.
b) selbiges Prinzip könnte (bei Bedarf) auch für Produkte und Dokumente angewandt werden

Sorry, war wieder mal viel Text.

Lieben Gruß,
Gerd

PS an Ralf (@rheydenr):
hoffe, dass ich den Sourcecode-Push meiner Version bald fertig bekomme (bin derzeit mit anderen Projekten zu "abgelenkt" 😉

Guten Morgen,

das klingt erst mal interessant du würdest also vorschlagen ein CLOB Feld zu nutzen?

Und darin eine neue Datendefinition incl. Daten abzulegen.

Das ist natürlich für das Datenmodell und selbst erstellte Views unpraktischer, da der Datensatz im SQL dann ggf. zerlegt werden muss.

Viele Grüße

@pcheld24

Danke Axel für den Einwand!
Die mittelfristig beste Lösung ist wohl, dies komplett und "sauber" in der DB abzubilden.
Der erstmal geringere Implementierungsaufwand wäre da vermutlich "am falschen Ende gespart".

Hier nun meine aktualisierte (unvollständige!) Idee zu den CustomFields:

In welchem Kontext?
für folgende Bereiche sehe ich derzeit bereits Bedarf für CustomFields

1. Eigene Unternehmendsaten
2. Debitoren/Kreditoren
3. Adressen
   wir bräuchten z.B. ein Feld um adress-/ansprechpartnerbezogen Kennzeichen für Mailingaktivitäten zu hinterlegen (z.B. Zustimmung, Interessenbereich)
4. Dokumente
   teilweise zusätzliche kundenvergebene Projekt-/Referenz-/Abrechnungnummern, v.a. für E-Rechnungen
5. Produkte

Die Implementierung würde ich mit (nur) zwei Tabellen machen.
Eine "Datentabelle" welche die Werte sämtlicher CustomFields aufnimmt (also für alle Kontexte) und
eine "Definitionstabelle" welche die Definition der Felder beinhaltet.

Datentabelle

• ID
• CONTEXT varchar - zu welchem Kontext das Feld gehört; z.B. Tabellenname oder (besser?) so wie die Platzhalter in den Templates, z.B. YOURCOMPANY, ADDRESS, DOCUMENT
• CONTEXT_ID int - Record-ID des Datensatzes zu dem das Feld gehört
• NAME varchar(30) - (technischer) Name des Feldes lt. Definition (s.u.)
• VALUE varchar(300+?) - Wert

PrimaryKey: ID
UniqueKey: CONTEXT, CONTEXT_ID, NAME

Definitionstabelle

• ID
• CONTEXT - s.o.
• NAME varchar(30)
  - technischer Name des Feldes, eindeutig im Kontext
  - nur Kleinbuchstaben (zur einfacheren Referenzierung)
  - zulässig: Zahlen, Buchstaben und . - _
  - Referenzierung in den Template-Platzhaltern, Bsp: <CONTACT.CUSTOM:feld_name-eins>
  - Bereitstellung im Document-XML (siehe XRechnungs-Beitrag, oben verlinkt) für E-Rechnung: <customfield name="feld_name-eins">Wert</customfield>
• LABEL varchar(80+) - Feldbezeichner in Anzeige/Maske
• TYPE - logischer Datentyp; evtl. auch als Kombi mit MAXLENGTH (z.B. String(4-12) = mind. 4 max. 12 Zeichen; EMail; URL; Datum)
• MAXLENGTH - maximale Anzahl Zeichen
• VALUES varchar(500+?)
  - trennzeichenbasierte Liste möglicher Werte
  - wenn nicht leer, wird zur Eingabe eine Auswahlliste/Dropdown mit diesen Werten bereitgestellt.
  - evtl. mit Option auf zusätzlich freie Eingabe.
  - denkbar wäre auch eine "multiselect" Option
• STATUS
  - optional(default)
  - erforderlich
  - inaktiv (keine Neuzuordnung, aber vorhandene editierbar)
  - gesperrt (wie inaktiv aber nicht editierbar)
• VALIDATION varchar - Validierungsregeln, z.B. RegEx-Pattern; auch mit Bezug auf TYPE

PrimaryKey: ID
UniqueKey: CONTEXT, NAME

Umbenennen von Feldnamen (NAME) soll (nur) in der Definition möglich sein und ein entsprechendes UPDATE auf die Datentabelle durchführen.

Löschen von Felddefinitionen löscht auch alle entsprechenden Einträge in der Datentabelle.

Nur eine Datentabelle?

• vom Datenumfang sollte das mal keine Probleme machen
• DB-Struktur bleibt schlanker
• es lassen sich ohne DB-Anpassung Kontexte flexibel ergänzen (stückweiser Ausbau)
• weniger DAOs
• simple Implementierung nur eines Widgets, welches dann generisch verwendet werden kann

LG
Gerd

Hallo zusammen,

meiner Meinung nach sollten bislang fehlende aber allgemein übliche Datenfelder, wie etwa zusätzliche Mailadressen für Rechnungsversand oder PayPal oder auch Geoinformationen etc. direkt in die DB aufgenommen werden. Weitere je nach Branche benötigte Felder wie etwa KFZ-Kennzeichen usw. sollten hingegen vom Anwender möglichst flexibel selbst definiert werden können. In der Regel sollte man dabei aber natürlich immer Datensparsamkeit walten lassen und nur wirklich benötigte Informationen erfassen. Alles weitere wie etwa Sozialmedia-Profile können zur eigenen Info natürlich recht interessant sein, benötigen dann aber natürliche auch entsprechenden Pflegeaufwand.

Gruß
Matthew