Office: (Office 2010) Staffelpreise mit Gültigkeitsbereichen

//OT: Das Beispiel hinkt nicht nur. Es keine Chance, auf die Beine zu kommen.
Derjenige, der das gewusst hat, hat sich bis jetzt gut versteckt.
Denn selbst für diejenigen, die immer alles wissen, kam der Zeitpunkt des Endes der DDR sehr überraschend.

Finde ich in der Situation nicht, oder wer garantiert eine unmittelbare und lückenlose Nachvermietung der Wohnungen und der eingangs angesprochenen Zusatzleistungen?

 

\@ebs: wen meinst du *confused.gif*

 

Ich meine die Sachen, auf die ich antworte, egal wer das äußert.

 

Hallo Sascha,

ich fasse meine bisherigen Gedanken zu folgenden Vorschlag zusammen:

- Du erstellst eine Kalenderhilfstabelle (alle Felder indiziert) über einen ausreichenden Zeitraum. Dabei ist das fortlaufende Tagesdatum der Primärschlüssel. Weitere Felder könnten festgehaltene berechnete Werte aus dem Datum sein wie Wochentag (zur Beherrschung des Wochenendes wie oben gewünscht oder Formate wie yyyymm, kw, q, wenn bei Zeitraumauswertungen bestimmte Gruppierungen benötigt werden.

- Aus den Tabellen aus #1 erstellst Du eine Abfrage Leistungbeschreibung/GültigAb/GültigBis (ohne Duplikate). Für diese Abfrage erstellst Du pro Datensatz eine Kalendertabelle, also Kreuzprodukt aus Abfrage und Kalendertabelle.
Da hier sehr schnell große und damit leistungsfressende Datenmengen entstehen, ist es angeraten, frühzeitig auf sinnvolle Werte zu filtern, also die Kalendertabelle z.B. auf die kommenden drei Monate und die Abfrage auf die wirklich nachgefragten Leistungen.

- Jetzt bekommst Du Eingangsparameter: Leistung, Beginn, Ende.
Damit filterst Du das eben beschriebene Kreuzprodukt und kannst das Ergebnis gruppieren/aggregieren und erhältst pro Leistung und Beginndatum die Anzahl der angefallenen Tage. Mit dieser Tagesanzahl kannst Du je nach Variante die zugehörige Tagesstaffel oder den Laufzeitrabatt ermitteln und letztlich mit Tagesanzahlen und Einzelpreisen zu einem Gesamtergebnis kommen.

Das ganze lässt sich eigentlich noch in einer Abfrage erledigen.

Jetzt zur Thematik halbe Tage: Die Kalendertabelle kann damit schlecht umgehen. Ich habe derzeit keine Vorstellung, wie man das umsetzen kann, aber die bisher beschriebene etwas komplexere und umfangreiche Abfrage dürfte dann um Unterkante Faktor drei komplexer und umfangreicher werden, falls sie gelingt.
Einfacher wäre es, den ersten halben Tag als ganzen zu werten (und bezahlen zu lassen) und den abschließenden halben Tag zu "schenken".

 

Hallo Ihr.

Kommen nun auf das Thema zurück und danke Euch allen für das Feedback. Eberhard speziellen Dank für die Zusammmenfassung. Folgend eine Preistabelle und eine Übersicht:

http://www.ms-office-forum.de/forum/...1&d=1349188995

http://www.ms-office-forum.de/forum/...1&d=1349188975

Das mit den 0,5 Tagen ist mir verständlich. Vielleicht ist es besser von Anzahl an Übernachtungen zu reden. Dann sollte die Problematik nicht auftauchen (siehe Grafik Übersicht). Grundsätzlich ist mir der Vorschlag der Kalendertabelle verständlich, aber ich kann den Vorteil nicht genau erkennen. Mit der Preistabelle kann ich doch alles verwalten und abfragen. Was übersehe ich da?

Bucht einer in der Nebensaison 4 Tage, dann erhält er "3er" Preis nämlich (150,00 € / 3 Nächte) * 4 Nächte = 200,00 €

Bei 7 Tagen in der Nebensaison eben den "7er" Preis. Soweit so gut. Was aber, wenn er 9 Nächte in der Nebensaison bucht?

Dann müsste der Preisvorschlag lauten:

7 Nächte = 300,00
2 Nächte = ?

(?) Der "3er" Preis findet also keine Anwendung. Demnach muss ich also einen Tages(Nacht)grundpreis hinterlegen. Gemäß Tabelle von 1 Nacht bis 1 Nacht.

In der Hauptsaison erkenne ich ein Problem. Nämlich folgendes. Im Regelfall werden nur volle Wochen vermietet, ich muss alo sicherstellen, dass nur volle Wochen gebucht werden können. 7 Nächte = ok / 14 Nächte = ok / 15 Nächte = nicht ok.

Das von Marsu vorgeschlagene Modell kann ich nicht nachvollziehen. Grundpreistabelle, Saisonrabatt-Tabelle, Staffelrabattabelle. Meine Tabelle bildet dies doch auch ab, oder? Ich werde das Gefühl nicht los, dass ich das Problem noch nicht so richtig erkannt habe oder ich habe mich einfach nur schlecht formuliert. Vielleicht kann mir jemand die Problematik erklären und davon ausgehen, dass ich "Dumm" bin. Bei mir Kippen manche Schalter eben erst später. Sorry.*stupid

Nachtrag:

aus #10

Jetzt habe ich mir selbst widersprochen. Grundsätzlich gilt das hier geschriebene. Eine angebrochene Woche wird nicht mit dem Durschnittspreis der vollen Woche belohnt.

 

Mit einer Kalendertabelle hast du "Zusatzangaben" zum Tag wie z.B. das Quartal, den Monat oder eben auch die Saison zur Hand, und kannst durch Verjoinung mit den GültigVon/-bis-Feldern bequem die Tage pro Saison ermitteln.

 

Das ist aber ein Problem der Eingabeprüfung und hat mit Preisberechnungen nichts zu tun.

Angenommen Buchungswunsch 22.09. - 06.10. / ab 01.10 Nebensaison

Mit der von mir vorgestellten Variante erhieltest Du über die Kalendertabelle einen Datensatz pro Tag (und Leistung):
22.09. / HS
23.09. / HS
...
30.09. / HS
01.10. / NS
02.10. / NS
...
06.10. / NS

Hiermit kannst Du per Abfrage zählen (über Gruppieren/Aggregieren).
Du wolltest doch eine Abfrage?

Zusätzlich bietet die Kalendertabelle wie beschrieben indizierte Werte für Filterungen und Gruppierungen. Das ist dann bezüglich Performance bei großen (datenbankgemäßen) Datenmengen sehr hilfreich.

Du kannst natürlich auch per Datumsfunktionen die Differenzen bilden, dann aber eher nur mit VBA weiterverarbeiten, per DLookup's Werte aus Tabellen holen usw. Das wäre dann eine Frage des Umfangs von Daten.

Und: Im Thema wurde fließend von Zusatzleistungen zu Wohnungen übergegangen. Ich unterstelle aber, dass erstere weiter eine Rolle spielen und auch in das System hinein passen sollen.
Ist diese Unterstellung berechtigt?

 

\@ebs17

sehe ich auch so.

Jepp. Diese wird dann bei Buchung angezeigt und der Nutzer soll vorgeschlagene Preise übernehmen können oder Preise selbst erfassen können.

Ich habe noch nie mit Kalendertabellen und Kreuztabellenabfragen gearbeitet und mir ist noch nicht klar wie das Endergebniss aussehen könnte. Mal schauen. Zum Datenmodell: Reicht meine gezeigte Preistabelle aus, oder sollte ich am Datenmodell noch was ändern?

Wie darf ich das mit dem "ohne Duplikate" verstehen?

 

Ich sprach von Kreuzprodukt (kartesisches Produkt / CROSS JOIN):
Code:

Da wird jeder Datensatz mit jedem Datensatz einer anderen Tabelle kombiniert. 14 Datensätze der einen Tabelle und 7 Datensätze der anderen Tabelle ergeben also 14 * 7 = 98 Datensätze.

Na so, dass die Kombination der drei Felder jeweils eindeutig ist, sonst wird das eben beschriebene Kreuzprodukt noch umfangreicher und vor allem schlechter auswertbar.

Deine Preistabelle überzeugt mich weder strukturell noch inhaltlich (mehrfache gleiche Feldnamen, redundante Inhalte):
1. Datensatz: 7 Tage kosten nun 500 € oder 7 * 71,43 € = 500,01 €?
Daraus abgeleitet: Wie berechnet man 9 Tage?
500 + 2 * 71,43 oder 9 * 71,43?
Wenn man hier mit vielen IIf's arbeiten müsste, hat man einen ernsthaften Hinweis, dass Strukturen und Abläufe nicht passen.
Stichwort: Eine Regel muss über alle Varianten belastbar sein.

Ich hatte einen Weg beschrieben: Vielleicht solltest Du ihn gehen, um zu sehen, wo Du ankommst.

 

Hatte ich mir gedacht*frown.gif* Ich werde das Datenmodell überarbeiten und dann hier vorstellen. Deine Voschläge setze ich dann mal um. Bei Fragen erscheine ich wieder hier. Danke Eberhard & und schönen Feiertag Euch allen.

 

Hallo zusammen,

 

Hallo Marsu.

Danke für Deinen Gedankenanstoß. Wie in #25 erwähnt, werde ich das Datenmodell überarbeiten und hier zur Diskussion bereitstellen.

Mache ich aber leider *frown.gif* Wenn ich nachher die Tabellen nicht auflösen kann, um zu meinen Wunschergebnis zu kommen, kann es zwei Ursachen haben: 1. Das Datenmodell ist falsch oder 2. Ich unterschätze die Fähigkeiten von SQL.