Am Montag, 4. März 2002 10:00 schrieb Hannes Vogelmann:
Praktisch wären vielleicht noch:
- eine einfache Lohnbuchhaltung - Scenario - zusätzliche Felder für alternative Lieferanten und deren Angebote
Vielleicht weniger für die Holzverarbeitung wichtig aber für viele andere:
eine Datenbank, die festlegt, aus welchen Zulieferartikeln ein Endprodukt hergestellt wird, damit Lagerhaltung und Auftragseingang vernünftig synchronisiert werden können und ensprechende Bestellungen automatisch genriert und in die Fakturierung/Buchführung übernommen werden können.
Letzter Punkt ist der Schwachpunkt (weil meistens sehr speziell zugeschnitten) einiger kommerzieller Fakturierungsprogramme, z.B. "Top Faktura" für Windows. Ich habe mal versucht so ein Feature mit M$Access für meine Firma zu erstellen, bin aber kläglich gescheitert.
cu Hannes
Hi, ich schreib' mal einfach meine ersten drei Gedanken nieder: Ein Fakturierungsprogramm ist zuerst einmal nicht branchenspezifisch, also weder Tischler noch Maler noch EDV-Händler, denn Grundanforderungen sind immer gleich: Kunden und Lieferanten und Artikel verwalten, gegebenenfalls einen kleinen Webshop anbinden etc.. Eine wesentlich interessantere Frage ist, wie umfangreich und flexibel das Projekt werden soll. Ich bin grundsätzlich der Meineung, dass es halbgare Produkte bereits gibt. Das mit den Artikeln ist klar, es gibt auch Artikel, die sich im Sinne einer Erzeugnisstruktur aus einzelnen `Unterartikeln` zusammensetzen. Zu jedem Artikel sollte es nicht nur einen EK und einen VK geben. Vielmehr bekomme ich einen Artikel durchaus von verschiedenen Lieferanten in unterschiedlichen Preisen in unterschiedlichen Qualitäten. Ein 'Lieferanten-Rating' sollte möglich sein, also ein Hauptlieferant, und wenn der nicht in Frage kommt, muss der Besteller sofort sehen, bei welchem Lieferanten er nun zu bestellen hat. Kunden und Lieferanten sind eigentlich identisch, sie unterscheiden sich nur durch ein Flag und könnten von daher in einer gemeinsamen Tabelle stehen. Natürlich kann ein Lieferant auch mal als Kunde auftreten... Zu Kunden und Lieferanten sollte es beliebige Ansprechpartner mit jeweils eigener Telephonnummer, Mailadresse und Straße etc. geben. Interessant wird es bei der Kalkulation. Denn spätestens hier scheiden sich die Geister. Und hier ist auch der Punkt, an dem ich für einen modularen Aufbau bin: Es kann mehrere Kalkulationsmodule geben (Tischler, Maler, EDV-Kaufleute), und jeder schaltet die Module ab, die er nicht sehen möchte. Die zugehörigen Datenbankfelder können ja durchaus noch da sein, aber UI-technisch sieht der Maler eben nur das Malerkalkulationstool. Multilingualität: Es sollte anderen Leutchen möglichst einfach gemacht werden, das Tool in die jeweilige Sprache zu lokalisieren, damit möglichst viele Leute was von unserer Arbeit haben. Ease of use: Das Produkt sollte einfach zu installieren, in Betrieb zu nehmen und zu nutzen sein. Stammdaten: Stammdaten sollten sich für die verschiedensten Gewerke über ein Script in die Datendatei einlesen lassen, so dass die Content-Leute (wie beispielsweise ich ;-) ) fertig vorkonfektionierte Scripte anbieten können, mit denen die Datendatei eifach auf den entsprechenden Stand gebracht werden kann. Ich kann euch bei Bedarf Kraft meiner beruflichen Ausbildung ziemlich viele Specs der Datenbank erarbeiten, also wie das Produkt funktionieren soll etc. Auch kann ich testentestentesten. Wie sieht euer Interese aus: Habt Ihr Bock auf was richtig großes oder soll es doch eher klein und beschaulich werden? Gruß ce -- Christoph Eckert