Abrechnungszeiträume bestimmen

  • gritsch schrieb:

    warum speicherst du das kaufdatum nicht einfach als zahl?
    also: (tag + (monat * 100) + (jahr * 100 * 100))
    dann kannst du ganz einfach damit rechnen, schnelle abfragen laufen lassen und hast nie ein problem der zeitzonen, dst, oder was auch immer.


    So hab ich das bei einer Mac-App für Verzugszinsberechnung gemacht. Funktioniert einwandfrei
    Ich bin gegen Signaturen!!!

  • Ich bin eher der Meinung, das ein die eigenschaft Datum auch als Datum gespeichert werden sollte.
    Denn Berechnungen mit Datumsangaben sollte man einfach mit den vorhandenen Mitteln durchführen und nicht selbst was basteln.
    Insbesondere beim Berechnen, bin ich doch darauf angewiesen, das Schaltjahre und die Monate korrekt berechnet werden. Da gibt es auch Ausnahmen, die alle 400 Jahre zutreffen.
    Das führt nur zu weiteren Fehlern, wenn man da selbst Hand anlegt.

    Mir ist übrigens die Problematik nicht ganz klar. Du sprichst von einem monatlichen Zeitraum schlägst aber einen Monat drauf und ziehst einen Monat ab.

    Wenn die Berechnung automatisch täglich durchgeführt wird, reicht es dann nicht zu prüfen, ob man vor dem (oder gleich) 15. oder nach dem 15. des monats liegt?
    Dann hat man doch immer die Antwort.

    Du solltest (mir zumindest) die Problematik ein wenig genauer erklären.
    Die Antworten oben zielen vermutlich auf die Speicherung ab, Aber warum dann nicht gleich die Abfrage so gestalten, dass ich nur die entsprechenden Einträge bekomme?
    Also nicht hole alle und dann alle jeweils prüfen, sondern hole mir die Bestellungen aus dem März/April. Dann entfällt die Prüfung.

  • entwickler schrieb:

    Ich bin eher der Meinung, das ein die eigenschaft Datum auch als Datum gespeichert werden sollte.
    Denn Berechnungen mit Datumsangaben sollte man einfach mit den vorhandenen Mitteln durchführen und nicht selbst was basteln.
    Insbesondere beim Berechnen, bin ich doch darauf angewiesen, das Schaltjahre und die Monate korrekt berechnet werden. Da gibt es auch Ausnahmen, die alle 400 Jahre zutreffen.
    Das führt nur zu weiteren Fehlern, wenn man da selbst Hand anlegt.

    Mir ist übrigens die Problematik nicht ganz klar. Du sprichst von einem monatlichen Zeitraum schlägst aber einen Monat drauf und ziehst einen Monat ab.

    Wenn die Berechnung automatisch täglich durchgeführt wird, reicht es dann nicht zu prüfen, ob man vor dem (oder gleich) 15. oder nach dem 15. des monats liegt?
    Dann hat man doch immer die Antwort.

    Du solltest (mir zumindest) die Problematik ein wenig genauer erklären.
    Die Antworten oben zielen vermutlich auf die Speicherung ab, Aber warum dann nicht gleich die Abfrage so gestalten, dass ich nur die entsprechenden Einträge bekomme?
    Also nicht hole alle und dann alle jeweils prüfen, sondern hole mir die Bestellungen aus dem März/April. Dann entfällt die Prüfung.


    bei solchen sachen eben nicht. so kann ich sicher sein dass die genannten probleme (DST, timezonen) nicht plötzlich aus 31. Mai 23:30 den 1. Juni 0:30 macht und somit zu teuren problemen führen kann.

  • Ich denke doch mal es geht um eine kontinuirliche Abrechnung. Warum speicherst du dir nicht einfach das Datum der letzten Abrechnugn (oder noch besser falls es da System noch hergibt) du flaggst alle berechneten rechnungen. Dann brauchst du nur alle Rechnungen nach dem Datum oder eben die nicht als abgerechnet geflaggt sind nehmen und fertig. So ist das Datum total egal und es kann auch keine Rechnung verloren gehen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Das meinte ich. Nicht selbst mit Monat+1, if Monat>12, dann Jahr+1, basteln, sondern die Methoden von apple nutzen.

    gritsch schrieb:

    bei solchen sachen eben nicht. so kann ich sicher sein dass die genannten probleme (DST, timezonen) nicht plötzlich aus 31. Mai 23:30 den 1. Juni 0:30 macht und somit zu teuren problemen führen kann.

    Aber das muss man doch nur vorher (in dem Moment, wo ich etwas berechne) bestimmen, in welchem Zeitrahmen/Zonen man arbeitet will. Wenn die Zeit korrekt gespeichert ist, dann habe ich alle Daten, die ich für weitere Berechnungen benötige. Als die Eigenschaften Sekunden, Minuten, Stunden, Tag, Monat, Jahr, Zeitzone getrennt zu speichern. Auch der Speicherplatz erhöht sich doch dadurch. Umrechnen – in was auch immer – kann ich doch danach.
    Wobei ich sagen muss, dass ich noch keine Berechnungen über Zeitzonen gemacht habe, aber ich erwarte vom apple-Framework, dass wenn ich eine New Yorker Zeitstempel von einer Berliner Zeit subtrahiere, es mir die korrekte Differenz wiedergibt.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von MacounFFM () aus folgendem Grund: Löschung auf Wunsch des Nutzers

  • Ehrlich gesagt. Verstehe ich immer noch nicht, was genau Du machen möchtest. Aber wenn das obige Zitat dein Problem ist, dann bestimme doch einfach den letzten Zahltag. Prüfe, ob er in diesem Monat war und gehe dann entsprechend vor.
    Wenn Du nicht direkt den letzten Zahltag aus der DB/den Quelldaten bekommst, dann kannst Du dies ja ebenfalls in einer for/next ermitteln.
    NSInteger month = [dateComponents month];
    NSInteger year = [dateComponents year];
    und jeweils den höheren Wert zwischenspeichern, am Ende hast Du das Jahr und den Monat deines letzten Zahltages. Damit solltest Du das obige Problem lösen können.

    Wobei ich mir sicher bin, das es auch eine saubere, bessere Lösung gibt. Wo werden die Daten überhaupt gespeichert?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MacounFFM () aus folgendem Grund: Löschung auf Wunsch des Nutzers