Če želiš dodat dodaten popust na cel račun ga lahko dodaš kot postavka na koncu s ceno v minus. Znesek moraš v tem primeru izračunat sam.

Je pa še neuraden trik. Če dodaš v začetku besedila * ti bo pri PDF-ju skrilo količino, ceno, enoto in prikazalo le znesek na desni. To lahko pride prav tudi npr. za poštnino ali druge stroške.

Primer na sliki:

@Balonar: hvala da si vskoču

@Matjaz: kot sva govorila po emailu sem testiral in mi nikakor ne uspe ponoviti težav pri dnevnem ali mesečnem poročilu, meni dela v vseh poskusih, je pa še nekdo to javil in računam da danes rešimo na konkretnih problematičnih podatkih če ne drugače. (napis na vrhu Dialog-a "Dnevno poročilo" pa je rešeno in pride z 1.04 kjer bo še drug problem rešen).

@MarioMisaron: aha, sem našel napako pri sprotnem dodajanju ja. Je odpravljena. hvala da si javil

@Matjaž: sem sedaj testiral in niesm opazil problemov. Drugače mesečnih poročil pred to verzijo (1.01 / 1.03) ni bilo. A zgoraj piše "Poročilo za mesec" ali "Poročilo za dan"?

Če je račun samo 1 bo pisalo le od, če jih je več pa bi moralo pisati od do (pravkar testiral).

Namesto "Izberi datum" v meniju sedaj le klikneš na ikonico koledarčka spodaj. Prikaže vse dneve v tem mesecu in seštevke. če spet klikneš inkonico na dnu seznam prikaže vse mesece v katerih so bili računi in zneske. S kliki na mesec in potem spet dan prideš do željenega dneva. Mesečno poročilo je vezano na izbrani dan.

@MarioMisaron: ne razumem točno za kaj se gre. Simobil ima težavo, da če ima mobilni telefon nastavljen njihov proxy potem čez ne spusti zahtevka na FURS. A misliš to ali kaj čisto drugega? Kje se ta dva simbola spremenita?

@pavletic: hvala za komentar zgoraj :)

Če je bil DDV 0% smo tudi mi prikazali 0% (kar je seveda meni bilo logično in se mi zdi jasno), potem pa smo od parih strank izvedeli, da jim je inšektor pravil da DDV stopnja 0% ne obstaja zato ne sme biti napisana in da mora biti v tem primeru prazno. Zato deluje tako kot deluje sedaj.

nočem biti preveč pedanten in vlečt te teme :) , a če Datalab, ki je med največjimi v slo napiše da ne more priporočiti pravega načina in naj vsak izbere svoj "strup" potem tako simpl rečt katera je edina prava ni:

"Ker od pristojih inštitucij (v nadaljevanju) nismo dobili nobenih konkretnih odgovorov, ne moremo enostransko objaviti priporočenih nastavitev samih zaokroževanj in izračunavanja cen in davka v programu" (na linku par objav nazaj)

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

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

@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

@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.

program osnovo in DDV kalkulira z več decimalkami.

OSNOVA: (5.65573 * 3 + 0.7377 * 14 ) = 27.29499 = 27.29

DDV: 27.29499 * 0.22 = 6.0048978 = 6.00

ZNESEK ZA PLAČILO: 27.29 + 6.00 = 33.29

Tu se držimo navodil trgovinske zbornice:

" Pri cenah, ki so izražene na večje število decimalnih mest, se morajo zneski vmesnih operacij zaokrožiti na najmanj toliko decimalnih mest, kolikor jih ima cena iz katere je vmesna operacija pridobjena. Pri tem se za vmesne operacije štejejo operacije, pri katerih takojšnji cilj operacije ni plačilo ali knjiženje kot končni obračun ustreznega denarnega zneska. "

Torej, jaz to razumem (in računovodji s katerimi sem se posvetoval) da se vmesne operacije lahko računajo na več decimalk (najmanj toliko) razen končne, za plačilo, ki pa se mora na 2.

Drugje tudi priporočajo naj izračunamo osnovo in ddv (po stopnjah in to seštejemo za končni znesek), ker če množiš končni znesek iz postavk z DDVjem, potem se dogaja da Osnova + DDV ni vedno Končni znesek in se ti bojo prejemniki računov pritoževal, da ne morejo poknjižit.

Npr. v tvojem primeru, če jaz končni znesek izračunam direktno iz postavk z neomejeno decimalkami (kot sem osnovo in DDV) potem se že ne bodo saj bo 27.29 + 6.00 = 33.30 kar ne drži.

--

Lahko bi npr dodal opcijo da računa tako pri tistih uporabnikih ki si jo izberejo, a ne vem če ne boš imel potem problemov, kot sem jih opisal.