projekt kivitendo

Vorbedingung um diese Funktionalität ordentlich abzubilden:

<Mosu> Für 27 gibt es keine gute Lösung.
<Mosu> 1. Bei jedem Druck auf Drucken auch zu speichern, erfordert den bekannten, widerlichen und immer wieder fehlerträchtigen Weg des zweifachen Submits inklusive blöden parse_amount/format_amount-Tiraden.
<Mosu> 2. Bei Änderungen in der Form »Drucken« so lange zu sperren, bis man wieder gespeichert hat, wird den User extrem verwirren, den vor dem ersten Speichern geht das ja noch. Erklärungsbedürftig, daher scheiße.
<Mosu> 3. Immer zu speichern beim Drucken hat den riesigen Nachteil, dass das bei Rechnungen nun gerade nicht passieren darf. Das heißt, entweder man macht bei Rechnungen die Maske nach dem Buchen unbearbeitbar, oder man hat plötzlich unterschiedliches Verhalten bei Rechnung vs. andere Belege. Ähnliche Argumentation gilt für bereits ausgelagerte Lieferscheine.
<Mosu> 4. Es gab in der Vergangenheit Kunden und User, die einen Beleg nach dem Erstellen sehr wohl noch mal verändert ausdrucken wollten, ohne ihn aber zu speichern, und zwar mit guten Gründen. Klar, das sollte nicht jede MitarbeiterIn dürfen, aber vertraute Personen durchaus schon.
<Mosu> = Ich habe für dich keine gute Lösung.
<Mosu> Falsch, ich habe eine gute Lösung, die aber aufwändig ist.

<Mosu> Sie besteht darin, alle Einkaufs- und Verkaufsbelege zusammen mit den FiBu-Masken für Debitoren-/Kreditoren-/Dialogbuchungen auf neue Controller umzustellen. Nachdem das geschehen ist, kann man relativ problemlos plötzlich Dinge implementieren wie Read-Only-Masken.
<Mosu> Aber ohne diesen Rewrite kann ich dir nahezu garantieren, dass du, egal mit welcher Lösung, entweder Benutzer total verwirrst oder immer und immer wieder subtitle Bugs einbaust (mal in io.pl, man in do/oe/ar/ap.pl, mal in DO/OE/IS/IR.pm…), weil der Code weiterhin extrem untereinander abhängig ist (Code in DO.pm verlässt sich darauf, dass Werte aus den Masken geparst oder eben nicht geparst sind etc).