View Issue Details

IDProjectCategoryView StatusLast Update
0000629FakturamaAllgemein (General)public2019-12-29 23:42
ReporterLastBoyScout Assigned Torheydenr  
PriorityhighSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version2.0.0 
Target Version2.1.0Fixed in Version2.1.0 
Summary0000629: Bereits vorhandene Dokumente bei erneuter Ausgabe nicht ohne Rückfrage überschrieben
Description

Bei der erneuten Ausgabe von Belegen, sollten bereits vorhandene Dokumente nicht einfach überschrieben werden.
Es sollte dann vielmehr einen entsprechenden Rückfragedialog geben, so das der Anwender selbst entscheiden kann:
[ ] Vorhandenes Dokument überschreiben?
[X] Neues Dokument mit angehängtem Zähler erstellen?
Beispielsweise vorhandene Rechnung= RE02158 und statt diese zu überschreiben neues Dokument= RE02158-1 und bei der nächsten Änderung= RE02158-2 usw.
Es soll ja auch weiterhin möglich sein Dokumente zu ändern, nur eben ohne die Vorversion dabei zu verlieren.

TagsArchivierung

Activities

rheydenr

2018-01-29 22:41

administrator   ~0000680

Derzeit kommt ein Hinweisdialog, daß das Dokument bereits gedruckt wurde (natürlich nur, wenn es wirklich bereits gedruckt wurde). Dann kann man entscheiden, ob das vorhandene Dokument geöffnet werden soll oder ein neues erstellt werden soll. Hier könnte man zusätzlich noch einen Zähler einbauen, wobei das für Rechnungsdokumente nicht geht (sonst hätte man dieselbe Rechnung mehrmals, das gibt zu viele Rückfragen vom Finanzamt).

LastBoyScout

2018-02-01 18:34

reporter   ~0000682

Der Hinweisdialog kommt bei mir nur, wenn der vorhandene Beleg nicht geändert wurde. Hier kann man wählen: JA = vorhandenes Öffnen oder NEIN = vorhandenes Überschreiben.
Sobald man etwas geändert hat (Beispielsweise eine Korrektur an der Produktbeschreibung), wird ein bereits vorhandenes Dokument ohne Rückfrage überschrieben.

Nun ist es ja so, dass sämtlich Belege mit Ihrer eindeutigen Nummer und in der jeweils aktuellen Version in der Datenbank auch nur einmal vorhanden sind. Dementsprechend ist die erforderliche Einmaligkeit gemäß Rechnungsausgangsbuch ja gegeben.

Wenn ein Nutzer Beispielsweise Rechnungen physisch Ausdruckt, abändert und dann erneut Ausdruckt, liegen diese Rechnungen ja auch mehrmals vor! Das gleiche wenn die bereits vorhandenen Dokumente vor der erneuten Ausgabe umbenannt oder verschoben werden.

Es liegt daher im Verantwortungsbereich des Nutzer und so sollte dieser auch die Entscheidungshoheit über angeregte Funktion erhalten. Die Nachvollziehbarkeit etwaiger Änderungen / Korrekturen, würde m.E. durch die bei bedarf angehängte Versionsnummer erhöht.

Streiten kann man sich natürlich ob dies nur auf das PDF oder auch auf das ODT zutreffen soll.

LastBoyScout

2018-02-01 18:49

reporter   ~0000683

Nachtrag: Wenn eine Versionsnummer gepflegt würde und man im zusätzlichen PDF- Pfad auch Parameter definieren könnte, hätte man optional ja quasi schon die Möglichkeit alle erzeugten Versionen Archivieren zu können.
Damit könnte man es bei Bedarf wie folgt Lösen:
A: Dokumente = nur jeweils zuletzt erzeugte Versionen, z.B. /{yyyy}/{doctype}/{docname}.pdf
B: PDF-Archiv = immer alle erzeugten Versionen, z.B. /{yyyy}/{doctype}/{docname}-{version}.pdf

rheydenr

2019-01-04 13:12

administrator   ~0000840

Die Idee mit der Version gefällt mir. Die kann ich allerdings erst in der 2.1 umsetzen, weil dazu eine Datenbank-Änderung notwendig ist.

rheydenr

2019-12-18 17:08

administrator   ~0000972

Wurde umgesetzt. Kleiner Knackpunkt: Die Versionsnummern sind aktuell nicht fortlaufend. Muß gelegentlich nochmal geprüft werden.

Issue History

Date Modified Username Field Change
2018-01-29 18:55 LastBoyScout New Issue
2018-01-29 18:55 LastBoyScout Tag Attached: Archivierung
2018-01-29 22:41 rheydenr Note Added: 0000680
2018-02-01 18:34 LastBoyScout Note Added: 0000682
2018-02-01 18:49 LastBoyScout Note Added: 0000683
2018-02-01 22:51 rheydenr Assigned To => rheydenr
2018-02-01 22:51 rheydenr Status new => assigned
2018-02-01 22:55 rheydenr Product Version => 2.0.0
2018-02-01 22:55 rheydenr Target Version => 2.0.4
2019-01-04 13:12 rheydenr Note Added: 0000840
2019-01-04 13:12 rheydenr Target Version 2.0.4 => 2.1.0
2019-12-18 17:08 rheydenr Status assigned => resolved
2019-12-18 17:08 rheydenr Resolution open => fixed
2019-12-18 17:08 rheydenr Fixed in Version => 2.1.0
2019-12-18 17:08 rheydenr Note Added: 0000972
2019-12-29 23:42 rheydenr Source_changeset_attached => Fakturama2 develop f177c270