Udo Spallek | 1 Sep 15:23 2007

Re: Wiederkehrende Rechnungen/Aufträge

Hallo Sebastian,

Sebastian Reimers schrieb:
> Die Zeitdimension würde ich auch ganz gerne mittels cron lösen.
> Das ist eigentlich ja noch das geringste Problem.
>> Ansonsten w?rde ich mir den Mechanismus 'als Vorlage speichern' in 
>> Lx-Office (Rechnungsmodul) mal anschauen, damit k?nntest du Vorlagen 
>> anlegen und diese zeitgesteuert drucken und buchen...
> Du meinst bestimmt "Entwurf speichern" das kommt der Funktion noch
> am nächsten... Ansonsten gibts ja nur "als Vorlage verwenden"
> bei fertigen Rechnungen und da werden ja nur bestimmte Variablen (Rechnungsnummer...)
> zurückgesetzt und der Rest als Vorlage direkt wiederverwendet.
Genau, als Entwurf speichern meinte ich, sorry...

> Also ich stelle mir das mal jetzt so vor:
> - Zunächst erstellt man einmal eine komplette Rechnung für den Wartungs-/Hostingkunden von Hand
>    und bucht diese ganz normal
> - Beim Betrachten über die Berichte gibts dann nen neuen Button "Auto Rechnung"
Hier könntest du evtl. etwas Arbeit sparen, wenn du den Button 
direkt auf die Rechnung legst. Der Vorgang wäre dann in etwa so: 
Erste Rechnung anlegen, buchen. Dann Verkauf->Berichte->Rechnungen, 
Rechnung anklicken, Rechnung wird dargestellt. Unten steht dann der 
Button "Auto Rechnung" oder Wiederkehrend"

> - Beim Klick darauf passiert dann folgendes:
> 
> 1. Teil Benutzeroberfläche
> -> Rechnung wird wie bei Vorlage soweit verändert das nur noch die Stammdaten
>       vorhanden sind (Rechnungsdatum, -Nummer etc. entfallen)
> -> In einem zusätzlichen Dialog kann der Benutzer dann den Zeitraum wählen, wie häufig
(Continue reading)

Sven Schöling | 3 Sep 15:51 2007
Picon

Re: Wiederkehrende Rechnungen/Aufträge


Udo Spallek schrieb:
> Hier könntest du evtl. etwas Arbeit sparen, wenn du den Button
> direkt auf die Rechnung legst. Der Vorgang wäre dann in etwa so:
> Erste Rechnung anlegen, buchen. Dann Verkauf->Berichte->Rechnungen,
> Rechnung anklicken, Rechnung wird dargestellt. Unten steht dann der
> Button "Auto Rechnung" oder Wiederkehrend"
Das wäre in der Funktion bin/mozilla/io.pl print_options, die kümmert
sich um die Buttons unter den Rechnungen.

> Wenn du modulintern auf eine Funktion von Lx zugreifen möchtest,
> dann kannst du dir die Refererschreibweise sparen, wenn du mit
> Variablen im Form-Objekt arbeitest:
> In etwa so (schnellschuss aus der Hüfte, ungetestet):
> #!/usr/bin/perl
> use SL/IS;
>
> $form->{id} = $id;
>
> IS::invoice_details ($self, $myconfig, $form, $locale);
>
> $form->{...}=...;
>
> if ($form->{id} ne ''){
>    IS::post_invoice($myconfig, $form, $provided_dbh, $payments_only);
> }
>
> Das alles ist ein wenig wirr in Lx. Eine API Beschreibung gibt es
> nicht, bzw. ist nur aus dem Quelltext ersichtlich.
> Das form-Objekt ist sehr gefährlich und seine Eigenschaften als
(Continue reading)

bugzilla-daemon | 5 Sep 10:45 2007
Picon

[Bug 752] New: Änderung von Buchungsgruppen nicht möglich

https://lx-office.linet-services.de/bugzilla/show_bug.cgi?id=752

           Summary: Änderung von Buchungsgruppen nicht möglich
           Product: Lx-Office ERP
           Version: 2.4.3
          Platform: PC
        OS/Version: Alle
            Status: NEW
          Severity: Kritisch
          Priority: Hoch
         Component: Systemeinstellungen
        AssignedTo: p.reetz <at> linet-services.de
        ReportedBy: frank <at> belau.de

Die Änderung der Buchungsgruppen ist nicht möglich, da der "Speichern"-Button fehlt.

--

-- 
Configure bugmail: https://lx-office.linet-services.de/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
(Continue reading)

bugzilla-daemon | 11 Sep 11:40 2007
Picon

[Bug 753] New: Ware nicht in Datenbank

https://lx-office.linet-services.de/bugzilla/show_bug.cgi?id=753

           Summary: Ware nicht in Datenbank
           Product: Lx-Office ERP
           Version: 2.4.3
          Platform: PC
        OS/Version: Alle
            Status: NEW
          Severity: Normal
          Priority: Normal
         Component: Einkauf
        AssignedTo: p.reetz <at> linet-services.de
        ReportedBy: info <at> ceos-gmbh.de

Legt man eine neue Bestellung oder Rechnung an und gibt eine unbekannte
Teilenummer oder Bezeichnung an, so erhält man den üblichen Prompt "Dieser
Artikel ist nicht in der Datenbank!" In der folgenden Eingabemaske für die Ware
werden die Nummer bzw. Beschreibung aus der Rechnungsmaske nicht wie noch bei
2.4.2 übernommen.

Das ganze ist auf eine falsche Stringverknüpfung in io.pl zurückzuführen. Hier
ein Patch, der das Problem löst:

--- bin/mozilla/io.pl.orig      2007-09-11 11:29:46.000000000 +0200
+++ bin/mozilla/io.pl   2007-09-11 11:25:24.000000000 +0200
 <at>  <at>  -874,7 +874,7  <at>  <at> 
 print $cgi->hidden("-name" => "previousform", "-value" => $previousform);
 map({ print($cgi->hidden("-name" => $_, "-value" => $form->{$_})); }
      qw(rowcount vc login password));
-     map({ print($cgi->hidden("-name" => $_, "-value" => $form->{"$__$i"})); }
(Continue reading)

Moritz Bunkus | 13 Sep 15:57 2007
Picon

Re: Syntax von Report-Variablen ohne %-Zeichen

Huhu,

On Wednesday 08 August 2007 17:11, Moritz Bunkus wrote:

> > vor einiger Zeit hatte ich angeregt, in der Syntax der Reportvariablen
> > auf das %-Zeichen zu verzichten, weil dies im Zusammenhang mit Latex zu
> > unangenehmen und nur schwer zu diagnostizierenden Fehlern führt. 

Ich habe das eben mal umgesetzt, allerdings NUR für HTML- und
LaTeX-Vorlagen. Nicht aber für andere Stellen, an denen die
<%var%>-Syntax vorkommt, z.B. bei den Zahlungsbedinungen. Meiner Meinung
nach reicht das aber aus.

In der unstable habe ich in Revision 2844 eine Änderung in
SL/Template.pm committed, die erlaubt, das Aussehen der Tags aus der
Vorlage heraus zu setzen (!). Nicht global, sondern nur für jede
Vorlage. Das funktioniert so:

Lx-Office schaut in der ersten Zeile einer Vorlage nach, ob dort das
Wort "set-tag-style" vorkommt. Wenn ja, so werden die Nicht-Leerzeichen
links und rechts vom Wort als Start und Ende des Tags benutzt. Achtung:
diese dürfen nicht identisch sein!

Beispielsweise würde eine LaTeX-Vorlage so anfangen, damit sie auch von
LaTeX selber problemlos geparst wird:

---------------------------------------------------
% ($set-tag-style$)
\documentclass{scrartcl}
....
(Continue reading)

Moritz Bunkus | 13 Sep 17:45 2007
Picon

Re: Syntax von Report-Variablen ohne %-Zeichen

Huhu,

On Thursday 13 September 2007 15:57, Moritz Bunkus wrote:

> In der unstable habe ich in Revision 2844 eine Änderung in
> SL/Template.pm committed, die erlaubt, das Aussehen der Tags aus der
> Vorlage heraus zu setzen (!). Nicht global, sondern nur für jede
> Vorlage. Das funktioniert so:

Diesen Mechanismus habe ich etwas verallgemeinert. Es wird jetzt nicht
nur die erste Zeile betrachtet, sondern alle Zeilen nach folgendem
Muster untersucht:

% config: key=value

und für HTML-Vorlagen

<!-- config: key=value >

Der Befehl, um den Tag-Stil zu setzen, sieht nun so aus:

% config: tag-style=($ $)

für mein Beispiel von vorhin.

Gruß,
Moritz

--

-- 
Dipl.-Inform. Moritz Bunkus
(Continue reading)

Carsten Maass | 13 Sep 21:05 2007
Picon

Re: [Bug 751] New: Beim Ausdruck von Rechnungen ab 01.01.2007 werden einige Reportvariablen nicht exportiert

bugzilla-daemon <at> linet-services.de schrieb:
> Seit dem Update auf Version 2.4.3 werden beim Ausdruck von Rechnungen ab dem
> Buchungsdatum 01.01.2007 die Reportvariablen cp_greeting, cp_name und
> cp_givenname nicht mehr exportiert, die entsprechenden Felder im Ausdruck
> bleiben leer.
> 
> Dies trifft auch für Rechnungen ein und desselben Kunden zu: Eine Rechnung des
> Kunden aus 2006 kann problemlos gedruckt werden, eine Rechnung aus 2007 mit
> denselben Kontaktdaten jedoch nicht.

Ich habe jetzt zwei mit "$LXDebug::global_level = LXDebug::ALL"
erstellte Logdateien an diesen Bugreport angehängt:

1. rechnungsdruck-2006-OK.log ist erstellt beim Ausdruck einer Rechnung
aus dem Jahre 2006, bei dem alle Reportvariablen korrekt ausgegeben werden

2. rechnungsdruck-2007-NOTOK.log ist erstellt beim Ausdruck einer
Rechnung aus dem Jahre 2007, bei dem einige Reportvariablen fehlen.

Soweit ich sehen kann liegt der Unterschied in folgendem SQL Aufruf:

2006:
SELECT ct.*, cp.*, ct.notes as customernotes, ct.phone AS customerphone,
ct.fa AS customerfax, ct.email AS customeremail FROM customer ct LEFT
JOIN contacts cp on ct.id = cp.cp_cv_id WHERE (ct.id = '460') AND
(cp.cp_id = '461') ORDER BY cp.cp_id LIMIT 1

2007:
SELECT ct.*, cp.*, ct.notes as customernotes, ct.phone AS customerphone,
ct.fax AS customerfax, ct.email AS customeremail FROM customer ct LEFT
(Continue reading)

Kai-Martin Knaak | 14 Sep 00:23 2007
Picon

Re: Syntax von Report-Variablen ohne %-Zeichen

On Thu, 13 Sep 2007 15:57:53 +0200, Moritz Bunkus wrote:

>> > vor einiger Zeit hatte ich angeregt, in der Syntax der
>> > Reportvariablen auf das %-Zeichen zu verzichten, 
> Ich habe das eben mal umgesetzt, allerdings NUR für HTML- und
> LaTeX-Vorlagen.

Prima. Danke!

> Ich habe hier ($ und $) als Start und Ende genommen. Grund: mit $...$
> wird in LaTeX der mathematische Modus aktiviert, sodass Variablen mit
> Unterstrichen im Namen (z.B. hier "employee_name") keine Probleme
> machen, weil der Unterstrich nicht-escapet ja nur im mathematischen
> Modus vorkommen darf.

So weit hatte ich nicht gedacht und wäre schon zufrieden, wenn Latex 
genau an der Stelle, der fehlgeschlagenen Ersetzung einen Sysntaxfehler 
anmeckern würde. Dein Vorschlag mit den Dollar-Zeichen hat auch seine 
Tücken. Wenn ein Dollarzeichen übrig bleibt, interpretiert Latex den 
folgenden Text im Mathemodus und läuft und verschluckt sich spätestens 
beim \end{document} Die daraus resultierenden Fehlermeldungen weisen 
leider nicht direkt auf die Ursache des Problems. So eine Falle würde ich 
gerne vermeiden. Ein Unterstrich erzeugt dagegen den Latexfehler genau an 
der Stelle, wo er sitzt.

> Das kannst du dir jetzt selber aussuchen. Ich würde aber von <: ... :>
> abraten, weil die Kleiner- und Größerzeichen ebenfalls nur im
> mathematischen Modus stehen dürfen.

Das ist in der Tat ein echter Nachteil. Wie wäre es mit (lx-FOOBAR-lx) ?
(Continue reading)

Moritz Bunkus | 14 Sep 08:04 2007
Picon

Re: Syntax von Report-Variablen ohne %-Zeichen

Huhu,

On Friday 14 September 2007 00:23, Kai-Martin Knaak wrote:

> So weit hatte ich nicht gedacht und wäre schon zufrieden, wenn Latex
> genau an der Stelle, der fehlgeschlagenen Ersetzung einen Sysntaxfehler
> anmeckern würde.

Fehlgeschlagene Ersetzung? Häh? Alles zwischen Tag-Start und Tag-Ende
steht, wird von Lx-Office ersetzt, auch wenn der Inhalt der Variable
leer ist. Insofern wäre das also ein Syntaxfehler des Benutzers; das
Ersetzen kann nicht fehlschlagen.

> Dein Vorschlag mit den Dollar-Zeichen hat auch seine Tücken. Wenn ein
> Dollarzeichen übrig bleibt, interpretiert Latex den folgenden Text im
> Mathemodus und läuft und verschluckt sich spätestens beim
> \end{document}

Kann durch Ersetzung nicht passieren, weil Dollarzeichen im Inhalt einer
Variablen entsprechend escapet werden, bevor sie ausgegeben werden.

Wenn du statt dessen aber sowas meinst wie "($customer)", dann mag das
natürlich zutreffen, aber mit jedem Editor, der Syntaxhighlighting für
LaTeX unterstützt, ist das sehr sehr schnell zu sehen.

> Das ist in der Tat ein echter Nachteil. Wie wäre es mit (lx-FOOBAR-lx)
> ?

Mir ist egal, was du nimmst :) Das kann halt in jeder Vorlage
individuell eingestellt werden.
(Continue reading)

Moritz Bunkus | 14 Sep 08:13 2007
Picon

Re: [Bug 751] New: Beim Ausdruck von Rechnungen ab 01.01.2007 werden einige Reportvariablen nicht exportiert

Huhu,

On Thursday 13 September 2007 21:05, Carsten Maass wrote:

> 2006:
> SELECT ct.*, cp.*, ct.notes as customernotes, ct.phone AS customerphone,
> ct.fa AS customerfax, ct.email AS customeremail FROM customer ct LEFT
> JOIN contacts cp on ct.id = cp.cp_cv_id WHERE (ct.id = '460') AND
> (cp.cp_id = '461') ORDER BY cp.cp_id LIMIT 1
>
> 2007:
> SELECT ct.*, cp.*, ct.notes as customernotes, ct.phone AS customerphone,
> ct.fax AS customerfax, ct.email AS customeremail FROM customer ct LEFT
> JOIN contacts cp on ct.id = cp.cp_cv_id WHERE (ct.id = '460') ORDER BY
> cp.cp_id LIMIT 1
>
> Wie kann es passieren, daß 2007 die cp.cp_id nicht mehr abgefragt
> wird?

Vermutlich, weil _bei der Rechnung_ kein Ansprechpartner ausgewählt
wurde.

Gruß,
Moritz

--

-- 
Dipl.-Inform. Moritz Bunkus
Geschäftsführung

LINET Services GbR  |  Gotenweg 15  |  38106 Braunschweig
(Continue reading)


Gmane