Pieņemsim, ka uz pavadzīmes ir 3 preces ar pamatsummām (bez PVN) A, B, C un visām piemēro nodokli 21%. Kā pareizi aprēķināt PVN?
Ir 2 varianti:
1) katrai rindiņai aprēķina PVN un visu skaita kopā:
ROUND(21%*A)+ROUND(21%*B)+ROUND(21%*C)
2) visas rindiņas saskaita kopā un aprēķina PVN:
ROUND(21*(A+B+C))
Tieši šie paši divi varianti ir arī tad, ja A, B, C ir preču cenas ar jau iekļautu PVN, tad formula ir sarežģītāka, bet jautājums ir tas pats - vai PVN rēķina katrai rindiņai atsevišķi un tad summē kopā vai arī rēķina no kopsummas.
Cik zinu, tad vairumtirdzniecības praksē, veikalos, datorprogrammās lieto 2) variantu. Veikalos tas ir tāpēc, ka kases aparāti rēķina PVN pa nodaļām un neskatās, kāds PVN ir katrai precei (kā arī PVN ir daudz vienkāršāk rēķināt no galasummām, ja starpsummām piemēro visdažādākās atlaides). Kāpēc šo metodi pielieto arī vairumtirdzniecība un datorprogrammas - tam iemeslu nezinu.
Vai ir kāds likums, kas nosaka, kādu metodi - 1) vai 2) ir jāizvēlas?
Līdz šim esmu atradis tikai "Kārtība, kādā norādāmas preču un pakalpojumu cenas", kas nosaka, ka mazumtirdzniecībā "Preces gabalcenā un noteiktas mērvienības cenā ietver pievienotās vērtības nodokli un visus citus nodokļus." (4. pants). Varētu likties, ka katrai precei "velkas" līdzi PVN (atšķirība no tā akcīze taču attiecas tieši uz preci), bet realitātē tā nav?
Kādu metodi 1) vai 2) izvēlēties? Un ko darīt, ja es strādāju pēc metodes 1), bet piegādātājs sūta pavadzīmi pēc metodes 2) vai pircējs prasa pavadzīmi pēc metodes 2)?
Metodei 1) ir lielas priekšrocības. Piem., tagad ir daudzi reversie PVN, protams, ka vienkāršāk būtu rēķināt PVN no rindiņām. Tāpat ir vēlme gan saņemtās gan izejošās preces no vienas pavadzīmes dalīt pa organizatoriskajām vienība vai grāmatvedības kontiem. Arī tad ir daudz vienkāršāk, ja PVN ir katrai rindiņai atsevišķi, nav pavadzīmes kopējais PVN ar n-tajiem decimālcipariem jādala pa rindiņām pēc kaut kādas metodogloģijas. Arī OLAP (Online
Ir 2 varianti:
1) katrai rindiņai aprēķina PVN un visu skaita kopā:
ROUND(21%*A)+ROUND(21%*B)+ROUND(21%*C)
2) visas rindiņas saskaita kopā un aprēķina PVN:
ROUND(21*(A+B+C))
Tieši šie paši divi varianti ir arī tad, ja A, B, C ir preču cenas ar jau iekļautu PVN, tad formula ir sarežģītāka, bet jautājums ir tas pats - vai PVN rēķina katrai rindiņai atsevišķi un tad summē kopā vai arī rēķina no kopsummas.
Cik zinu, tad vairumtirdzniecības praksē, veikalos, datorprogrammās lieto 2) variantu. Veikalos tas ir tāpēc, ka kases aparāti rēķina PVN pa nodaļām un neskatās, kāds PVN ir katrai precei (kā arī PVN ir daudz vienkāršāk rēķināt no galasummām, ja starpsummām piemēro visdažādākās atlaides). Kāpēc šo metodi pielieto arī vairumtirdzniecība un datorprogrammas - tam iemeslu nezinu.
Vai ir kāds likums, kas nosaka, kādu metodi - 1) vai 2) ir jāizvēlas?
Līdz šim esmu atradis tikai "Kārtība, kādā norādāmas preču un pakalpojumu cenas", kas nosaka, ka mazumtirdzniecībā "Preces gabalcenā un noteiktas mērvienības cenā ietver pievienotās vērtības nodokli un visus citus nodokļus." (4. pants). Varētu likties, ka katrai precei "velkas" līdzi PVN (atšķirība no tā akcīze taču attiecas tieši uz preci), bet realitātē tā nav?
Kādu metodi 1) vai 2) izvēlēties? Un ko darīt, ja es strādāju pēc metodes 1), bet piegādātājs sūta pavadzīmi pēc metodes 2) vai pircējs prasa pavadzīmi pēc metodes 2)?
Metodei 1) ir lielas priekšrocības. Piem., tagad ir daudzi reversie PVN, protams, ka vienkāršāk būtu rēķināt PVN no rindiņām. Tāpat ir vēlme gan saņemtās gan izejošās preces no vienas pavadzīmes dalīt pa organizatoriskajām vienība vai grāmatvedības kontiem. Arī tad ir daudz vienkāršāk, ja PVN ir katrai rindiņai atsevišķi, nav pavadzīmes kopējais PVN ar n-tajiem decimālcipariem jādala pa rindiņām pēc kaut kādas metodogloģijas. Arī OLAP (Online
