Adress-Programm mit SoftMaker Office Unterstützung

[allegro:it]

Hallo,

wir, die Firma allegro:it, haben vor Kurzem die Version 5.0 von unserer Adress-Verwaltung ProAdress veröffentlicht. Neu in dieser Version ist u.a. die Anbindung von SM Office für Windows. Aus ProAdress können mit wenigen Mausklicks in TextMaker Einzelbrief, Serienbriefe, Formulare erzeugt bzw. ausgefüllt werden. PlanMaker kann zur Erstellung von Listen genutzt werden. Unterstützt wird nur die Windows Version, da eine Fernsteuerung von SM Office nur unter Windows technisch realisierbar ist.

Auf der ProAdress Homepage http://www.allegro-it.de/proadress.htm können Sie eine Testversion downloaden.

Vielen Dank für Ihr Interesse!

Thomas H. Grimm
allegro:it

[greifenklau]

117 Euronen für eine Adressverwaltung - na dann arbeite ich doch lieber mit der kleinen A-Verwaltung von SMO.

[FFF]

117 Euronen für eine Adressverwaltung - na dann arbeite ich doch lieber mit der kleinen A-Verwaltung von SMO.

tue das - oder schreibe eine eigene AV mit gleichem Funktionsumfang und verkaufe sie mir für weniger Euronen - mal sehen, wie lange es bis zur Insolvenz dauert <s,cr>

[martin-k]

Ich finde es sehr begrüßenswert, dass allegro:it mit ihrer Adressverwaltung TextMaker und PlanMaker unterstützt.

Das in TextMaker eingebaute Datenbankmodul ist nicht direkt mit ProAdress vergleichbar, und da es bei allegro:it eine kostenlose Testversion gibt, kann jeder Interessent ProAdress selbst unter die Lupe nehmen.

[Dewes]

Ich habe mal einen Schnelltest gemacht.

Erster Schönheitsfehler, als Default-Installationsordner wird nicht wie üblich im Programmordner installiert, ok man kann das anpassen, aber besser wäre es umgekehrt.

Der Autor hat versucht, eine eierlegende Wollmilchsau zu programmieren. Dadurch benötigt man eine längere Einarbeitungszeit, um mit der Anwendung professionell zu arbeiten, auch wenn die Bedieneroberfläche grundsätzlich in Ordnung ist.

Aus langjähriger bitterer Erfahrung habe ich mal die Felder "Geburtsdatum" und "IBAN" getestet. Es gibt keine Prüfroutine, die Fehleingaben abfängt. Beim Anlegen einer neuen Datenbank kann man keine Felder auswählen, was sogar bei TextMaker möglich ist. Die Exportroutine ist ausgefeilt, aber für den durchschnittlichen Anwender zu umfangreich und verwirrt ihn nur.

Die Anwendung hat bestimmt ihre Existenzberechtigung für bestimmte kaufmännische Anwendungen. Aber für die meisten Anwender, die mit SMO arbeiten, halte ich das Programm für zu voluminös.

[Jossi]

Für den durchschnittlichen Privatanwender mit <100 Adressen ist es ja auch nicht gedacht, da reicht die in TextMaker eingebaute Datenbank allemal aus, und das allegro-Programm ist weder vom Preis noch vom Funktionsumfang her von Interesse. Aber zur Steigerung der Bereitschaft, SoftMaker Office auch in größeren Unternehmen betrieblich einzusetzen, kann die Verfügbarkeit solcher ergänzender Module durchaus von Bedeutung sein (allegro bietet ja unter anderem auch Faktura- und Warenwirtschaftsprogramme an).

[allegro:it]

Hallo,

vielen Dank für Ihre Interesse, wir von allegro:it für jede Anregung dankbar.

Erster Schönheitsfehler, als Default-Installationsordner wird nicht wie üblich im Programmordner installiert, ok man kann das anpassen, aber besser wäre es umgekehrt.

Aus langjähriger bitterer Erfahrung habe ich mal die Felder "Geburtsdatum" und "IBAN" getestet. Es gibt keine Prüfroutine, die Fehleingaben abfängt. Beim Anlegen einer neuen Datenbank kann man keine Felder auswählen, was sogar bei TextMaker möglich ist. Die Exportroutine ist ausgefeilt, aber für den durchschnittlichen Anwender zu umfangreich und verwirrt ihn nur.

Die Anwendung hat bestimmt ihre Existenzberechtigung für bestimmte kaufmännische Anwendungen. Aber für die meisten Anwender, die mit SMO arbeiten, halte ich das Programm für zu voluminös.

Erlauben Sie mir ein paar Anmerkungen. Hier hat Forums-Mitglied Dewes es als Schönheitsfehler bezeichnet, ProAdress nicht per Voreinstellung im Programme Ordner zu installieren. Es gibt Gründe dafür, dass wir das so nicht vorgeben, deren genaue Erläuterung hier zu weit führen würden. Ferner ist der Programme Ordner nur eine Empfehlung und kein Muss. Ebenso viele Empfehlungen gibt es, die anraten ein Laufwerk für das System, eines für die Programme und eines für die Daten zu nutzen. Folgt man dem, hat kein Programm etwas im Programme Ordner, also auf dem System-Laufwerk, zu suchen.

Geburtsdatum: Natürlich gibt es eine Prüfroutine, falsche Datumsangaben werden nicht in der Datenbank gespeichert, also abgewiesen.

IBAN: Dieses Feld ist nach unserer Klassifizierung eher von untergeordneter Bedeutung für eine Adress-Verwaltung. Ferner sind in den einzelnen Ländern die IBAN Nummern verschieden aufgebaut. Daher müsste man für jedes Land eine entsprechende Prüfroutine entwickeln. Etwas zu viel Aufwand für ein untergeordnetes Feld. Oder anders, kann man machen, schlägt sich aber dann auch irgendwo im Preis nieder.

Unter Stern.de wurde vor Jahren bereits die Version 3.1 getestet. Der Tester hat es unter dem Titel "Adressverwaltung mit Zusatznutzen" so zusammengefasst: "Die klassische Adressdatenbank reicht mittlerweile nicht mehr aus. Eine teure CRM-Software mit integrierter Kontaktverwaltung ist aber oft zu teuer oder zu kompliziert in der Handhabung. Den Zwischenweg schlägt das Programm ProAdress ein."

Sehr zutreffend gesagt. Wie die meisten Kommentatoren hier ja auch bereits angemerkt haben, richtet sich ProAdress primär an Gewerbetreibende. Damit ist es sicher für den einen oder anderen Privatnutzer überdimensioniert. Da wir aber nun ab ProAdress V5.0 auch SMO unterstützen, sollten das die SMO Anwender auch wissen, daher dieses Posting. Auch wenn der überwiegende Teil der SMO Anwender keine Gewerbetreibende sind. Wir im Unternehmen setzen übrigens auch in großem Umfang SMO ein. Einige Gründe: Es ist schnell, kann mit großem Dokumenten, liegt von der Programm-Logik auf unserer Linie. Und, nicht zuletzt, es ist ein deutsches Produkt. So war es längst überfällig eine SMO Anbindung in ProAdress zu integrieren.

Vielen Dank.

Thomas H. Grimm
allegro:it
lösungen und service

[Dewes]

Geburtsdatum: Natürlich gibt es eine Prüfroutine, falsche Datumsangaben werden nicht in der Datenbank gespeichert, also abgewiesen.

Das kann ich so nicht bestätigen. Im übrigen wäre es gut, wenn bei einem falschen Eintrag ein Warnhinweis erfolgt, so dass man den Eintrag sofort korrigieren kann.

[bwst]

Geburtsdatum: Natürlich gibt es eine Prüfroutine, falsche Datumsangaben werden nicht in der Datenbank gespeichert, also abgewiesen.

Das kann ich so nicht bestätigen.

Für mich sieht das wie ein Datum aus. Ich würde auch den 30.02.1712 als gültiges Datum akzeptieren.

Also was ist jetzt genau das Problem?

[Dewes]

Also was ist jetzt genau das Problem?

Ganz einfach, das Datum 09.07.2014 kann kein gültiges Geburtsdatum sein, weil der Tag noch nicht war, sondern erst kommt. Heute haben wir doch erst den 16. Mai.

[FFF]

Also was ist jetzt genau das Problem?

Ganz einfach, das Datum 09.07.2014 kann kein gültiges Geburtsdatum sein, weil der Tag noch nicht war, sondern erst kommt. Heute haben wir doch erst den 16. Mai.

Na, darüber könnte man streiten. Vielleicht nicht gerade 2 Monate im voraus, aber wenn meine Frau vor zwei Stunden in die Wehen kam, hätte ich mich schon getraut, "morgen" als Geburtsdatum einzugeben
Also, ungültig würde ich das nicht nennen. Wenn ich das codete, hätte ich eine Konfigurationsschalter, der kontrolliert, ob mich das Programm auf "zukünftige" Geburtstage hinweisen soll.

[Panosis]

Die Frage ist eben, was man als Fehler ansieht. In einem Programm, das Horoskope berechnen soll, sähe ich das genannte Problem zum Beispiel nicht als Fehler an, da es ja durchaus sein kann, dass jemand ein Horoskop einer längst verstorbenen Persönlichkeit berechnen möchte, also vielleicht Friedrichs des Grossen, der ja bekanntlich vor 1800 gelebt hat, oder eben auch einen Zeitpunkt in der Zukunft astrologisch ergründen möchte. Dabei besteht dann eher umgekehrt das Problem, dass es programmiertechnisch wohl etwas schwerer wird, etwa auch Daten vor dem Jahr 1 n. Chr. zu berechnen (von den evidenten historischen Problemen einmal abgesehen).
Wie dem auch immer sei - im Rahmen einer Adressverwaltung für gewerbliche Zwecke dürfte es sich ein wenig anders verhalten. Da die Geschäftsfähigkeit ja im allgemeinen vom Alter abhängt, wäre es wenigstens sinnvoll, wenn man auf einen Blick das Alter erkennen könnte. Es gibt ja immer wieder Berichte darüber, dass sogar Behörden Betreibungen gegen Dreijährige einleiten oder Inkasso gegen längst verstorbene über 100jährige androhen. Wie man eine solche Altersprüfung implementiert, darüber lässt sich wohl mit Fug und Recht streiten.

[Dewes]

@FFF
Häng dich nicht an dem konkreten Datum auf, hier könnte ja auch 2020 stehen.

Es ist auch nicht gut, dass man eine IBAN erfassen kann, und das Feld "BIC" bleibt leer, ohne dass eine Fehlermeldung kommt.

Als Hobbyprogrammierer habe ich vor einigen Jahren für einen Freund eine kleine AV entwickelt, und versucht , alles abzufangen, was ein DAU anstellen kann. Neben einem zukünftigen Geburts-Datum wurde auch z.B. das erwähnt Datum 30.02. abgefangen und eben auch die logischen Verknüpfungen. Die Eingabe einer BLZ und dann keine Konto-Nr. produzierte eine Fehlermeldung.

[Panosis]

Da muss ich aber mal wieder den Besserwissermodus einschalten:

Da Zahlungsdienstleister auch durch die in der IBAN enthaltenen Informationen eindeutig identifizierbar sind, muss der BIC bei grenzüberschreitenden SEPA-Zahlungen nur noch bis Februar 2016 zusätzlich zur IBAN angegeben werden, im inländischen SEPA-Zahlungsverkehr wird er bereits seit Februar 2014 nicht mehr benötigt.

[allegro:it]

Hallo,

@ Dewes:
Sehen Sie, da liegt ein Missverständnis vor. Ich bin von einem formal falschen Datum ausgegangen, also z.B. 44.05.2014. Sie meinten aber ein inhaltlich falsches Datum. Nun lässt sich trefflich darüber streiten, ob ein zukünftiges GeburtsDatum ein falsches Datum der Stärke ist, es als falsch abzulehnen.

@FFF
... habe ich vor einigen Jahren für einen Freund eine kleine AV entwickelt, und versucht , alles abzufangen, was ein DAU anstellen kann. Neben einem zukünftigen Geburts-Datum wurde auch z.B. das erwähnt Datum 30.02. abgefangen und eben auch die logischen Verknüpfungen. Die Eingabe einer BLZ und dann keine Konto-Nr. produzierte eine Fehlermeldung.

Mit der selben Begründung könnte man die Eingabe einer Adresse mit Nachnamen (also natürliche Person) aber ohne Vornamen als unsinnig ablehnen, da ja jeder einen Vornamen hat. Keine Ortsangabe - kann keine gültige Adresse sein. Keine Straße - abgelehnt!
Wir betreiben das Geschäft nun seit 2000. Dabei hat es sich herausgestellt, dass es von vielen Anwendern als "unpraktisch" erachtet wird, inhaltliche Vorschriften einzubauen. Warum soll man nicht, bei einer unvollständigen Bankverbindung, schon mal die BLZ eintragen und die Kontonummer nachtragen können? Hinzu kommt, dass der Anwender nicht immer die Software wie vom Programmierer gedacht einsetzt. Daher haben wir uns dafür entschieden, in den Standardversionen unserer Programme den Anwender so wenig wie nötig zu bevormunden. Bei einer individuellen Anpassung kann der Anwender natürlich die eine oder andere Gültigkeitsprüfung definieren, die wir dann implementieren.

Ich wünsche Ihnen einen erfolgreichen Tag.

Thomas H. Grimm
allegro:it
lösungen und service