@lastboyscout

Hallo Matthew,

yupp, genauso ist das mit den CustomFields gedacht - da kann jeder für sich entscheiden, was und wieviel er damit machen möchte/muss.

Welche "allgemein übliche Datenfelder" als solche gesehen und fest integriert werden (sollen) ist sicher eine etwas kniffligere Entscheidung.
Für uns hier z.B. wären "PayPal oder auch Geoinformationen" trotz ansehnlichem Adressumfang (>2500) nach-wie-vor vollkommen irrelevant - aber wie gesagt: für uns und bis dato (was sich ja ändern kann).

Frage für mein Verständnis* zu "zusätzliche Mailadressen für Rechnungsversand":
hier würde mich u.a. als (Fakturama Mit-)Entwickler interessieren:
- was ist hier der Anwendungsfall? und
- wo müsste(n) diese Mailadresse(n) zugeordnet werden? (allgemein zum Kontakt oder zu den jeweiligen Adressen?)

* Bei uns war trotz mittlerweile vorwiegend elektronischem Versand (aus Fakturama) bisher nämlich noch nie ein solcher Bedarf. Wir haben die relevante Mailadresse für den Rechnungsversand bei der/den Rechungsadresse/n hinterlegt.

LG
Gerd

Hier mein Wunschzettel für zusätzliche Felder

Namens- und Adresszusatz in der Tabelle FKT_DOCUMENTRECEIVER

• NAMEADDON als Pendant zu FKT_ADDRESS.NAME
• ADDRESSADDON als Pendant zu FKT_ADDRESS.ADDRESSADDON

dazu dann auch die entsprechenden Platzhalter für Verwendung in:
- Dokumentvorlagen
- Einstellungen > Kontakte > Format > Addressfeld

"Bezeichnung" (Label) für Adressen

nur zur internen Bezeichnung und Identifizierung von Adressen:
- auf den Adress-Tabs bei Debitoren/Kreditoren (statt "Hauptadresse" und "Zusatzadresse 1" ...)
- in der Liste bei der Adressauswahl
Das Feld Name(nszusatz) kann dafür nicht genutzt werden, da dies i.d.R. Teil der Adresse ist bzw. sein kann.
Bei mehreren Adressen je Kunde (bei uns z.T. >10) sind z.B. 6-mal "Wareneingang" (wie's im Namenszusatz stehen muss) wenig hilfreich. "WE, Hr. Packer", "WE Halle 2, Logistik" etc. hätten widerum nichts in der "offiziellen" Adresse zu suchen.

"Hinweis" bei Kontakten

nur interne Verwendung für aktuelle, kundenspezifische Hinweise im Dokumenteditor.
[ Dies war hier eine dringende Anforderung, welche ich derzeit per Workaround implementiert habe und welche sich in der Praxis als sehr nützlich erwiesen hat. ]
Wenn befüllt, wird dieser Hinweis im Dokumenteneditor deutlich erkennbar über der Adresse angezeigt.
Der Hinweis wird NICHT im Dokument gespeichert sondern grundsätzlich aktuell abgerufen.

Hintergrund / Anwendungsfälle (reale Beispiele):
(hier viele Bestandskunden oft mit mehreren Ansprechpartnern)
a) Nachricht vom Kunden (unabhängig von einem aktuellen Vorgang), dass ab dem X.Y. Rechnungen als XRechnung zu stellen sind
b) Rechnung 1 von Ansprechpartner A ist überfällig, Ansprechpartner B (der nichts davon weiß) möchte bestellen
c) es wurden Sonderkonditionen erst für Bestellungen ab Q3 vereinbart (nicht jeder Ansprechpartner weiß davon)
d) Projektleiter möchte in Kopie aller Anfragen sein (nicht jeder Ansprechpartner weiß davon)

"Wiedervorlage" (-Datum und -Notiz) bei Dokumenten

Hintergrund:
Übersicht "offene Vorgänge" / "ToDo-Liste"; s.a. div. Beiträge/Anfragen hier bzgl. Status

Ideenskizze:

1. Zusätzliche Felder "Wiedervorlage-Datum" und "Wiedervorlage-Notiz" varchar(100?) beim Dokument.
2. das optionale Notiz Feld ist einfach als Gedankenstütze wie ein "Post-It" gedacht
3. In der Dokumentauswahlliste ein zusätzlicher Punkt "Wiedervorlage", worunter alle Dokumente gelistet werden, deren WV-Datum <= heute ist (evtl. mit wählbarem Datumsbereich)
4. standardmäßig werden beim Erzeugen eines Folgedokumentes die WV-Daten übertragen und im Originaldokument entfernt; das Datum wird dabei ggfs. angepasst (z.B. bei Rechnung auf den Fälligkeitstag gesetzt)
5. evtl. weitere Automatismen; z.B. WV-Datum leeren bei Zahlungseingang
6. die WV-Felder können dabei jederzeit vollkommen beliebig editiert werden, womit der Anwender vollkommen frei ist, welches Dokument wann und wofür auf diese "ToDo-Liste" kommt - unabhängig von irgendeinem Status

Hier gefällt mir/uns besonders die Einfachheit und Flexibilität, welche vermutlich nicht (so einfach) per Status abbildbar ist (Beispiele):

• im Standardfall ist je Vorgang nur jeweils das "aktuelle" Dokument auf der Liste
• das, was (bis incl.) heute fällig / zu erledigen ist, ist im Fokus
• unabhängig vom Dokumenttyp (ggfs. filter/sortierbar)
• offene Vorgänge (Angebote ohne Bestellungen) können durch Entfernen des VW-Datums gezielt "geschlossen" werden - also von der Liste genommen
• "klassische" Wiedervorlage z.B. zum Nachtelefonieren
• jedes Dokument kann (warum auch immer) als "Reminder" genutzt werden (Bsp: eine Bestellung als Erinnerung dem Kunden in 2 Monaten den dann neu verfügbaren XYZ anzubieten)
• zyklische Rechnungen (Monat/Quartal) - hierfür könnte z.B. beim zugrundeliegende Auftrag das WV-Datum jeweils angepasst werden

Soweit mal meine aktuellen Wünsche.
Feedback, Anregungen? ... nur her mit! 😉

LG
Gerd

Frage für mein Verständnis* zu "zusätzliche Mailadressen für Rechnungsversand":
hier würde mich u.a. als (Fakturama Mit-)Entwickler interessieren:
- was ist hier der Anwendungsfall? und
- wo müsste(n) diese Mailadresse(n) zugeordnet werden? (allgemein zum Kontakt oder zu den jeweiligen Adressen?)

* Bei uns war trotz mittlerweile vorwiegend elektronischem Versand (aus Fakturama) bisher nämlich noch nie ein solcher Bedarf. Wir haben die relevante Mailadresse für den Rechnungsversand bei der/den Rechungsadresse/n hinterlegt.

Hier gäbe es aus meiner Sicht zwei mögliche Szenarien:

Der Kunde hat für jede Lieferadresse auch eine eigene Rechnungsadresse/Rechnungs-e-Mail;
Das kommt zugegebenermassen nicht wirklich häufig vor, aber ich hatte das schon.
Hier wäre wohl die Zuordnung zur einzelnen Adresse notwendig.

Der Kunde hat neben der wichtigen Adresse für Kommunikation eine eigene/gesonderte e-Mail-Adresse für den Rechnungsversand.
Diesen Anwendungsfall habe ich ständig, und einige Kunden reagieren da richtig ungehalten, wenn das vermischt wird.
In diesem Fall würde ich das dem Kunden ganz allgemein zuordnen.

Wie gesagt, dies aus meiner Sicht, aber vielleicht hatte Matthew (@lastboyscout) da ja anderes im Sinn.

LG
Jürgen

Ich hatte ja seinerzeit das Grundkonzept der multiplen Adressen für Ralf entwickelt und auch die Aufteilung der aktuellen Eingabemaske entworfen. Ob und wenn ja welche weiteren Felder noch in die Datenbankstruktur mit aufgenommen werden sollten, müsste daran ausgerichtet werden ob diese aktuell oder zumindest in naher Zukunft Branchen übergreifend genutzt werden. Für alle übrigen wäre die Idee der CustomFields wirklich ein sinnvolle und vor allem auch flexible Lösung. Zu klären wäre auch ob diese CustomFields an die einzelnen Adressen oder nicht besser an das übergeordnete Kundenkonto angebunden werden sollten. Evtl. würde es sogar Sinn machen diese Möglichkeit sowohl für das Kundenkonto als auch für jede der damit verknüpften Adressen zu haben. Etwas Knifflig dürfte dabei aber die Integration innerhalb der Im-/Exportfunktion werden.

Hinsichtlich des elektronischen Rechnungsversand habe die Erfahrung gemacht, dass immer mehr Firmen und Institutionen dazu übergehen eine spezielle Mailadresse einzurichten, welche ausschließlich für den Rechnungsempfang vorgesehen ist. Und dann gibt es ja auch noch die öffentlichen Verwaltungen, bei welchen man Rechnungen ggf. auf einem besonderen Portal hochladen muss. Hierzu ist dann wiederum eine Internetadresse nebst Zugangsdaten bei der Rechnungsanschrift zu speichern.
Mit Umsetzung der eingangs erwähnten Funktionalität kann man einem Konto ja nun beliebig viele Adressen zuordnen. Dementsprechend nutze ich dies und lege bei einer speziell für den Rechnungsempfang abweichenden Mailadresse eine weitere Adresse an. Jedoch ist diese überwiegend absolut Identisch mit der Hauptadresse, so das damit (bis auf die Mailadresse natürlich) ja eigentlich nur ein Duplikat erzeugt wird und sich damit jedoch der Aufwand für die Datenpflege verdoppelt. Somit erachte ich neben der Mailadresse für allgemeinen Kontakt eine zusätzliche "Funktions- Mailadresse" für Sinnvoll. Um hier aber nicht einfach wieder nur ein weiteres Feld einzubauen und zukünftig ggf. wieder eins usw. Würde ich es für Sinnvoll erachten auch innerhalb der einzelnen Adressen, potentiell multiple Felder (min. Mailadressen und Telefonnummern) wiederum in eine extra Tabelle aus zu lagern und mit der Adress-ID zu verknüpfen. Also Kontakt (n=1) -> Adressen (n=x) -> Mailadressen oder Telefonnummern (n=x).

Auch mein Beispiel mit den Geoinformationen wird bei Lieferanschriften m.E. wohl immer mehr an Bedeutung gewinnen. Textliche Zusätze wie "Wareneingang" oder "WE Halle 2, Logistik" sind letztendlich nur Hinweise anhand dessen der Mitarbeitende vor Ort erst den genauen Standort identifizieren muss. Besonders bei Firmen mit verteilten Standorten und unterschiedlichen Lieferadressen ist dies manchmal eine ziemliche Herausforderung, denn Adressen führen leider nicht immer genau ans gewünschte Ziel. Als eine ziemlich praktikable Lösung hat sich hierzu für uns wath3words herausgestellt. Hier kann man mit einer einfachen, aus drei Wörtern zusammengesetzten, Adresse (z.B. ///decke.entziehen.höherer) einen Standort mit einer Genauigkeit von 3x3m bestimmen. Besonders nützlich ist dies beispielsweise für Wartungs- oder Dienstleistungsaufträge an verteilten Standorten.

Neben einer "Bezeichnung" (Label) für Adressen wäre auch ein "Matchcode" für das eigentliche Kunden-/Lieferantenkonto hilfreich.

Zum Thema "Wiedervorlage" gibt es bereits einige detaillierte Feature-Wünsche im Bug Traker... Stichwort Aborechnung: #261 Dies sollte aber auf alle Belegarten anwendbar sein, so dass man Beispielsweise bei einem Wartungsvertrag auch einen Lieferschein turnusmäßig als Arbeitsauftrag erstellen kann, welcher dann nach Ausführung zur Rechnung weitergeführt werden kann. Hatte auch mal die Idee eines Makro (#702) als quasi eines Script dessen Ausführung man ja auch per Reminder anstoßen und mit Hilfe dessen man automatisiert entsprechende Belege erzeugen könnte.

Es freut mich wirklich das Ralf nun offenbar auch tatkräftige Unterstützung hat. Ich persönlich kann ja leider nur meine Expertise einbringen und Ideen, Vorschläge und Wünsche beisteuern. Im Bug Tracker gibt es ja einiges was dringend umgesetzt werden müsste. Hier wäre es evtl. Hilfreich die Community nach deren Prioritäten zu Fragen. Mir persönlich fehlt besonders dringlich die Möglichkeit Belege besser strukturieren und Kommentare einfügen zu können: #319 #653 #635 #675 #703 #728 danach kommen dann: #638 #726 #752 #865 #883 #888 usw.

Gruß
Matthew

Hallo,

hat jemand vielleicht einen Leitfaden, wie das Problem mit der separaten Mailadresse für den Rechnungsversand gelöst werden kann ?

LG

@dumbelek 

Leider gibt es da ganz aktuell noch keine Lösung dafür. Ralf (@rheydenr) hat aktuell eine andere dringendere Baustelle.

LG
Jürgen