burli
Anmeldungsdatum: 27. April 2007
Beiträge: 9000
Wohnort: Petersberg
|
Ich arbeite mich gerade in Python und GTK ein, allerdings für ein anderes Projekt. Wenn ich Tryton nutzen möchte muss ist sowieso vieles selbst ergänzen weil ich nicht glaube, dass die Standard Software alle meine Wünsche und Anforderungen erfüllen kann. Ich hab mir im laufe der Jahre ein paar Arbeitsabläufe angeeignet, die mir entgegenkommen, die aber von keinem mir bekannten Programm abgebildet werden. Ohne Anpassung läuft da nix. Ich schwanke aber noch, ob ich mit Tryton arbeiten soll oder ob ich mir Quick&Dirty selbst was schreiben soll
|
genios
(Themenstarter)
Anmeldungsdatum: 7. März 2008
Beiträge: 695
Wohnort: Goch
|
OK, ich mach mich dann mal an die Überarbeitung des Artikels und setze ein Tryton komplett neu auf. Möchte dazu den Thread nutzen um die ganzen Informationen zu sammeln und mit Euch abzugleichen Die Installation hat sich stark verändert und kann aus den Paketquellen erfolgen. Folgende Pakete sind für den Grundbetrieb nötig: * tryton-server * tryton-client * Starter anlegen * erster Login: Benutzer = Admin, Passwort = Passwort von der DB Erstellung * Modul aus Paketquelle installieren, oder Metapaket tryton-modules-all
* Tryton neu starten und Modul in Tryton installieren PostgreSQL Abschnitt kann eigentlich bleiben (User anlegen etc...) Config Datei des Tryton Server: /etc/trytond.conf Beim ersten Start muss die Datenbank doch immernoch eingerichtet werden, oder etwa nicht?
|
udono
Anmeldungsdatum: 24. Mai 2009
Beiträge: Zähle...
|
agaida schrieb: udono schrieb: agaida schrieb: Grundinstallation ist ja auch eher trivial, die ersten Stolperfallen, die den doch positiven Eindruck trüben, sind gefunden.
Hast du vielleicht ein Paar Stichpunkte für mich?
Richte mal Module ein. Versuche, mehrere Module zu markieren. Drücke auf auf den nicht vorhandenen Button zur Installation vormerken.
Thx, vermerkt. https://bugs.tryton.org/roundup/issue1750 Alternativ schalte die Vormerkung aus der Übersich per Shortcut um.
Ich bin mir gerade nicht sicher ob das frameworkseitig funktioniert.
Den technischen Teil kann man ja hier abhandeln. Das Ding ist genau so mistig aufgebaut, wie vergleichbare Lösungen im professionellen Umfeld. Wenn ich das Zeug verkaufen müsste, würde ich sagen 5 Manntage Installation, 14 Tage Anwenderschulung in verschiedenen Blöcken und mindestens 2-3 Tage Zusammenarbeit mit dem Steuerberater.
Wenn du eine einfache Einplatzlösung auf Basis von SQLite zum ausprobieren brauchst, kannst du auch Neso benutzen. Zeiten kalkulieren wir eher mit drei Stunden bis einem Tag Installation (auch nur bei exotischen Betriebssystemen), zwei Tage Anwenderschulung und maximal einem Tag Zusammenarbeit mit dem Steuerberater.
Installation technisch mag hinkommen, ich meinte Schlüsselfertig.
Tryton ist kein schlüsselfertiges Produkt[1]. Es handelt sich bei Tryton um ein "universelles Drei-Schichten Applikations-Framework [...] [,dass] die Basis einer kompletten Unternehmenslösung"[1] sein kann. Trotzdem ist Tryton so aufgebaut, das man es mit wenigen Modifikationen (anpassen der Druckvorlagen...) im allgemeinen einsetzen kann.
Das Problem sehe ich aber auch nicht beim Handwerker um die Ecke, KMU dürfte auch schneller gehen. Ab 5-10 Plätze Handel sind das die minmalen Zeiten, die immer passen. Das macht aber nichts, da Handel Mittelstand was anderes ist. Da ich in diesem Fall von ganz anderen Voraussetzungen ausgehe, wie bestehender Warenwirtschaft, muss ich das anders Kalkulieren. Da würde noch das Thema Datenübernahme/Migration hinzukommen. Das ist immer ein politischer Posten auf dem Angebot. Aber das ist ein ganz anderes Paar Schuhe. Bei Einzelplatz aus der kalten passt Dein Modell, da man ja eine Datenbank einmalig vorbereiten kann. Was ich immer hasse, wie die Pest ist FiBu-Einrichtung, Nummernkreise, Kontierungen, Mitarbeiter etc. Der Aufwand steigt bei größeren Firmen ganz rapide.
Ja sicher. Der höchste Aufwand bei uns als Implementierer ist die Bedarfsanalyse, die konzeptionelle Planung des Datenmodells und der Prozesse und die Gestaltung der Benutzungsschnittstelle. Migration ist schlecht kalkulierbar. Die eigentliche Programmierung ist im Verhältnis zu den genannten Aspekten inzwischen weniger aufwändig. Die endgültige Einrichtung haben wir weitgehend automatisiert.
Damit haben wir dann noch nicht einmal Daten im System. Ein einziger richtig großer Vorteil und Pluspunkt ist der vorhandene SKR03. Der reisst wenigstens auf der Seite der Buchhaltung alles wieder raus.
Schön zu hören. Wenn du Hilfe brauchst, schau mal unter http://tryton.origo.ethz.ch/wiki/doc oder besuch uns im IRC channel #tryton.de auf freenode.
Wer übrigens den Kontenrahmen verbrochen hat - Ja ich hab den Link gelesen. Trotzdem ist es nicht witzig, das ganze deutsche Gelumpe als englisch getaggt zu finden. Das macht es nicht unbedingt leichter, eine Mehrsprachigkeit durchzuziehen. wenn man sowas schon macht, dann prügelt man Deutsch in Deutsch und Englisch. Ich möchte aber an dieser Stellen nicht der Consultant sein, der der englischen Buchhalterin erklärt, dass sie das selbst übersetzen darf, wenn Sie ihren Kontenrahmen mehrsprachig haben möchte. Diesen Fall hatte ich schon einige Male, da schicke ich dann andere Leute vor.
Es scheint mir du hast das Konzept nicht verstanden. Alle Einträge in Tryton werden in der Sprache des Benutzers angezeigt. Rechnungen/Gutschriften/Angebote etc. werden in der Sprache der Empfängerpartei angedruckt. Wenn etwas nicht oder schlecht übersetzt ist, dann ist das ein Bug. Allerdings glaube ich nicht, das der Kontenrahmen über unübersetzte Bestandteile verfügt, weil wir (virtualthings und mb-solutions) ihn selbst gebaut und übersetzt haben und weiterhin pflegen. Du solltest vielleicht die Benutzungsschnittstelle auf Deutsch schalten[1], dann werden alle Sachen auch auf Deutsch dargestellt. Die Englische Übersetzung der grundlegenden Konten ist guter Programmierstil. Es soll einem anderssprachigen Entwickler ermöglichen auch an einem deutschsprachigen Kontenrahmen zu arbeiten. Zudem sind alle Kontenrahmen (Spanien, Deutschland, Belgien, ...) in Tryton mit gleichen englischsprachigen ids getaggt, so das man sich als Entwickler besser zurecht findet. Auf der Benutzungsoberfläche bekommt man davon nichts mit.
Alles in allem bin ich immer noch positiv überrascht und an einigen Stellen begeistert. Auf jeden Fall ist tryton eine Basis, auf der man sehr gut aufbauen kann.
Schön, das freut mich. Genau dazu ist Tryton auch gedacht, als Basis für eine eigene Anwendung.
Ich habe das jetzt erst mal an die Seite gepackt, das System läuft ja soweit 😉 Nächster Schritt wird sein, dass ich mir einen existierenden Navision-Kunden nehme und das Ding mal ein wenig mit Leben fülle. Von der Bedienung muss ich allerdings jetzt schon sagen, ein paar Kleinigkeiten fehlen einfach, da wird am Ende der Woche erst einmal das Lesen des Handbuchs angesagt sein.
Ja, es fehlen noch einige Grundmodule, die aber zum größten Teil bereits vorgeplant sind und von Zeit zu Zeit ergänzt werden, wie z.B. das von burli angesprochene Produktionsmodul[3] aka MRP I und II. Zudem fehlt die komplette Implementierung auf individuelle Anwendungsfälle. [1] http://www.tryton.org/de/index.html [2] http://code.google.com/p/tryton/wiki/UserFAQ#How_to_change_the_language? [3] http://code.google.com/p/tryton/wiki/TrytonMRPIntegration
|
udono
Anmeldungsdatum: 24. Mai 2009
Beiträge: 9
|
agaida schrieb: Schaun wir mal. Im Endeffekt sollte aber eine Handelsstückliste so schwer nicht zu programmieren sein.
Nein, ist nicht aufwändig, es fehlt nur jemand der es macht oder der etwas Geld in die Hand nimmt um es machen zu lassen.
Vor allem, wenn man eine Vorlage hat, die vom Feinsten funktioniert. Wie siehts eigentlich mit Artikelvarianten aus? Ich weiss, RTFM, aber eine anwort ja oder nein würde mir schon reichen.
Nein, nur ein alter Ansatz, den wir lange nicht mehr überarbeitet haben und der nur auf Version 1.2 läuft, also nicht mehr funktioniert.
|
udono
Anmeldungsdatum: 24. Mai 2009
Beiträge: 9
|
genios schrieb: OK, ich mach mich dann mal an die Überarbeitung des Artikels und setze ein Tryton komplett neu auf. Möchte dazu den Thread nutzen um die ganzen Informationen zu sammeln und mit Euch abzugleichen Die Installation hat sich stark verändert und kann aus den Paketquellen erfolgen. Folgende Pakete sind für den Grundbetrieb nötig: * tryton-server * tryton-client * Starter anlegen * erster Login: Benutzer = Admin, Passwort = Passwort von der DB Erstellung * Modul aus Paketquelle installieren, oder Metapaket tryton-modules-all
* Tryton neu starten und Modul in Tryton installieren PostgreSQL Abschnitt kann eigentlich bleiben (User anlegen etc...) Config Datei des Tryton Server: /etc/trytond.conf Beim ersten Start muss die Datenbank doch immernoch eingerichtet werden, oder etwa nicht?
Ja, es wird beim Login ein Button 'Datenbank anlegen' angezeigt, wenn keine Datenbank für den db-username aus der trytond.conf verfügbar ist.
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
Es scheint mir du hast das Konzept nicht verstanden. Alle Einträge in Tryton werden in der Sprache des Benutzers angezeigt. Rechnungen/Gutschriften/Angebote etc. werden in der Sprache der Empfängerpartei angedruckt. Wenn etwas nicht oder schlecht übersetzt ist, dann ist das ein Bug. Allerdings glaube ich nicht, das der Kontenrahmen über unübersetzte Bestandteile verfügt, weil wir (virtualthings und mb-solutions) ihn selbst gebaut und übersetzt haben und weiterhin pflegen. Du solltest vielleicht die Benutzungsschnittstelle auf Deutsch schalten[1], dann werden alle Sachen auch auf Deutsch dargestellt. Die Englische Übersetzung der grundlegenden Konten ist guter Programmierstil. Es soll einem anderssprachigen Entwickler ermöglichen auch an einem deutschsprachigen Kontenrahmen zu arbeiten. Zudem sind alle Kontenrahmen (Spanien, Deutschland, Belgien, ...) in Tryton mit gleichen englischsprachigen ids getaggt, so das man sich als Entwickler besser zurecht findet. Auf der Benutzungsoberfläche bekommt man davon nichts mit.
Schade eigentlich, konzeptionelle Arbeit ist eigentlich meine Stärke. Was mich irritiert, ist ungefähr folgendes Verhalten, dass ich für eine Übersetzugnstabelle so in Ordnung finde:
"The user used to execute this action" "Der Benutzer, der diese Aktion ausführt" "False" "ir.cron,user" "Deutsch" "Hilfe" "0" "ir"
"RFC 4646 tag: http://tools.ietf.org/html/rfc4646" "RFC 4646 tag: http://tools.ietf.org/html/rfc4646" "False" "ir.lang,code" "Deutsch" "Hilfe" "0" "ir"
"The id of the record in the database." "Die ID des Datensatzes in der Datenbank" "False" "ir.model.data,db_id" "Deutsch" "Hilfe" "0" "ir"
"The id of the record as known on the file system." "Die ID des Datensatzes wie im Dateisystem bekannt" "False" "ir.model.data,fs_id" "Deutsch" "Hilfe" "0" "ir"
"Module in which this field is defined" "Modul, in dem dieses Feld definiert ist" "False" "ir.model.field,module" "Deutsch" "Hilfe" "0" "ir"
"Module in which this model is defined" "Modul, in dem dieses Modell definiert ist" "False" "ir.model,module" "Deutsch" "Hilfe" "0" "ir" Ich mag mich täuschen, da es sich um den deutschen Kontenrahmen handelt, aber das ist mir ins Auge gefallen beim Überfliegen der Daten. Wenn das über die Modulsteuerung so in Ordnung ist, dann ok. Nur was mache ich mit meinem Spezialfall. Ausgehend davon, dass Englisch Fallbacksprache ist, würde die Sprache in diesen Fällen in Deutsch angezeigt werden. Was sieht aber meine englische Buchhalterin. Wenn das so richtig ist, habe ich nichts gesagt. "Aktiva" "" "False" "account.account.type.template,name" "Englisch" "Modell" "18" "account_de_skr03"
"Ausstehende Einlagen" "" "False" "account.account.type.template,name" "Englisch" "Modell" "19" "account_de_skr03"
"davon eingefordert" "" "False" "account.account.type.template,name" "Englisch" "Modell" "20" "account_de_skr03"
"Aufwendungen für die Ingangsetzung und Erweiterung des Geschäftsbetriebs" "" "False" "account.account.type.template,name" "Englisch" "Modell" "21" "account_de_skr03"
"Aufwendungen für die Währungsumstellung auf den Euro" "" "False" "account.account.type.template,name" "Englisch" "Modell" "22" "account_de_skr03"
"Anlagevermögen" "" "False" "account.account.type.template,name" "Englisch" "Modell" "23" "account_de_skr03"
|
udono
Anmeldungsdatum: 24. Mai 2009
Beiträge: 9
|
agaida schrieb: Es scheint mir du hast das Konzept nicht verstanden. Alle Einträge in Tryton werden in der Sprache des Benutzers angezeigt. Rechnungen/Gutschriften/Angebote etc. werden in der Sprache der Empfängerpartei angedruckt. Wenn etwas nicht oder schlecht übersetzt ist, dann ist das ein Bug. Allerdings glaube ich nicht, das der Kontenrahmen über unübersetzte Bestandteile verfügt, weil wir (virtualthings und mb-solutions) ihn selbst gebaut und übersetzt haben und weiterhin pflegen. Du solltest vielleicht die Benutzungsschnittstelle auf Deutsch schalten[1], dann werden alle Sachen auch auf Deutsch dargestellt.
Die Englische Übersetzung der grundlegenden Konten ist guter Programmierstil. Es soll einem anderssprachigen Entwickler ermöglichen auch an einem deutschsprachigen Kontenrahmen zu arbeiten. Zudem sind alle Kontenrahmen (Spanien, Deutschland, Belgien, ...) in Tryton mit gleichen englischsprachigen ids getaggt, so das man sich als Entwickler besser zurecht findet. Auf der Benutzungsoberfläche bekommt man davon nichts mit.
Schade eigentlich, konzeptionelle Arbeit ist eigentlich meine Stärke.
War nicht böse gemeint. Und ich glaube Dir, dass du bestimmt gut konzipieren kannst. Was ich meine ist, das die Konzeption des Tryton Frameworks, besonders des translation-objects nicht trivial ist ...
Was mich irritiert, ist ungefähr folgendes Verhalten, dass ich für eine Übersetzugnstabelle so in Ordnung finde:
"The user used to execute this action" "Der Benutzer, der diese Aktion ausführt" "False" "ir.cron,user" "Deutsch" "Hilfe" "0" "ir"
"RFC 4646 tag: http://tools.ietf.org/html/rfc4646" "RFC 4646 tag: http://tools.ietf.org/html/rfc4646" "False" "ir.lang,code" "Deutsch" "Hilfe" "0" "ir"
"The id of the record in the database." "Die ID des Datensatzes in der Datenbank" "False" "ir.model.data,db_id" "Deutsch" "Hilfe" "0" "ir"
"The id of the record as known on the file system." "Die ID des Datensatzes wie im Dateisystem bekannt" "False" "ir.model.data,fs_id" "Deutsch" "Hilfe" "0" "ir"
"Module in which this field is defined" "Modul, in dem dieses Feld definiert ist" "False" "ir.model.field,module" "Deutsch" "Hilfe" "0" "ir"
"Module in which this model is defined" "Modul, in dem dieses Modell definiert ist" "False" "ir.model,module" "Deutsch" "Hilfe" "0" "ir"
Ich mag mich täuschen, da es sich um den deutschen Kontenrahmen handelt, aber das ist mir ins Auge gefallen beim Überfliegen der Daten. Wenn das über die Modulsteuerung so in Ordnung ist, dann ok.
Ich habe nicht genau verstanden, was dich an dem Schnipsel oben irritiert?
Nur was mache ich mit meinem Spezialfall. Ausgehend davon, dass Englisch Fallbacksprache ist,
richtig
würde die Sprache in diesen Fällen in Deutsch angezeigt werden. Was sieht aber meine englische Buchhalterin. Wenn das so richtig ist, habe ich nichts gesagt.
Wie gesagt, es sind nur die grundlegenden Konten ins Englische Übersetzt. Deine englischsprachige Buchhalterin wird also einige Konten in Englisch sehen, und viele in Deutsch. Grundsätzlich lässt sich eine Kontenbezeichnung in Tryton in jede verfügbare Sprache übersetzen. Wenn du englische Bezeichnungen für die Konten brauchst, dann kannst du den SKR03 Kontenplan auch in englische Sprache übersetzt bei der DATEV erwerben. Damit könntest du die Übersetzungstabelle (de_DE.csv im Modul account_de_skr03) anpassen. Damit würde deine Buchhalterin alle Konten und die Bilanz/GuV Gliederung in Englischer Sprache lesen. Das gibt es vielleicht auch in Französisch. Die Tryton Module sind für die internationale Verwendung konzipiert. Es unterstützt verschiedensprachige Benutzungsschnittstellen und verschiedensprachige Dokumente. Der Namensraum im Quelltext ist durchgängig Englisch.
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
Der untere Schnipsel irritiert mich. Das sah in der Datenbank nicht "schön" aus. Ausgehend von dem von mir angenommenen Verhalten wäre es für die Benutzbarkeit und Übersetzbarkeit evtl. besser, wenn Quell- und Zielfeld gleich belegt wären, so wie das auch an anderen Stellen innerhalb der Übersetzungstabelle gehandhabt wird. Da das dann in jedem Fall richtig angezogen wird, macht es keinen Unterschied. Beim Editieren aber evtl. schon. Das ist jetzt aber die Vermutung des Tages. Feld Englisch → kopieren nach Deutsch und dann das Deutsche im englischen Feld überschreiben fände ich nicht so toll. Du hast übrigens den oberen Auszug genommen, an dem ich nichts zu mäkeln habe 😬 Ist auch nicht weiter tragisch, ich sehe so was nur auf mich zukommen, da ich genau diesen Anforderungsfall habe. Im Dokumentenlayout kommen dann auf jeden Fall italienisch und eventuell spanisch dazu. Aber das ist Zukunftsmusik und nicht weiter tragisch. Als ernsthaften Mangel würde ich das nicht bezeichnen, da man es in Sekunden abstellen kann, wenn nötig. Wenn es aber notwendig ist, zu ändern, gehört es an der Quelle geändert 😉 Ich habe in den letzten 2 Stunden noch ein wenig geschaut und bin immer noch begeistert. Es sieht so aus, als ob ich dann doch mal Python lernen sollte. Das ist aber auch kein Problem, da dass jetzt das dritte Projekt ist, wofür ich das brauchen könnte. Jetzt lohnt sich das Lernen, jetzt macht das wirklich Sinn. Das wäre dann die 3 Sprache mit P.
|
genios
(Themenstarter)
Anmeldungsdatum: 7. März 2008
Beiträge: 695
Wohnort: Goch
|
Habe den Artikel mal überarbeitet. Bin dabei lediglich auf die Installation von Tryton-Neso, der Client / Server Lösung sowie den Modulen eingegangen. Denke eine weitere Beschreibung würde den Rahmen hier sprengen. Man möge das ganze mal Korrektur lesen und evtl. Verbessern / Erweitern.
|
udono
Anmeldungsdatum: 24. Mai 2009
Beiträge: 9
|
genios schrieb: Habe den Artikel mal überarbeitet. Bin dabei lediglich auf die Installation von Tryton-Neso, der Client / Server Lösung sowie den Modulen eingegangen. Denke eine weitere Beschreibung würde den Rahmen hier sprengen.
Man möge das ganze mal Korrektur lesen und evtl. Verbessern / Erweitern.
Super! Vielen Dank. Ich schaue es mir bald bei Gelegenheit an.
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! ´*räusper*´ Euer Engagement in Ehren, aber für eine derartige Überarbeitung gehört der Artikel zunächst in eine Baustelle, da kann man dann werkeln, ohne dass ggf. Leute die noch unfertige Version versehentlich als "abgesegnete Anleitung" verwenden... so long hank
|
genios
(Themenstarter)
Anmeldungsdatum: 7. März 2008
Beiträge: 695
Wohnort: Goch
|
Es wurde nicht in die Baustelle verschoben weil die Überarbeitung in einem Rutsch gemacht wurde und die wirkliche Installation derweil recht einfach geworden ist.
|
udono
Anmeldungsdatum: 24. Mai 2009
Beiträge: 9
|
@genios: Ich habe die Anleitung noch mal leicht überarbeitet.
|
ChristianSL
Anmeldungsdatum: 26. Februar 2008
Beiträge: 45
Wohnort: Halle
|
Hallo, hätte ne kurze Frage (hoffe die passt hier her) bzgl. der Installation von Tryton: Ich nutze Lucid und würde aber gern Tryton auf Basis von MySql nutzen (kann mit Prostgre überhaupt nichts anfangen); besteht die Möglichkeit Tryton für Lucid zB aus den Maverick Quellen (v1.6 mit MySql)zu holen? Danke schonmal! Gruß
Christian
|
burli
Anmeldungsdatum: 27. April 2007
Beiträge: 9000
Wohnort: Petersberg
|
Ich würde die Sourcen von Tryton direkt von der Projektseite holen. Ist auch nicht mehr Aufwand als die Maverick Pakete zu portieren. Außerdem, wo ist das Problem mit PostgreSQL? Mit 3 Handgriffen ist das für Tryton eingerichtet.
|