projekt kivitendo

• Die Idee mit einer zentralen Zeile drüber oder drunter gefällt mir gut. Es sollte aber die Möglichkeit gegeben werden vorhandene Positionen im nachhinein zu editieren.
• Eine Sortierfunktion nach der ich nach Artikelnr, Artikelbezeichnung oder Artikelgruppe und vielleicht auch Preis und Projekt aufsteigen bzw absteigend sorieren kann (ähnl. den diversen Listen) halt ich auch noch für Sinnvoll.
• Die Möglichkeit die Artikelbezeichnung zu ändern sollte weiterhin gegeben sein. Ich hab zum Beispiel bei mir einen Dummyartikel für Text in der Rechnung wenn das z.B als Überschrift genutzt werden soll oder ich keinen neuen Artikel anlegen will.
• Die alte Verschiebefunktion (ändern der Position) finde ich zwar nicht besonders aktraktiv, aber doch recht kompfortabel und schnell. Ich denke schneller als wenn ich z.B. 20 mal klicken muss wenn ich Pos 25 auf Pos 5 haben will. Hier wär aber auch eine Verschiebefunktion mit anfassen ähnl. die dem Pflichtenheft aktraktiv und schnell.
• Ich habe auch öfters das Problem mit dem Langtext, dass ich z.B. nicht weiss was ich wo reingeschrieben habe, ich nutze das für Dienstleistungen wo ich nochmal genauer beschreibe was getan wurde. Hier fände ich einen Tooltip gut
  Technisch kann ich Dir gerade keine Hinweise geben.
  Grüße
  Werner

Damit es nicht verloren geht (und für mich als Erinnerung), hier einige Kommentare aus dem irc:

• 15:48 <mosu> »Besser gefällt mir jedoch eine zentrale Zeile oben,
  wo immer die neuen Artikel eingegeben werden…« ←
  Zustimmung. So haben wir auch eine ähnliche Maske für
  opendynamic umgesetzt. Nachteil ist, wenn man viele
  Positionen hat und dann oftmals scrollen muss, weil
  man doch vergessen hat, einen Punkt hinzuzufügen…
• 15:50 <mosu> »Welche Masken werden wie im Code gleich behandelt?«
  Würde ich so machen wie im alten Code: ein Controller
  für alle vier in oe gespeicherten Typen. Die sind sich
  von der Funktionalität her auch deutlich am
  Ähnlichsten.
• 15:50 <gorash> da ihr das beide schonmal gemacht habt, wäre es
  möglich das zeile oben/unten variabel zu halten? ich
  sag explizit nicht konfigurierbar, aber zumindest,
  dass man die zeile ohne viel stress
  hinundherschieben kann
• 15:51 <mosu> Lieferscheine hingegen sind schon ne Ecke anders,
  Rechnungen dito, allerdings solltest du tunlichst
  zusehen, dass relativ viel des gemeinsamen Codes in
  möglichst gut gekapselten (= kleinen und nur jeweils
  ein Ziel verfolgenden) Helferfunktionen in
  SL/Controller/Helper/* landet. Welche das sind, wirst
  du spätestens dann feststellen, wenn du den zweiten
  Controller anfängst – und hier mach dir nicht zu v
• 15:51 <mosu> iel Stress. Refactoren ist nicht ...
• 15:51 <mosu> ... böse, und von Anfang an alles gleich exakt richtig
  aufzusplitten ist praktisch unmöglich.
• 15:52 <mosu> Code aus PTC kopieren: bitte auf KEINEN Fall und so
  schnell es geht wieder weg-refactoren und den
  entsprechenden Code nur im PTC haben. Sinn und Zweck
  vom PTC war, aus den bisher grob sieben Stellen, an
  denen Belege berechnet werden, langfristig nur noch
  eine einzige zu machen.
• 15:53 <mosu> Anpassungen am PTC sind hingegen natürlich sinnvoll
  und gewünscht, vor allem, wenn du nur eine Position
  berechnen musst und nicht alle gleichzeitig.

Hallo Bernd,
hab mir gerade den Augtragscontroller angeschaut
EInmal bekomm ich den Fehler
Fehler: get_objects() - DBD::Pg::st execute failed: ERROR: column t1.delivery_plan_show_value_of_goods does not exist LINE 34: t1.delivery_plan_show_value_of_goods, ^ at /usr/local/share/perl/5.18.2/DBIx/Log4perl/st.pm line 62. at /opt/kivi/kivitendo-erp/SL/DB/Helper/PriceTaxCalculator.pm line 67.
Das liegt aber vermutlich daran, dass meine DB schon auf 3.3 ist.
Aber was ich anregen wollte ist,
dass die generierten Positionszeilen ab einer bestimmten scrollbar werden, sodass die Gesamtsumme usw. und die Buttons immer sichtbar sind.

Hallo Werner,

Werner Hahn schrieb:

Hallo Bernd,
hab mir gerade den Augtragscontroller angeschaut

Sehr gut, vielen Dank - da wollte ich Dich nämlich noch drum bitten. Es geht definitiv vieles noch nicht. Evtl. kannst Du aber schon was zur Geschwindigkeit sagen.

EInmal bekomm ich den Fehler
Fehler: get_objects() - DBD::Pg::st execute failed: ERROR: column t1.delivery_plan_show_value_of_goods does not exist LINE 34: t1.delivery_plan_show_value_of_goods, ^ at /usr/local/share/perl/5.18.2/DBIx/Log4perl/st.pm line 62. at /opt/kivi/kivitendo-erp/SL/DB/Helper/PriceTaxCalculator.pm line 67.
Das liegt aber vermutlich daran, dass meine DB schon auf 3.3 ist.

Ja, vermutlich. Ich kann das mal rebasen - dann würde ich aber den Branch auf github komplett ersetzen. Ein einfaches pull geht dann wohl nicht mehr.

Aber was ich anregen wollte ist,
dass die generierten Positionszeilen ab einer bestimmten scrollbar werden, sodass die Gesamtsumme usw. und die Buttons immer sichtbar sind.

Ja - das habe ich auf dem Schirm und auch gestern mit Geoffrey schon drüber gesprochen.

Wenn Du das rebased hast kann ich die Geschwindigkeit testen, bisher bekomme ich halt den oben genannten Fehler.

Hab auch zum testen kurz lokal rebased. Da machen ja nur die Menüeinträge Probleme, und die sind einfach zu fixen. Und ja, ist bei feature branches üblich, dass du ab und zu force push machst. Dafür ist es ja in nem Branch.

Was mir beim testen aufgefallen ist:

- Enter im Eingabeblock oben triggert Erneuern, was alles cleared. Unintuitiv, sollte eher auf den Abschicken button gehen
- Wollte Menge evtl eher auf 1 defaulten?
- Würdst Du Patches akzeptieren, wenn ich das html etwas umbaue? wäre guter Zeitpunkt die table-hell loszuwerden und auf sauberes html5 zu gehen. Ausserdem sind da noch ein paar kaputte ecken wie divs mit name property, doppelte ids etc.
- Die alten Controller haben absichtlich nicht die Möglichkeit die Ware in einer Position zu ändern, weil das ganz haarig wird. Soll das hier funktionieren? Hast Du das gut durchdacht?

Sven Schöling schrieb:

Was mir beim testen aufgefallen ist:

- Enter im Eingabeblock oben triggert Erneuern, was alles cleared. Unintuitiv, sollte eher auf den Abschicken button gehen

Ja - da bin ich gerade dran.

- Wollte Menge evtl eher auf 1 defaulten?

Wenn man das Mengenfeld leer läßt, so wird Menge 1 übernommen. Genau wie bei Preis und Rabatt. Bei leerem Feld werden da die Werte aus den Stammdaten gesetzt.
Allerdings fehlt ja noch Beschreibung und Langtext. Hierbei ist der default ja erst bekannt, wenn die Ware ausgewählt wurde (gilt auch für Preis/Rabatt). Wenn man den anpassen will, ist es blöd, erst hinzuzufügen und dann zu ändern. Deshalb habe ich überlegt, dass nach der Auswahl per Picker in einem ersten ajax-call die default-Werte in die Eingabezeile geladen werden (bzw. mit fat_set_item??) und hoffe, dass das nicht zu träge wird.

- Würdst Du Patches akzeptieren, wenn ich das html etwas umbaue? wäre guter Zeitpunkt die table-hell loszuwerden und auf sauberes html5 zu gehen. Ausserdem sind da noch ein paar kaputte ecken wie divs mit name property, doppelte ids etc.

sicher

- Die alten Controller haben absichtlich nicht die Möglichkeit die Ware in einer Position zu ändern, weil das ganz haarig wird. Soll das hier funktionieren? Hast Du das gut durchdacht?

Nein - nicht durchdacht. Will ich auch ändern. Mein erster Ansatz war, keine zentrale Eingabe-Zeile zu haben, sondern, wie bei den alten Masken, unten immer eine leere Zeile anzufügen. So war Pos-Zeile und Eingabe-Zeile gleich. Deshalb ist das noch so.

Wenn man das Mengenfeld leer läßt, so wird Menge 1 übernommen. Genau wie bei Preis und Rabatt. Bei leerem Feld werden da die Werte aus den Stammdaten gesetzt.
Allerdings fehlt ja noch Beschreibung und Langtext. Hierbei ist der default ja erst bekannt, wenn die Ware ausgewählt wurde (gilt auch für Preis/Rabatt). Wenn man den anpassen will, ist es blöd, erst hinzuzufügen und dann zu ändern. Deshalb habe ich überlegt, dass nach der Auswahl per Picker in einem ersten ajax-call die default-Werte in die Eingabezeile geladen werden (bzw. mit fat_set_item??) und hoffe, dass das nicht zu träge wird.

Genau dafür habe ich fat_set_item gebaut, weil mosu das für so etwas brauchte. Der garantiert Dir, dass der trigger erst kommt, wenn alle Daten vorhanden sind. Probiers aus, es sollte nicht allzu langsam sein.

Zur Info: Ich habe rebased und die neue "Version" auf github mit force gepusht.

Um die Maske übersichtlich zu gestalten, möchte ich gerne zum Ändern von Angaben und Details in Positionszeilen ein Popupfenster verwenden. Also ungefähr so: Eingabe der Positionen an zentraler Stelle (oben) mit Picker, Menge, evtl. Betrag. Die hinzugefügten Pos. werden dann unten ohne Input-Felder (also nur Text) aufgelistet. Wenn ich nichts mehr ändern muss, ist alles übersichtlich und ok. Will ich eine Pos. ändern, klicke ich auf die Zeile und das Popup mit den Input-Feldern geht auf. Wird es geschlossen, werden die Angaben übernommen und Beträge und Steuern neu berechnet.

Mit Werner hatte ich das schon besprochen, er fand die Idee gut - gibt es da weitere Ansichten?

Und technisch: Muss ich von allen Zeilen (auch beim Laden eines vorhandenen Belegs) die Inputfelder/Popups schon erzeugen? Denn sonst würden ja Felder fehlen, z.B. beim Speichern (also, wenn ich z.B. den Langtext im Popup habe und bei einer Pos. das Popup nicht geöffnet wurde, so gibt es auch kein longdescription-Feld, was mit assign_attributes zugeordnet werden würde). Oder geht das auch anders (irgenwie merken, ob Änderungen gemacht wurden, o.ä.)?

Hat da jmd. Anregungen zu?

Ich würde Dir sehr stark von Popups abraten.

Basierend auf dem was ich von Kunden und Anwendern gehört habe, sind Popups einer der Gründe warum sie überhaupt die derzeitige Auftragsmaske akzeptieren. Nämlich weil die fast keine hat. Desktopsoftware macht sehr viel über Dialoge, und das ständige Dialog auf + Feld anvisieren + ändern + bestätigen + zu wurde mir als Arbeitsfluss behindernd berichtet (was ich persönlich nachvollziehen kann, aber ich arbeite eh fast nur auf Konsole).

Die Popups, die wir haben (für Langtext, Formeln, Lager), sind alle nachträglich reingekommen und sind alles technische Notlösungen weil uns der Screenspace ausgegangen ist.

Abgesehen davon: Was hindert Dich daran die Position vertikal um die entsprechenden Sachen zu erweitern? So wie die alte Maske das auch macht, aber halt nur für jeweils eine Zeile?

Danke für die Infos.

Abgesehen davon: Was hindert Dich daran die Position vertikal um die entsprechenden Sachen zu erweitern? So wie die alte Maske das auch macht, aber halt nur für jeweils eine Zeile?

Kein Hinderungsgrund - ich hatte halt zuerst an ein Popup gedacht, kam zwischendurch aber auch auf die Idee mit einer Erweiterung nach unten.

Ich lasse mir das nochmal durch den Kopf gehen.

@Werner: was sagst Du dazu?

Ich kann auch gut mit Svens und hab hier gerade auch gefragt. Lieber in der Zeile bearbeiten und keine popups wegdrücken.
Bei shopware werden mit doppelklick auf die Zeile alle zu editierenden Felder geöffnet und mit speichern wieder geschlossen.

was ist ein Doppelklick? :)

Zur Info: Ich habe mal wieder rebased und die neue "Version" auf github mit force gepusht.