Office: (Office 2016) Datumsentscheidung bei monatsüberlappenden Wochen

Guteb Morgen,
Ich bitte um Tipps zur Herangehnsweise, um folgende Aufgabenstellung abzuarbeiten.

In einer monatlichen Quelldatei sind artikelbasierte Stückzahlen, deren Abverkauf pro Kalenderwoche dort hinterlegt wurde. Das eigentliche Zielsystem überschreibt nach bestimmten Kriterien (Datumskennung ist eines davon) die Werte.
z.B.

1. Monatsdatei 10.2019: Artikel 4711 wurde in KW44 18 Stück verkauft
2. Monatsdatei 11.2019 Artikel 4711 wurde in KW44 3 Stück verkauft

KW 44 überlappt vom Oktober in den November (28.10. bis 03.11.)
Das hätte zur Folge, daß nur die 3 Stück in der entsprechenden Woche bestehen bleiben würden und nicht die korrekt abverkauften 21 Stück.

Ich versuche daher den Artikeln ein Tagesdatum so zu verpassen, daß bei nicht überlappenden Wochen der Montag der Kalenderwoche, bei überlappenden Wochen aber der erste des Monats verwendet werden soll.

Dafür verfolge ich diesen Ansatz (alles noch Teststadium)
(Quelle: FirstDateOfCalWeek)

Code:

 

Hallo,

wie sind die Zahlen zu verstehen:

in KW 44 Nov 3 Stück -> in Oct 18 - 3 = 15?

mfg

 

Hallo Fennek11,
jeden Monat kommt eine Datei z.B. 10.2019 und 11.2019
In jedem Datenatz ist die Woche als Zahlenwert enthalten.
Die KW 44 überlappt aber und richtigerweise in beiden Monatsdateien enthalten Für den Teil, der auf den Oktober (aus 10.2019) entfällt stehen dort 18 Stück, für den Teil der auf den November (aus 11.2019) entfällt 3 Stück.
Warum das so ist (und auch so akzeptiert wird) kann ich nicht sagen.
Hab ich deine Frage hinreichend beantworten können?
VG
Thomas

 

Hallo Thomas,

Warum nicht addieren statt überschreiben ?

Gruß
Aloys

 

Hallo Aloys,
ich habe leider keinen Einfluss auf das Zielsystem, "not in my authority."
VG
Thomas

 

Hallo zusammen,
so weit funktioniert das, was ich bisher zusammengebracht habe zufriedenstellend gut..., wenn da nicht doch noch eine weitere Pirouette zu drehen wäre...

Wochen können ja nicht nur über Monatsultimo hinweg überlappen, sondern auch..., richtig über das Jahresultimo.

So der Fall in Woche 1 2019.

Mein weiter unten angeführter Code liefert korrekterweise bei
Code:

 

Wie soll eigentlich nachfolgend ausgewertet werden? Das sollte doch der Wegweiser sein, was man aus bekommenen Daten macht.

Dass man Kalenderwochen nicht sauber in Monate und Jahre umpacken kann, ist ja erkannt.

Ein Weg könnte sein, alle Informationen gleich beizubehalten. Struktur:
Artikel | Stückzahl | Monat | Jahr | KW | JahrKW

Da könnte man unmittelbar die Zeiträume ansprechen, die man benötigt. Redundanzen sind in Excel recht häufig üblich, warum nicht hier?

Wenn man die Zeitangabe auf ein Datum bringen will, was ja auch seinen Charme hat und weil man Woche, Monat, Jahr und vieles andere aus dem Datum herleiten kann, sollte man sich bewusst machen, dass ein solches Datum nur stellvertretend für den Zeitraum steht und nicht als präzises Datum zu verwenden wäre.
An der Stelle würde ich mit einer Kalendertabelle arbeiten:
Kalendertage fortlaufend für einen ausreichenden Zeitraum, in zusätzlichen Spalten einmalig berechnet Jahr, Monat, KW, ... zum Tag.

Herrührend aus den Dateiangaben kann man sich mit der Kombination "Monat | Jahr | KW" ein passendes Datum aus der Liste nachschlagen, bspw. das erste mit übereinstimmender Kombi.
Umgedreht könnte man dann aus dem Datum wieder Zeiträume ableiten und z.B. eine Quartalsauswertung anfertigen.

 

Guten Morgen Eberhard.

Das ganze dient dazu, für einen nachgelagerten ETL-Prozess die Daten so aufzubereiten, daß in die Zielarchitektur ohne Datenverlust durch immanentes Überschreiben (siehe vorangegangenen Beitrag vonAloys und meine Replik) geladen werden kann.

Du hast natürlich damit :

recht. Mir ist es auch bewusst, und dem AG, da er nur die Woche sieht, wird es egal sein. Die Tasache aber, daß das Zielsystem nicht additiv arbeitet. will ich über die "virtuelle" Abgrenzung umgehen. Außerdem hat das nur eine kurze Halbwertszeit und soll für einen Übergang herhalten.

Den Ansatz, hier eine Kalendertabelle zu verwenden halte ich generell für richtig, an dieser Stelle aber für überdimensioniert.

Ganz herzlichen Dank für deinen Input.

Einen schönen 3. Advent
Thomas

 

Kann sein, muss nicht sein.

Einige Gedanken:

- Eine einmalige Erstellung und langfristige Nutzbarkeit von ein paar Tabellen muss jetzt nicht der Riesenaufwand sein, auch entwicklerseitig nicht. Etwas aufwändigere VBA-Prozeduren oder Formeln haben auch ihren Preis.
Man könnte ja spaßeshalber die obige Aufgabenstellung präzisieren, dass das erzeugte Datum nicht auf ein Wochenende und nicht auf einen Feiertag fallen soll, womöglich noch bundeslandkompatibel.

- Die obige VBA-Berechnung ist auf jeden Einzelwert jeweils neu auszuführen, also mindestens entsprechend der Datensatzanzahl. Da summiert sich auch Aufwand.
Eine Tabellenlösung wird darauf orientieren, dass häufig benötigte Berechnungsergebnisse einmal berechnet werden und dann nachschlagbar fixiert werden. Bei einem Kalender wird das besonders deutlich, auch aus praktischem Erleben daran: Für den Ostermontag genügt es, ihn einmal in 10 Jahren zu berechnen.

Die Frage, die sich also auch stellen kann: Bin ich jeweils schneller und sicherer, wenn ich für jeden ankommenden Wert komplett neu berechne, oder bin ich schneller, wenn ich für diesen Wert in einer Tabelle nachschlage.
Dass der zweite Weg gut funktionieren kann, beweisen die nach wie vor benutzten Papierkalender (die auch einige Zeit vor Verwendung geplant und gedruckt werden).

- Aufwand für eine Lösung wird man auch daran bemessen, ob diese Lösung nur für einen winzigen konkreten Fall benutzt wird oder aber man diese Lösung, die man nun schon mal da wäre, für gleiche und ähnliche Aufgaben ergiebig eingesetzt werden kann und man man dafür auch seine Augen öffnet: Auto nur zum Brötchen holen, oder könnte man da auch Einkaufen fahren, die Kinder zum Sport bringen, zur Arbeit kommen usw.

- Nicht zuletzt: Lösungen, die man "auf Lager" hat, sind dann auch schneller und unaufwändiger in eine Anwendung integriert.