Money & RoundingMode
Vrill7 opened this issue · 8 comments
W pl.com.bottega.ecommerce.sharedkernel.Money
kwoty są zaokrąglane metodą RoundingMode.HALF_EVEN
czy przypadkiem nie powinna być to metoda RoundingMode.HALF_UP przynajmniej dla
klientów płacących podatki w Polsce?
Chyba tylko w wypadku podatków, w przypadku FV czy zamówień już nie bardzo.
Na fakturach VAT przecież liczymy właśnie podatek ;)
Przyznam się że mam mały mętlik w głowie ... bo
w zakresie zaokrąglania do 2 miejsc po przecinku obie metody dają te same wyniki (zgodne z rozporządzeniem ministra finansów). Więc w sumie w przypadku groszy o których myślałem nie będzie różnic.
Odnośnie zaokrąglania to bazując na tym: http://docs.oracle.com/javase/7/docs/api/java/math/RoundingMode.html UP - podatki należne (PIT, odsetki kapitałowe) zaokrąglane do pełnych złotych, FV do 2 miejsc po przecinku (faktycznie HALF_UP - IMHO), ale to jest trochę grubszy temat, bo i tak zostaje jeszcze kwestia sumowania w stopce (czy sumujemy podatek z pozycji czy liczymy go na postawie sumy netto). Oczywiście zostaje kwestia zgodności z drukarką fiskalną i z księgowością. W .NET kiedyś domyślne było HALF_EVEN i jak się nad tym zastanowić jest to najbardziej pragmatyczne podejście (raz pół grosza stracisz, raz odzyskasz - statystycznie).
To co jest piękne w DDD - właściwie w już nawet w samych VO dzięki
enkapsulacji - to to, że z czasem możemy pogłębiać rozumienie domeny czy
korygować błędy w tym rozumieniu i jest jedno miejsce na zmianę tych reguł:)
2014-07-18 21:18 GMT+02:00 PiotrB notifications@github.com:
Odnośnie zaokrąglania to bazując na tym:
http://docs.oracle.com/javase/7/docs/api/java/math/RoundingMode.html UP -
podatki należne (PIT, odsetki kapitałowe) zaokrąglane do pełnych
złotych, FV do 2 miejsc po przecinku (faktycznie HALF_UP - IMHO), ale to
jest trochę grubszy temat, bo i tak zostaje jeszcze kwestia sumowania w
stopce (czy sumujemy podatek z pozycji czy liczymy go na postawie sumy
netto). Oczywiście zostaje kwestia zgodności z drukarką fiskalną i z
księgowością. W .NET kiedyś domyślne było HALF_EVEN i jak się nad tym
zastanowić jest to najbardziej pragmatyczne podejście (raz pół grosza
stracisz, raz odzyskasz - statystycznie).—
Reply to this email directly or view it on GitHub
#2 (comment)
.
Tu raczej mieliśmy do czynienia z dokładaniem nowych reguł (zasady zaokrąglania podatku (PIT) do niedawna były takie same. To chyba dobry case na demo właściwości DDD.
czyli przydalby nie osobny VO modelujacy ten problem...
2014-07-18 21:29 GMT+02:00 PiotrB notifications@github.com:
Tu raczej mieliśmy do czynienia z dokładaniem nowych reguł (zasady
zaokrąglania podatku (PIT) do niedawna były takie same. To chyba dobry case
na demo właściwości DDD.—
Reply to this email directly or view it on GitHub
#2 (comment)
.
Jak dla mnie tak, ale spotkałem się też z podejściem, że tworzy się strategie i umożliwia jej wybór w konfiguracji (jak dla mnie armata na muchę, niezgodne z YAGNI).
pojawi sie problem: gdzie i kiedy jest wiedza o wyborze strategii
a vat wie, ze jest vatem wiec powinien wiedziec jak sie zachowac
ew ten VO ma w sobie strategiczny Money, i vat wie jaka strategie obrac w
money w tym kontekscie
2014-07-18 21:36 GMT+02:00 PiotrB notifications@github.com:
Jak dla mnie tak, ale spotkałem się też z podejściem, że tworzy się
strategie i umożliwia jej wybór w konfiguracji (jak dla mnie armata na
muchę, niezgodne z YAGNI).—
Reply to this email directly or view it on GitHub
#2 (comment)
.