Čebelca.biz - online poslovni program
58 naročnikov
58 naročnikov
Oj,
Zdaj ko je Site Assistant pripushan do stanja kje lahko človek pride in naroči paket sem se spet lotil tadrugega projekta ki sem ga razvijal vzporedno. Zadnji mesec sem ga malo opustil da bi čimprej končal site assistant. Stvar še ni online, tako da sem naredu kar screencast kjer se vse vidi :)
http://screencast.com/t/HxfFGtg9r
V glavnem, ker predvidevam da imate tukaj nekateri tudi "manjša podjetja" tako kot jaz, je vaš feedback zelo dobrodošel...
282 odgovorov
@pavletic:
hvala za dodatne primere. jih bom preučil kaj točno se zgodi. Za prvega že vem.
Drugače ni, da je do sedaj delalo idealno sedaj pa smo spremenili. Že sedaj smo imeli dva načina delovanja. A je lahko med zneskom na računu pri seštevkih in v DDV tabeli ter med seznamom in prikazom računa v aplikaciji lahko prišlo do razlike za 1cent v redkih primerih z več kot 2 decimalkami ali popusti (kar si napisal tudi ti). To smo sedaj poenotili in hkrati preučili vse uradne informacije ki smo jih našli (tudi eden največji rač. programov tu nima idealne rešitve in dajo uporabniku na voljo da si izbere enega od načinov). Prav tako niti oni niso dobili jasnega odgovra od FURS, dobili pa so od trgovinske zbornice, ki smo ga upoštevali.
Kot sem že prej rekel, lahko naredim dodaten način ki si ga aktiviraš in ti bo delovalo drugače kot po defaultu. A bi vseeno rad ugotovil kje točno je problem in ali se da to rešiti bolje kot je bilo prej, ker prej je bilo manj enotno kot sedaj.
Bom sedaj pogledal tvoja primera in ti javil kako točno pride do cifer do katerih pride. Prvega okvirno že vem v čem je stvar. Ti javim.
Janko, nam je do včeraj delal tisti čuden seštevek 43,80eur, danes je OK in je spet 43,79 (in štima tudi pri drugih produktih in drugih cenah), se pravi kar se nas tiče če ostane tako bo super :) Danes imamo po dolgem času vse cene pravilne na računih, sicer je bil vedno 1 cent preveč ali premalo.
@Torcida, super. Ja, tu imam cca 16 primerov računov za testirat, ki so bili prej problematični in sedaj so vsi enotni na seznamu, pri prikazu v app-u in pri PDF-ju pri seštevku in tabeli z davki.
to da je prej prihajalo do občasne 1centa razlike pri cenah z več kot 2 decimalke me je mučilo dalj časa, a kot sem rekel ni bilo videti nobenega uradno pravega načina, nekje pa se je napaka zaokroževanja morala pokazat, vprašanje je le kje jo dovoliš. Kot olajševalno okoliščino bom citiral FURS (najdeno pri drugem ponudniku blagajniških programov):
""Davčni zavezanec cene za klic izkazuje na štiri decimalna mesta. Tako je na razčlenjenih računih znesek za posamezni klic prikazan na štiri decimalna mesta (zneski vmesnih operacij), na mesečnih računih pa se zneski za posamezne klice za isto vrsto storitve, np
r: klici v notranjem prometu, seštejejo in prikažejo na dve decimalni mesti, ker se znesek knjiži na ustrezni konto. DDV se obračuna in izkaže na računu od vsake storitve posebej. Zmnožek seštevka davčnih osnov in davčne stopnje zaradi zaokroževanja ni vedno
enak seštevku vrstičnih postavk DDV. Razlike so se pojavljale že v sistemu tolarjev, vendar davčni zavezanci, ker so bile razlike v stotinih tolarjev, nanje niso bili pozorni."
Tist odgovor trgovinske zbornice nam je dal usmeritev in sedaj mislim da je veliko boljše. Primere, ki mučijo uporabnika pavletič pa bom tudi rešil, če ne drugače naredim opcijsko drugačno izračunavanje.
@pavletic
1) pri prvem primeru se pri 5 decimalkah res ne izzide. Razlog je, da mi zneske postavk (brez DDV) interno zaokrožujemo na 4 decimalke (tvoje cene pa so na 5 decimal), ker je kazalo da več kot 4 decimalke pri ceni običajno niso potrebne. Problem se da videtu tu:
( brez zaokroževanja postavk na 4 dec. )
10.32786 * 1 + 2.37705 * 1 = 12.70491 = 12.70
( z zaokroževanjem na 4. dec )
10.3279 + 2.3771 = 12.705 = 12.71
Zato je naš program dobil 12.71. A sem sedaj zaokroževanje postavk nastavil na 6 decimal pri vseh preračuni (app, pdf, ..). Zato se stvar izide kot bi pričakoval in dobiš 12.70 in bruto 15.50
(( če bi dal cene na 4 decimalke, kot npr preračuna naše orodje za preračun neto cen:
https://www.cebelca.biz/tool-tax-si.html
bruto: 12.60 + 2.90
bi dobil neto: 10.3279 + 2.3770 = 12.7049 = 12.70 in bi se tudi izšlo že prej ))
2) drugi primer pa je pravilen. enice centov ne pridejo 0 kljub temu da so mogoče končne cene artiklov z enicami 0 ker imaš popust 5%.
( 10.08196 * (1 - 5/100) + 9.34426 * (1 - 5/100) + 2.37705 ) = 20.831959 = 20.83 --OK
20.831959 * 0.22 = 4.58303098 = 4.58 --OK
20.83 + 4.58 = 25.41
celo tako (kot želiš ti računati če razumem) pride .41 na koncu v tem primeru:
( 10.08196 * (1 - 5/100) + 9.34426 * (1 - 5/100) + 2.37705 ) * 1.22 = 25.41498998 = 25.41
A imaš še kakšen problematičen račun, da vidim če je še kaj za rešit ali bo to sedaj v redu?
LP
Janko
Neto cene (če hočemo "lepe" in pravilne bruto cene z DDV), morajo biti najmanj na 5 decimalk (6 še bolje), da dobimo pravilne bruto cene z DDV.
Problema ne bi bilo (v večini primerov), če bi šlo za 1 ali 2 kosa. Konkreten problem nastane, ko je npr. kosov 100 ali 200, neto cena pa je zaokrožena na samo 4 ali celo manj decimalk. V temu primeru lahko nastane razlika v končni ceni za plačilo (bruto ceni) za kar nekaj centov, kar pa nikakor ni OK.... Upam, da se razumemo?
Bom poročal čez nekaj časa kako se program odziva, če je sedaj vse OK.
Pa še to. Če je TorcidaST prej imel napačne bruto cene to pomeni, da je imel napačno nastavljene neto cene (premalo decimalk).
Drugih opcij tukaj ni, to upam, da se razumemo, gre za matematiko :)
Skratka edini pravilen način je, da program za računanje uporablja najmanj 5 ali 6 decimalk pri neto ceni, drugače pri bruto zneskih, še posebej, če gre za večje količine kosov, nastanejo velike razlike. Težava (če je program pravilno nastavljen), torej ni v programu, ampak v uporabnikih, ki ne znajo pravilno nastaviti neto cen (uprabijo premalo decimalk).
Kot sem rekel... zadeva je simpl, gre za matematiko :)
Ok. A 6 decimalk je potem v redu zate ali imaš kdaj še več?
Če najdeš katerkoli račun, ki je še problem mi prosim javi. Zdaj trenutno mi vsi test casi ki jih imam delajo enotno in prav.
LP
Janko
pavletic: so druge opcije, a ta sedanja je najbol uradno potrjena. poglej si npr stran od datalaba na to temo: https://usersite.datalab.eu/printclass.aspx?type=wiki&id=75786