Revision 543d7822
Von G. Richardson vor mehr als 5 Jahren hinzugefügt
| SL/Taxkeys.pm | ||
|---|---|---|
| 60 | 60 |
|
| 61 | 61 |
if (!$self->{handles}->{get_tax_info}) {
|
| 62 | 62 |
$self->{queries}->{get_tax_info} = qq|
|
| 63 |
SELECT t.rate AS taxrate, t.taxnumber, t.taxdescription, t.chart_id AS taxchart_id,
|
|
| 63 |
SELECT t.rate AS taxrate, c.accno as taxnumber, t.taxdescription, t.chart_id AS taxchart_id,
|
|
| 64 | 64 |
c.accno AS taxaccno, c.description AS taxaccount |
| 65 | 65 |
FROM taxkeys tk |
| 66 | 66 |
LEFT JOIN tax t ON (tk.tax_id = t.id) |
Auch abrufbar als: Unified diff
Spalte taxnumber aus Tabelle tax entfernt
tax.taxnumber war ein redundanter Eintrag, und entsprach dem Wert von
chart.accno aus tax.chart_id.
Z.B. in SKR04 hatte Steuerschlüssel 3 (Umsatzsteuer 19%) die taxnumber
1776 und die chart_id 775 (chart mit id 775 ist das Konto 1776).
Ein Problem dabei ist, daß wenn man in den Konteneinstellungen die
Kontonummer von 1776 ändert, dies nicht automatisch in tax.taxnumber mit
aktualisiert wurde.
Im Code wurde taxnumber v.A. verwendet, um bei Belegen die Steuern zu
gruppieren, mit der taxnumber als Schlüssel.
taxnumber wurde nun also entfernt, und obwohl zum Gruppieren der Steuern
immer noch diese Kontonummer verwendet wird, wird diese Kontonummer
nicht mehr zum Suchen des entsprechenden Taxeintrags verwendet, sondern
die Suche passiert indirekt über die chart_id.
Das ganze System basiert derzeit darauf, daß es für jeden tax-Eintrag ein
eindeutiges Automatikkonto gibt, in der Praxis muß dies aber nicht der
Fall sein!