aktuelles Mwst.-Problem [SQL]

[Hansa]

@Kompon Ente : und sonst gehts dir noch gut ?

Die Überlegungen gehen in die Richtung, tatsächlich den Mwstsatz pro Position zu speichern. Also 0,7,16 (seit 1.4.1998) als integer. Die nächsten Mwst.-DS wären dann eben 0,7,18 (ab 1.??.2006). Nur taucht da ein Problem auf : was mache ich z.B. mit dem momentanen Monat 8/2005 ? Angenommen ein Artikel hat Mwst.Satz Nr. 2, also jetzt 16% und später 18%. In der DB steht jetzt die 2 als Mwstsatz. Wie kann ich nun auf 16% kommen ? Das Datum liegt ja dazwischen. Ich müßte dann ja in der Mwst.Tabelle nach kleinerem und/oder größerem Wert nachgucken in Abhängigkeit vom Datum. Nur wie am besten ?

[Jelly]

Ich würde (und habe auch schon) die MWSt. direkt in die Rechnungsposten mit reinschreiben. Genauso verfahre ich mit dem Postenpreis, der sich ja auch im Laufe der Zeit ändern kann. Für ältere Rechnungen gilt dies natürlich nicht, die bleiben unberührt. Somit ist hier nicht direkt von Redundanz die Rede, weil jeder Rechnungsposten für sich genommen, einzigartig ist.

[alex517]

ich hab mal ein kleines Beispiel erstellt (IBExpert sein Dank).
Es wird in der Verkaufsdatei nur das aktuelle MWSt-Kennzeichen mit geführt.
NICHT die ID des MWSt-Datensatzes. In der MWSt-Datei können mehrere
Sätze mit dem gleichen Kennzeichen aber mit jeweils verschiedenen
Gültigkeitsdaten existieren. Die SP_GET_MWST gibt dann den jeweils
zum Verkaufstag gültigen MWSt-Satz passend zum Kz zurück.

alex

SQL-Code:

SET SQL DIALECT 3;
SET NAMES ISO8859_1;
CONNECT 'D:\TestDB\test_datenbank.fdb' USER 'SYSDBA' PASSWORD 'masterkey';

CREATE GENERATOR GEN_MWST_ID;
SET GENERATOR GEN_MWST_ID TO 5;

CREATE GENERATOR GEN_VERKAUF_ID;
SET GENERATOR GEN_VERKAUF_ID TO 0;

SET TERM ^ ;
CREATE PROCEDURE SP_GET_MWST (
    KZ SMALLINT,
    VK_DATUM DATE)
RETURNS (
    MWSTSATZ DECIMAL(15,2))
AS
BEGIN
  EXIT;
END^
SET TERM ; ^


CREATE TABLE MWST (
    ID               INTEGER NOT NULL,
    KZ               SMALLINT DEFAULT 0 NOT NULL,
    ABDATUM          DATE,
    MWSTSATZ         DECIMAL(15,2),
    ANGELEGT         TIMESTAMP,
    LETZTEAENDERUNG  TIMESTAMP
);


CREATE TABLE VERKAUF (
    ID          INTEGER NOT NULL,
    ARTIKEL_ID  INTEGER,
    BEZ         VARCHAR(50),
    MWST_KZ     SMALLINT,
    VK_NETTO    DECIMAL(15,2),
    VK_DATUM    DATE
);


INSERT INTO MWST (ID, KZ, ABDATUM, MWSTSATZ, ANGELEGT, LETZTEAENDERUNG) VALUES (1, 0, '1900-01-01', 0, NULL, NULL);
REINSERT (3, 2, '1900-01-01', 0.14, NULL, NULL);
REINSERT (2, 1, '1900-01-01', 0.07, NULL, NULL);
REINSERT (4, 2, '1998-04-01', 0.16, NULL, NULL);

COMMIT WORK;

INSERT INTO VERKAUF (ID, ARTIKEL_ID, BEZ, MWST_KZ, VK_NETTO, VK_DATUM) VALUES (1, 1, 'Teil1', 2, 40, '1996-05-25');
REINSERT (2, 333, 'Teil1', 2, 40, '2005-05-25');
REINSERT (3, 444, 'Teil2', 1, 100, '1996-05-25');
REINSERT (4, 44, 'Teil2', 1, 100, '1996-05-25');

COMMIT WORK;

ALTER TABLE MWST ADD CONSTRAINT PK_MWST PRIMARY KEY (ID);
ALTER TABLE VERKAUF ADD CONSTRAINT PK_VERKAUF PRIMARY KEY (ID);

SET TERM ^ ;
CREATE TRIGGER MWST_BI FOR MWST
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(GEN_MWST_ID,1);
END
^

CREATE TRIGGER VERKAUF_BI FOR VERKAUF
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(GEN_VERKAUF_ID,1);
END
^
SET TERM ; ^

SET TERM ^ ;

ALTER PROCEDURE SP_GET_MWST (
    KZ SMALLINT,
    VK_DATUM DATE)
RETURNS (
    MWSTSATZ DECIMAL(15,2))
AS
BEGIN
  SELECT FIRST 1
    MWSTSATZ
  FROM
    MWST
  WHERE
    (KZ=:KZ) AND (ABDATUM <= :VK_DATUM)
  ORDER BY
    ABDATUM DESC
  INTO
    :MWSTSATZ;
  IF (MWSTSATZ is null) then MWSTSATZ = 0;
  SUSPEND;
END
^
SET TERM ; ^

Abfrage:

SQL-Code:

select V.*, M.MWSTSATZ, V.VK_NETTO*(1+M.MWSTSATZ) as Brutto
from
  VERKAUF V
  left JOIN SP_GET_MWST(V.MWST_KZ, V.VK_DATUM) M on (1=1)

[Hansa]

Alex, der Tip ist echt gut ! Interessant ist insbesondere das hier :

SQL-Code:

ALTER PROCEDURE SP_GET_MWST ( 
    KZ SMALLINT, 
    VK_DATUM DATE) 
RETURNS ( 
    MWSTSATZ DECIMAL(15,2)) 
AS 
BEGIN 
  SELECT FIRST 1 
    MWSTSATZ 
  FROM

Könnte fast von mir sein. Erkläre mir mal bitte noch einer was da genau gemacht wird, bzw. das "First" und die "1". Habe das angepaßt, eingebaut und es geht so.

Allerdings stellt sich noch eine Frage : wie verwende ich das im Zusammenhang mit SUM ? Was, wenn ich eine Brutto-Liste brauche von 10/2005 bis 3/2006 und ab 1.1. gilt 18 % ? Siehe Source weiter oben.

[alex517]

Mit First 1 erhält man nur genau den ersten Datensatz einer
Ergebnismenge.

Das ist notwendig, da es mehrere Sätze mit dem gleichen MWSt-Kz geben kann.
Von denen ist aber nur der mit dem jüngsten Datum das kleiner gleich
dem Verkaufsdatum ist der Richtige.
Man beachte die Sortierung!

SQL-Code:

SELECT FIRST 1 
    MWSTSATZ 
  FROM 
    MWST 
  WHERE 
    (KZ=:KZ) AND (ABDATUM <= :VK_DATUM) 
  ORDER BY 
    ABDATUM DESC

So bekommt man auch Summen.

SQL-Code:

select
  EXTRACT(YEAR from V.vk_datum) as YY,
  EXTRACT(Month from V.vk_datum) as MM,
  M.MWSTSATZ,
  sum(V.VK_NETTO*(1+M.MWSTSATZ)) as Brutto
from 
  VERKAUF V 
  left JOIN SP_GET_MWST(V.MWST_KZ, V.VK_DATUM) M on (1=1)
group by 1,2,3

alles klar?

alex

[Hansa]

Was hat das hier zu bedeuten : ON (1=1) Und das GROUP BY 1,2,3 ist mir auch nicht ganz klar. Prinzipiell geht es ancheinend schon. Es ist aber immer interessant zu wissen, warum genau.

[Jelly]

Zitat von Hansa:

Und das GROUP BY 1,2,3

Das bedeutet nichts anderes als dass nach der 1., 2. und 3. Spalte deines Resultsets gruppiert wird. Hat den gleiche Effekt, als wenn du die Spaltennamen hinschreibst. Ich ziehe jedenfalls die Spaltennamen vor, denn wenn du was im Select änderst, kann dein group by falsch werden.

Das Ganze funktioniert übrigens auch bei "order by", wo das dann auch mehr Sinn macht. Hast du berechnete Felder in deinem Select, so kannst du so leichter nach diesen Feldern sortieren lassen, statt den ganzen berechnenden Ausdruck nochmals in den "order by" Teil zu kopieren.

[alex517]

Zitat von Jelly:

Ich ziehe jedenfalls die Spaltennamen vor, denn wenn du was im Select änderst, kann dein group by falsch werden.

Ich eigentlich auch. In diesem Beispiel wolle ich nur nicht so viel schreiben.
Vorteil für hansa, er hat was dazugelernt.
Aber manchmal ist es aber auch nicht möglich Namen zu verwenden z.B. in einer UNION.

Zitat von hansa:

Was hat das hier zu bedeuten :
ON (1=1)

Da die Stored Procedure über ein Join eingebunden wird und dieses Join
von der Syntax am Ende ein "ON (logische Ausdruck)" verlangt,
hat es dieses mit "ON (1=1)" auch bekommen.

alex

[Hansa]

Es gibt noch ein Problem :

SQL-Code:

  SELECT MWSTWERT FROM MWSTWERTSP (:MWSTSATZ,:MONAT,:JAHR) INTO :VAR_MWSTWERT;
  VAR_UMSATZBRUTTO = :UMSATZ * (1 + :VAR_MWSTWERT / 100);

VAR_UMSATZBRUTTO ist immer 0. Das ganze ist innerhalb einer SP. Ich rufe innerhalb dieser SP also die proc. MWSTWERTSP auf. Lasse ich in IBExpert nur diese Mwst-Proz. laufen, so stimmt das Ergebnis schon. Ein NULL Wert kann nicht entstehen, da so was in einem vorgeschalteten Trigger abgefangen wird. Wer weiß mehr ?

[alex517]

Hi,

zeig doch mal die SP's komplett, damit man sich ein Bild machen kann.

Doppelpunkte werden nur in einer SP bei SELECT, UPDATE usw. verwendet
wenn innerhalb des Statements auf Variablen zugegriffen werden soll.

Zitat von Hansa:

  VAR_UMSATZBRUTTO = :UMSATZ * (1 + :VAR_MWSTWERT / 100);

Hier, glaube ich, sind die Doppelpunkte fehl am Platz.

alex