New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature/belegnummer #58
base: master
Are you sure you want to change the base?
Conversation
…tfunktion aus anderen Buchungsfeldern) + neue Einstellmöglichkeit
…erwendeten Einstellung)
…die Belegnummer (anstatt der Buchungsnummer) anzeigen
…nt automatisch pro Konto und pro Geschäftsjahr (de)aktiviert werden.
… erstellten Felder in den Einstellungen wieder gelöscht werden
Hier nun die im Forum angemerkte, notwendige Korrektur (https://jverein-forum.de/viewtopic.php?p=19526#p19526) in Zeile 238.
Die Umlaute in BuchungsControl sind nicht kaputt. Du hast sie lediglich mit dem falschen Encoding geöffnet. JVerein verwendet ISO-8859-1 und nicht UTF-8 (kann man sicher irgendwann mal umstellen, soll aber nicht Thema dieses PR sein). Generell: Bitte kleinere(!) Pull-Requests, die jeweils nur genau eine isolierte Änderung enthalten. Das Review ist sonst echt schwer. |
Es ist ein bisschen unglücklich, ausgerechnet in einem so großen PR die Formatierung zu ändern. Z.B. scheinen die Änderungen in BuchungQuery.java (fast?) nur aus Umformatierungen zu bestehen. Es ist sehr mühsam, hier zu kontrollieren, ob es überhaupt inhaltliche Änderungen gibt. Das mach das Review unnötig langwierig. |
Ich bin der Meinung, dass ich es vereinfacht habe, da in dem f1c553a mindestens die Formatierung (wohl auch das encoding) umgestellt wurden was zu noch mehr geänderten Zeilen im PR geführt hätte. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review und Funktionstest okay
…ummer - Add Update0421 database update file
public static void setNewLastBelegnummer(Integer NewLastBelegnummer, | ||
Date NewDate_, String NewKontoId) throws RemoteException | ||
{ | ||
getLastBelegnummer(NewDate_, NewKontoId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wird hier nur für side effects aufgerufen, das ist nicht gut. Generell wäre der Code deutlich einfacher, wenn der aktuelle Status (Konto, Geschäftsjahr, ...) nicht gespeichert würde.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gerne einen Code Vorschlag machen. Es ist nicht meine Implementierung, ich würde die Funktion dem openjverein aber gerne hinzufügen.
|
||
if (b.getSpeicherung()) | ||
{ | ||
b.store(); | ||
getID().setValue(b.getID()); | ||
setNewLastBelegnummer(b.getBelegnummer(), b.getDatum(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wenn ich den Code richtig lese, bekommt eine neue Buchung die Nachfolgenummer der zuletzt bearbeiteten Buchung. Wenn das eine alte Buchung war, die nur bearbeitet wurde, gibt es doppelte Nummern. Ich würde den Cache entfernen (und damit auch die Funktion setNewLastBelegnummer), dann gibt es das Probem nicht.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kann ich nicht nachvollziehen. Die setNewLastBelegnummer holt sich doch über getLastBelegnummer die nächste/korrekte Nummer. Hast du deine Überlegung mal getestet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nein, die Funktion holt sich nichts. getLastBelegnummer wird nur aufgerufen, um die Cache-Variablen zu setzen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mach bitte einen Code-Vorschlag (change request / PR).
setNewLastBelegnummer wird insgesamt an drei Stellen verwendet:
public Integer getBelegnummer() throws RemoteException | ||
{ | ||
Integer belegnummer = (Integer) getAttribute("belegnummer"); | ||
if (belegnummer == null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Der Fall sollte doch gar nicht vorkommen. Warum nicht return (Integer) ... wie bei den anderen Attributen? Genauso bei setBelegnummer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hier scheint der default Wert -1 von Bedeutung zu sein. In der Update Datei ist der default auch mit -1 gesetzt. Würde ich so lassen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ich sehe aber keinen Fall, für den belegnummer == null eintritt. Für die alten Zeilen wird das Feld beim Datenbankupdate gefüllt, für die danach angelegten Buchungen beim Speichern. Und wenn das Feature deaktiviert ist, wird immer 0 gespeichert, nicht -1.
execute(addColumn("einstellung", | ||
new Column("belegnummer_pro_jahr", COLTYPE.BOOLEAN, 0, "TRUE", false, false)), false); | ||
execute( | ||
addColumn("buchung", new Column("belegnummer", COLTYPE.INTEGER, 19, "-1", false, false)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warum -1, wenn neue Buchungen bei deaktiviertem Feature 0 bekommen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Steht in Zeile 100. Um zu prüfen, dass die hinterlegten Belegnummern nicht konvertiert werden können.
"In der neueste jVerein Version besteht die M�glichkeit manuelle Belegnummern anstatt " | ||
+ "der Buchungsnummer aus der Datenbank zu verwenden.\n\nFalls du bisher schon Belegnummern verwendet hast, " | ||
+ "kannst du im folgenden Dialog ausw�hlen, aus welchem bisherigen Buchungsfeld diese importiert werden sollen. " | ||
+ "Falls du dieses Feature nicht nutzen m�chtest, w�hle \"Buchungsnummer\" aus.\n\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wenn das Feature nicht genutzt wird, bekommen neue Buchungen Belegnummer 0. Beim Import nicht, das kommt mir nicht vernünftig vor. Außerdem ist das Datenbankupdate kein guter Ort für den Import, weil dann der Auswahldialog auch angezeigt wird, wenn JVerein neu aufgesetzt wird. Der Auswahldialog sollte angezeigt werden, wenn die Einstellungen verändert werden. Mit der zusätzlichen Option, gar keinen Import vorzunehmen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Das hatte sich @VinRud so gedacht. Ich finde es nicht schlimm. Kannst gerne einen Code-Vorschlag machen.
Hallo zusammen, Scheinbar ist ja weiterhin das größte Problem hier die unterschiedliche Formatierung. Leider weiß ich nicht genau wie man die Konflikte hier auflöst und somit kann das Feature aktuell nicht übernommen werden... |
In dem PR geht es um die neue Funktion Belegnummern zu verwenden und die Möglichkeit diese zu importieren. Original von VinRud im jverein#62 und Forum Titel neues Feld bei Buchungen - Belegnummer.
Im PR ist die angepasste Version von kpatzwald um den DB Fehler com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException in buchungscontrol.java Zeile 238 zu beheben.