obliczenia w access
adam@@
w tym że przy obliczaniu wartości brutto, podatku dla każdej pozycji i w
podsumowaniu podawane są złe wyniki. Ilość groszy po przecinku się nie
zgadza... Obliczenia są zrobione w kwerendach.. W formularzu przy klikniecie
na pole wyświetlane jest więcej niż dwie liczby po przecinku. Jak to zmienić
bo nie bardzo to Qmam.
--
________________________________
GG : 760779 ad...@interia.pl
________________________________
MKotynia
> Mam zrobiona baze danych a access 2000 do pisana faktur
> vat..Klopot jest
>w tym ze przy obliczaniu wartości brutto, podatku dla kazdej pozycji
>i w podsumowaniu podawane są zle wyniki. Ilośc groszy po przecinku
>sie nie zgadza... Obliczenia są zrobione w kwerendach.. W formularzu
>przy klikniecie na pole wyświetlane jest wiecej niz dwie liczby po
>przecinku. Jak to zmienic bo nie bardzo to Qmam.
4 miejsca po przecinku to BADZO zly pomysl w jakimkolwiek programie
obslugujacym fakturowanie lub gm
osobiscie pracuje na sql serverze i uzywam typu decimal do zapisania
liczb zerknolem sobie na formaty tabel w mdb i tam tez mozna wybrac decimal
czyli
DATA TYPE = NUMBER
FIELD SIZE = DECIMAL
SCALE = 2
DECIMAL PLACES = 2
i jeszcze jedno nalezy zaokraglac przed mnozeniem
np teoria obliczania brutto
wariant 1
@ilosc*@cenap*@vatliczba/100+@ilosc*@cenap = ZLE
wariant2
set @temp = @ilosc*@cenap
@temp*@vatliczba/100+@temp =DOBRZE
to tylko przyklad teorii obliczenia wydaje mi sie ze w tabelach accesowych
jest tak samo jak na sql serv , jesli nei niech mnei ktos poprawi
--
Pozdrowienia,
Marcin Kotynia
kot...@wp.pl
gg 2742480
MKotynia
> Mam zrobiona baze danych a access 2000 do pisana faktur
> vat..Klopot jest
>w tym ze przy obliczaniu wartości brutto, podatku dla kazdej pozycji
>i w podsumowaniu podawane są zle wyniki. Ilośc groszy po przecinku
>sie nie zgadza... Obliczenia są zrobione w kwerendach.. W formularzu
>przy klikniecie na pole wyświetlane jest wiecej niz dwie liczby po
>przecinku. Jak to zmienic bo nie bardzo to Qmam.
>
>--
>________________________________
>GG : 760779 ad...@interia.pl
>________________________________
sie rozpisalem a tu nic :) nie wiem czy moj posta poszedl na priva czy nie
czy zginol gdzies w otchlani internetu
jesli nic nie dostales to typ currency to zly pomysl
w fakturowaniu i gm
osobiscie pracuje na sql serwerze i korzystam z decimal(18,2) zerknolem
do accessa i tez mozna tak samo
czyli
DATA TYPE =NUMBER
FIELD SIZE =DECIMAL
DECIMAL PLACES =2
SCALE = 2
i jeszcze jedna uwaga (przyklad obliczania)
----------------------------------------------------
brutto = @ilosc*@cena*@vatliczba/100+@ilosc*@cena =ZLE
-----------------------------------------------------
@temp = @ilosc*@cena
brutto = @temp*@vatliczba/100+@temp =DOBRZE
chodzi o metode obliczania i zaokraglanie przed dodatkowym mnozeniem
to tyle oczywiscie sposobow jest wiele
MKotynia
>jesli nic nie dostales to typ currency to zly pomysl
>w fakturowaniu i gm
oczywiscie ze wzgeldu na zapisywanie 4 miejsc po przecinku
krz...@poczta.onet.pl
>
> > Mam zrobiona baze danych a access 2000 do pisana faktur
> > vat..Klopot jest
> >w tym ze przy obliczaniu wartości brutto, podatku dla kazdej pozycji
> 4 miejsca po przecinku to BADZO zly pomysl w jakimkolwiek programie
> obslugujacym fakturowanie lub gm
Bzdury Kolego, bzdury!!!
Przyjrzyj się choćby fakturze za energię elektryczną, gdzie cena
jednostki (1 kWh) podana jest z dokładnością włąśnie do _czterech_ miejsc
po przecinku.
A zatem w niektórych przypadkach (gdy cena jednostkowa jest tak mała,
iż trzeba ją określić z większą precyzją), konieczne jest użycie czterech
miejsc po przecinku. Tak samo jest w przypadku np. kursów walut.
I właśne po to jest typ wlatutowy!
Natomiast błędy wynikają z błędnego przeprowadzenia obliczeń i zaokrągleń.
To nie ma nic wspólnego z typem danych.
--
Krzysztof Czuryło
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
MKotynia
On 14 mar 2003, you wrote in pl.comp.bazy-danych.msaccess:
>Bzdury Kolego, bzdury!!!
>
>Przyjrzyj sie chocby fakturze za energie elektryczną, gdzie cena
>jednostki (1 kWh) podana jest z dokladnością wląśnie do _czterech_
>miejsc po przecinku.
>A zatem w niektorych przypadkach (gdy cena jednostkowa jest tak
>mala, iz trzeba ją określic z wiekszą precyzją), konieczne jest
>uzycie czterech miejsc po przecinku. Tak samo jest w przypadku np.
>kursow walut.
>
>I wlaśne po to jest typ wlatutowy!
>
>Natomiast bledy wynikają z blednego przeprowadzenia obliczen i
>zaokrąglen. To nie ma nic wspolnego z typem danych.
>
>--
>Krzysztof Czurylo
Przykro mi Krzysztofie ale to ty gadasz bzdury
1.widziales jakis program finansowo ksiegowy ktory umozliwia
generowanie liczb lub wpisywanie z 4 miejscami po przecinku?????????
2.biegly zakwestionowal sprawe 4 miejsc po przecinku w mojej firmie w polsce
obowiazuja grosze nie ma czesci grosza jak wyobrazasz sobie ze
klient zaplaci fakture na kwote 122,3232 ? czy masz taki nominal ktory to umozliwia?
(potem dlaczego)
3. jak wyobrazasz sobie dekretowanie faktur i dokumentow magazynowych
do systemu ksiegowego ? ktory ma 2 miejsca po przecinku ?
prosty przyklad
zapis danych w tabeli
cena ilosc wartosc
12,1958 * 12 = 146,3496
dobrze zapisalismy taka kwote do zbiorow
czyli
cena = 12,1958 wyglad takiej kwoty w podgladzie (12,20)
ilosc = 12 (12)
wartosc = 146,3496 (146,35)
__________________________________
i teraz transmitujemy do fk lub wysylamy fakture vat kontrahentowi
na ktorej on widzi
cena ilosc wartosc
12,20 12 146,35 = bzdura
po czym dostajemy taka fakture spowrotem
bo
12,20 12 = 146,40
a nie 146,35!!!!!!!!!!!!!!!
______________________________________________________
W firmie ktorej pracuje dziennie jest przyjmowanych
okolo 150 faktur zakupu na zadnej fakturze nigdy!!!!
nie wystepuja 4 miejsca po przecinku
sprawdzilem takze twoj rachunek za prad !
nigdzie tam nei znalazlem w kwotach! 4 miejsc po przecinku znajduja sie one
w jednostkach ilosci tylko?
a teraz cie pociesze bo :P w kasach fiskalnych (niektorych typach)
faktycznie istnieja 4 miejsca po przecinku a teraz bedize smiesznie jesli ktos
ma taka kase i potem wprowadzi system do fakturowania i bedzie chcial przeniesc dane
oczywiscie faktury nei bede sie zgadzaly jednak wtedy przyjmuje sie
fiskalizacje za wlasciwa
jesli chodzi o kurs waluty
(spytalem rownierz o to bieglego ksiegowego ktory wlasnei znajdusje sie w firmie
ktoreej pracuje)
"kurs waluty traktowany jest bardziej jako jednostak ilosciowa" i w rozliczeniach
i tak koncowa kwote sie zaokragla ? do 2 miejsc po przecinku w polsce obowiazuje
system monetarny opierajacy sie na 2 miejscach po przecinku w specyficznych przypadkach
uzywane jest 4 miejsca
a jesli chodzi o zwykla gm i fakturowanie to nadal uwazam ze 4 miesjsca to zly pomysl
chyba ze ktos pisze program na zaliczenie do szkoly to i tak nie ma to znaczenia
byc moze w twoje fakturze za prad istnieja 4 miejsca ale potraktowalbym
to jako ewemenent i odstepstwo od reguly (bardzo rzadkich)
Krzysztof Naworyta
> >Bzdury Kolego, bzdury!!!
(...)
> >Natomiast bledy wynikają z blednego przeprowadzenia obliczen i
> >zaokrąglen. To nie ma nic wspolnego z typem danych.
(...)
> Przykro mi Krzysztofie ale to ty gadasz bzdury
Przypuszczam że Krzysiek Czuryło też odpowie, ale pozwolę sobie sie wtrącić ...
> 1.widziales jakis program finansowo ksiegowy ktory umozliwia
> generowanie liczb lub wpisywanie z 4 miejscami po przecinku?????????
> 2.biegly zakwestionowal sprawe 4 miejsc po przecinku w mojej firmie w polsce
> obowiazuja grosze nie ma czesci grosza jak wyobrazasz sobie ze
> klient zaplaci fakture na kwote 122,3232 ? czy masz taki nominal ktory to umozliwia?
> (potem dlaczego)
>
> 3. jak wyobrazasz sobie dekretowanie faktur i dokumentow magazynowych
> do systemu ksiegowego ? ktory ma 2 miejsca po przecinku ?
(...)
> "kurs waluty traktowany jest bardziej jako jednostak ilosciowa" i w rozliczeniach
> i tak koncowa kwote sie zaokragla ? do 2 miejsc po przecinku w polsce obowiazuje
> system monetarny opierajacy sie na 2 miejscach po przecinku w specyficznych przypadkach
> uzywane jest 4 miejsca
>
> a jesli chodzi o zwykla gm i fakturowanie to nadal uwazam ze 4 miesjsca to zly pomysl
> chyba ze ktos pisze program na zaliczenie do szkoly to i tak nie ma to znaczenia
>
> byc moze w twoje fakturze za prad istnieja 4 miejsca ale potraktowalbym
> to jako ewemenent i odstepstwo od reguly (bardzo rzadkich)
Nadal mieszasz pojęcia:
Owszem, nasz system prawny wyklucza pojęcie ułamka grosza, a jednak są wyjątki !
- kursy walut
- cena prądu (na mojej fakturze również !)
- i inne pewnie też
I nie ma większego znaczenia czy przyjmiemy interpretację, że są to współczynniki.
Po prostu na wielu etapach pośrednich w trakcie obliczania ceny końcowej, otrzymujemy ułamki groszy
i nie zawsze na każdym z nich należy cenę zaokrąglać do pełnego grosza.
Twój przykład z fakturą jest przypadkiem szczególnym, gdzie nieprawidłowo przeprowadzone
zaokrąglenia (czy ich pominięcie) skutkuje niezgodnością między cenami poszczególnych pozycji a
całościowym podsumowaniem.
Ale codziennie na walutach dokonuje sie dużo subtelniejszych operacji.
Nie znam się na tym ale wymienię: kapitalizacja odsetek, rozliczenia międzybankowe, kosztorysowanie
w końcu.
Typ "walutowy" jest po prostu typem stałoprzecinkowym (!!!)
(z zapasem dwóch pozycji, aby nie dokonywać zaokrągleń tam gdzie nie jest to wskazane !)
Jego "stałoprzecinkowość" zabezpiecza przed powstawaniem gorszych błędów zaokrągleń z jakimi mamy do
czynienia używając typów "zmiennoprzecinkowych". A cztery miejsca po przecinku to już tradycja w
praktyce finansowej, stąd też nazwa "walutowy"
(format z dodatkowym "zł" jest tu rzeczą drugo- albo wręcz trzeciorzędną)
Ty używając typu decimal z dokładnością=2 skazujesz się jedynie na wąski obszar zastosowań, jak
fakturowanie właśnie.
Równie dobrze to samo mógłbyś robić na polu "walutowym" czy decimal skala=10, jedynie pamiętając aby
w odpowiednim momencie dokonać właściwego zaokrąglenia.
Poszedłeś na skróty, proszę bardzo. Ale nie uogólniaj !
--
KN
MKotynia
On 14 mar 2003, you wrote in pl.comp.bazy-danych.msaccess:
>I nie ma wiekszego znaczenia czy przyjmiemy interpretacje, ze są to
>wspolczynniki. Po prostu na wielu etapach pośrednich w trakcie
>obliczania ceny koncowej, otrzymujemy ulamki groszy i nie zawsze na
>kazdym z nich nalezy cene zaokrąglac do pelnego grosza.
>
>Twoj przyklad z fakturą jest przypadkiem szczegolnym, gdzie
>nieprawidlowo przeprowadzone zaokrąglenia (czy ich pominiecie)
>skutkuje niezgodnością miedzy cenami poszczegolnych pozycji a
>calościowym podsumowaniem.
ja przypomniam ze watek mowi o fakturowaniu i ja sam powiedzialem ze moj post dotyczy
fakturowanie i gm(gospodarki magazynowej)
>uzywając typow "zmiennoprzecinkowych". A cztery miejsca po przecinku
>to juz tradycja w praktyce finansowej, stąd tez nazwa "walutowy"
jaki program finansaowy ma 4 miejsca:) nie widzialem takiego
>Ty uzywając typu decimal z dokladnością=2 skazujesz sie jedynie na
>wąski obszar zastosowan, jak fakturowanie wlaśnie.
a o fakturowaniu mowa wlasnie nie interesuje mnie rozliczenia
miedzybankowe a fakturowannie o ktore ktos pytal
pozatym przytoczylem bardzo obrazowy przyklad co sie stanie w przypadku
nieumiejetnego korzystania z 4 miejsc po przecinku (moje skromne obliczenia)
> Poszedleś na skroty, prosze bardzo. Ale nie
>uogolniaj !
Nie uogolniam wskazalem ze istnieja przyklady(kasy fiskalne gdzie sa 4 miejsca podobno)
A ja wracam caly czas do tego ze rozmawiamy o fakturowaniu
>--
>KN
tralala ejstem zirytowany to jakas zmowa
wiec zakonczmy ten watek tym ze niech kazdy robi se jak chce..........
Krzysztof Naworyta
(...)
> a o fakturowaniu mowa wlasnie nie interesuje mnie rozliczenia
> miedzybankowe a fakturowannie o ktore ktos pytal
> pozatym przytoczylem bardzo obrazowy przyklad co sie stanie w przypadku
> nieumiejetnego korzystania z 4 miejsc po przecinku (moje skromne obliczenia)
>
> > Poszedleś na skroty, prosze bardzo. Ale nie
> >uogolniaj !
> Nie uogolniam wskazalem ze istnieja przyklady(kasy fiskalne gdzie sa 4 miejsca podobno)
>
> A ja wracam caly czas do tego ze rozmawiamy o fakturowaniu
>
> tralala ejstem zirytowany to jakas zmowa
>
> wiec zakonczmy ten watek tym ze niech kazdy robi se jak chce..........
Dodam jeszcze tylko tyle, że w A'97 nie istnieje typ pola Decimal a mimo to jakoś udawało się w nim
robić poprawne programiki finansowe ;-)
(faktury również ;-))))
Powtarzam: istotne jest to, że typ "walutowy" jest typem "stałoprzecinkowym"
Cztery miejsca po przecinku są konieczne dla większości operacji pośrednich, jak choćby przeliczenie
wartości z jednej waluty na drugą. Zaokrąglenia dokonać możesz dopiero na końcu! (cokolwiek przez
ten "koniec" rozumiejąc)
No i kolejna sprawa: sposoby zaokrągleń !
Ty, używając pola decimal ze skala=2 skazujesz się na zaokrąglenia coprocesora, przynajmniej jeśli
mówimy o Accessie
(vide http://www.krzycz.com/)
Ja, używając skali większej mogę dokonać zaokrągleń wg własnego widzimisie
(matematycznych, finansowych amerykańskich itd.)
Zależy to jedynie od funkcji jakiej do tych celów użyję.
Na koniec zwrócę uwagę, może dla Ciebie mało istotną, ale inni Accessowcy niech czytają:
Access też popełnia błędy zaokrągleń podczas sumowania w kwerendach agregujących.
Ale to akurat z ilością miejsc po przecinku chyba nie ma związku.
12/25/2002 Q167602 BUG: Precision and Scale Change with SUM or AVG Functions
(choć jakby go ostatnio zdjęli ?)
--
KN
MKotynia
>Uzytkownik "MKotynia" <kot...@wp.pl> napisal
>> A ja wracam caly czas do tego ze rozmawiamy o fakturowaniu
>>
>> tralala ejstem zirytowany to jakas zmowa
>Dodam jeszcze tylko tyle, ze w A'97 nie istnieje typ pola Decimal a
>mimo to jakoś udawalo sie w nim robic poprawne programiki finansowe
>;-) (faktury rowniez ;-))))
......
>KN
jeszcze cos napiszesz a cie pogryze :)
Leon
Użytkownik "adam@@" <ad...@interia.pl> napisał w wiadomości
news:b4s6o1$m86$1...@nemesis.news.tpi.pl...
> Mam zrobiona bazę danych a access 2000 do pisana faktur vat..Kłopot
jest
> w tym że przy obliczaniu wartości brutto, podatku dla każdej pozycji i w
> podsumowaniu podawane są złe wyniki. Ilość groszy po przecinku się nie
> zgadza... Obliczenia są zrobione w kwerendach.. W formularzu przy
klikniecie
> na pole wyświetlane jest więcej niż dwie liczby po przecinku. Jak to
zmienić
> bo nie bardzo to Qmam.
>
dokładnie przedmówcy - należy wiedzieć, jak zrealizować podsumowanie
faktury.
Do obliczenia wartości brutto na fakturze dla podatnika VAT nie sumuje się
wartości cząstkowych brutto z rekordów lecz oblicza się:
a/ sumę netto dla każdej stawki podatkowej
b/ VAT dla każdej stawki podatkowej i zaokrągla do 1 grosza
c/ dodaje sie VAT do netto i otrzymuje brutto.
Przeważnie ta suma nie jest zgodna z sumą wartości brutto z poszczególnych
pozycji.
Natomiast przy sprzedaży dla osób fizycznych sumuje się brutto z rekordów,
od tej sumy oblicza VAT (dzieląc przez 1+stawka/100) a potem netto z różnicy
tych sum.
Często dokument wystawiony dla osoby fizycznej ma inna wartość końcową, niż
dla podmiotu gospodarczego, przy tych samych cenach!
Księgowy-amator
Grzesiek B.
> [posted and mailed]
>
> jaki program finansaowy ma 4 miejsca:) nie widzialem takiego
Zobacz na notowania walut i ilość miejsc po przecinku. W firmach operujących
dużą ilością walut takie systemy FK funkcjonują. Sam nawet taki pisałem.
> Nie uogolniam wskazalem ze istnieja przyklady(kasy fiskalne gdzie sa 4
miejsca podobno)
Kas fiskalnych z ceną lub wartością do 4 miejsc po przecinku NIE MA ! Są
najwyżej 3 miejsca po przecinku dla ilości.
Pozdr,
GB
Grzesiek B.
news:b4tf9m$s5k$1...@atlantis.news.tpi.pl...
>
> Do obliczenia wartości brutto na fakturze dla podatnika VAT nie sumuje się
> wartości cząstkowych brutto z rekordów lecz oblicza się:
> a/ sumę netto dla każdej stawki podatkowej
> b/ VAT dla każdej stawki podatkowej i zaokrągla do 1 grosza
> c/ dodaje sie VAT do netto i otrzymuje brutto.
> Przeważnie ta suma nie jest zgodna z sumą wartości brutto z poszczególnych
> pozycji.
Sru tu tu tu. Sumuje się netto, podatek i brutto. Na końcu faktury jest
podsumowanie liczb z pozycji a nie jakieś dziwaczne wyliczanie kwoty do
zapłaty. Kwota ta musi wynikać z wartości brutto poszczeglnych pozycji.
Źródło: Ustawa o VAT.
> Natomiast przy sprzedaży dla osób fizycznych sumuje się brutto z rekordów,
> od tej sumy oblicza VAT (dzieląc przez 1+stawka/100) a potem netto z
różnicy
> tych sum.
To jedna z metod dopuszonych w ustawie dla podatnika posiadającego kasy
fiskalne. Oczywiscie można również poprzednią metodą. Podstawą do
rozliczenia podatku w tym wypadku nie jest faktura, tylko raporty z kasy
fiskalnej.
> Księgowy-amator
Nie chcę być złośliwy, ale rzeczywiście.
Pozdr,
GB
Leon
> podsumowanie liczb z pozycji a nie jakieś dziwaczne wyliczanie kwoty do
> zapłaty. Kwota ta musi wynikać z wartości brutto poszczeglnych pozycji.
> Źródło: Ustawa o VAT.
>
..
>
> > Księgowy-amator
> Nie chcę być złośliwy, ale rzeczywiście.
>
Nie jesteś złośliwy, jesteś tylko niedouczony.
Poczytaj ową ustawę o VAT, zanim się na nią powołasz.
Tylko ze zrozumieniem.
Grzesiek B.
> > Sru tu tu tu. Sumuje się netto, podatek i brutto. Na końcu faktury jest
> > podsumowanie liczb z pozycji a nie jakieś dziwaczne wyliczanie kwoty do
> > zapłaty. Kwota ta musi wynikać z wartości brutto poszczeglnych pozycji.
> > Źródło: Ustawa o VAT.
> > Nie chcę być złośliwy, ale rzeczywiście.
> >
> Nie jesteś złośliwy, jesteś tylko niedouczony.
> Poczytaj ową ustawę o VAT, zanim się na nią powołasz.
> Tylko ze zrozumieniem.
Za mnie robią to księgowe i radcy prawni w kilku firmach, a mnie podają
tylko gotowe wnioski na których się opieram. Zwykle nie kwestionuję zdania
osób, które mają wieloletnie doświadczenie w księgowości i analizie
przepisów.
Zresztą rób jak uważasz, masz do tego prawo i czekaj na kontrolę skarbowego
w poczuciu przeczytanej i dobrze zrozumianej ustawy.
Pozdr,
GB
Grzesiek B.
> wartości cząstkowych brutto z rekordów lecz oblicza się:
> a/ sumę netto dla każdej stawki podatkowej
> b/ VAT dla każdej stawki podatkowej i zaokrągla do 1 grosza
> c/ dodaje sie VAT do netto i otrzymuje brutto.
> Przeważnie ta suma nie jest zgodna z sumą wartości brutto z poszczególnych
> pozycji.
Towar kosztuje 15 zł. brutto - widać na półce.
1szt. 12,30netto 2,71 VAT22 15,01 brutto
.... 10 takich pozycji
Suma 123,00 netto 27,06 VAT 150,06brutto w/g Twojej metody liczone !
Ile w/g Twojego rozumienia ustawy ma zapłacić Klient ?
Którą kwotę wziąć do rozliczenia podatku dochodowego i VAT ?
> Natomiast przy sprzedaży dla osób fizycznych sumuje się brutto z rekordów,
> od tej sumy oblicza VAT (dzieląc przez 1+stawka/100) a potem netto z
różnicy
> tych sum.
10 szt. x 15 zł. = 150 zł.
150/(1+22/100)=122,95 to jest w/g Ciebie VAT
150-122,95=27,05 netto, też w/g Ciebie
> Poczytaj ową ustawę o VAT, zanim się na nią powołasz.
> Tylko ze zrozumieniem.
No ja może nie zrozumiałem, ale Ty zrozumiałeś doskonale !
Pozdr,
GB
adam@@
typ danych dla pola we właściwościach tabeli : Walutowy
Format Standardowy , miejsca dziesiętne 2
wyswietlane są dwa miejsca po przecinku ale jak kliknąć na pole w tabeli lub
formularzu widać trzy lub cztery liczby po przecinku.
Gdy sumy są okrągłe ,00 oczywiście dobrze oblicza. ale jak są grosze
zaokrągla raz w górę raz w dół, wychodzą takie bzdury że na oko widać..
I jeszcze jedno , w panelu sterowania windows - ustawienia regionalne
zakładka waluta mam ustawione 2 miejsca po przecinku... Access z tych
ustawień chyba nie korzysta.
Krzysztof Czuryło
"MKotynia" <kot...@wp.pl> wrote in message news:Xns933E83E393D1EX...@127.0.0.1...
|
| jesli nic nie dostales to typ currency to zly pomysl
| w fakturowaniu i gm
|
| osobiscie pracuje na sql serwerze i korzystam z decimal(18,2) zerknolem
| do accessa i tez mozna tak samo
A świstak siedzi... ;-)))
Kolego Kotynia, ja myślałem, żeś Ty bardziej łebski gość, ale muszę ten pogląd
zweryfikować.
Powtarzam, duby smalone bredzisz!!!
Typ Currency/Walutowy jest tak samo dobry do fakturowania jak Twój Decimal,
a może nawet lepszy. De facto typ walutowy jest to nic innego jak typ
stałoprzecinkowy (czyli Decimal) z ustawioną "na sztywno" precyzją na cztery
miejsca dziesiętne. (No może nie do końca jest to to samo, ale można przyjąć
takie uproszczenie).
Jedno co jest słuszne w typie Decimal, to to, że jest stałoprzecinkowy.
Nie będę się tu rozwodził dlaczego, ale do obliczeń finansowych należy
w miarę możliwości korzystać tylko z typów stałoprzecinkowych. Czyli w Accessie
w grę wchodzi tylko typ Currency i Decimal (oraz Integer/Long ;-)))).
Mogę się zgodzić z faktem, że 99,99% użytkowników nie sprzedaje towarów, ani
usług z _ceną_jednostkową_ wyrażoną w ułamkach groszy, ale z całą pewnością
takie sytuacje występują (vide energetyka, a niedługo może także telekomunikacja
- tzw. rozliczenia sekundowe - ile kosztuje 1 sekunda rozmowy?)
W związku z tym, mówienie, że większa precyzja jest złym pomysłem jest
nieprawdą choćby tylko z tego powodu.
Ale to i tak jest mało ważne, bo mnie nie chodzi tu nawet o tę cenę jednostkową.
Niech nawet towar/usługa ma cenę określoną z dokładnością do pełnych groszy.
Wiadomo również, że na fakturze łączne kwoty (poszczególne pozycje, jak i sumy)
wyrażone są z dokładnością do pełnych groszy.
Czy to oznacza, że należy KONIECZNIE używać typu z precyzją ustaloną na _dwa_
miejsca dziesiętne? Czy to oznacza, że większa precyzja jest ZŁYM POMYSŁEM?
Nieprawda! Tak mówią tylko ci, którzy nigdy nie słyszeli o funkcji Round(),
kórzy nie potrafią jej używać, lub którzy mają problemy z arytmetyką.
Albowiem zaprawdę powiadam Wam, MOŻNA użyć typu Decimal z precyzją 2, ale:
a) można, lecz nie trzeba!!!
b) trzeba wiedzieć jak!!! Sposób podany przez Ciebie nie jest niestety poprawny!
Zamiast jawnie zaokrąglić kwotę, stosujesz jawną/niejawną konwersję typów
i w ten sposób realizujesz konieczne "zaokrąglanie". Specjalnie napisałem
to w cudzysłowie, gdyż nie jest to żadne zaokrąglanie (przynajmniej w Accessie).
Wpisanie jakiejś wartości do zmiennej/pola o mniejszej precyzji powoduje bowiem
UCIĘCIE odpowiedniej części ułamkowej, a nie ZAOKRĄGLENIE.
Różnicy chyba nie muszę tłumaczyć?
Przykład:
Cena jednostkowa towaru - 1,12 zł
Ilość sztuk - 20
Wartość netto - 20 * 1,12 zł = 22,40 zł
VAT (stawka 22%) - 22,40 zł * 0,22 = 4,928 zł
po zaokrągleniu = 4,93 zł !!!!!, a nie 4,92 zł !!!!!
Różnica niewielka, ale jednak jest!
Oznacza to, że nie należy bazować na niejawnych konwersjach, lecz robić
zaokrąglanie samemu, tak jak na arytmetyce uczyli.
Tu uwaga!!! Accessowa funkcja Round() źle zaokrągla (do najbliższej parzystej),
więc trzeba użyć własnej funkcji, która robi to zgodnie z zasadami matematycznymi
(i zgodnie z polską księgowością). Było o tym na grupie nie raz.
Jaki z tego wniosek? - Skoro i tak trzeba zaokrąglać samemu, to jaka jest korzyść
z używania typu Decimal o precyzji 2??? Typ walutowy jest równie dobry. Po prostu
po zaokrągleniu dwa ostatnie miejsca znaczące będą zerami.
Reasumując - do obliczeń finansowych należy używać typów stałoprzecinkowych
z precyzją _co_najmniej_ 2 lub więcej miejsc dziesiętnych.
Zaokrąglanie należy realizować samodzielnie i nie bazować na ustalonej precyzji.
Osobny temat stanowi przeprowadzanie obliczeń podczas fakturowania (obliczanie
podatku VAT oraz kwoty brutto).
Moim zdaniem, jedyna słuszna (???) metoda (tu mogę się mylić, ale takiej używam)
jest następująca:
Dla każdej pozycji (wiersza) na fakturze:
1) Obliczamy wartość_netto = cena_jednostkowa_netto * ilość (godzin, kg, itp.).
1a) Jeśli (rzadka sytuacja) cena jednostkowa wyrażona jest w ułamkach grosza,
to należy otrzymaną wartość zaokrąglić do pełnych groszy.
2) Obliczamy kwotę_podatku_VAT = wartość_netto * (stawka_VAT / 100)
2a) Otrzymaną kwotę VAT należy zaokrąglić do pełnych groszy!
3) Obliczamy wartość_brutto = wartość_netto + kwota_podatku_VAT
4) Sumujemy kwoty netto, VAT i brutto dla każdej stawki VAT oddzielnie.
5) Sumujemy wszytko razem.
Zsumowane pozycje każdego wiersza będą się zawsze zgadzać z sumą całkowitą
co do grosza!!! Także wartość brutto każdej pozycji z osobna będzie równa wartości
netto + VAT. Nie ma tu miejsca na żadne rozbieżności!!!
Jeśli komuś się nie zgadza, to znaczy, że nie umie liczyć i powinien wrócić
do podstawówki.
A jeśli ktoś wie jak zrobić to lepiej, to chętnie się dowiem.
| i jeszcze jedna uwaga (przyklad obliczania)
| ----------------------------------------------------
| brutto = @ilosc*@cena*@vatliczba/100+@ilosc*@cena =ZLE
| -----------------------------------------------------
| @temp = @ilosc*@cena
| brutto = @temp*@vatliczba/100+@temp =DOBRZE
Druga metoda jest może i dobra, ale nieczytelna. Nie lepiej zapisać to tak:
@netto = @ilosc*@cena
@vat = @netto*@vatliczba/100
@brutto = @netto+@vat
A najlepiej tak:
@netto = Round(@ilosc*@cena, 2) // Round() opcjonalne
@vat = Round(@netto*@vatliczba/100, 2) // Round() obowiązkowe!!!
@brutto = @netto+@vat
Round(x, 2) powinno zaokrąglać do dwóch miejsc dziesiętnych zgodnie
z zasadami matematycznymi.
A na koniec pytanie filozoficzne.
Skoro w takiej Ameryce (i zapewne w znakomitej większości krajów świata),
najmniejszą jednostką płatniczą jest odpowiednik naszego grosza (cent, fenig,
ore, centym, kopiejka, halerz, ...), czyli jedna setna podstawowej waluty,
to skąd w głowach programistów MS narodził się pomysł, by typ walutowy
zrobić z precyzją 4???!!!
I jeszcze cytat z helpa:
"The Currency data type is useful for calculations involving money and for fixed-
point calculations in which accuracy is particularly important."
--
+---------------------------------------------------------------+
| lek. Krzysztof Czuryło access(at)krzycz.com |
| www.krzycz.com |
+---------------------------------------------------------------+
Grzesiek B.
w wiadomości news:b58c8v$jqj$1...@atlantis.news.tpi.pl...
> A na koniec pytanie filozoficzne.
> Skoro w takiej Ameryce (i zapewne w znakomitej większości krajów świata),
> najmniejszą jednostką płatniczą jest odpowiednik naszego grosza (cent,
fenig,
> ore, centym, kopiejka, halerz, ...), czyli jedna setna podstawowej waluty,
> to skąd w głowach programistów MS narodził się pomysł, by typ walutowy
> zrobić z precyzją 4???!!!
>
Też się nad tym zastanawiałem i doszedłem do wniosku, że sprawa musiała być
konsultowana z "prof." Grzegorzem Kołodko czy innym takim.
Pozdr,
GB
MKotynia
On 19 mar 2003, you wrote in pl.comp.bazy-danych.msaccess:
>Zamiast jawnie zaokrąglic kwote, stosujesz jawną/niejawną konwersje
>typow i w ten sposob realizujesz konieczne "zaokrąglanie".
>Specjalnie napisalem to w cudzyslowie, gdyz nie jest to zadne
>zaokrąglanie (przynajmniej w Accessie). Wpisanie jakiejś wartości do
>zmiennej/pola o mniejszej precyzji powoduje bowiem UCIECIE
>odpowiedniej cześci ulamkowej, a nie ZAOKR GLENIE. Roznicy chyba nie
>musze tlumaczyc?
>
>Przyklad:
>Cena jednostkowa towaru - 1,12 zl
>Ilośc sztuk - 20
>
>Wartośc netto - 20 * 1,12 zl = 22,40 zl
>VAT (stawka 22%) - 22,40 zl * 0,22 = 4,928 zl
> po zaokrągleniu = 4,93 zl !!!!!, a nie
> 4,92 zl !!!!!
>
>Roznica niewielka, ale jednak jest!
>
A swistak siedzi
ja jestem praktykiem wiec empirycznie udowodnie ze nie masz racji !
jesli chodzi o ten przyklad
Msaccess 2000/ADP/SQL
Alter Procedure testdlaczurylo
As
declare @cena decimal(18,2)
set @cena = 1.12
declare @ilosc decimal(18,2)
set @ilosc = 20
declare @temp decimal(18,2)
set @temp = @cena * @ilosc
insert into test (ilosc,cena,razem,vat) values (@ilosc,@cena,@temp,@temp*0.22)
set nocount on
return
wynik
ilosc cena vat razem
20 1,12 4,93 22,4
>zmiennej/pola o mniejszej precyzji powoduje bowiem UCIECIE
>odpowiedniej cześci ulamkowej, a nie ZAOKR GLENIE. Roznicy chyba nie
wiec gow*o prawda ze obcina i nie mam zamiaru juz dyskutowac w tym watku
na reszte postu nei mam czasu pisac niech kazdy robi jak chce
(wyraznie napisalem "osobiscie pracuje na sql serwerze i korzystam z decimal(18,2) ")
ps.
jesli w accesie nei jest tak samo to faktycznie moj pie*ony blad
ale od tego sa inni grupowicze zeby poprawic mnie a nie atakowac
Pawel Durys
ani
> usług z _ceną_jednostkową_ wyrażoną w ułamkach groszy, ale z całą
pewnością
> takie sytuacje występują (vide energetyka, a niedługo może także
telekomunikacja
> - tzw. rozliczenia sekundowe - ile kosztuje 1 sekunda rozmowy?)
Na stacje paliwowa podjezdza BMW X5.
Kierowca pyta sie obslugi: ile kosztuje kropla paliwa?
Obsluga odpowiada: Nic!
Na to kierowca: to prosze mi nakapac do pelna!
--
Pozdrowienia
Pawel Durys
--
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Pawel Durys
> No ja może nie zrozumiałem, ale Ty zrozumiałeś doskonale !
Sorry, ze tak pozno, ale dopiero teraz sie wczytalem w ten watek.
Nie jestem ksiegowym.
Nie znam ustawy o VAT wedlug Prawa RP.
Nie jestem Developerem.
Na codzien, walcze jak lew (no moze jak maly lewek) z systemem Ksiegowo -
Produkcyjno - Magazynowym (chyab tak to sie nazywa).
Co jest zlego w rozumowaniu Leona? Wedlug mnie nic, jesli tylko pamietac sie
bedzie, tak jak to robi (chyba) moj program, o tych trzech przypadkach
opisanych przez Leona.
1. Podatek VAT uwzgledniony w cenie produktu
2. Podatek VAT nie uwzgledniony w cenie produktu
3. Podatek VAT nie naliczany
w przypadku 1. nalezny podatek VAT jest obliczany z sumy koncowej wszsytkich
pozycji (oczywiscie o takiej samej stawce podatku). Liczba mnozen / dzielen
rowna najwyzej liczbie stawek VAT.
w przypadku 2. nalezny podatek VAT oblicza sie dla kazdej pozycji osobno, a
nastepnie wszsytkie skladniki sumuje. Liczba mnozen / dzielen rowna
dokladnie liczbie pozycji.
w przypadku 3. nic sie nie oblicza, tylko wartosci posrednie.
Dlatego tez, moim zdaniem obaj macie racje, tylko w innych fragmentach.
--
Pozdrowienia
Pawel Durys
PS. A tak bezposrednio do Grzegorza: nauczylem sie nikomu nie ufac,
zwlaszcza ksiegowym. Nawet jesli wszystko mowi, ze jest zle, oni i tak
znajda (stworza) wytlumaczenie i jeszcze z tego wyjdzie, ze jest wspaniale.
Pawel
Grzesiek B.
W tym cała rzecz, że ustawodawca wymyślając sposoby liczenia VAT miał "w
poważaniu"
programistów i przyjęto czysto matematyczne zasady. Stąd wszelkie próby
dostosowania
kodu do innego działania niż czysto matematyczne są błędne.
Zgadzam się w 100% z KC - VAT powinien być liczony dokładnie tak jak to
napisał.
Pozdr,
GB
Grzesiek B.
news:b59g3k$414$1...@inews.gazeta.pl...
> PS. A tak bezposrednio do Grzegorza: nauczylem sie nikomu nie ufac,
> zwlaszcza ksiegowym. Nawet jesli wszystko mowi, ze jest zle, oni i tak
> znajda (stworza) wytlumaczenie i jeszcze z tego wyjdzie, ze jest
wspaniale.
> Pawel
Jeśli firma mi płaci za robotę i księgowy (wyznaczony do konsultacji) daje
mi na papierze to co chce żebym zrobił, to moje do niego zaufanie nie ma
żadnego znaczenia. Podstawową zasadą jest posiadanie wszystkiego na papierze
i temu ufam bezgranicznie, pozostałe sprawy, zwłaszcza przekazywane "na
gębę" - puszczam mimo uszu.
Pozdr,
GB
Pawel Durys
> mi na papierze to co chce żebym zrobił, to moje do niego zaufanie nie ma
> żadnego znaczenia. Podstawową zasadą jest posiadanie wszystkiego na
papierze
> i temu ufam bezgranicznie, pozostałe sprawy, zwłaszcza przekazywane "na
> gębę" - puszczam mimo uszu.
Oczywiscie to podstawa.
Instynkt samozachowawczy ;-)
Ale w ten sposob postepujac, zakladasz (mozliwe ze nieprawidlowo), ze Twoja
aplikacja dziala niezgodnie z przepisami. Byc moze Twoj zleceniodawca
potrzebuje takiej aplikacji jaka Ci na papierze opisal (wiesz taki kreatywny
ksiegowy, to potrafi duzo napisac).
A tylko o tym pisal Leon, ze sa rozne sposoby obliczania VAT.
Jeszcze raz, uwazam, ze obaj macie racje tylko w innych obszarach.
Przychylam sie do Twojej propozycji z innej galezi tego watku aby wywolac
EOT().
--
Pozdrowienia
Pawel Durys
Grzesiek B.
> Oczywiscie to podstawa.
> Instynkt samozachowawczy ;-)
>
> Ale w ten sposob postepujac, zakladasz (mozliwe ze nieprawidlowo), ze
Twoja
> aplikacja dziala niezgodnie z przepisami. Byc moze Twoj zleceniodawca
> potrzebuje takiej aplikacji jaka Ci na papierze opisal (wiesz taki
kreatywny
> ksiegowy, to potrafi duzo napisac).
zgodność
z przepisami bierze na siebie zleceniodawca, chyba, że robię to dla siebie,
wtedy
dbam o taką zgodność. Dla swojej firmy bazy piszę w FoxPRO, które
ma problem liczb i zaokrągleń rozwiązany wzorowo stąd problemy z typem
Currency i Decimal nie występują. Ponieważ na codzień pracuję dla około
50 firm, mam pełen przekrój poglądów księgowych w kwestiach przepisów
i właściwie dla siebie robię tak, jak sądzi 2-3 zaufanych księgowych. Każda
z większych firm jest kontrolowana przez US kilka razy w roku i wpadki
w rozpatrywanym w tym wątku zakresie się nie zdarzyły.
> A tylko o tym pisal Leon, ze sa rozne sposoby obliczania VAT.
> Jeszcze raz, uwazam, ze obaj macie racje tylko w innych obszarach.
Zgadziam się, że liczenie VAT od netto i od brutto to oddzielne kwestie.
> Przychylam sie do Twojej propozycji z innej galezi tego watku aby wywolac
> EOT().
Może to będzie EOT, zobaczymy. Tym nie mniej miło mi było "pokonwersować".
Pozdr,
GB
Pawel Durys
> W tym cała rzecz, że ustawodawca wymyślając sposoby liczenia VAT miał "w
> poważaniu"
> programistów
A czemu niby mialby sie nimi przejmowac?
> i przyjęto czysto matematyczne zasady. Stąd wszelkie próby
> dostosowania
> kodu do innego działania niż czysto matematyczne są błędne.
> Zgadzam się w 100% z KC - VAT powinien być liczony dokładnie tak jak to
> napisał.
Moje trzy grosze i 33 setne (0.0333 PLN)
VAT powinien byc liczony tak jak to okreslil ustawodawca. Koniec kropka.
========================================================================
ROZPORZĄDZENIE MINISTRA FINANSÓW z dnia 22 marca 2002 r.
w sprawie wykonania niektórych przepisów ustawy o podatku od towarów i usług
oraz o podatku akcyzowym
(tekst ujednolicony, opracowany na podstawie: Dz. U. Nr 27, poz. 268, Nr 46,
poz. 438, Nr 155, poz. 1290, i Nr 216, poz. 1828)
Rozdział 10...
========================================================================
zrodlo: http://www.mf.gov.pl/_files_/podatki/vat_i_akcyzowy/rmf03_01_01.doc
Pawel Durys
> Moja zasada jest taka, że aplikacja działa tak, jak chce tego zlecający,
> zgodność
> z przepisami bierze na siebie zleceniodawca, chyba, że robię to dla
siebie,
> wtedy
> dbam o taką zgodność.
Czyli jak nie dasz zleceniodawcy (np. na zadanie) do wgladu kodu programu z
objasnieniem co, gdzie i w jaki sposob sie magicznie przeksztalca z netto na
brutto, a w umowie jest napisane, ze aplikacja ma dzialac zgodnie z
obowiazujacymi przepisami prawa, to jednak ty bedziesz ponosil
odpowiedzialnosc za ewentualne bledy. Czy sie myle?
Ale to juz mialo byc EOT.
--
Pozdrowienia
Pawel Durys
PS. Nie chcialem Cie straszyc, wiem ze nie jest latwo wyegzekwowac
odpowiedzialnosc od programisty. To tylko takie IF tresc_umowy != precyzyjna
THEN ....
Pawel
Grzesiek B.
> Czyli jak nie dasz zleceniodawcy (np. na zadanie) do wgladu kodu programu
z
> objasnieniem co, gdzie i w jaki sposob sie magicznie przeksztalca z netto
na
> brutto, a w umowie jest napisane, ze aplikacja ma dzialac zgodnie z
> obowiazujacymi przepisami prawa, to jednak ty bedziesz ponosil
> odpowiedzialnosc za ewentualne bledy. Czy sie myle?
W umowie nie jest NIGDY napisane, że aplikacja ma działać zgodnie z
obowiązującymi przepisami, ponieważ sposób interperacji tych przepisów jest
wprost proporcjonalny do wysokości stołka na którym siedzi interpretujący.
Jest to zdefiniowane matematycznie np.
Kwota netto jest iloczynem ilości i ceny netto i jest zaokrąglana do pełnych
groszy.
...
Lecę na wiadomości,
Pozdr,
GB
MKotynia
>Uzytkownik "MKotynia" <kot...@wp.pl> napisal w wiadomości
>W tym cala rzecz, ze ustawodawca wymyślając sposoby liczenia VAT
>mial "w powazaniu"
>programistow i przyjeto czysto matematyczne zasady. Stąd wszelkie
>proby dostosowania
>kodu do innego dzialania niz czysto matematyczne są bledne.
>Zgadzam sie w 100% z KC - VAT powinien byc liczony dokladnie tak jak
>to napisal.
>
>Pozdr,
>
>GB
z calym powazaniem chyba niedoczytales postu bo my juz
nie dyskutujemy jak powinien byc liczony vat ale o obcieciu pozycji
kc przytoczyl przyklad
> po zaokrągleniu = 4,93 zl !!!!!, a nie
> 4,92 zl !!!!!
a ja na niego odpowiedzialem ze to zbdura ze tak sie stanie
>> >zmiennej/pola o mniejszej precyzji powoduje bowiem UCIECIE
>> >odpowiedniej cześci ulamkowej, a nie ZAOKR GLENIE. Roznicy chyba
>> >nie
--
Grzesiek B.
> z calym powazaniem chyba niedoczytales postu bo my juz
> nie dyskutujemy jak powinien byc liczony vat ale o obcieciu pozycji
> kc przytoczyl przyklad
> > po zaokrągleniu = 4,93 zl !!!!!, a nie
> > 4,92 zl !!!!!
> a ja na niego odpowiedzialem ze to zbdura ze tak sie stanie
>
> >> >zmiennej/pola o mniejszej precyzji powoduje bowiem UCIECIE
> >> >odpowiedniej cześci ulamkowej, a nie ZAOKR GLENIE. Roznicy chyba
> >> >nie
No przyznaję, nie do końca doczytałem, ale ta dyskusja stała się już dość
"wielowątkowa" i całość raczej trudno ogarnąć. Lepszym rozwiązaniem byłoby
podzielić to na kilka węższych zagadnień. Ech, co tam VAT w porównaniu do
wojny w Iraku....
Pozdr,
GB
Krzysiek SArna
1. Cena z czterema miejscami na fakturze za EE jest jakimś bardzo dziwnym
wyjątkiem, nie wiem jak zakłady energetyczne się z tego tłumaczą. Ja bym
tego nie ryzykował.
2. Kurs waluty nie jest wartością samą w sobie, ale przelicznikiem.
3. Zaokrąglanie do dwóch miejsc "na końcu" jak ktoś to raczył ując - nie
jest dobrym wyjściem. Twierdzę, że każda kwota zapisywana w księgach musi
zostać zaokrąglona do dwóch miejscach po przecinku. Nawet wartości w walucie
przeliczane wg kursu z czterema miejscami po przecinku
3. Co mówią przepisy:
Rozporządzenie ministra finansów w sprawie wykonywania niektórych przepisów
ustawy o podatku od towarów i usług oraz podatku akcyzowym.
Rozdział 10 Zasady wystawiania i przechowywania faktur VAT
paragraf 35 ustęp 1 Faktura powinna zawierać:
...
6) cenę jednoistkową bez kwoty podatku ...
7) wartość sprzedanych towarów
..
9) sumę wartości sprzedaży netto ...
10) kwotę podatku od sumy wartości ...
11) wartość sprzedaży towarów .. z podziałem na stawki ...
12) kwotę należności
....
Ustęp 5.
Kwoty wykazane na fakturze zaokrągla się do pełnych groszy, przy czym
koncówki poniżej 0.5 grosza pomija się, a końcówki 0.5 grosza i wyższe
zaokrągla się do 1 grosza.
Jak przekonać kogoś że jak autor pisał "cenę jednostkową" to nie miał na
myśli "kwoty" z ustepu 5, a jak pisał "wartość" to miał na myśli "kwotę" z
ustępu 5 ?
Niech sie zakład energetyczny martwi. Podejrzewam, że tłumaczą sie tak, że
to jest usługa i tak obliczają jej wartość, ale to jet mętne, bo cene
jednostkową usługi też trza na fakturze wykazać, można nie wykazywać ilości
dla usług.
Użytkownik "adam@@" <ad...@interia.pl> napisał w wiadomości
news:b4s6o1$m86$1...@nemesis.news.tpi.pl...
> Mam zrobiona bazę danych a access 2000 do pisana faktur vat..Kłopot
jest
> w tym że przy obliczaniu wartości brutto, podatku dla każdej pozycji i w
> podsumowaniu podawane są złe wyniki. Ilość groszy po przecinku się nie
> zgadza... Obliczenia są zrobione w kwerendach.. W formularzu przy
klikniecie
> na pole wyświetlane jest więcej niż dwie liczby po przecinku. Jak to
zmienić
> bo nie bardzo to Qmam.
>
Krzysztof Czuryło
"Pawel Durys" <pdu...@gazeta.pl> wrote in message news:b5aa9r$2qu$1...@inews.gazeta.pl...
|
| > Zgadzam się w 100% z KC - VAT powinien być liczony dokładnie tak jak to
| > napisał.
Cieszę się, choć zastrzegam, że jest to tylko moja propozycja (IMHO zgodna
z przepisami i dająca jednoznaczne, spójne wyniki).
| Moje trzy grosze i 33 setne (0.0333 PLN)
|
| VAT powinien byc liczony tak jak to okreslil ustawodawca. Koniec kropka.
|
| ========================================================================
| ROZPORZĄDZENIE MINISTRA FINANSÓW z dnia 22 marca 2002 r.
|
| w sprawie wykonania niektórych przepisów ustawy o podatku od towarów i usług
| oraz o podatku akcyzowym
Z tym się zgadzam, choć pragnę dodać, że ustawa i rozporządzenie to czasem
za mało. Są jeszcze oficjalne interpretacje MF, instrukcje US, wyroki NSA, itd.
W rozporządzeniu jest to napisane tak, że w efekcie każdy robi po swojemu
i każdemu się wydaje, że to on robi dobrze. A US i tak wie swoje. ;-)))
Krzysztof Czuryło
"MKotynia" <kot...@wp.pl> wrote in message news:Xns93436825E6D3AX...@127.0.0.1...
| ja jestem praktykiem wiec empirycznie udowodnie ze nie masz racji !
| jesli chodzi o ten przyklad
| Msaccess 2000/ADP/SQL
|
| Alter Procedure testdlaczurylo
| As
| declare @cena decimal(18,2)
| set @cena = 1.12
| declare @ilosc decimal(18,2)
| set @ilosc = 20
| declare @temp decimal(18,2)
| set @temp = @cena * @ilosc
| insert into test (ilosc,cena,razem,vat) values (@ilosc,@cena,@temp,@temp*0.22)
| set nocount on
| return
|
| wynik
| ilosc cena vat razem
| 20 1,12 4,93 22,4
Przykład świetny, ale co on ma wspólnego z Accesem???
| wiec gow*o prawda ze obcina i nie mam zamiaru juz dyskutowac w tym watku
| na reszte postu nei mam czasu pisac niech kazdy robi jak chce
| (wyraznie napisalem "osobiscie pracuje na sql serwerze i korzystam z decimal(18,2) ")
Napisałeś również:
<cite>
4 miejsca po przecinku to BADZO zly pomysl w _jakimkolwiek_ (podkr. KC) programie
obslugujacym fakturowanie lub gm
</cite>
Twoje kategoryczne stwierdzenie zostało przeze mnie równie kategorycznie nazwane
bzdurą i swoją opinię podtrzymuję. Argumenty podałem (w przeciwieństwie do Ciebie)
i jeśli Cię to nie przekonuje to trudno, może inni się zastanowią.
Jedyny Twój "argument" jest taki, że u Ciebie na SQL Serwerze Twoje rozwiązanie
działa. Tylko czy tak będzie u innych, na innych platformach, a w szczególności
w Accessie!!! Ba! Czy tak samo będzie na innej wersji SQL Serwera!!!
W "czystym" Accessie (2000) nie działa NA PEWNO, gdyż _osobiście_to_sprawdziłem_.
Podany przeze mnie przykład własnoręcznie wklepałem i wynik był taki jak podałem -
- część ułamkowa została obcięta, a nie zokrąglona.
| jesli w accesie nei jest tak samo to faktycznie moj pie*ony blad
| ale od tego sa inni grupowicze zeby poprawic mnie a nie atakowac
Nie! To Ty powinieneś najpierw sprawdzić, czy to co piszesz jest prawdą.
A nie zrobiłeś tego!
<cite>
_zerknolem_ (podkr. KC) sobie na formaty tabel w mdb i tam tez mozna wybrac decimal
</cite>
<cite>
_wydaje_mi_sie_ (podkr. KC) ze w tabelach accesowych jest tak samo jak na sql serv
</cite>
I jeszcze jedno - nie wysyłaj mi swoich odpowiedzi na moje konto mailowe,
bo nie ma takiej potrzeby, a tylko zaśmieca mi to skrzynkę. Grupę czytuję
regularnie i na pewno Twoja odpowiedź nie zostanie niezauważona.
Krzysztof Czuryło
"Krzysiek SArna" <k.s...@teta.com.pl> wrote in message news:b5d8ae$2q9d$1...@Dwarf.Rozanka.WROC.PL...
| Sie jeszcze wtrące:
| 1. Cena z czterema miejscami na fakturze za EE jest jakimś bardzo dziwnym
| wyjątkiem, nie wiem jak zakłady energetyczne się z tego tłumaczą. Ja bym
| tego nie ryzykował.
Ja tam nie wiem, ale wiem, że Energa Gdańsk mi takie faktury przysyła.
Pragnę tylko zauważyć, że energetyka i telekomunikacja rządzą się swoimi prawami.
Wolno im np. wystawiać faktury bez NIP-ów i podpisów. Jest na to stosowne
rozporządzenie. Być może mówi ono również o cenach jednostkowych wyrażonych
w ułamkach grosza? Nie sprawdzałem, ale kto wie?
Pawel Durys
> Pragnę tylko zauważyć, że energetyka i telekomunikacja rządzą się swoimi
prawami.
> w ułamkach grosza?
Zawsze moga wystawiac faktury podajac cene jednostkowa wyrazona w MW
(megawatach), nawet z dokladnoscia do czterech miejsc po przecinku.
W polsce to nie jest takie widoczne, ale np. w niemczech ceny za paliwo sa
podawane za 100 litrow, aby mozliwe bylo pokazanie tych ulamkow (juz nie
fenigow) ale eurocentow.
--
Pozdrowienia
Pawel Durys
Krzysiek SArna
>
> > Pragnę tylko zauważyć, że energetyka i telekomunikacja rządzą się swoimi
> prawami.
> > ... Być może mówi ono również o cenach jednostkowych wyrażonych
> > w ułamkach grosza?
>
> Zawsze moga wystawiac faktury podajac cene jednostkowa wyrazona w MW
> (megawatach), nawet z dokladnoscia do czterech miejsc po przecinku.
Skąd to przekonanie ?
Arkadiusz Jestratjew
Obecnie zakłady energetyczne za "jednostkę" energii uważają kWh
(kilowatogodzina).
Gdyby za jednostkę uznać MWh (megawatogodzina - nie megawat :) to podając
jej
cenę z dokładnością do groszy dostaje się cenę kWh z dokładnością do 0,001
grosza.
Czy jest przepis zabraniający ZE użycia takiej jednostki? Nie wiem.
Ale w Polsce obowiązuje układ jednostek SI. W tym układzie jednostką energii
jest
1 J (dżul) - inaczej Ws (watosekunda). 1kWh = 3,6 x 10^6 J. Skoro wolno jest
używać w rozliczeniach jednostki energii równej 3,6 x 10^6 J to czemu nie
3,6 x 10^9 J ?
--
AJ, z lekko oftopicznym podejściem dzisiaj ;)
Pawel Durys
> > (megawatach), nawet z dokladnoscia do czterech miejsc po przecinku.
>
> Skąd to przekonanie ?
>
Z zycia.
W moim "swiecie" sprzedajemy towar, ktorego cena wyrazana jest z
dokladnoscia czterech miejsc dziesietnych za metr kwadratowy. Zawsze!
Poniewaz produkt ma znana szerokosc, to klienci zycza sobie podawanie ceny w
1000lm (metry biezace), albo 100sqm (metry kwadratowe), albo w dowolnej
innej (wlaczajac w to cale i stopy kwadratowe).
Skoro moja firma potrafi dostosowac sie do klienta i zafakturowac go w
dowolnych jednostkach za ten sam produkt, to co stoi na przeszkodzie aby ZE
fakturowal za MW?