Office: (Office 2010) Staffelpreise mit Gültigkeitsbereichen

Hallo & Mahlzeit!

In Anlehnung an diesen Thread
http://www.ms-office-forum.de/forum/...d.php?t=293441

habe ich zu meiner Problemstellung noch Hilfebedarf. Es gibt Staffelpreise die sich nach Anzahl der Reisetage ergeben, die aber auch einen Gültigkeitszeitraum haben. Es gibt aber Leistungen die keiner Staffel unterliegen aber auch den Gültigkleitszeitraum haben. Das mit dem Gültigkeitszeitraum ist nun im genannten Thread beantwortet. DER SQL String sieht wie folgt aus:

Code:

Daten als Beipiel:

Bollerwagen 1 Tag - 2,50 - 01.12.2012 bis 31.08.2012
Bollerwagen 3 Tag - 4,50 - 01.12.2012 bis 31.08.2012
Bollerwagen 1 Tag - 3,00 - 01.09.2012 bis 31.12.2013
Bollerwagen 3 Tag - 5,00 - 01.09.2012 bis 31.12.2013
Wäschepaket Pauschal - 14,50 - 01.01.2012 bis 31.08.2012
Wäschepaket Pauschal -15,00 - 01.09.2012 bis 31.12.2013

(1) Wenn nun der Anreise/Abreise Zeitraum 2 Gültigkeitsbereiche anschneiden, wie Werte ich die per SQL aus und lasse mir den günstigsten Preis anzeigen (aus jedem der betreffenden Zeiträume)?

(2) Wie behandel ich Leistungen, die keiner Staffel unterliegen? Sep. Tabelle oder als Staffel 0 hinterlegen um damit den Pauschalpreis kenntlich zu machen?

Ich bin nun leider (noch) kein SQL Profi, vielleicht hat einer von Euch Anregungen.

:)

 

Hi,

wenn ich das recht verstehe, und ohne allzu tiefe Versenkung in das Thema:

(1) "Technisch" widerspricht das "Günstigster-Preis-Ansinnen" bei Anschneiden von zwei Preiszeiträumen dem Sinn einer Gültigkeit. Eine Gültigkeit, die "gnadenhalber" weitergilt, ist eigentlich keine, auch wenn ich das als Kunde natürlich fair finde. In diesem Fall würde ich die Daten wohl eher in einer temporären Tabelle aufbereiten; dort kannst du die Preise erstmal "gemäß Zeitraum" eintragen lassen und ggf. freundliche Preise drübermörteln. Innerhalb von SQL müsste ich jetzt auch länger überlegen, das zu lösen.

(2) Da "hat keine Staffel" sich jederzeit ändern kann, würde ich alle Artikel in der Staffel erfassen und die Ohne-Staffel-Artkel mit MengeAb = 1 und MengeBis = leer. Das entspricht dem Ansatz bei den leeren Gültig-Bis-Daten.

 

Schau Dir mal Deine Beispieldaten an: Merkwürdige Darstellung (01.12. - 31.08.).

Zu (1): Hier wäre eine Kalenderhilfstabelle hilfreich, die mit den Staffelungs-Gültigkeitszeiträumen verknüpft ist. Hiermit könnte man sauber auf die verschiedenen Zeiträume aufteilen.
Was bedeutet "günstigster Preis"? Der niedrigste Preis aus angeschnittenen Zeiträumen?

Zu (2): Lassen sich die Preise generell als Eintagespreise angeben? (Einer Kalendertabelle käme das sehr entgegen.) Dann könnte man, auch unter Zugrunde-Legung von (1), Rabatte auf Laufzeiten ergeben. Für krumme Zahlen könnte man dann passende Rundungen vornehmen.

Vielleicht müsste man auch zusätzlich Fälle definieren, wo z.B. das Gerät länger als drei Tage und dann noch übergreifend auf mehrere Zeiträume verliehen wird.

 

Hallo Ihr Beiden.

Um der Sache ein bissl mehr Verständnis zu geben: Es geht um eine Datenbank, mit der wir unsere Ferienwohungsvermietungen verwalten wollen. Der Gast kann neben der Wohnung auch weitere Leistungen (Geräte) buchen.

@Artrus:

Gebe ich Dir grundsätzlich recht, hier wird überlegt ob wir bei den Zusatzleistungen dem zum Buchungsdatum gültigen Preis nehmen. Aber (und das war von mir schon vorbeugend), wenn Du als Gast über 14 Tage eine Wohnung buchst und die erste Woche in der Hauptsaison liegt und die zweiten Woche in der Nebensaison, dann fände ich es nur fair und zu erwarten das mir die richtigen Preise für die Zeiträume berechnet werden. Mein (vielleicht auch blöder) Gedanke war eben, wenn ich das jetzt schon auf die Leistungspreise umsetze, muss ich bei den Wohnungen nicht mehr fragen :-)

Der Gedanke ist gut. Dafür müsste ich aber auch per SQL die angesprochenen Zeiträume in die temporäre Tabelle schaufeln, oder nicht?

Gut. Dann fällt es mir auch leichter die richtige Staffel zu treffen.

@Eberhard

Beispiel Bollerwagen:
Reisezeitraum : 15.08.2012 - 10.09.2012

Wunschergebnis:
15.08.2012 - 31.08.2012 = 3 Tag Staffel = (4,50/3) * Reisetage
01.09.2012 - 10.09.2012 = 3 Tag Staffel = (5,00/3) * Reisetage

Du meinst damit einen grundsätzlichen Ein-Tages-Preis und dann in Abhängigkeit der Anzahl der Tage einen Rabatt einräumen? War auch eine Idee von mir, aber wird seitens der GF nicht gewollt. Aber würde ich da nicht eh in Konflikt mit den "Pauschal" Preisen kommen?

Eine Datumstabelle ist bisher in der Datenbank nicht drin. Zumal auch der Belegungsplan damit nicht arbeitet. Sollte aber eine solche Tabelle entscheidende Vorteile bringen, dann würde ich auch den Belegungsplan auf diese Tabelle aufsetzen.

BTW: Danke für die Hilfe.

 

Wenn die erste Woche in die teure und die zweite in die billige Zeit fällt, würde ich auch eine teure Woche und eine billige Woche erwarten. Ich hatte dich aber mit dem Wort "billigerer Preis" so verstanden, dass für beide Wochen der billigere der beiden Preise angesetzt werden soll. Das ist dann keine strikte Gültigkeit mehr.

Wenn es die "Preis bei Anreise-Lösung sein soll", brauchst du - statt auf den ganzen Buchungszeitraum - nur auf den Beginn der Buchung gehen und schauen, wo der drinliegt. Dieser Preis ist dann der einzig relevante für 2 Wochen.

Wenn es doch eine strikte Gültigkeit sein soll, hast du doch kein Problem und kannst alles mit einer von-bis-Datumsstaffel abdecken - die SQL ist so wie die aus dem verlinkten Beitrag.

 

\@Artrus: Da habe ich mich wohl nicht klar genug ausgedrückt. Sorry

Beispiel in Bezug auf eine Wohnung:

Beispiel Wohnung 12:
Reisezeitraum : 15.08.2012 - 10.09.2012

Wunschergebnis:
Reisezeitraum
A...15.08.2012 - 31.08.2012 = 7 Tag Staffel = (500/7) * Reisetage = Haupsaison
B...01.09.2012 - 10.09.2012 = 7 Tag Staffel = (450/7) * Reisetage = Nebensaison

Es gilt immer der Preis am Tage der Buchung. Also müsste ich ich für die Preisverwaltung der Wohungen neben dem Gültiglkeitszeitraum auch eine Reisezeitraum erfassen können. Das entfällt bei den Leistungen, da diese nicht Saision abhängig sind, sondern nur von der Anzahl der Tage und der Preisgültigkeit.

Nehmen wir mal Deinen Vorschlag mit der temp Tabelle an. Wie würde dann ein SQL Code aussehen, der mir obiges Wunschergebnis in die Tabelle schaufelt?

 

Es gibt nicht "den Preis" bei Buchung, sondern ein Preismodell, d.h. eine mit Gültigkeitszeiträumen versehene Preisliste, die Haupt- und Nebensaison klarmacht.

Dieses Preismodell kannst du jederzeit ändern, aber das Modell - samt seiner "Zukunft" der Preise - gilt ab sofort. Und damit für alle Buchungen, die ab sofort eingehen.

Die Reisezeit, die du als neue Info erwägst, ist keine Eigenschaft der Wohnung. Wohnungen reisen nur selten. *wink.gif* Was überlappt, ist das Preismodell (mit Zukunftspreisen) und der Reisezeitraum einer Buchung.

Die Zusatzleistungen sollten genauso schmecken. Es gibt im Preismodell einen Satz mit dem Preis pro Tag. Dieser Preis wird dann aber mit einem buchungsbezogenen Rabatt versehen, der abhängt von der Länge der Belegung. Wenn der Tagessatz sich mal ändern sollte, geht das wie bei den Wohnungen auch per GültigAb/-bis.

 

Hallo Artrus.

Ich kann Dir jetzt nicht folgen. Warum kann es für einen gleichen Reisezeitraum nicht unterschiedliche Preise geben, die aber einen unterschiedlichen Gültigkeitszeitraum haben? Bei uns werden häufig die Preise für gleiche Reisezeiträume angepasst. Im Januar kann ich immer meinen, dass ich 500,00 die Woche bekomme, aber dann durchaus feststellen, dass meine Preise nicht mehr in den Markt passen.

Beispieldaten :

<table border="1" class="tabletext"><tr><td class="tablehead1" colspan="9">Daten der Tabelle <strong>tbL_WohnungenPreise</strong></td></tr><tr><td class="tablehead1" align="center"><strong>PreisID</strong></td><td class="tablehead1" align="center"><strong>Wohnung</strong></td><td class="tablehead1" align="center"><strong>ReisezeitraumVON</strong></td><td class="tablehead1" align="center"><strong>ReisezeitraumBIS</strong></td><td class="tablehead1" align="center"><strong>TageVon</strong></td><td class="tablehead1" align="center"><strong>TageBis</strong></td><td class="tablehead1" align="center"><strong>Preis</strong></td><td class="tablehead1" align="center"><strong>GültigAb</strong></td><td class="tablehead1" align="center"><strong>GültigBis</strong></td></tr><tr><td class="tabletext2" align="right">1</td><td class="tabletext2">Wohnung 1</td><td class="tabletext2" align="right">01.09.2012</td><td class="tabletext2" align="right">31.10.2012</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">500,00 €</td><td class="tabletext2" align="right">01.01.2012</td><td class="tabletext2" align="right">14.01.2012</td></tr><tr><td class="tabletext2" align="right">2</td><td class="tabletext2">Wohnung 1</td><td class="tabletext2" align="right">01.09.2012</td><td class="tabletext2" align="right">31.10.2012</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">475,00 €</td><td class="tabletext2" align="right">15.01.2012</td><td class="tabletext2" align="right">31.08.2012</td></tr><tr><td class="tabletext2" align="right">3</td><td class="tabletext2">Wohnung 1</td><td class="tabletext2" align="right">01.07.2012</td><td class="tabletext2" align="right">31.08.2012</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">550,00 €</td><td class="tabletext2" align="right">01.01.2012</td><td class="tabletext2" align="right">30.06.2012</td></tr><tr><td class="tablehead1" colspan="9"><font size="-2">Tabelleninhalte mit <a *****"http:>TabToWeb 0.75</a> nach HTML 4.01 transferiert.</font></td></tr></table>

Buchungsdatum: 15.01.2012
Wohnung 1
Reisezeitraum : 15.08.2012 - 10.09.2012

Wunschergebnis:

Reisezeitraum
15.08.2012 -31.08.2012 7 Tagestaffel = 550,00/7 * Reisetage (PreisID =3)
01.09.2012 - 10.09.2012 7 Tagstaffel = 475,00/7 * Reisetage (PreisID=2)

Hätte der Gast vor dem 15.01.2012 gebucht, so hätte er noch 500,00 € pro 7 Tage für den Reisezeitraum 01.09.2012 -10.09.2012 zahlen müssen. Verstehen wir uns da so miss?

Der Vorschlag der tmp Tabelle gefällt mir sehr gut. Weil der Anwender eben den Preisvorschlag übernehmen kann, oder gem. Deinen Worten mit seinen eigenen Preisen übermörteln darf. Wie also mein Wunschergebniss in die tmp Tabelle zaubern?

 

Da dieser Zeitraum 17 Tage umfasst (oder 16, je nach Bewertung eines Anreise- bzw. Abreisetages), müsste einem Unwissenden (Deiner gewünschten Anweisung) erklärt werden, warum nun gerade eine 7-Tages-Staffel eingesetzt wird.

 

Hallo Eberhard.

Da ist meine Datentabelle mit den voran geschriebenen Angaben nicht ganz plausibel. Neu:



<table border="1" class="tabletext"><tr><td class="tablehead1" colspan="9">Daten der Tabelle <strong>tbL_WohnungenPreise</strong></td></tr><tr><td class="tablehead1" align="center"><strong>PreisID</strong></td><td class="tablehead1" align="center"><strong>Wohnung</strong></td><td class="tablehead1" align="center"><strong>ReisezeitraumVON</strong></td><td class="tablehead1" align="center"><strong>ReisezeitraumBIS</strong></td><td class="tablehead1" align="center"><strong>TageVon</strong></td><td class="tablehead1" align="center"><strong>TageBis</strong></td><td class="tablehead1" align="center"><strong>Preis</strong></td><td class="tablehead1" align="center"><strong>GültigAb</strong></td><td class="tablehead1" align="center"><strong>GültigBis</strong></td></tr><tr><td class="tabletext2" align="right">1</td><td class="tabletext2">Wohnung 1</td><td class="tabletext2" align="right">01.09.2012</td><td class="tabletext2" align="right">31.10.2012</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">0</td><td class="tabletext2" align="right">500,00 €</td><td class="tabletext2" align="right">01.01.2012</td><td class="tabletext2" align="right">14.01.2012</td></tr><tr><td class="tabletext2" align="right">2</td><td class="tabletext2">Wohnung 1</td><td class="tabletext2" align="right">01.09.2012</td><td class="tabletext2" align="right">31.10.2012</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">0</td><td class="tabletext2" align="right">475,00 €</td><td class="tabletext2" align="right">15.01.2012</td><td class="tabletext2" align="right">31.08.2012</td></tr><tr><td class="tabletext2" align="right">3</td><td class="tabletext2">Wohnung 1</td><td class="tabletext2" align="right">01.07.2012</td><td class="tabletext2" align="right">31.08.2012</td><td class="tabletext2" align="right">7</td><td class="tabletext2" align="right">0</td><td class="tabletext2" align="right">550,00 €</td><td class="tabletext2" align="right">01.01.2012</td><td class="tabletext2" align="right">30.06.2012</td></tr><tr><td class="tablehead1" colspan="9"><font size="-2">Tabelleninhalte mit <a *****"http:>TabToWeb 0.75</a> nach HTML 4.01 transferiert.</font></td></tr></table>

- Anreise und Abreise Tag werden zusammen als ein Tag gewertet.

Weil eine höhere Staffel nicht hinterlegt ist. :-) Klartext: Es bleibt sich gleich, ob der Gast dann 55 Tage bleibt, es sei den in den 55 Tagen wird ein anderer An- und Abreise Zeitraum beschnitten.

 

Was heißt dass genau? Der Anreisetag ist ein halber Tag, und 6,5 Tage berechtigen noch nicht einen Preis nach einer 7-Tages-Staffel?

Du musst Deine Wünsche bzw. die Wünsche des Aufttraggebers in Regeln fassen, denn nur mit belastbaren Regeln kannst Du eine SQL-Anweisung oder aber eine VBA-Funktion oder ein Gemisch daraus aufbauen.

 

Hallo.

Anreise 0,5 Tag und Abreise 0,5 Tag = 1 Tag. Die Regeln sind schon genau definiert.

- In der Hauptsaison werden nur volle Wochen vermietet (7 Tage) in der Nebensaison können es auch angebrochene Wochen sein, aber meistens immer mehr als 3 Tage.

- In der Hauptsaison können je nach Objektgruppe An- und Abreisen nur Sa/Sa oder So/So stattfinden. Ob sich das nun per SQL abfangen lässt, wage ich zu bezweifeln. Hier würde ich wohl auf der Buchungsoberfläche bei Eingabe des Anreise- und Abreisedatums validieren.

 

Bei einem Wechsel von Gültigkeitszeiträumen - Du erinnerst Dich an Deine eingangs gestellte Frage - gibt es nicht Anreise und Abreise gemeinsam, sondern eben pro Gültigkeitszeitraum einen halben Tag. Also beantworte die Frage.

Regeln müssen gerade in den Grenzfällen belastbar sein, am besten in allen denkbaren Grenzfällen, falls das Gesamtgebilde fehlerunfällig sein soll.

 

Hallo zusammen,

Sascha, wie du siehst, hat deine Datenhaltung einige unerwünschte Auswirkungen *wink.gif*

Ich würde das - wie von Martin und indirekt auch Eberhard vorgeschlagen - anders aufbauen.

- Eine Wohnung (Bollerwagen, was auch immer ...) hat einen Grundpreis(-Tages/Wochen)
- Es gibt einen Saisonrabatt
Name------------Von---------Bis-----------Artikel_FK-------Minderung---Gültig_ab (Buchungsdatum)
Hauptsaison--xx.xx.xxxx--xx.xx.xxxx------Wohnung1----------0-------------xx.xx.xxxx
Nebensaison--xx.xx.xxxx--xx.xx.xxxx------Wohnung1---------50-------------xx.xx.xxxx
...
(für einen Buchungssatz musst du nur die Tage zählen, die in den(die) Zeitraum(e) reinfallen)

- Es gibt einen Zeitdauer Rabatt
Artikel_FK--- Mindestbuchungsdauer --- Rabatt --- Gültig_ab
Wohnung1 --- 0 Tage-----------------0
Wohnung1 --- 7 Tage-----------------10
- einen Frühbucherrabatt
... usw.

Damit kannst du auf alles reagieren und bist bezgl. der Buchungsdauer unabhängig.

BTW: das ist IMHO eine reine Kalkulationsaufgabe und hat mit Pauschalpreisen nichts zu tun.

Pauschalpreis wäre = Wohnung1 kostet für den Zeitraum xx.xx.xxxx-yy.yy.yyyy (und nur für diesen festgelegten Zeitraum) pauschal zzz,-- Euro.
Denkbar wäre somit eine entspr. aufgebaute zusätzliche Pauschalpreistabelle.
Hier könnte man z.B. eine Reisedauerverlängerung (wie oben) kalkulieren oder mit entspr. Zuschlägen arbeiten.

[EDIT]
GültigBis-Felder sind eigentlich überflüssig, da die Datensatzwerte bis zum nächsten GültigAB gültig sind.
Es sei denn, sie haben wirklich nur einen begrenzten, festgelegten Gültigkeitszeitraum (Staat der DDR)
Kommt es zu Überschneidungen (durch Fehleingaben) können sogar Fehlern in Berechnungen auftreten.
[/EDIT]

 

\@Marsu:
GültigBis-Felder sind eigentlich überflüssig, haben aber der Reiz, dass den Zeitraum bequem und effizient in SQLs ermitteln kann: Stichtag >= DatumVon AND (Stichtag