Moritz Bunkus [Wed, 2 Jul 2014 07:19:55 +0000 (09:19 +0200)]
Wiederkehrende Rechnungen: Variablen für lange Monatsnamen gefixt
Ging im Commit »Wiederkehrende Rechnungen: Formatierung von
Datumsdruckvariablen über freie Formatstrings« kaputt. Danach waren die
Variablen <%current_month_long%> schlicht leer.
Die Relationships für die Positionen heißen in allen Klassen
unterschiedlich. Daher gibt es schon seit Längerem den Alias »items« in
allen Klassen.
Das Hinzufügen von Positionen hingegen erforderte bisher, dass man den
Namen der Relationship kennt, z.B. für Invoice:
$obj->add_invoiceitems. Um das zu Vereinfachen: neuer Alias »add_items«
in allen vier Klassen.
Jan Büren [Mon, 30 Jun 2014 11:51:53 +0000 (13:51 +0200)]
Hinweis von Sven format_amount hat nichts in Template Verzweigung zu suchen.
Keine Ahnung warum mein Test am Freitag, dass nicht korrekt evaluiert hat.
Wahrscheinlich ist qty undef. Es reicht hier aber auch aus, einfach zu prüfen, ob
es sich um einen oder mehrere Einträge in STOCK_INFO handelt.
Jan Büren [Mon, 30 Jun 2014 11:42:59 +0000 (13:42 +0200)]
Hinweis von Sven format_amount hat nichts in Template Verzweigung zu suchen.
Keine Ahnung warum mein Test am Freitag, dass nicht korrekt evaluiert hat.
Wahrscheinlich ist qty undef. Es reicht hier auch aus, einfach zu prüfen, ob
es sich um einen oder mehrere Einträge in STOCK_INFO handelt
Jan Büren [Fri, 27 Jun 2014 11:45:43 +0000 (13:45 +0200)]
Einkaufslieferschein, Einlagern mit mehreren Lagern verbessert
Mehrfaches Aufrufen vom Fragezeichen Einlagern-Knopf, bzw. Erneuern der Posititonseinlagermaske
hat die Zuordnung zu Lager -> Lagerplatz fehlerhaft gesetzt, falls ein Standardlagerplatz in
den Stammdaten gesetzt war.
Details s.a. Ticket: 2485
Moritz Bunkus [Thu, 26 Jun 2014 08:19:45 +0000 (10:19 +0200)]
Lieferadresse eingeben: Möglichkeit zum Kopieren aus Stammdaten
Im Dialog für die Eingabe einer individuellen Lieferanschrift gibt es
nun die Möglichkeit, die Felder aus den Stammdaten des
Kunden/Lieferanten vorzubelegen. Dabei werden sowohl die
Rechnungsadresse als auch alle Lieferadressen angeboten.
Ist beim Abschicken in mindestens einem Feld etwas eingetragen, so wird
eine eventuell vorher ausgewählte shipto_id abgewählt, ansonsten
beibehalten.
Was momentan noch nicht angeboten wird, ist die Firmenadresse aus den
Mandantendaten, weil hier das Adressfeld leider nicht nach Straße,
Postleitzahl, Ort aufgeteilt ist. Ansonsten wäre das für Einkaufsbelege
sinnvoll.
Moritz Bunkus [Thu, 26 Jun 2014 07:32:56 +0000 (09:32 +0200)]
Verkauf: leeren Eintrag in Lieferadressendropdown klarer benennen
Angezeigt wird nun »Keine/individuelle Lieferadresse«, um es den
Benutzern klarer zu machen, dass die über den Button »Lieferadresse«
eingetragene Lieferadresse greift.
Moritz Bunkus [Thu, 26 Jun 2014 07:12:38 +0000 (09:12 +0200)]
Einkauf/Verkauf: Lieferadressenfelder nie aus Stammdaten vorbelegen
Das neue Verhalten ist wie folgt:
- Weder die shipto_id (die Drop-Down-Box in den Belegmasken) noch die
individuellen shipto*-Felder werden weder beim Neuanlegen eines
Beleges noch bei Wechsel des Kunden aus den Datenbanken belegt.
- Beim Ausdruck werden die shipto*-Felder nicht mehr aus der
Mandantenkonfiguration vorbelegt, wenn keine Lieferadresse gesetzt
ist.
- Beim Ausdruck werden die shipto*-Felder mit den Daten aus den
Kundenstammdaten belegt, wenn die shipto_id (die Drop-Down-Box in den
Belegmasken) gesetzt ist.
Die ursprüngliche Intention war, möglichst viele Fälle abzudecken. Ganz
ursprünglich war es nämlich in den Druckvorlagen gar nicht möglich,
Kontrollstrukturen zu benutzen und damit die Ausgabe konditional zu
steuern. Es konnte also rein in den Druckvorlagen nicht unterschieden
werden zwischen »der Benutzer hat keine Lieferadresse eingegeben« und
»der Benutzer hat eine eingegeben oder ausgewählt«.
Daher wurde die ganze Logik immer im Perl-Code abgehandelt.
Das macht aber erhebliche Probleme für den Benutzer, für den es absolut
intransparent ist, wann welche Lieferadresse wie vorbelegt wird. Hinzu
kommt, dass in den Belegmasken nicht ersichtlich ist, dass eine
individuelle Lieferadresse eingetragen wurde.
Hinzu kommt, dass die Druckvorlagen inzwischen verschiedene Mechanismen
zur Verfügung haben, um Fallunterscheidungen zu treffen (z.B. die
kivitendo-Mechanismen $(if shipto…)$ oder die LaTeX-eigenen
\IfThenElse{\equal{$(shipto…)$}{…}}}…). Leider war es mit dem vorherigen
Code für die Druckvorlagen nicht mehr möglich festzustellen, ob der
Benutzer nun eine Lieferadresse eingegeben hat oder nicht.
Die neue Situation ist recht einfach:
Steht in »shiptoname« oder »shiptostreet« ein nicht leerer Wert, so ist
eine Lieferadresse vorhanden, ansonsten nicht.
Für die »nicht«-Fall kann dann jede Vorlage selber entscheiden, was zu
tun ist. Für Vorlagen im Verkaufsbereich sinnvollerweise gar keine
Lieferadresse ausgeben (oder einfach die Lieferadresse aus den
Kundenrechnungsdaten), für Vorlagen im Einkaufsbereich ebenfalls keine
Lieferadresse oder die Adresse aus der Mandantenkonfiguration.
Zudem einen Test dazu angelegt. Allerdings weicht die Art, wie der
PriceTaxCalculator und die Beleg-Masken rechnen, von einander ab.
Da müsste nochmal geprüft werden, was die richtige Art ist
(erst Rabatt abziehen und dann runden,
oder gerundeten Rabatt abziehen und wieder runden).
Auch beim Errechnen des Amounts gibt es unterschiede
(netamount * (1+Steuersatz),
oder aufsummieren).
Moritz Bunkus [Wed, 25 Jun 2014 09:31:34 +0000 (11:31 +0200)]
rose_auto_create_model.pl: Relationship-Namen anhand der Spaltennamen mappen
Bisher wurde das Umbenennen der generierten Relationships anhand des von
Rose vergebenen Namens der Relationship vorgenommen. Das ist
problematisch, weil diese wiederum von der Reihenfolge abhängen, in der
die Fremdschlüsseldefinitionen von der Datenbank zurückgeliefert werden.
Konkretes Beispiel: Tabelle »follow_up_access« mit den Spalten »who« und
»what«, die beide Fremdschlüssel auf employee sind.
Rose benennt die erzeugten Relationships nach dem Klassennamen
derjenigen Tabelle, auf die die Schlüssel verweisen. Tabelle »employee«
→ Klasse »SL::DB::Employee« → Default-Relationshipname »employee«.
Die erste von der Datenbank gemeldete Fremdschlüsseldefinition bekommt
nun den Namen »employee«. Die zweite sollte diesen ebenfalls bekommen,
aber da der schon vergeben ist, bekommt sie das Suffix »_obj«, ergo
»employee_obj«. Soweit, so gut. Ändert sich nun aber die Reihenfolge, so
werden die Namen genau umgekehrt herum vergeben.
Die Umbenennung anhand des Tripels <Domäne, Tabelle, Spaltennamen>
hingegen ist immer eindeutig.
Moritz Bunkus [Wed, 25 Jun 2014 06:46:29 +0000 (08:46 +0200)]
Lieferantenauftrag → Kundenauftrag: Verkaufspreis als Einkaufspreis übernehmen
Der Preis, den ich beim Lieferanten zahlen musste (alte Maske:
sellprice_N) ist dann im weiteren Verkaufsprozess der
Einkaufspreis (neue Maske: lastcost_N).
Moritz Bunkus [Mon, 23 Jun 2014 14:38:16 +0000 (16:38 +0200)]
Einkaufs-/Verkaufsprozesse: optionale Einschränkungen für gewisse Aktionen
Über die Mandantenkonfiguration kann verboten werden, dass gewisse
Aktionen in den Einkaufs- und Verkaufsprozesse durchgeführt
werden. Diese sind:
- Direkte umwandlung von Verkaufsangeboten und -aufträgen in
Verkaufsrechnungen (nur über den Weg der Lieferscheine)
- Direktes Anlegen neuer Einkaufslieferscheine und -rechnungen (nur
durch Umwandlung bestehender Belege)
Moritz Bunkus [Mon, 23 Jun 2014 14:15:11 +0000 (16:15 +0200)]
Offene Transaktionen vor DB-Upgrades comitten
Hintergrund ist, dass Locks potenziell vorhanden sein können. Einfaches
Beispiel: $::instance_conf wird geladen (dadurch implizites
ACCESS-SHARE-Lock auf »defaults«), Upgrade will Schema von »defaults«
verändern, was dann hängt, weil dafür ACCESS-EXCLUSIVE benötigt wird –
das mit ACCESS-SHARE kollidiert.
Sven Schöling [Thu, 20 Sep 2012 13:35:10 +0000 (15:35 +0200)]
special_chars: U+00A0 NO-BREAK SPACE in latex erkennen und korrekt rendern.
Das Zeichen passiert oft, wenn Artikelbeschreibungen von Webseiten von
Lieferanten copy&pasted wird. Webseiten padden ihre Daten gerne mit das
dann als U+00A0 gerendert wird, und landet so in der Datenbank.
Moritz Bunkus [Thu, 19 Jun 2014 15:12:21 +0000 (17:12 +0200)]
Task-Server: vor jedem Job mehr Variablen re-initialisieren
Besonders wichtig: $::request, da sie zum Cachen genutzt wird und die
Garantie vom Cache ist, dass er nach jedem »Request« (beim Task-Server:
nach jedem Job) geleert wird.
Sven Schöling [Thu, 12 Jun 2014 12:29:26 +0000 (14:29 +0200)]
Tab Persistenz in allen masken ausser customer_vendor
War beim Umschreiben auf jquery-ui kaputtgegangen, weil der div.tabwidget eine
id braucht. CustomerVendor hatte das beim neuschreiben schon korrekt mit id
versehen.
Moritz Bunkus [Thu, 12 Jun 2014 07:07:31 +0000 (09:07 +0200)]
Dispatcher: Requests auf controller.pl ohne action auf Loginseite redirecten
Ist hilfreich, wenn man aus der Browserhistory einen Link wie
http://…/kivitendo/controller.pl aufruft. Bisher wurde nur eine böse
Fehlerseite angezeigt.
Moritz Bunkus [Thu, 5 Jun 2014 08:07:07 +0000 (10:07 +0200)]
RDBO Invoice->new_from: Fälligkeitsdatum und Zahlungsbedingungen gefixt
1. Konvertierung von Order-Objekten: Hier wurde das Fälligkeitsdatum
zwar richtig übernommen, nicht aber die Zahlungsbedingungen.
2. Konvertierung von DeliveryOrder-Objekten: Lieferscheine haben gar
keinen Fremdschlüssel auf die Zahlungsbedingungen. Daher wurden hier
weder das Fälligkeitsdatum noch die Zahlungsbedingungen übernommen.
Was jetzt gemacht wird, ist die Zahlungsbedingungen vom Quellobjekt zu
nehmen, wenn dort welche existieren, und ansonsten vom dazugehörigen
Kunden. Wurden Zahlungsbedingungen gefunden, so wird das
Fälligkeitsdatum daraus berechnet und ansonsten auf »Rechnungsdatum + 1
Tag« gesetzt.
Macht man die Vermischung ->new(%args, %attributes), so ist die
Reihenfolge, wann welche aus %args und welche aus %attributes genommen
werden, aufgrund von Perls beliebiger Hash-Reihenfolge nicht
garantiert. Also zuerst nur die berechneten aus %args zuweisen und
danach die vom Caller bereitgestellten in %attributes.
projects / kivitendo-erp.git / log