Office: (Office 2003) Datum addieren ohne Wochenende

Hallo zusammen,

ich habe folgendes Problem in Access und hoffe, dass mir jemand dabei helfen kann.
Und zwar habe ich ein Feld LetztePrüfung (Datum) und ein Prüfungsintervall (Optionsgruppe). Mit der Optionsgruppe Prüfungsintervall kann man das Intervall 6 Monate, 12 Monate, 18 Monate oder 24 Monate auswählen.

Nun würde ich gerne das Datum für die NächstePrüfung berechnen. Dies stellt ja mit der Funktion DatAdd kein Problem dar, da die Formel für das Steuerelementinhalt Nächste Wartung= DatAdd („m“; [Prüfungsintervall];[LetztePrüfung] ist.
Nur würde ich gerne wissen, ob es mit einem VBA Code möglich ist, dass man die Samstage und Sonntage nicht mitberechnet.

Leider bin ich nicht der Programmier-Profi und hoffe, dass ihr mir dabei helfen könnt.

Danke
Eva

:)

 

Hallo und willkommem im Forum *hands,

vermutlich soll der Termin ja auch nicht an Pfingsten oder Weihnachten sein, richtig?

Dann rate ich zu einer Kalendertabelle mit allen Datumswerten des Jahres (anwachsend), in der die Nichtarbeitstage (Sa/So/Fei) durch ein J/N-Feld gekennzeichnet sind. Da kann man dann gucken, wohin der "Serientermin" fällt, und ggf. per Recordset ein bisschen vor- oder nachrutschen. Im Idealfall könntest du damit eine DateAdd-Variante bauen, die eben dieses "Anpassen" übernimmt.

Ein orignal VBA-DatAdd "nur für Werktage" ist jedenfalls nicht möglich. Tage sind Tage, und Monate sind Monate.

Wenn die Kalendertabelle existiert, meld dich nochmal mit den Namen der Tabelle und Felder, dann bau ich dir eine kleine DateAdd-Variante, die das macht.

 

Hallo
weiss nich ob dir das Hilft

Anzahl Arbeistage zwichen zwei Datum (anz. Tage ohne Sa, So, Feiertage)

AnzArbeitstageOFTSASO =
Arbeitstage
LngAFT = Feiertage
LngASA = Samstage
LngASO= Sonntage

Code:

für die Feiertag Berechnung brauchst Du Noch die Tabelle TblFeiertage
kann ich dir auch den Code liefern. *Smilie

 

Hallo,

vielen Dank schon mal für die Antworten.
Hab jetzt die Prüfungsintervalle 6,12,18, 24 Monate in Tage umgeschrieben. Gibt es denn da eine Möglichkeit mit der Funktion DatAdd das Datum für NächstePrüfung ohne Wochenende ausrechnen kann?
Es geht mir primär darum, die Wochenenden nicht zu berechnen und vielleicht dann noch die Feiertage.
Für Hilfe und Infos wäre ich sehr dankbar.

Gruß
Eva

 

Hallo Eva,
wenn ich Dich richtig verstanden habe, geht es dir darum, dass dein errechnetes Datum nicht auf ein Wochenende liegt.(fangen wir damit erst mal an)
Ist es dann nicht eine Möglichkeit, das Datum zu errechnen und dann zu prüfen, ob es auf einen Samstag, Sonntag liegt, und das Datum dann auf den nächsten Montag zu verschieben?

 

Hi,

niemand hat davon gesprochen, die Fristen auf Tage umzurechnen. Das ist auch gar nicht so einfach (wie viele Tage sind denn 3 Monate?!). Das war also unnötig.

Ignoriert hast du dagegen die Aussage (v.a. jetzt. wo Feiertage auch in Sicht kommen), dass DateAdd nunmal nur Tage, WOchen etc. "kann". Werktage sind da einfach nicht definiert.

Du hast zwei Lösungen bekommen, die mit Hilfe einer "Nur-Feiertagstabelle" (Lanz Rudolf) bzw. einer Kalendertabelle (ich) arbeiten. Die hast du nicht verfolgt.

Was soll man dir nun raten? *frown.gif*

 

Hallo Lanz Rudolf,

hab die Feiertagstabelle nun endlich gebastelt.
Aber nun habe ich noch eine Frage zu deinem Code:
Wie kann ich in den Code meine Formel für das Feld NächstePrüfung= DatAdd („m“; [Prüfungsintervall];[LetztePrüfung] einbauen, damit ich das Prüfungsintervall ausgedrückt in Monaten mitberechnen kann?

Für Hilfe wäre ich dankbar.

Gruß
Eva

 

Hi,

da wirst du dir eine klein Funktion bauen müssen:

1. "rechnerisches" Folgedatum mit DatAdd ermitteln
2. Recordset der Feiertagstabelle öffnen für SÄtze, die >= rechnereisches Datum sind
3. wenn rechenrisches datum kein feiertag ist -> fertig
4. Wenn es ein feiertag ist, so lange 1 addieren, bis es kein feiertag mehr ist.

Wenn du alle Kalendertage (nicht nur die Feiertage) in der Tabelle hast, könntest du auch einfach den kleinsten Arbeitstag der Tage nehmen, die >= rechnerisches Datum sind. Das käme dann ganz ohne VBA aus:

Code:

 

Hallo
Taggenaue Prüfungsintervalle sind ein Greul.
Wenn du nicht am Wochende prüfen willst steigt der Intervall ja doch um bis zu 2 Tage.
Sinnvoll ist gleichzeitig zum Prüftermin Karenztage festzulegen.
Monntags kann man dann schauen welche Prüfungen fällig sind oder die fälligen Prüfungen vorziehen.
Das ist z.B. bei unser Prüfmittelüberwachung usus

 

Ich verstehe ehrlich gesagt nicht wofür man eine Jahrestabelle braucht nur um bei einem Datum zu prüfen ob es ein Feiertag oder ein Wochenende ist.

Mit Hilfe einer Formel die ich in einem Buch gefunden habe, habe ich die folgende Funktion zur Ermittlung der Feiertage in Deutschland gebastelt:

Code:

Man übergibt das Datum und bekommt zurück ob es ein Feiertag ist oder nicht (geht übrigens bis ins Jahr 2099 genau). Übergibt man noch ByRef ftag kann man auch noch den Namen des Feiertages selber abholen und z.B. als Anzeige mit nutzen.

Und um festzustellen ob es ein WOE ist, geht das so doch einfacher:

Code:

Also wenn man nicht unbedingt besondere Sachen wir Betriebsurlaub oder ähnliches mit berücksichtigen muss, geht es doch mit den beiden Funktionen einfacher als Jahrestabellen anzulegen. Oder sehe ich da was falsch?

Gruß

Rainer

 

Meiner Meinung nach: ja, das siehst du falsch.
Feiertage kann man zwar ausrechnen. Aber ob die bis dahin auch noch Feiertage sind, hängt von der Gesetzeslage ab. Die ist variabel gegen die Zeit.

Man denke nur an den Buß- und Bettag oder den 17.Juni, der mal "hoch und heilig war".

"Ich hab zu" ist eine letztlich gewillkürte Sache. Und Willkür lässt sich nicht in Code gießen.

Zudem gibt es ja durchaus auch

• lokale Spezialitäten (Karneval in Kölle, Friedensfest Aufgsburg)
• Betriebsspezifika (Werksferien)
• Trotzdem-Arbeitstage: Notdienste arbeiten immer, auch die Börse/Zahlungssysteme wie Target kennen nur wenige "closing days".
• ich selbst hatte mal eine arbeitstägliche Datenlieferung, die leider vom Erzeuger nicht immer richtig erzeugt wurde. Da gab es dann Tage, die "falsch" waren und für die dann statistisch der Vortag weitergelten musste. Da musst dann auch mal ein ganz normaler Tag "weggeworfen" werden - flupp, war das ein "Feiertag", und alles war wieder glatt.

Willst du das alles in Code pressen?!

Und schließlich will man ja oft auch den nächsten/vorigen Werktag wissen. Selbst dann, wenn mal superseltene Kombinationen auftreten und mal tatsächlich 20 "freie" Tage aufeinanderfolgen. Das lässt sich dann mit einer "kleinste der größeren" oder "größter der kleineren"-Abfrage per SQL erzeugen...

 

Deswegen hatte ich ja foglenden Satz in meinem Post geschrieben:

Aber sowas kann man relativ einfach ändern:

Feiertag einfach aus dem Code rausnehmen. Sowas musst Du wenn Du es berücksichtigen willst eh konstant per Hand aktualisieren. Und bevor ich jeden Feiertag in eine Tabelle für's laufende Jahr einarbeite, änder ich lieber eine Zeile im Code und fertisch.

Wobei das wiederum eine ganz andere Thematik ist, hat ja nix mit normalen Wochenenden oder Feiertagen zu tun.

Aber gut, hab begfriffen worauf Du hinaus willst und gebe Dir zum Teil Recht - insbesondere bei lokalen Gegebenheiten und Betriebsbesonderheiten.

Aber andersrum sowas kann man eh nur in Anwendung die speziell für einen Betrieb erstellt sind berücksichtigen ... und dann kann man das schon wieder gut in einen Code packen, bzw. nur die von der Norm abweichenden Besonderheit erfassen und braucht nicht die Jahrestabellen die man per Hand erstellt (werden sie per Code erstellt dann ist es ja in Code fassbar und dann kann man gleich den Code für den Feiertag einbauen).

Somit nein, verstehe die Logik dahinter das von Hand erstellte Jahrestabellen die jedes Jahr neu geschrieben werden müssen besser sein sollen nicht wirklich. *wink.gif*

Gruß

Rainer

 

Der 17. Juni war aber 1988 noch Feiertag. Heute ist er es nicht mehr. "Ist Feiertag" ist zeitabhängig und wird beim Erreichen Geschichte, also Fakt. Und Fakten gehören in Tabellen, oder? Ich habe hier arbeitstägliche Daten bis zurück in 1982... damals gabs noch keinen 03.10. als Feiertag.

Notdienste und Target als "ganz andere Thematik":
Das ist nichts anderes. WOchenende und Feiertage heißen "hier läuft nix", und das ist je nach Aufgabe bei Nortdiensten und Zahlungssystemen etc. eben anders. Das meinte ich ja mit "Ich hab zu": Target hat am 3.10. auf, und damit muss z.B. ein Zahlungssystem umgehen können. Andere Systeme haben am 3.10 wirklich frei und "haben zu", da ist das ja dann auch ok.

Jede Datenbank hat eine Aufgabe. Und dnatürlich gibt es Fälle, wo die schiere Feiertagsberechnung ausreicht. Meine Erfahrung zeigt aber, dass man mit einer Feiertags- oder auch "Jahreskalendertabelle" flexibler ist.

Meine Kalendertabellen fülle ich übrigens per Generator. Der aber liest die aktuelle Feiertagstabelle aus, wendet sie an - und erzeugt Sätze mit Arbeitstag = True/False. Im nächsten Jahr sind die Feiertage womöglich anders.

PS: Feiertage interational sind auch ganz nett. Synchronisiere mal per Code die Feiertag in den zig Ländern, in denen meine Firma sitzt... *Smilie "4. Juli: USA haben zu, D hat auf, ... " Und Weihnachten? Und Sabbat/Freitag in andere Religionen? Fragen über Fragen... alles fließt! *Smilie

 

\@ Artrus

Ich kann mir gerade nicht vorstellen das es heute wichtig wäre zu wissen ob der 03.10.1982 ein Feiertag war ... und auch das liesse sich mit einer Zeile mehr in meinem obigen Code problemlos ermitteln/auswerten.

Der Feiertag ist doch nicht zu speichernde Relevanz, sondern wenn überhaupt wurde an diesem Tag gearbeitet ja oder nein.

Und desweiteren ist die Eigenschaft Feiertag eh ein berechnetes Feld und hat von daher nicht wirklich was in einer Tabelle zu suchen. *wink.gif*

Aha ... also doch code basiert. ^^ Und die Feiertage im nächsten Jahr sind mit Sicherheit anders da Ostern immer an einem anderen Datum liegt und einige der folgenden Feiertage von Ostern abhängig sind.

Also wirst Du immer eine Basis brauchen ... Feiertage und Wochenenden. Die musst Du irgendwo her holen und da macht die Handeingabe ja nun wirklich keinen Sinn nur weil evtl. nächstes Jahr ein Feiertag keiner mehr ist. Sowas korrigiert man in der Funktion in dem man sagt das Datum XYZ nur berücksichtigen wenn das Datum nach dem Jahre 2009 liegt.

Wenn es nun gilt unterschiedliche Bereiche zu koordinieren eben Arbeitstage in verschiedenen Ländern und/oder normal Arbeitszeit Büro, Arbeitszeit Not-/Reparaturdienst am besten noch mit Schichtplänen wer von wann bis wann ... ja, da gebe ich Dir Recht da hilft wirklich nur eine Tabelle in der alles als Eigenschaft/Argument der Entität Tag erfasst wird. Aber auch da gehört nicht wirklich rein ob Wochenende oder Feiertag (sind ja beides nur berechnete Felder), sondern nur wurde gearbeitet ja/nein bzw. wo wurde gearbeitet und wo wurde nicht gearbeitet.

Aber in wie vielen Fällen ist das wirklich nötig?

In der Mehrzahl der Fälle reicht es schlicht zu wissen ist an dem Datum ein Wochenende oder ein Feiertag und im Zweifel ergänzt um noch ein paar lokale Parameter, die sich aber über eine Tabelle wo nur die Ausnahmen abgebildet werden besser darstellen lässt.

Aber auch nur wenn Du sie per Hand erstellst. Erstellst Du sie per Code automatisiert bist Du genauso wenig flexibel, bzw. brauchst Nacharbeit per Hand um eben Abweichungen von der Norm zu erfassen.

Speichert man aber nur die Abweichungen ab (z.B. Betriebsurlaub oder lokale Sachen wie Bergkerwa in Erlangen oder Karneval in Köln) bin ich mit einer Berechnung genauso flexibel/unfelxibel wie mit einer Tabelle.

Gruß

Rainer

 

Hi,

zum folgenden: Feiertag heißt "der Laden hat geschlossen" als J/N-Feld. Warum er zu hat, ist eine ganz andere Sache...

Gewesenes ist aber Fakt geworden und sollte nicht durch Code "neu ermittelt" werden, denn ebi dieser Neuermittlung können sich Fehler einschleichen. Zumal du dann in deinem Code ja auch eine Art History einbauen müsstest: war Feiertag in den Jahren von-bis. Ist aber doch längst zu Daten geronnen und wird nie wieder "angewendet".

Darum hab ich ja auch nur ein J/N-Feld drin.

Nein. Feiertagsein ist zeitabhängig. Entweder führst du dann im Code eine Historie, oder legst einfach die Wahreit in der Tabelle ab. Wer weiß: im Jahr 2150 ist Ostern vielleicht auch kein Feiertag mehr. Und dann?

Ich erzeuge nur die Kalendertage per Dateserial-Schleife und setze Sa und SO auf tot. Den Rest mache ich mit der Hand anhand der Vorgabe der offiziellen Stellen (EZB für Target, Betriebsvereinbarungen für internes etc.). Man kann das Osterdatum zwar ausrechnen, man kann aber nicht ausrechnen, ob das ein Feiertag ist. Anders als Naturgesetze, kann man Gesetze ändern, und flupp, ist Ostern kein Feiertag mehr. Und dann?

Und den 17. Juni gabs nur von 1954 (?) bis 1990 (?). Ah ja. History by Coding. Schreibst auch "damals gewesene" MwSt-Sätze in Code?

Fast überall. Meist sind ja Termine (im weitesten Sinne) an Feuertage unerwünscht. Dann muss man oft den vorigen oder nächsten Tag raussuchen. Der Datenbank ist es ja wurscht, ob Feiertag ist , die arbeitet solange der PC läuft... die Menschen interssiert das aber, um zu reagieren, Termine zu verschieben, Dinge vor- oder nachzulagern etc. U.U. wird Feiertagsarbeit auch besser bezahlt, da ist es absolut wichtig zu wissen, ob das ein Feiertag war. So von wegen AUfbewahrungsfristen, Gehaltsarbechnung und so.

Das kann man ja diskutioeren, ob man alle kalendertage oder nur die (viel selteneren) Nichtarbeitstage ablegt. Aber z.B. eine "nächster Werktag"-Ermittlung ist bei einer Nur-Feiertags-Tabelle schweiriger als bei einer "Kalendertagetabelle", weil man da einfach den kleinsten der späteren Arbeitstage nimmt....

Die Hand ist teilautomatisiert (365/366 Tage eintippen ist mir zu doof). Aber ansonsten ja, ich pflege das per Hand. Die Wirklichkeit entsteht ja auch per Hand: der Köhler unterschreibt ein neues Gesetz, und schwupp ist Neujahr ein Arbeitstag. Da kommt keine Formel mit! Realität ist komplex!

Was nicht zu berechnen ist, kann man nur glauben, und das heißt: in Tabellen ablegen.

Kurz: Vieles, was "müsste", "ist" nicht. Mein Feierabendzug müsste auf Gleis 9 abfahren, tut er heute ausnahmsweise nicht. Der Anzeigetafel ist aber völlig egal, wo er stehen müsste, sondern ich muss wissen, wo er steht. Das ist prinzipiell formelbasiert, aber im Einzelfall variabel. Das ist bei den Feiertagen auch so.