für mich ist die neue Adress-logik nicht ganz sauber.

Ja das scheint wirklich noch ein Problem...

Habe hier auch eine Verwaltung als Kunde, welche für jedes Objekt eine eigene Rechnungs- und Lieferanschrift benötigt. Das ist ja nun prinzipiell eigentlich kein Problem mehr, lässt sich mit der aktuellen Umsetzung aber leider nicht abbilden.

Das Problem dabei ist, dass einige Felder nach wie vor noch in der Tabelle fkt_contact liegen und nicht mit in die fkt_address ausgelagert wurden. Somit wird dann auch bei mehrerer unterschiedlicher Adressen immer noch die gleiche Firmenbezeichnung (bzw. Namen) mit ausgegeben.

Ich schlage daher vor das die angestrebte Trennung zwischen eindeutigen und multiplen Werten konsequenter umgesetzt werden sollte, indem zumindest auch die nachfolgenden Felder nach fkt_address verlagert werden:
GENDER
TITLE
FIRSTNAME
NAME
COMPANY
BIRTHDAY (könnte man ja auch als Gründung / Eröffnungsdatum bei Firmen verwenden)

Im Prinzip sollte also einzig T_ALIAS als Namensbezeichnung in fkt_contact verbleiben und alle anderen als potenziell multiple Felder ausgelagert werden. Vorhandene Daten sollten dabei der Hauptadresse zugeordnet werden.

Bei LFO wird übrigens die Aliasbezeichnung beim anlegen eines neuen Datensatz automatisch aus der Hauptadresse gebildet (kann dann aber natürlich noch geändert werden). Eine dabei zu verwendende Regel könnte man ja in den Programmeinstellungen definieren: {company}|{lastname} {firstname}

Gruß
Matthew

Hallo Matthew,

vielen Dank für deine Nachricht.
Der Hauptadresse / dem Hauptgeschäftspartner würden dann die verschiedenen anderen Adressen zugeordnet?
(Mehrere Lieferadressen, etc ?) OK
Aber eben vollständig so wie in 2.0.5 bei einer Adresse?

Ein weiteres Problem ist dann noch die Auftragserfassung. Dort müsste die entsprechende Lieferadresse ausgewählt werden können. (Falls es mehrere gibt)

Viele Grüße
Axel

Der Hauptadresse / dem Hauptgeschäftspartner würden dann die verschiedenen anderen Adressen zugeordnet?
(Mehrere Lieferadressen, etc ?) OK
Aber eben vollständig so wie in 2.0.5 bei einer Adresse?

Nein, sämtliche Adressen werden dem Debitoren-/Kreditorenkonto zugeordnet... Somit eben gerade nicht mehr wie in Version 2.0.5. Die Trennung zischen einmaligen Werten (z.B. Kundennummer usw.) und den dazugehörigen Adressaten (inkl. Namen, Firmenbezeichnung usw.) sollte hingegen noch konsequenter umgesetzt werden.

Vereinfacht gesagt geht es darum sämtliche potentiell multiplen Felder aus der Waagerechten (innerhalb eines Datensatz von fkt_contact) heraus zu nehmen und in die Senkrechte (jeweils ein eigener Datensatz in fkt_address) zu verfrachten.

Als Hauptadresse gilt immer die erste Adresse eines Datensatz. Hier sollte im eigenen Workflow daher immer der eigentliche Vertragspartner (Hauptniederlassung/Stammsitz bei Firmen) hinterlegt werden.

Ein weiteres Problem ist dann noch die Auftragserfassung. Dort müsste die entsprechende Lieferadresse ausgewählt werden können. (Falls es mehrere gibt)

Das geht aktuell nur beim Lieferschein.

In der Tat wäre es aber wünschenswert dies bereits vorher hinterlegen zu können, so das der "Versandabteilung" bei Erstellung des Lieferschein bereits die zu verwendende Lieferanschrift vorausgewählt ist.

Gruß
Matthew

Nein, sämtliche Adressen werden dem Debitoren-/Kreditorenkonto zugeordnet... Somit eben gerade nicht mehr wie in Version 2.0.5. Die Trennung zischen einmaligen Werten (z.B. Kundennummer usw.) und den dazugehörigen Adressaten (inkl. Namen, Firmenbezeichnung usw.) sollte hingegen noch konsequenter umgesetzt werden.

😉 Wir reden von dem selben habe ich verstanden.
Einem Debitor oder Kreditor (Geschäftspartner) werden die zusätzlichen Adressen zugeordnet.

Als Hauptadresse gilt immer die erste Adresse eines Datensatz. Hier sollte im eigenen Workflow daher immer der eigentliche Vertragspartner (Hauptniederlassung/Stammsitz bei Firmen) hinterlegt werden.

Finde ich OK

In der Tat wäre es aber wünschenswert dies bereits vorher hinterlegen zu können, so das der "Versandabteilung" bei Erstellung des Lieferschein bereits die zu verwendende Lieferanschrift vorausgewählt ist.

Das müsste Ralf beantworten.

Ich würde es begrüßen wenn auch andere 2.1.0 Nutzer in diese Diskussion einsteigen würden.
Gibt es für die anderen kein solches Thema, weil die Arbeitsweise eine andere ist?
(Keine anderen Lieferadressen, alles immer nur ein Debitor/ Kreditor)

Viele Grüße
Axel

Moin,
ich finde die Diskussion hier sehr hilfreich. Voraussichtlich werde ich an den Adressen nochmal was ändern. Dazu brauche ich aber eben wie gesagt eure Rückmeldungen. Scheinbar gibt es da sehr viele unterschiedliche Ansätze, die wir irgendwie konsolidieren müssen.
Übrigens habe ich die Übernahme der "richtigen" Adresse anfangs auch schon umgesetzt gehabt, dann hat mir aber leider ein kleiner Fehler in der Tabelle einen Strich durch die Rechnung (haha 🙂 ) gemacht. Ich hatte mir das so überlegt, daß die Auswahltabelle eine Art Baumstruktur hat, bei der dann die zur aktuellen Dokumentart passende Adresse rausgesucht wird. Das muß ich nochmal verbessern.
Über die zusätzlichen Felder können wir auch nochmal reden, da kann ich gerne noch was einbauen.

Hallo Ralf,

vielen Dank für die Rückmeldung.
Ich denke bei den meisten mit mehreren Lieferadressen, dürfte folgender Ablauf funktionieren:

Auftragserfassung zum Kunden (Zahler) --> Auswahl der Lieferanschrift / Serviceadresse im Auftragsdialog -->
Erstellung des Lieferscheines (An die Lieferadresse) --> Oder sofort Rechnung (an den Zahler) --> Rechnung an Kunden mit dem Verweis auf die Service Adresse.

Gibt es nur den einen Kunden (Zahler) ist dieser automatisch Liefer-anschrift und Rechnungsanschrift.

Beispiel:
Bäckerei Meier bestellt 3t Mehl direkt bei mir, der Mühle.
Die Rechnung schreibe ich aber dem Großhändler.
Bezahlen tut auch der Großhändler.
Und der Bäcker zahlt an den Großhändler.

Die Rollen sind doch trotzdem die gleichen. Oder?
Auftrag erteilt zwar der Bäcker telefonisch, aber dieser Auftrag ist eigentlich bei dem Großhändler anzulegen,
mit der Liefer-Anschrift des Bäckers oder?
Sprich der Zahler ist der Auftraggeber.

Für mich ist jeder Auftrag beim Zahler / Rechnungsempfänger anzulegen. Alles weitere wie Lieferanschriften oder Serviceadressen sind untergeordnete Rollen. Wovon es pro Kunde / Auftraggeber mehrere geben kann.

Gibt es Geschäftsmodelle die von dieser Logik abweichen?
Beispiel / Problemstellung 2:
Die einzelnen Hausmeister einer WBG dürfen kleine Aufträge selber vergeben.

Hausmeister Hans Müller bestellt den Elektriker Service.
Im Auftrag wird der Hausmeister Müller als Kunde angelegt.
Aber die Rechnung muss an die Wohnungsbau Genossenschaft gehen.
System kann so nicht verwendet werden (Boing!) 😉

Der Kundenstamm muss so aufgebaut sein, das ich den Auftrag richtig anlegen kann, wenn Hausmeister Hans Müller anruft. (WBG als Übergeordneter Kunde zu finden)
Für die Suche könnte man ein zusätzliches Feld "Matchcode" nutzen.
Oder besser wenn nach der Lieferadresse gesucht wird, das der Auftraggeber daraus automatisch hervor geht.

Auftragerfassung nach Lieferanschrift:
Suche Hans Müller --> Automatisch wird die Rechnungsadresse der übergeordneten Hausverwaltung gezogen.
Suche Bäcker Meier --> Automatisch wird die Rechnungsadresse des Grosshändlers gezogen.

Auftragerfassung nach Kunde:
Suche Wohnungsbaugesellschaft --> Auswahl einer Lieferadresse im Auftrag --> Rechnungs und Lieferadresse ok
Suche Bäckereigrosshandel --> Auswahl der Lieferadresse --> Rechnungs und Lieferadresse --> ok
Suche Heini Baumeister es gibt nur Heini Baumeister also Liefer und Rechnungsadresse --> ok

Gibt es noch Abrechnungsmodelle die nicht mit dieser Logik vereinbar sind?

Viele Grüße
Axel

Hallo zusammen,

Die von Axel aufgezeigten Modelle sind sehr schöne Beispiele... Begründen sich aber natürlich auf die jeweilige Vertragsgestaltung zischen Auftragnehmer und Auftraggeber. Fakturama kann und sollte hier keinerlei Vorgaben machen, sondern nur einen flexiblen Rahmen bilden, um damit möglichst viele Konstellationen abbilden zu können.

Im Beispiel der Mühle müsste also ein entsprechender Vertrag mit dem Großhändler vorliegen, in dem geregelt ist das Bäckerei Meier Bestellungen auf Rechnung des Großhändler auslösen darf und die Lieferungen direkt an die Bäckerei gehen. Hier stellt sich für mich aber auch schon die Frage ob Bäcker Müller den Preis des Großhändler erfahren darf? ::o Wenn wir dies aber vorerst außer acht lassen, so könnte man es nun mit Fakturama 2.1.0 wie folgt abbilden:

1. Der Großhändler als direkter Vertragspartner wird als Kunde angelegt und dessen Anschrift auch als Hauptadresse eingetragen.
2. Die bestellberechtigten Bäckereien werden einfach als zusätzliche Anschriften für Bestellungen und Lieferungen hinterlegt.

Lieferungen gehen dann direkt an die jeweiligen Bäckereien und der Großhändler erhält dazu Einzel- oder auch Sammelrechnungen mit Bezug zu den einzelnen Lieferungen (Lieferdatum und Lieferort).
Nun könnte man noch überlegen ob die Bäckereien auch Auftragsbestätigungen erhalten!? Wenn hier eine andere als die Rechnungsadresse angegeben ist, müsste darauf aber wohl auch die Rechnungsadresse mit aufgeführt sein (genau so wie der Liefer- / Leistungs- bzw. Erfüllungsort auf einem Lieferschein).
Hierzu könnte man noch überlegen ob nicht noch ein weiteres optionales Feld für eine "Kommissionsbezeichnung" eingeführt werden sollte! So könnte man dem Großhändler aus v.g. Beispiel dessen Abrechnung mit seinem Kunden erleichtern, indem man dort die von Ihm an die Bäckerei vergebene Kundennummer eintragen könnte.

Beim Beispiel mit der WBG und dessen Hausmeistern würde es doch eigentlich ebenso erfolgen:

1. Der WBG als Vertragspartner wir ein Debitorenkonto erstellt und deren Anschrift wiederum als Hauptadresse hinterlegt.
2. Je Objekt wird eine Lieferanschrift hinterlegt
3. Hausmeister werden als zusätzliche Anschriften für Angebot und Auftragsbestätigung erfasst.

Analog würde man ja auch bei größeren Firmen verfahren, wo es extra Abteilungen und/oder Ansprechpartner für Einkauf, Verkauf, Wareneingang, Abrechnung etc. gibt.

Etwas komplexer wird es bei Auftraggebern mit mehren Rechnungsempfängern. Etwa Hausverwaltungen welche für jede Abrechnungseinheit eine gesonderte Rechnungsanschrift und eine davon abweichende Lieferanschrift benötigen.
In der Vergangenheit musste man sich damit behelfen jeweils ein neues Debitorenkonto anzulegen. Ab Version 2.1.0 kann man auch dies nun unter einer einzigen Kundennummer ablegen:

Debitorenkonto: KD1234
- Hausverwaltung Schulze (Hauptanschrift)
- Objekt A (Lieferanschrift)
- Objekt A (Rechnungsanschrift)
- Objekt B (Lieferanschrift)
- Objekt B (Rechnungsanschrift)
usw.

Allerdings gibt es hierbei momentan noch den Makel, dass selbst bei Ausgabe unterschiedlicher Adressen immer noch die Namensfelder aus der Tabelle fkt_contact beigefügt werden.

Bei diesem Abrechnungsmodell fehlt höchstens noch ein Merkmal, welches die Beziehungen der einzelnen Zusatzanschriften definiert: WENN Lieferanschrift = Objekt A DANN Rechnungsanschrift = Objekt A. Hierzu könnte man aber wiederum das bereits oben angeregte Feld einer "Kommissionsbezeichnung" verwenden, indem man eine identische Objektnummer hinterlegt.

Wer bei so etwas lieber weiterhin eine extra Kundennummer vergeben möchte, kann das natürlich auch ab Version 2.1.0 weiterhin so machen. 😉 Genau so wie man ja auch weiterhin nur eine einzelne Rechnungs- & Lieferanschrift eingeben braucht. Fakturama sollte da eben m.E. möglichst flexiebel sein und als "schweizer Taschenmesser" möglichst viele Anwendungsfälle abdecken können. Wie es in den einzelnen Unternehmen im Endeffekt gehandhabt wird hängt natürlich von der individuellen Vertragsbeziehung/-gestaltung ab und bleibt jedem selbst überlassen.

Ich finde übrigens man muss das wie ein Adressbuch begreifen. B) Nur das die Adressen eben einem Debotoren-/Kreditorenkoto zugeordnet sind und ein Verwendungsmerkmal (Rechnungs- oder Lieferanschrift etc.) enthalten.
Ich persönlich werde nun selbst für jeden einzelnen Ansprechpartner eine extra Anschrift hinterlegen. Schließlich kann man da ja nicht nur Anschriften eintragen, sondern auch Rufnummern und Mailadresse.
Auch ist es oftmals so, das Firmen eine gesondert Mailadresse nur für den elektronischen Rechnungsversand haben. Und auch da kann man ja nun eine extra Rechnungsanschrift anlegen und darin diese Mailadresse speichern (auch wenn die übrigen Angaben ggf. identisch sind).

Gruß und :)-D
Matthew

Liebe Fakturama Gemeinde,

ist die Diskussion was den Adressstamm angeht für euch un relevant?

Es ist nur so das Ralf unseren Input benötigt um eventuell noch Änderungen vorzunehmen.

Das neue Forum gefällt mir übrigens sehr gut.

viele grüße 

Hallo Axel, Hallo Ralf,

ich muss das leider nochmal ausgraben, weil es mir gerade jetzt auf die Füße fällt.

ja, für mich ist das immer noch SEHR relevant. Ich möchte den Vorschlag von LastBoyScout unterstützen! Wie von ihm in

https://www.fakturama.info/community/hilfe-bei-installation-und-bedienung/import-kundendaten/#post-10957

vorgschlagen, würde ich mir eine strenge Trennung von Stammdaten (Kundennummer, UStID, Bankdaten, Notizen etc) und Adressdaten (Firma/Abteilung, Ansprechpartner, Adresse(n), Kontaktdaten, etc) wünschen, da dies bei mir zu 99% der Fall ist.

Viele Grüße und ein FETTES DANKE an das gesamte Fakturama-Team,

Labortechniker.

Hallo,

ich hatte dieses Thema auch schon mal angesprochen, der Post gilt so auch noch:

https://www.fakturama.info/community/fehler-verbesserungsvorschlaege/adressen-funktionieren-nicht/#post-16858

Mittlerweile habe ich es mir mit mehreren Kundenadressen je Kunde (siehe Bild) "gelöst".

Gruß Roland

Für mich hat sich mit der Umstellung auf die Version 2.1 die Unschönheit ergeben, dass aus Name und Vorname bei Lieferadresse jetzt Ansprechpartner wurde und ich diesen nicht mehr referenzieren kann. Vorher war das DELIVERY.ADDRESS.NAMEWITHCOMPANY, jetzt geht das ins Leere. Das Handbuch (Version 2.1.3) schweigt sich dazu aus. Wie kann man auf das Feld in Zusatzadresse #1, (Lieferanschrift) zugreifen, wenn man eine Rechnung schreibt?
Problematisch wird es, wenn man sogar mehrere Lieferanschriften hat. Dann müsste man sogar wissen, zu welcher Lieferung die Rechnung gehört. Das macht es nicht einfacher.
Zu dem Beispiel der Hausverwaltung mit den Hausmeistern von LastBoyScout: Es gibt den Fall, dass ein Hausmeister für verschiedenen Verwaltungen arbeitet. Dann geht der Weg von Axel Berse auch nicht so einfach, weil Hans Müller ja zumindest bei zwei Verwaltungen und/oder mehreren Objekten auftritt. Aber das könnte man ja vielleicht mit etwas Denken lösen.