Bug 1520: Division by zero Fehler
verhindern, daß Preisfaktor 0 ist
Standard-Auswahl für Umlaufvermögenskonto (Bank) mandantenweit setzen. Ferner yearend aus AM.pm entfernt und schliessende </options> für selectAP_paid Array hinzugefügt
cogs-Bug behoben
price_factor wurde bei Warenbestandsbuchung nicht berücksichtigt. Wurde dieWare z.B. mit "pro 100" eingekauft war die Bestandsbuchung um das 100fache zugroß.Ist das basefactor noch nötig?
Wechselkurs wird falsch ausgelesen
Es hat sich herausgestellt, dass der Fehler nicht in der Formatierung lag. DasProcedere ist wie folgt: Bei post_invoice wird geprüft, ob einWechselkurseintrag für das fragliche Datum existiert:
Ja -> diese Zahl wird genommen....
IS->retrieve_invoice und IS->get_customer brauchen keine eigenen Datenbankhandle
(ich glaube ich sehe ein Muster hier...)
EK-Preis editierbar gemacht und marge_total repariert
Der EK-Preis ist jetzt in Angebot/Auftrag/Rechnung editierbar.
Dies ist praktisch für Händler/Wiederverkäufer, bei denen sich der EK-Preishäufig ändert, und es sich nicht lohnt, diesen in den Stammdaten zu pflegen....
Projektbeschreibung als Variable in Vorlagen(globalprojectdescription und projectdescription)
deliverydate_$i heisst in Rechnungen reqdate_$i
Fix für Bug 1213.
Bugfix zu 1289 Gutschriften zu Rechnungen haben in der Tat Lagerbewegungen (in der Tabelle parts) ausgelöst. Entsprechend rausgenommen
Keine Tabs in SL/* Modulen.
Machen das Leben nur schwer für Leute die zufällig nicht die Tabbreite eingestellt haben wie der Autor.
datepaid darf nicht beim speichern übergeben werden.
Fix für Bug 1240
Beim Buchen von Rechnungen/Zahlungen das Feld "datepaid" richtig setzen.
Zusätzlich noch ein Datenbankupgradescript, das die Felder inbestehenden Einträgen berichtigt.
Kosmetik
Und wieder ein Schwung strict.
Fix für Bug 1164 - form->datepaid wird beim Speichern einer Verkaufsrechnung auf form->invdate gesetzt
Auch wirklich $form->{TEMPLATE_ARRAYS}->{...} initialisieren, und nicht nur den Key ansprechen.
Verwendung von benutzerdefinierten Variablen für Waren/Dienstleistungen/Erzegunisse in Verkaufsrechnungen implementiert.
Noch mehr Debugcode entfernt.
Debugcode entfernt.
Ausweitung der benutzerdefinierten Variablen für Waren/Dienstleistungen/Erzeugnisse auf Anzeige/Modifikation in Angeboten/Aufträgen.
Ansprechpartner: cp_greeting durch cp_gender ersetzt
contacts->cp_greeting, was normalerweise fuer Frau/Herr benutzt wird,wird durch cp_gender (m/f) ersetzt, was den Vorteil hat, dass man jenach beim Kunden definierter Sprache verschiedene Anreden generieren und...
Beim Auslesen von Kundendaten die Verkäufer-ID nur dann überschreiben, wenn beim Kunden tatsächlich ein Verkäufer ausgewählt ist.
Fix für Bug 1034.
TEMPLATE_ARRAYS auf einen definierten Zustand setzen.
IC.pm->prepare_parts_for_printing an die TEMPLATE_ARRAYS Konvention angepasst,Dor auch gleich die Spalten drawing, microfiche, image und weight exportiert.
Ausserdem clobbering von TEMPLATE_ARRAYS in IS.pm entfernt.
Fix für Bug 992.
Hash initialisieren.
Einführung einer ID-Spalte in acc_trans
Die Benutzung der von PostgreSQL zur Verfügung gestelltenSpalte "oid" hat ihre Tücken. Über diese wird in Lx-Office dieReihenfolge der Einträge in acc_trans geregelt. Wird aber einUPDATE-SQL-Query auf acc_trans ausgeführt, so kann es (anscheinend...
Die Funktionen in Template.pm zum Ersetzen von Schleifenvariablen so erweitert, dass die Schleifenarrays auch in $form->{TEMPLATE_ARRAYS} gesucht werden. Weiterhin die Druckmechanismen in IS.pm, OE.pm und DN.pm so angepasst, dass sie diese Unterebene benutzen, um die Positionswerte zu speichern. Dadurch wird verhindert, dass Elemente direkt in $form sowohl als Skalar als auch als Array benutzt werden (z.B. $form->{reqdate} = ... und push @{ $form->{reqdate} }, ...).
Bugfix:
Wenn Waren mit Preisgruppen angelegt wurden, und Kunden ohne Preisgruppen angelegt wurden,und dann eine Rechnung mit einem dieser Artikel angelegt wurde, dann wurde von der Backendroutine der Verkaufspreis immer wieder überschrieben.
Korrektur fuer Bug 817 Rabatte die beim Kunden hinterlegt sind, werden jetzt bei jeder neuen Position automatisch gesetzt in der Angebots/Auftrags-Maske sowie in der Rechnungsmaske (so war dies sicherlich irgendwann mal fruehr SQL-Ledger vor dem fork ...;-)). - Beim Kundenwechsel wird der vorher gesetzte Rabatt nicht ueberschrieben. Ferner heisst die Variable jetzt customer_discount, da discount ueberall und fuer alles verwendet wurde
Beim Ausdrucken von Rechnungen das Feld "memo" der Zahlungseingänge als Array "paymentmemo" zur Verfügung stellen. Die Dokumentation bezüglich der Vorlagenvariablen für die Zahlungen überarbeitet.
Suche auch nach EAN auf Gleichheit, wenn nur partnumber gefüllt ist
Potentieller Fix für Bug 879. IS::cogs hatte unsicheres basefactor Handling.
Whitespace Purge
Lieferscheinnummer (donumber) auch in Rechnungen übergeben und als Druckvariable zu Verfügung stellen. OFFEN: Lieferscheinnummern fuer Rechnungen bestehend aus mehreren Lieferscheinen
Die Warengruppe beim Ausdruck der Vorlage zur Verfügung stellen.
Strict in 4 Dateien wieder deaktiviert.
Idee war gut, aber einige interne Mechaniken verhindern, dass strict so einfach eingesetzt werden kann.Diese Mechaniken, unter anderem die beliebte Array/Scalar Schizophrenie, lassen sich nicht ohne weiteres fixen,...
Beim Buchen von Verkaufsrechnungen muss die Umbuchung der Warenbestandskonten mit Steuerschlüssel 0 ( = keine Steuer) vermerkt werden.
Mehr Perlcode strict gemacht.
Bei verschachtelten Schleifen in der inneren Schleife eine andere Schleifenvariable als in der äußeren Schleife benutzen. Bei Perl 5.10 wird ansonsten unter der Bedingung "äußere Schleifenvariable mit my deklariert, innere hingegen ohne my" Speicher korrumpiert, und es trägt zum einfacheren Verständnis bei. Fix für Bug 839.
Einige Variablen der Warenstammdaten auch beim Ausdruck zur Verfügung stellen: ean, make, model.
Bei Berechnung des absoluten Rabattes den Rundungsfehler mit einbeziehen.
Beim Anlegen des allerersten Beleges eines Typs dafür sorgen, dass vendor_id bzw. customer_id auch gesetzt werden. Andernfalls funktionieren Dinge wie Ansprechpartner-Drop-Down-Boxen nicht, oder es erscheinen später SQL-Fehler.
Beim Ausdruck von Angeboten / Anfragen / Aufträgen / Rechnungen wurde der Rabatt ohne Nachkommastellen berechnet und dargestellt.
Beim Ausdruck wurde der Rabattbetrag nicht anständig auf ein Array gepackt, weil IS::customer_details() $form->{discount} mit dem Wert aus der Datenbank befüllt; und deswegen ist $form->{discount} kein Array.
Beim Umwandeln von Aufträgen in Rechnungen nicht sofort den Auftrag schließen. Beim Buchen von Rechnungen die Aufträge schließen, aus denen die Rechnung erzeugt wurde (auch mit Umweg über Lieferscheine), sofern der Auftrag damit vollständig abgerechnet wurde.
Beim Umwandeln von Angeboten/Preisanfragen in Aufträge die IDs in record_links speichern. Beim Umwandeln von Aufträgen und Lieferscheinen in Rechnungen die IDs in record_links speichern.
------------------------------------------------------------------------r7135 | mbunkus | 2008-06-20 10:56:08 +0200 (Fri, 20 Jun 2008) | 1 line
Wenn eine Rechnung aus einem oder mehreren Lieferscheinen erstellt wird, so wird beim Buchen der Rechnung automatisch alle Lieferscheine als geschlossen markiert, aus denen die Rechnung erstellt wurde....
Das Zeilenlieferdatum bei Rechnungen wurde nicht gespeichert
Trennung zwischen Dienstleistungs- und Wareneinheiten aufgehoben.
Wechselkurse.
Zum einen den unsaeglichen Algorithmus zum setzen von exchangerate und forex im ganzen Porgramm geaendert.Dann einen Bug mit der Angzeige der Wechselkurseingabe in oe.pl gefixt.Ausserdem Bug 666 gefixt.
Kosmetik.
Lagerverwaltung implementiert.
Implementation des Features "Benutzerdefinierte Variablen für Kunden- und Lieferantenstammdaten".
SQL-Injection vermeiden. Fix für Revisionen 2936, 2937.
Fehler bei neuen Rechnungen ohne Umwandlung
Beim Umwandeln von Auftrag in Rechnung wurden die Zahlungsbedingungen des Kunden und nicht diedes Auftrags verwendet
Die Variable "ranking" für Zahlungsbedinungen konnte nirgends konfiguriert werden. Zusätzlich werden beim Wechsel des Kunden in einer Verkaufsmaske die beim Kunden hinterlegten Zahlungsbedingungen immer ausgewählt, nicht nur dann, wenn vorher keine ausgewählt waren.
Quoten von allen in regulären Ausdrücken verwendeten Variablen, die direkt oder indirekt von Benutzereingaben stammen können. Fix für Bug 302.
Einheitliche Benennung der Margen-Formular-Variablen analog zu den Namen der Spalten in der Datenbank.
Bei Gutschriften wurde der Lagerbestand falsch aktualisiert
Preisfatkoren implementiert.
Bugfix Rabattberechnung: Berechnung so umgestellt, dass der Rabatt von der Zeilensumme genommen wird und nicht vom Einzelpreis (Rundung). Fix für Bug 325.Bugfix Zwischensummen: Bei Belegen aus OE.pm (Angebote, Aufträge, Anfragen) wurde die Variable <%runningnumber%> innerhalb eines Zwischensummenblocks nicht "1.1, 1.2, 1.3" etc hochgezählt, sondern normal "1, 2, 3" etc....
Kosmetikmerge aus Revisionen 5187, 5191, 5193, 5194, 5218, 5219, 5222, 5228, 5229
Kosmetik, merge aus -r5105,5106,5118,5120,5124
subtotal ist eine Boolean-Spalte; ältere DBI-Versionen mögen's nicht, wenn man ihnen dort Integer unterschiebt.
Beim Versenden von Emails wird der Text etc wieder in intnotes gespeichert. Fix für Bug 713.
Verkaufsrechnungen: Beim Stornieren den absoluten Ertrag negativ speichern.
Beim Stornieren von Einkaufs- und Verkaufsrechnung auch die storno_id mit speichern (analog zu AR.pm/AP.pm), damit später eine Unterscheidung zwischen Stornorechnung und stornierter Rechnung möglich ist.
Erweiterung um Anzeige des Ertrages im Verkauf
Der letzte Einkauspreis wurde nicht geladen und daher auch keine MArgenberechnung
Probleme mit mehreren Währungen und Wechselkursen behoben.
Copy & Paste-Fehler
Debug-Code entfernt.
Copy&Paste-Fehler.
Die Funktion "Zahlung buchen" bei Ausgangsrechnungen komplett umgeschrieben. Sie verlässt sich nun nicht mehr auf die aktuellen Daten in $form, um die alten Einträge in acc_trans zu löschen, sondern lädt den vorherigen Stand aus der Datenbank, entfernt darauf basierend die Einträge in acc_trans und lässt IS->post_transaction() selber die Zahlungen eintragen.
Revision 2532 rückgängig gemacht (Befehl aus falschem Verzeichnis abgeschickt)
Merge der Änderungen zwischen https://ls-bs-si1.bs.linet-services.de/svn/prog/vendor/lxoffice-erp/2.4.2 und https://ls-bs-si1.bs.linet-services.de/svn/prog/vendor/lxoffice-erp/unstable-rev-2530
Verkaufsrechnung: Die Drop-Down-Box für den Bearbeiter heißt nun employee_id (wie auch in oe.pl) und wird richtig befüllt und vorausgewählt.
Gutschriften heben jetzt auch den Lagerbestand an (Bug 636)
zusaetzlich zu der vorhandenen has_storno funktion (bugfix)eine is_storno funktion die die halbherzigen checks auf das mitgeschleifte $form->{storno} ersetzt
@values wurde in der falschen Reihenfolge befüllt. Fix für Bug 654.
Feld "Vorgangsbezeichnung" bei Verkaufsrechnungen hinzugefügt.
Alle Queries zur Vermeidung von SQL injections auf die Verwendung von Parametern bzw. ordentliches Quoten umgestellt.
Umstellung der Form.pm auf die Verwendung parametrisierter Queries zur Vermeidung von SQL injection. Zusätzlich etwas Kosmetik (trailing whitespace, TABs entfernt).
Vergessen, einen Spaltennamen mit umzubenennen.
Mahnwesen: Die Tabelle dunning so umgebaut, dass gemeinsam gestartete Mahnungen auch später gemeinsam erneut ausgedruckt werden können. Dafür auch die Listenansicht bereits gestarteter Mahnungen verbessert.
Nettobeträge bei taxincluded auf Druckvorschau angepasst (Bug 576)
Speichern und Anzeigen eines Verkäufers bei Verkaufsmasken.
IS::get_customer auf neue DBUtils umgestellt,neue DBUtils funktion selectfirst_hashref_query
Einkaufs- und Verkaufsrechnungen: Beim Erstellen der Einträge in acc_trans keine leeren Felder für taxkey erzeugen.
Debugcode...
Einkaufs-/Verkaufsmasken: Da es das Zahlungsziel in den Masken nicht mehr gibt, müssen zur Berechnung des voreingestellten Fälligkeitsdatums die beim Kunden/Lieferanten eingestellten Zahlungskonditionen benutzt werden.
Bei Buchungen mit IS::post_payment taxkey mitbuchen.Fix fuer Bug 583.
IS::post_payment auf derzeitigen Stand gebracht um hinterher bug 583 anzugehen.Aenderungen sind zum Grossteil sicherheitsrelevant oder kosmetisch.
- Aenderungen von perltidy wurden rueckgaengig gemacht (voellig unleserlich)- Queries werden jetzt sicher ueber do_query und DBI gehandhabt...
Debitorenrechnungen: Beim Erstellen einer neuen Debitorenrechnung das richtige Steuerkonto für die erste Zeile auswählen, auch wenn das ausgewählte Konto nicht das erste Konto in der Liste ist.
Paranoiasicherheitscheck in IR.pm
Codeduplikation vermeiden.
Rechnungsfunktionen gehören natürlich nach IS und nicht nach IC.