Alle weiteren Unterkapitel in diesem Kapitel sind ebenfalls wichtig und dienen sollten vor einer ernsthaften Inbetriebnahme gelesen werden.

2.14. SKR04 19% Umstellung fÃ¼r innergemeinschaftlichen Erwerb

2.14.1. EinfÃ¼hrung

Die Umsatzsteuerumstellung auf 19% fÃ¼r SKR04 fÃ¼r die + 2.14. SKR04 19% Umstellung fÃ¼r innergemeinschaftlichen Erwerb

2.14. SKR04 19% Umstellung fÃ¼r innergemeinschaftlichen Erwerb
ZurÃ¼ck	Kapitel 2. Installation und Grundkonfiguration	Weiter

2.14. SKR04 19% Umstellung fÃ¼r innergemeinschaftlichen Erwerb

2.14.1. EinfÃ¼hrung

Die Umsatzsteuerumstellung auf 19% fÃ¼r SKR04 fÃ¼r die SteuerschlÃ¼ssel "EU ohne USt-ID Nummer" ist erst 2010 erfolgt. kivitendo beinhaltet ein Upgradeskript, das das Konto 3804 automatisch erstellt und die Steuereinstellungen korrekt einstellt. Hat der @@ -33,4 +33,4 @@ Als Letztes sollte die Steuerliste unter System -> Steuern -> Bearbeiten kontrolliert werden. Zum Vergleich der Screenshot.

ZurÃ¼ck	Nach oben	Weiter
2.13. Konfiguration zur EinnahmenÃ¼berschussrechnung/Bilanzierung: - EUR	Zum Anfang	2.15. Einstellungen pro Mandant

\ No newline at end of file + EUR Zum Anfang 2.15. Verhalten des Bilanzberichts

\ No newline at end of file diff --git a/doc/html/ch02s15.html b/doc/html/ch02s15.html index 4281f9e1c..bde424c2b 100644 --- a/doc/html/ch02s15.html +++ b/doc/html/ch02s15.html @@ -1,20 +1,21 @@ - 2.15. Einstellungen pro Mandant

2.15. Einstellungen pro Mandant
ZurÃ¼ck	Kapitel 2. Installation und Grundkonfiguration	Weiter

2.15. Einstellungen pro Mandant

Einige Einstellungen kÃ¶nnen von einem Benutzer mit dem - Recht "Administration - (FÃ¼r die Verwaltung der aktuellen Instanz aus einem Userlogin heraus)" - gemacht werden. Diese Einstellungen sind dann fÃ¼r die aktuellen - Mandanten-Datenbank gÃ¼ltig. Die Einstellungen sind - unter System - -> Mandantenkonfiguration erreichbar.

Bitte beachten Sie die Hinweise zu den einzelnen - Einstellungen. Einige Einstellungen sollten nicht ohne Weiteres - im laufenden Betrieb geÃ¤ndert werden (siehe - auch Bemerkungen zu - Bestandsmethode).

Die Einstellungen show_bestbefore - und payments_changeable aus dem - Abschnitt features und die Einstellungen im - Abschnitt datev_check (sofern schon vorhanden) - der kivitendo-Konfigurationsdatei - werden bei einem Datenbankupdate einer Ã¤lteren Version automatisch - Ã¼bernommen. Diese EintrÃ¤ge kÃ¶nnen danach aus der Konfigurationsdatei - entfernt werden.

ZurÃ¼ck	Nach oben	Weiter
2.14. SKR04 19% Umstellung fÃ¼r innergemeinschaftlichen Erwerb	Zum Anfang	2.16. kivitendo ERP verwenden

\ No newline at end of file + 2.15. Verhalten des Bilanzberichts

2.15. Verhalten des Bilanzberichts
ZurÃ¼ck	Kapitel 2. Installation und Grundkonfiguration	Weiter

2.15. Verhalten des Bilanzberichts

+ Bis Version 3.0 wurde "closedto" ("BÃ¼cher schlieÃen zum") als Grundlage fÃ¼r das + Startdatum benutzt. SchlieÃt man die BÃ¼cher allerdings monatsweise fÃ¼hrt dies + zu falschen Werten.

In der Mandantenkonfiguration kann man dieses Verhalten genau einstellen:

weiterhin closed_to benutzt (Default, es Ã¤ndert sich nichts zu vorher)
immer den Jahresanfang nimmt (1.1. relativ zum Stichtag)
immer die letzte ErÃ¶ffnungsbuchung als Startdatum nimmt
mit Jahresanfang als Alternative wenn es keine EB-Buchungen gibt
immer alle Buchungen seit Beginn der Datenbank nimmt

+ Folgende Hinweise zu den Optionen: + Das "BÃ¼cher schlieÃen Datum" ist sinnvoll, wenn man nur komplette Jahre + schlieÃt. Bei Wirtschaftsjahr = Kalendarjahr entspricht dies aber auch + Jahresanfang. + "Alle Buchungen" kann z.B. sinnvoll sein wenn man ohne JahresabschluÃ + durchbucht. + ErÃ¶ffnungsbuchung mit "alle Buchungen" als Fallback ist z.B. sinnvoll, wenn man + am sich Anfang des zweiten Buchungsjahres befindet, und noch keinen + Jahreswechsel und auch noch keine EB-Buchungen hat. + Bei den Optionen mit EB-Buchungen wird vorausgesetzt, daÃ diese immer am 1. Tag + des Wirtschaftsjahres gebucht werden. + Zur Sicherheit wird das Startdatum im Bilanzbericht jetzt zusÃ¤tzlich zum + Stichtag mit angezeigt. Das hilft auch bei der Kontrolle fÃ¼r den + Abgleich mit der GuV. +

ZurÃ¼ck	Nach oben	Weiter
2.14. SKR04 19% Umstellung fÃ¼r innergemeinschaftlichen Erwerb	Zum Anfang	2.16. Einstellungen pro Mandant

\ No newline at end of file diff --git a/doc/html/ch02s16.html b/doc/html/ch02s16.html index 79a818c7b..937b2fdd8 100644 --- a/doc/html/ch02s16.html +++ b/doc/html/ch02s16.html @@ -1,8 +1,20 @@ - 2.16. kivitendo ERP verwenden

2.16. kivitendo ERP verwenden
ZurÃ¼ck	Kapitel 2. Installation und Grundkonfiguration	Weiter

2.16. kivitendo ERP verwenden

Nach erfolgreicher Installation ist der Loginbildschirm unter - folgender URL erreichbar:

- http://localhost/kivitendo-erp/login.pl -

Die Administrationsseite erreichen Sie unter:

- http://localhost/kivitendo-erp/controller.pl?action=Admin/login -

ZurÃ¼ck	Nach oben	Weiter
2.15. Einstellungen pro Mandant	Zum Anfang	Kapitel 3. Features und Funktionen

\ No newline at end of file + 2.16. Einstellungen pro Mandant

2.16. Einstellungen pro Mandant
ZurÃ¼ck	Kapitel 2. Installation und Grundkonfiguration	Weiter

2.16. Einstellungen pro Mandant

Einige Einstellungen kÃ¶nnen von einem Benutzer mit dem + Recht "Administration + (FÃ¼r die Verwaltung der aktuellen Instanz aus einem Userlogin heraus)" + gemacht werden. Diese Einstellungen sind dann fÃ¼r die aktuellen + Mandanten-Datenbank gÃ¼ltig. Die Einstellungen sind + unter System + -> Mandantenkonfiguration erreichbar.

Bitte beachten Sie die Hinweise zu den einzelnen + Einstellungen. Einige Einstellungen sollten nicht ohne Weiteres + im laufenden Betrieb geÃ¤ndert werden (siehe + auch Bemerkungen zu + Bestandsmethode).

Die Einstellungen show_bestbefore + und payments_changeable aus dem + Abschnitt features und die Einstellungen im + Abschnitt datev_check (sofern schon vorhanden) + der kivitendo-Konfigurationsdatei + werden bei einem Datenbankupdate einer Ã¤lteren Version automatisch + Ã¼bernommen. Diese EintrÃ¤ge kÃ¶nnen danach aus der Konfigurationsdatei + entfernt werden.

ZurÃ¼ck	Nach oben	Weiter
2.15. Verhalten des Bilanzberichts	Zum Anfang	2.17. kivitendo ERP verwenden

\ No newline at end of file diff --git a/doc/html/ch03.html b/doc/html/ch03.html index 16b8828e9..d870b5fe8 100644 --- a/doc/html/ch03.html +++ b/doc/html/ch03.html @@ -1,6 +1,6 @@ - Kapitel 3. Features und Funktionen

Kapitel 3. Features und Funktionen
ZurÃ¼ck		Weiter

Kapitel 3. Features und Funktionen

3.1. Wiederkehrende Rechnungen

3.1.1. EinfÃ¼hrung

Wiederkehrende Rechnungen werden als normale AuftrÃ¤ge definiert + Kapitel 3. Features und Funktionen

Kapitel 3. Features und Funktionen
ZurÃ¼ck		Weiter

Kapitel 3. Features und Funktionen

3.1. Wiederkehrende Rechnungen

3.1.1. EinfÃ¼hrung

Wiederkehrende Rechnungen werden als normale AuftrÃ¤ge definiert und konfiguriert, mit allen dazugehÃ¶rigen Kunden- und Artikelangaben. Die konfigurierten AuftrÃ¤ge werden spÃ¤ter automatisch in Rechnungen umgewandelt, so als ob man den Workflow benutzen wÃ¼rde, und auch die @@ -78,4 +78,4 @@ den neu konfigurieren Auftrag erkennt und daraus eine Rechnung generiert hat. Alternativ setzt man das Startdatum auf den Monatsersten des Folgemonats und erstellt die erste Rechnung direkt - manuell Ã¼ber den Workflow.

ZurÃ¼ck		Weiter
2.16. kivitendo ERP verwenden	Zum Anfang	3.2. Dokumentenvorlagen und verfÃ¼gbare Variablen

\ No newline at end of file + manuell Ã¼ber den Workflow.

ZurÃ¼ck		Weiter
2.17. kivitendo ERP verwenden	Zum Anfang	3.2. Dokumentenvorlagen und verfÃ¼gbare Variablen

\ No newline at end of file diff --git a/doc/html/ch03s02.html b/doc/html/ch03s02.html index 01554890c..bd0fdc632 100644 --- a/doc/html/ch03s02.html +++ b/doc/html/ch03s02.html @@ -566,7 +566,7 @@ invdate

Rechnungsdatum

invnumber -

Rechnungsnummer

3.2.10. Variablen in anderen Vorlagen

3.2.10.1. EinfÃ¼hrung

Die Variablen in anderen Vorlagen sind Ã¤hnlich wie in der +

Rechnungsnummer

3.2.10. Variablen in anderen Vorlagen

3.2.10.1. EinfÃ¼hrung

Die Variablen in anderen Vorlagen sind Ã¤hnlich wie in der Rechnung. Allerdings heiÃen die Variablen, die mit inv beginnen, jetzt anders. Bei den Angeboten fangen sie mit quo fÃ¼r "quotation" an: diff --git a/doc/html/ch04.html b/doc/html/ch04.html index 7584f82f0..ef1b24b82 100644 --- a/doc/html/ch04.html +++ b/doc/html/ch04.html @@ -1,6 +1,6 @@ - Kapitel 4. Entwicklerdokumentation

Kapitel 4. Entwicklerdokumentation
ZurÃ¼ck		Weiter

Kapitel 4. Entwicklerdokumentation

4.1. Globale Variablen

4.1.1. Wie sehen globale Variablen in Perl aus?

Globale Variablen liegen in einem speziellen namespace namens + Kapitel 4. Entwicklerdokumentation

Kapitel 4. Entwicklerdokumentation
ZurÃ¼ck		Weiter

Kapitel 4. Entwicklerdokumentation

4.1. Globale Variablen

4.1.1. Wie sehen globale Variablen in Perl aus?

Globale Variablen liegen in einem speziellen namespace namens "main", der von Ã¼berall erreichbar ist. DarÃ¼ber hinaus sind bareword globs global und die meisten speziellen Variablen sind... speziell.

Daraus ergeben sich folgende Formen:

@@ -25,7 +25,7 @@ $PACKAGE::form.
local $form: Alle Ãnderungen an $form werden am Ende - des scopes zurÃ¼ckgesetzt

4.1.2. Warum sind globale Variablen ein Problem?

Das erste Problem ist FCGIâ¢.

+ des scopes zurÃ¼ckgesetzt

4.1.2. Warum sind globale Variablen ein Problem?

Das erste Problem ist FCGIâ¢.

SQL-Ledgerâ¢ hat fast alles im globalen namespace abgelegt, und erwartet, dass es da auch wiederzufinden ist. Unter FCGIâ¢ mÃ¼ssen diese Sachen aber wieder @@ -39,7 +39,7 @@ dies hat, seit der EinfÃ¼hrung, u.a. schon so manche langwierige Bug-Suche verkÃ¼rzt. Da globale Variablen aber implizit mit Package angegeben werden, werden die nicht geprÃ¼ft, und somit kann sich - schnell ein Tippfehler einschleichen.

4.1.3. Kanonische globale Variablen

Um dieses Problem im Griff zu halten gibt es einige wenige + schnell ein Tippfehler einschleichen.

4.1.3. Kanonische globale Variablen

Um dieses Problem im Griff zu halten gibt es einige wenige globale Variablen, die kanonisch sind, d.h. sie haben bestimmte vorgegebenen Eigenschaften, und alles andere sollte anderweitig umhergereicht werden.

Diese Variablen sind im Moment die folgenden neun:

@@ -62,7 +62,7 @@ $::request

Damit diese nicht erneut als MÃ¼llhalde missbraucht werden, im Folgenden eine kurze ErlÃ¤uterung der bestimmten vorgegebenen - Eigenschaften (Konventionen):

4.1.3.1. $::form

Ist ein Objekt der Klasse + Eigenschaften (Konventionen):
4.1.3.1. $::form
- Ist ein Objekt der Klasse "Form"
- Wird nach jedem Request gelÃ¶scht
- Muss auch in Tests und Konsolenscripts vorhanden sein.
- EnthÃ¤lt am Anfang eines Requests die Requestparameter vom User
- Kann zwar intern Ã¼ber Requestgrenzen ein Datenbankhandle @@ -110,7 +110,7 @@ push @{ $form->{TEMPLATE_ARRAYS}{number} }, $form->{"partnumber_$i"}; push @{ $form->{TEMPLATE_ARRAYS}{description} }, $form->{"description_$i"}; # ... -}
4.1.3.2. %::myconfig
- Das einzige Hash unter den globalen Variablen
- Wird spÃ¤testens benÃ¶tigt wenn auf die Datenbank +}
4.1.3.2. %::myconfig
Das einzige Hash unter den globalen Variablen
Wird spÃ¤testens benÃ¶tigt wenn auf die Datenbank zugegriffen wird
Wird bei jedem Request neu erstellt.
EnthÃ¤lt die Userdaten des aktuellen Logins
Sollte nicht ohne Filterung irgendwo gedumpt werden oder extern serialisiert werden, weil da auch der Datenbankzugriff fÃ¼r diesen user drinsteht.
EnthÃ¤lt unter anderem Listenbegrenzung vclimit, @@ -122,10 +122,10 @@ Ã¼berwiegend die Daten, die sich unter Programm -> Einstellungen befinden, bzw. die Informationen Ã¼ber den Benutzer die Ã¼ber die - Administrator-Schnittstelle eingegeben wurden.
4.1.3.3. $::locale
Objekt der Klasse "Locale"
Wird pro Request erstellt
Muss auch fÃ¼r Tests und Scripte immer verfÃ¼gbar + Administrator-Schnittstelle eingegeben wurden.
4.1.3.3. $::locale
Objekt der Klasse "Locale"
Wird pro Request erstellt
Muss auch fÃ¼r Tests und Scripte immer verfÃ¼gbar sein.
Cached intern Ã¼ber Requestgrenzen hinweg benutzte Locales
Lokalisierung fÃ¼r den aktuellen User. Alle Ãbersetzungen, - Zahlen- und Datumsformatierungen laufen Ã¼ber dieses Objekt.
4.1.3.4. $::lxdebug
Objekt der Klasse "LXDebug"
Wird global gecached
Muss immer verfÃ¼gbar sein, in nahezu allen + Zahlen- und Datumsformatierungen laufen Ã¼ber dieses Objekt.
4.1.3.4. $::lxdebug
Objekt der Klasse "LXDebug"
Wird global gecached
Muss immer verfÃ¼gbar sein, in nahezu allen Funktionen
$::lxdebug stellt Debuggingfunktionen bereit, wie "enter_sub" und @@ -135,14 +135,14 @@ "message" und "dump" mit denen man flott Informationen ins Log (tmp/kivitendo-debug.log) packen kann.
Beispielsweise so:
$main::lxdebug->message(0, 'Meine Konfig:' . Dumper (%::myconfig)); -$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});
4.1.3.5. $::auth
Objekt der Klasse "SL::Auth"
Wird global gecached
Hat eine permanente DB Verbindung zur Authdatenbank
Wird nach jedem Request resettet.
+$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});
4.1.3.5. $::auth
Objekt der Klasse "SL::Auth"
Wird global gecached
Hat eine permanente DB Verbindung zur Authdatenbank
Wird nach jedem Request resettet.
$::auth stellt Funktionen bereit um die Rechte des aktuellen Users abzufragen. Obwohl diese Informationen vom aktuellen User abhÃ¤ngen wird das Objekt aus GeschwindigkeitsgrÃ¼nden nur einmal angelegt und dann nach jedem Request kurz resettet.
Dieses Objekt kapselt auch den gerade aktiven Mandanten. Dessen Einstellungen kÃ¶nnen Ã¼ber $::auth->client abgefragt werden; RÃ¼ckgabewert ist ein Hash mit den Werten aus der Tabelle - auth.clients.
4.1.3.6. $::lx_office_conf
Objekt der Klasse + auth.clients.
4.1.3.6. $::lx_office_conf
Objekt der Klasse "SL::LxOfficeConf"
Global gecached
ReprÃ¤sentation der config/kivitendo.conf[.default]-Dateien
Globale Konfiguration. Configdateien werden zum Start gelesen und danach nicht mehr angefasst. Es ist derzeit nicht geplant, dass @@ -152,16 +152,16 @@ $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{ file = /tmp/kivitendo-debug.log
ist der Key file im Programm als $::lx_office_conf->{debug}{file} erreichbar.
Warnung
Zugriff auf die Konfiguration erfolgt im Moment Ã¼ber - Hashkeys, sind also nicht gegen Tippfehler abgesichert.
4.1.3.7. $::instance_conf
Objekt der Klasse + Hashkeys, sind also nicht gegen Tippfehler abgesichert.
4.1.3.7. $::instance_conf
Objekt der Klasse "SL::InstanceConfiguration"
wird pro Request neu erstellt
Funktioniert wie $::lx_office_conf, speichert aber Daten die von der Instanz abhÃ¤ngig sind. Eine Instanz ist hier eine Mandantendatenbank. Beispielsweise Ã¼berprÃ¼ft
$::instance_conf->get_inventory_system eq 'perpetual'
- ob die berÃ¼chtigte Bestandsmethode zur Anwendung kommt.
4.1.3.8. $::dispatcher
Objekt der Klasse + ob die berÃ¼chtigte Bestandsmethode zur Anwendung kommt.
4.1.3.8. $::dispatcher
Objekt der Klasse "SL::Dispatcher"
wird pro Serverprozess erstellt.
enthÃ¤lt Informationen Ã¼ber die technische Verbindung zum Server
Der dritte Punkt ist auch der einzige Grund warum das Objekt global gespeichert wird. Wird vermutlich irgendwann in einem anderen - Objekt untergebracht.
4.1.3.9. $::request
Hashref (evtl spÃ¤ter Objekt)
Wird pro Request neu initialisiert.
Keine Unterstruktur garantiert.
+ Objekt untergebracht.
4.1.3.9. $::request
Hashref (evtl spÃ¤ter Objekt)
Wird pro Request neu initialisiert.
Keine Unterstruktur garantiert.
$::request ist ein generischer Platz um Daten "fÃ¼r den aktuellen Request" abzulegen. Sollte nicht fÃ¼r action at a distance benutzt werden, sondern um lokales memoizing zu @@ -174,20 +174,20 @@ file = /tmp/kivitendo-debug.log
ist der Key file$::request
Muss ich von anderen Teilen des Programms lesend drauf zugreifen? Dann $::request, aber Zugriff Ã¼ber - Wrappermethode

	Warnung
Zugriff auf die Konfiguration erfolgt im Moment Ã¼ber - Hashkeys, sind also nicht gegen Tippfehler abgesichert.

4.1.4. Ehemalige globale Variablen

Die folgenden Variablen waren einmal im Programm, und wurden - entfernt.

4.1.4.1. $::cgi

war nÃ¶tig, weil cookie Methoden nicht als + Wrappermethode

4.1.4. Ehemalige globale Variablen

Die folgenden Variablen waren einmal im Programm, und wurden + entfernt.

4.1.4.1. $::cgi

war nÃ¶tig, weil cookie Methoden nicht als Klassenfunktionen funktionieren
Aufruf als Klasse erzeugt Dummyobjekt was im Klassennamespace gehalten wird und Ã¼ber Requestgrenzen leaked
liegt jetzt unter $::request->{cgi} -

4.1.4.2. $::all_units

war nÃ¶tig, weil einige Funktionen in Schleifen zum Teil +

4.1.4.2. $::all_units

war nÃ¶tig, weil einige Funktionen in Schleifen zum Teil ein paar hundert mal pro Request eine Liste der Einheiten brauchen, und de als Parameter durch einen Riesenstack von Funktionen geschleift werden mÃ¼ssten.
Liegt jetzt unter $::request->{cache}{all_units}
Wird nur in AM->retrieve_all_units() gesetzt oder - gelesen.

4.1.4.3. %::called_subs

wurde benutzt um callsub deep recursions + gelesen.

4.1.4.3. %::called_subs

wurde benutzt um callsub deep recursions abzufangen.
Wurde entfernt, weil callsub nur einen Bruchteil der mÃ¶glichen Rekursioenen darstellt, und da nie welche auftreten.
komplette recursion protection wurde entfernt.

ZurÃ¼ck		Weiter
3.4. Mandantenkonfiguration Lager	Zum Anfang	4.2. Entwicklung unter FastCGI

\ No newline at end of file diff --git a/doc/html/index.html b/doc/html/index.html index 8308bbdd7..025e8f8d3 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -1,9 +1,9 @@ kivitendo 3.0.0: Installation, Konfiguration, Entwicklung