Relativen Anteil von zwei Datümer auf Monatsebene umrechnen

Bitte aktiviere JavaScript!
ChronoUnit.MONTHS.between und ChronoUnit.HOURS.between ist doch wesentlich einfacher, als in einer Schleife durchzugehen
 
ChronoUnit.MONTHS.between und ChronoUnit.HOURS.between ist doch wesentlich einfacher, als in einer Schleife durchzugehen
Klar kann ich jede Menge Frameworks anhängen. Ich tendiere halt immer dazu eine Funktion eben schnell selbst zu schreiben wenn ich sonst nichts aus einer Lib brauche. Aber das ist heutzutage ja nicht mehr in Vogue. Lieber aufblähen die App.
 
Ich bin mir nun wirklich nicht mehr sicher, inwiefern sich die Berechnung bei den verschiedenen Gebührenintervalle unterscheidet und was die notwendigen Schritte sind???
Wenn Du z. B. eine Flatrate für 10 €/Monat verkaufst, der Vertrag eine Laufzeit von 12 Monaten vorsieht und Du eine Vorauszahlung der 12 Monate verlangst, dann würde ich das als Monatspreis sehen, der eben 12-mal berechnet wird.

Die Frage ist, welche Konditionen Du beim Wechsel in einen anderen Tarif während der Vertragslaufzeit anbietest. Es kann ja sein, dass Du das ausschließt oder nur zum vollen Monat ermöglichst. Insbesondere, wenn Du einen Wechsel während des Monats ermöglichst, musst Du natürlich dazusagen, wie das berechnet wird.
 
So, ich habe jetzt mir nochmal Gedanken gemacht, wie das für Tag, Woche, Monat, Jahr aussehen müsste.
Stimmt das so? Oder habe ich irgendwo einen Denkfehler?

Tag:
- Bestellung: 05.05.2019 16:00 Uhr
- Upgrade: 05.05.2019 19:00 Uhr
-> Differenz zwischen 16:00 - 19:00 Uhr ausrechnen: 16-19 = 3h
3h = 10800000ms
24h = 86400000ms

10800000ms / 86400000ms = 0,125

Der ungenutzte Teil:
1- 0,125 = 0,875

Woche
- Bestellung: 05.05.2019 16:00 Uhr
- Upgrade: 07.05.2019 19:00 Uhr

-> Anteil an Millisekunden ausrechnen
-> Differenz ausrechen
51 Stunden = 183600000ms
7 Tage = 604800000ms

183600000ms / 604800000ms = 0,3035714285714286

Ungenutzter Teil:
1 - 0,3035714285714286 = 0,6964285714285714

Monat
- Bestellung: 05.05.2019 16:00 Uhr
- Upgrade: 07.06.2019 19:00 Uhr
-> Datum Abrechnung im nächsten Monat ausrechnen: 05.06.2019 + 1 Monat (addMonth) -> 05.07.2019 16:00 Uhr
-> Differenz an Millisekunden ausrechnen vom 05.06.2019 16:00 Uhr - 05.07.2019 16:00 Uhr = 2602800000 ms
-> Differenz an Millisekunden vom 05.06.2019 16:00 Uhr - 07.06.2019 19:00 Uhr = 183600000 ms
183600000ms / 2602800000ms = 0,0705394190871369

Ungenutzter Teil:
1 - 0,0705394190871369 = 0,9294605809128631


Jahr
-> Anteilig pro Monat
- Bestellung: 05.05.2019 16:00 Uhr
- Upgrade: 07.06.2019 19:00 Uhr

-> Differenz der Monate ausrechnen vom 05.05.2019 16:00 Uhr - 07.06.2019 19:00 Uhr = 1 Monat
-> Datum Abrechnung im nächsten Monat ausrechnen: 05.06.2019 + 1 Monat (addMonth) -> 05.07.2019 16:00
-> Differenz vom 07.06.2019 19:00 - 05.07.2019 16:00 = 2602800000 ms
-> Differenz an Millisekunden vom 05.06.2019 16:00 Uhr - 07.06.2019 19:00 Uhr = 183600000 ms

1 Monat + (183600000ms / 2602800000 ms) = 1 + 0,0705394190871369
= 1,070539419087137

1,070539419087137 / 12 Monate = 0,0892116182572614

Ungenutzter Teil:
1 - 0,0892116182572614 = 0,9107883817427386

Danke für die Hilfe
 
Wenn ich dich bisher richtig verstanden habe, gibt es nur monatliche oder jährliche Abrechnung?

Worin unterscheiden sich dann Tag, Woche und Monat?

Und worin sollen sich monatliche und jährliche Abrechnung unterscheiden?


Warum nicht einfach verbrauchte Stunden und Gesamtstunden auf den Abrechungszeitraum beziehe, die ganze rumrechnerei ist dann doch gar nicht nötig.
 
Tag und Woche ist nicht zwingend notwendig, aber wenn man schon dabei ist, dann kann man das doch auch gleich mit implementieren....

Die von mir oben aufgestellte Rechnung war nur ein Beispiel und ich bin mir auch nicht 100% sicher, ob das passt.
Prinzipiell ist das so:

Tarif:
- Kosten 15 EUR / Monat
- Kosten 120 EUR / Jahr

Der User kann dann eben wählen, ob das Gebührenintervall monatlich oder järhlich ist.
Stimmen die oben von mir aufgezeigte Berechnungen? Oder habe ich was nicht bedacht?
 
Prinzipiell ist das so:

Tarif:
- Kosten 15 EUR / Monat
- Kosten 120 EUR / Jahr

Der User kann dann eben wählen, ob das Gebührenintervall monatlich oder järhlich ist.
Ja, und Du musst dem User sagen: wenn Du jährlich wählst und während eines Jahres wechselst, dann wird Dir folgendes in Rechnung gestellt: ...

Das "..." ist, was noch fehlt, um sagen zu können: ja, das passt oder nein, das ist falsch.

EDIT: natürlich analog für "wenn Du während eines Monats wechselst...."
 
Deine Berechnungen sind auf jeden Fall komplexer, als einfach nur Stunden pro Abrechnungszeitraum zu betrachten.

Abrechnung pro Jahr:
- Bestellung: 05.05.2019 16:00 Uhr
- Upgrade: 07.06.2019 19:00 Uhr

Dazwischen liegen 795h, Abrechnungszeitraum (= 1 Jahr) hat 8784h. Genutzt sind also einfach 795/8784 des Jahres.

Abrechnung pro Monat:
- Bestellung: 05.05.2019 16:00 Uhr
- Upgrade: 07.06.2019 19:00 Uhr
- aktueller Abrechnungszeitraum ist 05.06.2019 - 05.07.2019,

Zwischen Start und Upgrade liegen 51h, Abrechnungszeitraum (= 1 Monat) hat 720h. Genutzt sind also einfach 51/720 des Monats.
 
Stimmen die oben von mir aufgezeigte Berechnungen? Oder habe ich was nicht bedacht?
Wollt ihr euren Kunden eigentlich wirklich ein Berechnungsmodell zumuten, bei dem ihr selbst nicht beantworten könnt, ob es korrekt ist? Wie sollen die denn ihre Rechnungskontrolle machen? Die winken das entweder einfach so durch oder müssen sich genau dieselben Gedanken machen. In beiden Fällen werden sie wohl denken: "Was sind das denn für Spinner?". Oder sie rufen an, um die Sachlage zu klären. Und da verweist ihr dann auf das Java-Forum?;)

Für mich wäre es das Normale, nur vollständige Tage abzurechnen und den Umstellungstag zugunsten des Kunden zu berechnen. Es sei denn, ihr habt tatsächlich einen so speziellen Fall, wo es wirklich auf die Stunden ankommt. Dann würde ich aber auch gleich Stundenpreise ansetzen und fakturieren.
 
Oder sie rufen an, um die Sachlage zu klären. Und da verweist ihr dann auf das Java-Forum?;)
LOL

nur vollständige Tage abzurechnen
Auch hier wäre das Problem: wie wird ein vollständiger Tag bei einem Monatspreis berechnet? Gilt ein bestimmter Tagessatz oder 1/30 des Monatspreises oder 1/d des Monatspreises wobei d die Zahl der Tage des Monats ist?

So lange wir nicht wissen, was @beta20 seinen Kunden berechnen will, ist hier alles nur Spekulation.
 
Die Kündigungsfrist sollte schon konfigurierbar sein... Bei jährlichen Tarifen sollte sie anders sein, als bei monatlichen....
"billwerk.com" löst das so:

2019-08-14 16_47_48-billwerk.png
 
Und was wird dann abgerechnet? :)
Telekom rechnet soweit ich sehe nach Tagen und mit 30 Tage pro Monat.

(Nach Beispiel oben:
- Bestellung: 01.07.2019 16:00 Uhr
- Upgrade: 07.07.2019 19:00 Uhr

Berechnet wird 1.7-7.7 zu 7/30 des damaligen Tarifs und 8.7-31.7 zu 23/30 des neuen Tarifs.

Wenn man klugerweise am ersten um 00:01 upgraded, bekommt man einen Tag geschenkt o_O )
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben