Revision c1ec3f4f
Von Kivitendo Admin vor fast 9 Jahren hinzugefügt
doc/dokumentation.xml | ||
---|---|---|
3881 | 3881 |
</listitem> |
3882 | 3882 |
</varlistentry> |
3883 | 3883 |
|
3884 |
<varlistentry> |
|
3885 |
<term><varname>cusordnumber_oe</varname></term> |
|
3886 |
|
|
3887 |
<listitem> |
|
3888 |
<para>Bestellnummer des Kunden aus dem Auftrag, aus dem der Posten ursprünglich stammt (nur Verkauf)</para> |
|
3889 |
</listitem> |
|
3890 |
</varlistentry> |
|
3891 |
|
|
3884 | 3892 |
<varlistentry> |
3885 | 3893 |
<term><varname>discount</varname></term> |
3886 | 3894 |
|
... | ... | |
3897 | 3905 |
</listitem> |
3898 | 3906 |
</varlistentry> |
3899 | 3907 |
|
3908 |
<varlistentry> |
|
3909 |
<term><varname>donumber_do</varname></term> |
|
3910 |
|
|
3911 |
<listitem> |
|
3912 |
<para>Lieferscheinnummer des Lieferscheins, aus dem die Position ursprünglich stammt, wenn die Rechnung im Rahmen des Workflows aus einem Lieferschein erstellt wurde.</para> |
|
3913 |
</listitem> |
|
3914 |
</varlistentry> |
|
3915 |
|
|
3900 | 3916 |
<varlistentry> |
3901 | 3917 |
<term><varname>drawing</varname></term> |
3902 | 3918 |
|
... | ... | |
3981 | 3997 |
<term><varname>ordnumber_oe</varname></term> |
3982 | 3998 |
|
3983 | 3999 |
<listitem> |
3984 |
<para>Auftragsnummer des Originalauftrags, wenn die Rechnung |
|
3985 |
aus einem Sammelauftrag erstellt wurde</para> |
|
3986 |
</listitem> |
|
3987 |
</varlistentry> |
|
3988 |
|
|
3989 |
<varlistentry> |
|
3990 |
<term><varname>donumber_do</varname></term> |
|
3991 |
|
|
3992 |
<listitem> |
|
3993 |
<para>Lieferscheinnummer desjenigen Lieferscheins, aus dem die Position stammt, sofern die Rechnung aus einem oder |
|
3994 |
mehreren Lieferscheinen erstellt wurde</para> |
|
4000 |
<para>Auftragsnummer des Originalauftrags, aus dem der Posten ursprünglich stammt. Nützlich, wenn die Rechnung aus mehreren Lieferscheinen zusammengefasst wurde, oder wenn zwischendurch eine Sammelauftrag aus mehreren Aufträgen erstellt wurde. In letzterem Fall wird die unsprüngliche Auftragsnummer angezeigt.</para> |
|
3995 | 4001 |
</listitem> |
3996 | 4002 |
</varlistentry> |
3997 | 4003 |
|
... | ... | |
4101 | 4107 |
</listitem> |
4102 | 4108 |
</varlistentry> |
4103 | 4109 |
|
4110 |
<varlistentry> |
|
4111 |
<term><varname>transdate_do</varname></term> |
|
4112 |
|
|
4113 |
<listitem> |
|
4114 |
<para>Datum des Lieferscheins, wenn die Rechnung im Rahmen des Workflows aus einem Lieferschein stammte.</para> |
|
4115 |
</listitem> |
|
4116 |
</varlistentry> |
|
4117 |
|
|
4104 | 4118 |
<varlistentry> |
4105 | 4119 |
<term><varname>transdate_oe</varname></term> |
4106 | 4120 |
|
4107 | 4121 |
<listitem> |
4108 |
<para>Auftragsdatum des Originalauftrags, wenn die Rechnung |
|
4109 |
aus einem Sammelauftrag erstellt wurde</para> |
|
4122 |
<para>Datum des Auftrags, wenn die Rechnung im Rahmen des Workflows aus einem Auftrag erstellt wurde. Wenn es Sammelaufträge gab wird das Datum des ursprünglichen Auftrags genommen.</para> |
|
4123 |
</listitem> |
|
4124 |
</varlistentry> |
|
4125 |
|
|
4126 |
<varlistentry> |
|
4127 |
<term><varname>transdate_quo</varname></term> |
|
4128 |
|
|
4129 |
<listitem> |
|
4130 |
<para>Datum des Angebots, wenn die Position im Rahmen des Workflows aus einem Angebot stammte.</para> |
|
4110 | 4131 |
</listitem> |
4111 | 4132 |
</varlistentry> |
4112 | 4133 |
|
Auch abrufbar als: Unified diff
Belegpositionen nicht mehr mit ordnumber, transdate, cusordnumber speichern
stattdessen für das Drucktemplate der Rechnung ordnumber_oe, transdate_oe und
cusordnumber_oe aus Recordlinks auslesen, und auch entsprechende
Druckvariablen für Angebot und Lieferschein bereitstellen.
Diese Informationen sollen in Zukunft nur noch aus record_links bestimmt
werden, aus Kompatibilitätsgründen werden die alten Werte aber vorerst
noch in der DB belassen, aber eben nicht mehr bei neuen Aufträgen oder
Lieferscheinen gespeichert. Dadurch werden sie auch nicht mehr im Rahmen
des Workflows weitergereicht.
Ursprünglich wurden diese Datenbankfelder wahrscheinlich für
Sammelaufträge konzipiert, d.h. sie sollten nur befüllt werden, wenn man
einen neuen Auftrag aus mehreren bestehenden Aufträgen erstellt hat.
Das passt insofern, als daß diese Felder beim initialen Speichern eines
Auftrags nicht gefüllt wurden. Allerdings wurden die Felder schon
gefüllt, wenn man einen Auftrag zum zweiten Mal gespeichert hat, es war
also nicht allein auf das Zusammenfügen von Aufträgen beschränkt.
Außerdem wurden diese Felder im Rahmen des Workflows von Auftrag zu
Lieferschein oder Auftrag zu Rechnung dann in delivery_order_items oder
invoice gefüllt.
Bei "als neu speichern" eine Auftrags wurde auch noch die alte
Auftragsnummer in die neue Position übernommen.
Weiterhin wurde nicht berücksichtigt, daß man mittlerweile auch aus
mehreren Lieferscheinen eine Rechnung erstellen kann, die auch
unterschiedliche Aufträge haben können.
Für das Rückverfolgen der ursprünglichen Belege ist generell nun
record_links eine gute Möglichkeit, die Rückverfolgung von Positionen zu
ermöglichen. Das Verhalten, daß die Variablen nur dann gefüllt sind,
wenn sie aus Sammelaufträgen stammen, ist nun nicht mehr vorgesehen (und
hat vorher auch nicht richtig funktioniert).
In der Druckvorlage gibt es für Rechnungspositionen nun auch neue
Druckvariablen, nämlich die Angebotsnummer, Angebotsdatum,
Lieferscheinnummer und Lieferscheindatum für die Belege, aus denen die
Positionen im Rahmen des Workflows ursprünglich stammten. Siehe Doku.