Hatte jetzt mal für einen Musterkunden allen Datenfelder gefüllt und in ne csv exportiert. Leider werden die besagten Felder auch beim exportieren nicht mit übergeben!? Das sollte also dringend erweitert werden, insbesondere auch für den Import!!!!

siehe dazu Bug #677.

Hallo Ralf,

bei mir wurde übrigens auch zu jedem importierten Kontakt zusätzliche eine leere Lieferanschrift und eine Bankverbindung eingetragen, obwohl im Datensatz der CSV keine diesbezüglichen Informationen übergeben wurden? Beim Import sollte eine zusätzliche Lieferanschrift nur angelegt werden, wenn in mindestens einem der betreffenden Felder delivery_ auch tatsächlich Informationen vorhanden sind!

Bei einem Blick in die DB mittels HeidiSQL wird ersichtlich, dass nicht nur in fkt_address eine zusätzliche leere Lieferanschrift abgelegt wurde, sondern auch in fkt_contact ein kompletter zweiter Eintrag (ebenfalls nur leere Felder, bis auf ID und Fremdschlüssel) erstellt wurde.
Hierbei wird auch ersichtlich, dass der Importwert date_added nur der Tabelle fkt_contact und auch nur im 1. Datensatz übernommen wurde. Dieser Wert sollte beim Import aber zwingend in den DATEADDED Feldern aller Tabellen übernommen werden.

Mir erschließt sich auch die Trennung der Daten in zwei Tabellen fkt_contact und fkt_address nicht ganz... wenn dies aber so erstellt wird, sollten insbesondere die Kontaktfelder (Telefon, Fax, Mobilfon, Mail, und Web) des 2. Datensatz (alternative Lieferanschrift) unbedingt auch nutzbar sein. Um also das bereits vorhandene kurzfristig in Fakturama verfügbar zu machen, sollten v.g. Felder einfach von Reiter Sonstiges zu den jeweiligen Adressen verschoben werden.

Längerfristig sollte dann der Feature-Wunsch #624 umgesetzt und evtl. auch eine Bereinigung / Umstrukturierung der Tabellen (z.B. Verschieben des Feld MANDATEREFERENCE in die Tabelle fkt_bankaccount usw.) angegangen werden.

Gruß
Matthew

Hallo Matthew,
das Problem mit den Kontaktdaten geht mir schon eine ganze Weile nach. Daß beim Import ein gänzlich leerer Datensatz angelegt wird ist nicht in Ordnung und muß behoben werden, da stimme ich Dir zu. Die Trennung zwischen Kontakt und Adresse rührt daher, daß ich plane, pro Kontakt mehrere Adressen erfassen zu können (bspw. bei Firmen, die aus verschiedenen Filialien bestehen).
Außerdem gibt es im Fakturama die Möglichkeit, eine Adresse manuell im Adreßeingabefeld zu erfassen (wenn es mal schnell gehen muß oder man keine Lust hat, den Kontakt über den Kontakteditor zu erfassen). Früher war das dann einfach nur ein Anhängsel an den Kontakt. In der Version 2 habe ich das so gemacht, daß diese manuell eingegebene Adresse dann auch wirklich im Adreßdatensatz hängt. In diesem Fall sind aber die Felder des Kontaktdatensatzes leer, weil es eben nichts gibt, was man dort eintragen könnte.
Zu einem Kontakteintrag gehören aktuell zwei Einträge in der Datenbank, einer für die "normale" Rechnungsadresse, einer für die evtl. abweichende Lieferadresse.

Hallo Ralf,

eigentlich passt das nun nicht mehr zu o.g. Thema, will aber der Einfachheit halber dennoch hier Antworten...

Die Trennung zwischen Kontakt und Adresse ist ja absolut richtig, insbesondere im Hinblick auf mehr als zwei Adressen je Kontakt. Mir ist klar das man dabei nach Möglichkeit auf einer historisch gewachsene Datenbankstruktur aufbauen will. Aufgrund dieser Umgehungsstrategie kommt es aktuellen aber zu einer Gefährdung der Datenintegrität. Die Umsetzung bedarf daher eben einer konsequenten Trennung von einmaligen und evtl. mehrfach vorkommenden Daten.

Bislang sind in fkt_address ja eigentlich nur Straße, PLZ, Ort und Land hinterlegt, die dazugehörigen Namen werden aber weiterhin in fkt_contact abgelegt. Dies hat dann natürlich unschöner Weise zur folge das bei jeder zusätzlichen Anschrift auch ein weiterer Kontakteintrag angelegt werden muss, nur um Namen und Fremdkey der Adresse zu hinterlegen. Eigentlich soll doch aber nur eine abweichende Lieferanschrift gespeichert werden und nicht auch noch ein alternativer Kontakt bei dem zu allem Übel auch noch alle übrigen Felder leer oder ungenutzt (z.B. Telefonnummern usw.) bleiben.
Entfernt man nun das Häkchen bei "Abweichende Lieferanschrift", geht nur der Bezug FK_ALTERNATECONTACT verloren und in der DB bleiben gleich zwei Karteileichen zurück. Auf diese kann über Fakturama nicht mehr zugegriffen und auch der Bezug leider nicht wieder hergestellt werden. Wird das Häkchen erneut gesetzt, wird in jeder der beiden Tabellen wieder ein neuer Datensatz angelegt. In diesem Fall sind es nun also bereits sechs Datensätze für einen Kunden mit abweichender Lieferanschrift (kann aber auch sehr schnell noch mehr werden).

Nachfolgend mein Vorschlag:
In der Tabelle fkt_contact sollten am besten nur die einmaligen Daten enthalten sein und es sollte zu jedem Kreditor / Debitor auch wirklich nur ein Eintrag existieren!
Die Datenfelder zu denen ein oder mehr Einträge existieren können, sollten hingegen in fkt_address abgelegt werden, wo es dann auch mehrere bzw. sogar beliebig viele Einträge je Kreditor / Debitor geben kann.
Um die Relation zwischen diesen beiden Tabellen herzustellen, sollten die Fremdkeys in einer extra Tabelle fkt_contact2address gepflegt werden. Hier kann dann auch die Art der Beziehung (Rechnungsanschrift, Lieferanschrift usw.) definiert werden.

Innerhalb von Fakturama sollte die Maske dann wie bereits von dir Vorgeschlagen (noch erweitert um Telefonnummern, Mailadresse usw.) umgesetzt werden:
Eine weitere Anschrift wird dann bei Bedarf [+] neu hinzugefügt.
Beim Löschen einer dieser Adressen wir nicht nur dessen Bezug in fkt_contact2address gelöscht sonder auch der Datensatz in fkt_address entfernt, so das auch in der DB keinerlei Geisterdaten zurück bleiben.

Sofern ein Kontakt oder eine bestimmte Adresse nicht gelöscht sondern nur gesperrt werden soll, kann in den Tabellen ein Bitwert BLOCKED auf 1 gesetzt werden. Dieser Kontakt oder auch nur die betreffende Adresse ist dann ausgegraut und nicht verwendbar. Um diese danach evtl. Löschen zu können, muss erst wieder die Freigabe erfolgen. Dies wäre von Vorteil, um in Hinblick auf zukünftig geplante Nutzerprofile entsprechende Rechte zuweisen zu können.

Hier dazu mal die betreffende Tabellenstruktur meines Vorschlag:

-- Neue Struktur der Tabelle fkt_contact
CREATE TABLE IF NOT EXISTS `fkt_contact` (
 `ID` bigint(20) NOT NULL AUTO_INCREMENT,
 `DTYPE` varchar(31) COLLATE utf8_unicode_ci DEFAULT NULL,
 `CONTACTTYPE` int(11) DEFAULT NULL,
 `CUSTOMERNUMBER` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `SUPPLIERNUMBER` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `MATCHCODE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Bezeichnung z.B. 1. Zeile des Firmennamen oder Nachname Vorname',
 `GLN` bigint(20) DEFAULT NULL,
 `NOTE` text COLLATE utf8_unicode_ci,
 `DISCOUNT` double DEFAULT NULL,
 `RELIABILITY` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `VATNUMBER` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `VATNUMBERVALID` bit(1) DEFAULT b'0',
 `USENETGROSS` smallint(6) DEFAULT NULL,
 `USESALESEQUALIZATIONTAX` bit(1) DEFAULT b'0',
 `WEBSHOPNAME` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `DATEADDED` date DEFAULT NULL,
 `MODIFIED` date DEFAULT NULL,
 `MODIFIEDBY` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BLOCKED` bit(1) DEFAULT b'0' COMMENT 'Anstatt DELETED, wass gem. DSGVO ja dann auch tatsächlich geschehen muss',
 `VALIDFROM` date DEFAULT NULL,
 `VALIDTO` date DEFAULT NULL,
 `FK_CATEGORY` bigint(20) DEFAULT NULL,
 `FK_PAYMENT` bigint(20) DEFAULT NULL,
 PRIMARY KEY (`ID`),
 KEY `FK_FKT_CONTACT_FK_CATEGORY` (`FK_CATEGORY`),
 KEY `FK_FKT_CONTACT_FK_PAYMENT` (`FK_PAYMENT`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Tabelle der Kreditoren und Debitoren (Nur ein Eintrag je Kontakt)';

-- Neue Struktur der Tabelle fkt_address
CREATE TABLE IF NOT EXISTS `fkt_address` (
 `ID` bigint(20) NOT NULL AUTO_INCREMENT,
 `COMPANY` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `GENDER` int(11) DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `TITLE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `FIRSTNAME` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `NAME` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `STREET` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `ZIP` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `CITY` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `CITYADDON` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `COUNTRYCODE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BIRTHDAY` date DEFAULT NULL,
 `PHONE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `FAX` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `MOBILE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `EMAIL` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `WEBSITE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `MANUALADDRESS` varchar(4096) COLLATE utf8_unicode_ci DEFAULT NULL,
 `DATEADDED` date DEFAULT NULL,
 `MODIFIED` date DEFAULT NULL,
 `MODIFIEDBY` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BLOCKED` bit(1) DEFAULT b'0' COMMENT 'Anstatt DELETED, wass gem. DSGVO ja dann auch tatsächlich geschehen muss',
 `VALIDFROM` date DEFAULT NULL,
 `VALIDTO` date DEFAULT NULL,
 PRIMARY KEY (`ID`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Tabelle mit beliebig vielen Adressen je Kreditor / Debitor';

-- Neue Tabelle fkt_contact2address
CREATE TABLE IF NOT EXISTS `fkt_contact2address` (
 `FK_CONTACT` bigint(20) NOT NULL COMMENT 'fkt_contact.ID',
 `FK_ADDRESS` bigint(20) NOT NULL COMMENT 'fkt_address.ID',
 `RELATION` int(11) DEFAULT NULL COMMENT 'Art der Beziehung: NULL für alle Belegarten ansonsten z.B. 1 = Angebot, 2 = Rechnung, 3 = Lieferung usw. oder evtl. auch 23 = Rechnung und Lieferung',
 UNIQUE KEY `FK_CONTACT_FK_ADDRESS` (`FK_CONTACT`,`FK_ADDRESS`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Relation zwischen den Tabellen fkt_contact und fkt_address';

-- Neue Struktur der Tabelle fkt_bankaccount
CREATE TABLE IF NOT EXISTS `fkt_bankaccount` (
 `ID` bigint(20) NOT NULL AUTO_INCREMENT,
 `ACCOUNTHOLDER` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `ACCOUNT` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT='Alte Bezeichnung NAME',
 `IBAN` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BANKNAME` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BIC` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BANKCODE` int(11) DEFAULT NULL,
 `MANDATEREFERENCE` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Verschoben aus fkt_contact',
 `DATEADDED` date DEFAULT NULL,
 `MODIFIED` date DEFAULT NULL,
 `MODIFIEDBY` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
 `BLOCKED` bit(1) DEFAULT b'0' COMMENT 'Anstatt DELETED, wass gem. DSGVO ja dann auch tatsächlich geschehen muss',
 `VALIDFROM` date DEFAULT NULL,
 `VALIDTO` date DEFAULT NULL,
 PRIMARY KEY (`ID`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Tabelle mit den Bankdaten';

-- Neue Tabelle fkt_contact2bankaccount
CREATE TABLE IF NOT EXISTS `fkt_contact2bankaccount` (
 `FK_CONTACT` bigint(20) NOT NULL COMMENT 'fkt_contact.ID',
 `FK_BANKACCOUNT` bigint(20) NOT NULL COMMENT 'fkt_bankaccount.ID',
 `RELATION` int(11) DEFAULT NULL COMMENT 'Art der Beziehung: NULL für alle Arten ansonsten z.B. 1 = Lastschrift, 2 = Gutschrift',
 UNIQUE KEY `FK_CONTACT_FK_BANKACCOUNT` (`FK_CONTACT`,`FK_BANKACCOUNT`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Relation zwischen den Tabellen fkt_contact und fkt_bankaccount';

Zur Deklarierung der Beziehungen könnte man anstatt dem Datentyp int auch einen Bitwert nehmen, wobei dann jedes Bit für eine bestimmte Belegart steht.

Gruß
Matthew

P.S. Warum verwendest du als Engine eigentlich MyISAM und nicht InnoDB? Bei letzterer kann doch Transaktionssicherheit und referenzielle Integrität über Fremdschlüssel direkt gewährleistet werden!

Hallo Matthew,
ich werde mir das mal überlegen. Das Problem ist, daß ich ja dafür sorgen muß, daß die Daten aus der aktuellen Struktur in die neue übernommen werden. Ich bau die Tabellen nicht selber, sondern laß die automatisch anlegen (per EclipseLink bzw. Liquibase). Wahrscheinlich macht Eclipselink standardmäßig MyISAM, ich hab das nicht explizit angegeben.
Ich habe über dem Thema vor einigen Monaten schon mal ziemlich gebrütet, aber so richtig zufrieden war ich mit meiner Lösung auch nicht. Ich denke mal drüber nach, ob Dein Vorschlag umsetzbar ist. Besten Dank erst mal.

Hallo Ralf,

mit EclipseLink bzw. Liquibase kenne ich mich leider so gar nicht aus... ich werkele diesbezüglich immer von Hand und hab in Sachen Programmieren auch nur von PHP etwas Ahnung. Die Überführung der Daten bereitet natürlich Kopfzerbrechen. Da es aber mit der momentan Lösung zu Inkonsistenzen und Datenbankleichen kommt, ist eine neue Struktur m.E. unumgänglich. Der Vorteil meines Lösungsvorschlag ist dabei ja nicht nur die Sicherung der Datenintegrität, sondern gerade auch die Flexibilität und Zukunftsfähigkeit dank quasi beliebig vieler Adressen je Geschäftskontakt.

Habe mir erlaubt dazu mal ein neues Tiket zu öffnen.

Gruß
Matthew

P.S. Ich hoffe mein Vorschlag und die Umfangreichen Erläuterungen Helfen auch wirklich weiter.

Hallo Matthew,
mir hilft das tatsächlich weiter, weil man sich an manchen Stellen einfach nur noch im Kreis dreht und keine neuen Ideen hat. Wenn man dann mal einen neuen Gedankenanstoß bekommt geht das gleich viel besser 🙂 Von daher - alles paletti 🙂
Das Ticket sieht gut aus!

Hallo,

ich habe im Bugtracker gesehen, dass ein Update erst in v.2.1.1 vorgesehen ist. Die Einteilung in "Unschönheit" finde ich allerdings nicht ganz passend (kenne die Abstufungen aber auch nicht). Ich möchte Fakturama gern einsetzen, und stehe vor der Herausforderung unsere Kunden zu importieren.
Per CSV ist das zwar möglich, aber wenn die Hälfte der Informationen nicht mit übernommen werden ist das nicht unschön, sondern leider eher unbrauchbar. Einen anderen Weg für einen Import als Workaround, sodass ich alles im System habe, gibt es aktuell nicht, oder?

Viele Grüße

Moin, einen anderen Weg gibt es derzeit leider nicht. Das Problem ist, daß in der 2.1.0 schon ziemlich viele wichtige Dinge drin sind. Ich bin hier auch nicht Vollzeit dran, sondern nur in meiner Freizeit. Deswegen geht's gerade etwas schleppend voran, weil ich auch noch andere Verpflichtungen habe. Leider bin ich hier auch noch Einzelkämpfer in der Weiterentwicklung...