Ja 1s 8.3 nepareizi aprēķina iedzīvotāju ienākuma nodokli. Preču norakstīšana “mīnus”

Šajā rakstā es vēlos apsvērt iedzīvotāju ienākuma nodokļa aprēķināšanas un ieturēšanas aspektus 1C 8.3, kā arī pārskatu sagatavošanu veidlapās 2-NDFL un 6-NDFL.

Reģistrācijas iestatīšana nodokļu iestādē

Vissvarīgākais iestatījums, bez tā jūs nevarēsit iesniegt pārskatus pārvaldes iestādēm. Dosimies uz direktoriju "Organizācijas" (izvēlne "Galvenā" - "Organizācijas"). Kad esat izvēlējies vajadzīgo organizāciju, noklikšķiniet uz pogas “Vairāk...”. Nolaižamajā sarakstā atlasiet “Reģistrācija nodokļu iestādēs”:

Jums rūpīgi jāaizpilda visa informācija.

Algu uzskaites sakārtošana

Šie iestatījumi tiek veikti sadaļā “Alga un personāls” – “Algas iestatījumi”.

Dosimies uz “Vispārīgie iestatījumi” un norādīsim, ka grāmatvedība tiek uzturēta mūsu programmā, nevis ārējā, pretējā gadījumā visas sadaļas, kas saistītas ar personāla un algu uzskaiti, nebūs pieejamas:

Cilnē “Iedzīvotāju ienākuma nodoklis” jānorāda, kādā secībā tiek piemēroti standarta atskaitījumi:

Cilnē “ ” jānorāda, pēc kādas likmes tiek aprēķinātas apdrošināšanas prēmijas:

Jebkuri uzkrājumi privātpersonām tiek veikti saskaņā ar ienākumu kodu. Šim nolūkam programmā ir uzziņu grāmata “Iedzīvotāju ienākuma nodokļa veidi”. Lai apskatītu un, ja nepieciešams, pielāgotu uzziņu grāmatu, jāatgriežas logā “Algu iestatījumi”. Izvērsīsim sadaļu “Klasifikatori” un noklikšķiniet uz saites “NDFL”:

Atvērsies iedzīvotāju ienākuma nodokļa aprēķina parametru iestatījumu logs. Uzziņu grāmata atrodas attiecīgajā cilnē:

Lai iestatītu iedzīvotāju ienākuma nodokļa aplikšanu katram uzkrājumu un atskaitījumu veidam, logā “Algu iestatījumi” jāpaplašina sadaļa “Algas aprēķināšana”:

Vairumā gadījumu ar šiem iestatījumiem pietiek, lai sāktu algu un iedzīvotāju ienākuma nodokļa uzskaiti. Atzīmēšu tikai to, ka direktorijus var atjaunināt, kad tiek atjaunināta programmas konfigurācija, atkarībā no izmaiņām likumdošanā.

Iedzīvotāju ienākuma nodokļa uzskaite 1C: uzkrāšana un atskaitīšana

Iedzīvotāju ienākuma nodoklis tiek aprēķināts par katru faktiski saņemto ienākumu summu atsevišķi par periodu (mēnesi).

Iedzīvotāju ienākuma nodokļa summa tiek aprēķināta un uzkrāta, izmantojot tādus dokumentus kā “ “, “ “, “ ” un tā tālāk.

Kā piemēru ņemsim dokumentu “Algas saraksts”:

Saņemiet 267 video nodarbības 1C bez maksas:

Cilnē “Iedzīvotāju ienākuma nodoklis” redzam aprēķināto nodokļa summu. Pēc dokumenta grāmatošanas tiek izveidoti šādi iedzīvotāju ienākuma nodokļa darījumi:

Dokumentā tiek izveidoti arī ieraksti reģistrā “Ienākuma uzskaite iedzīvotāju ienākuma nodokļa aprēķināšanai”, saskaņā ar kuriem pēc tam tiek aizpildītas atskaites veidlapas:

Faktiski no darbinieka ieturētais nodoklis tiek atspoguļots grāmatvedībā, grāmatojot dokumentus:

  • Iedzīvotāju ienākuma nodokļa uzskaites darbība.

Atšķirībā no uzkrāšanas nodokļa ieturēšanas datums ir iegrāmatotā dokumenta datums.

Atsevišķi jāapsver dokuments “Iedzīvotāju ienākuma nodokļa uzskaites operācija”. Tas paredzēts iedzīvotāju ienākuma nodokļa aprēķināšanai no dividendēm, atvaļinājuma naudas un citiem mantiskajiem labumiem.

Dokuments tiek izveidots izvēlnē “Algas un personāls” sadaļā “Iedzīvotāju ienākuma nodoklis”, saite “Visi dokumenti par iedzīvotāju ienākuma nodokli”. Logā ar dokumentu sarakstu, noklikšķinot uz pogas “Izveidot”, tiek parādīts nolaižamais saraksts:

Gandrīz visos dokumentos, kas vienā vai otrā veidā ietekmē iedzīvotāju ienākuma nodokli, tiek izveidoti ieraksti reģistrā “Nodokļu maksātāju aprēķini ar iedzīvotāju ienākuma nodokļa budžetu”.

Kā piemēru aplūkosim nodokļu uzskaites reģistra ierakstu veidošanu, izmantojot dokumentu “Norakstīšana no norēķinu konta”.

Pievienosim dokumentu "" (izvēlne "Algas un personāls" - saite "Izraksti bankai") un uz tā pamata izveidosim "Norakstīšanu no norēķinu konta":

Pēc tam apskatīsim grāmatojumus un kustības reģistros, ko dokuments ģenerēja:

Iedzīvotāju ienākuma nodokļa atskaites veidošana

Iepriekš es aprakstīju galvenos reģistrus, kas ir iesaistīti iedzīvotāju ienākuma nodokļa pamata pārskatu veidošanā, proti:

Logā ar dokumentu sarakstu noklikšķiniet uz pogas Izveidot un aizpildiet darbinieka sertifikātu:

Dokuments neģenerē darījumus un ierakstus reģistros, bet tiek izmantots tikai drukāšanai.

  • (2. sadaļa):

Ziņojums attiecas uz regulētu ziņošanu. Varat arī pāriet uz tā reģistrāciju sadaļā “Iedzīvotāju ienākuma nodoklis”, izvēlnē “Algas un personāls” vai izvēlnē “Pārskati” sadaļā “1C pārskati” “Regulētie pārskati”.

Otrās sadaļas aizpildīšanas piemērs:

Ieturētā un uzkrātā iedzīvotāju ienākuma nodokļa pārbaude

Lai pārbaudītu nodokļu uzkrāšanas un iemaksas budžetā pareizību, varat izmantot “ “. Tas atrodas izvēlnes “Pārskati” sadaļā – “Standarta pārskati”.

Šodien es aplūkošu soli pa solim sniegtās instrukcijas iedzīvotāju ienākuma nodokļa (saīsināti kā iedzīvotāju ienākuma nodokļa) uzskaitei 8.3 (pārskats 3.0).

Kā jau visi droši vien zina, galvenais nodoklis, kas tiek ieturēts no mūsu algām, ir iedzīvotāju ienākuma nodoklis. Atlikušos ieturējumus galvenokārt veic darba devējs (piemēram, tās ir iemaksas pensiju fondā un slimokasē. Tos sauc arī par “apdrošināšanas iemaksām”).

2017. gadā iedzīvotāju ienākuma nodokļa likme joprojām ir 13% no kopējās uzkrājumu summas mīnus atskaitījumi.

Atskaitījumi var atšķirties. Viens no standarta un izplatītākajiem atskaitījumiem ir atskaitījums par nepilngadīgu bērnu. Par pirmo un otro bērnu 2015. gadā atskaitījuma summa ir 1400 rubļu, par trešo un bērnu invalīdu 3000 rubļu.

Tiek piemēroti arī atskaitījumi pieaugušo bērnu audzēkņiem un citi atskaitījumi, kurus mēs šajā rakstā neapskatīsim, tas ir veltīts citai tēmai.

Kā tiek piemēroti atskaitījumi? Ļoti vienkārši. Tie tiek atskaitīti no nodokļa bāzes pirms iedzīvotāju ienākuma nodokļa aprēķināšanas un ieturēšanas.

Piemēram:

Darbinieka alga ir 40 000 rubļu. Viņam par šo summu jāmaksā nodoklis. Bet ja viņam ir nepilngadīgs bērns, tad mums ir pienākums piemērot atskaitījumu! Un nodoklis tiks ņemts no summas 40 000 – 1 400 = 38 600 rubļi Kopā maksājamais darbiniekam (ja viņam nav citu ieturējumu vai saistību) 38 600 – 13% = 33 582 rublis Iedzīvotāju ienākuma nodoklis paliks 5 018 rubļi

Tātad, mēs aptuveni izdomājām, kā tiek aprēķināts iedzīvotāju ienākuma nodoklis. Tagad apskatīsim, kā iedzīvotāju ienākuma nodokļa uzskaites operācijas ir atspoguļotas 1s 8.3, un izmantosim piemēru, lai pārbaudītu ieturamo summu.

Iedzīvotāju ienākuma nodokļa ieturēšana 1C ZUP 8.3

Iedzīvotāju ienākuma nodoklis tiek ieturēts gandrīz no visiem fizisko personu ienākumiem. Tā ir tieši alga, atvaļinājuma nauda, ​​finansiālā palīdzība utt.

Apskatīsim soli pa solim instrukcijas par iedzīvotāju ienākuma nodokļa ieturēšanu, izmantojot algas dokumenta piemēru programmā 1C ZUP 3.0.

Saņemiet 267 video nodarbības 1C bez maksas:

Dodieties uz izvēlni "Alga", pēc tam sekojiet saitei izvēlnē "". Saraksta formas logā noklikšķiniet uz pogas “Izveidot” un atlasiet “Algas un iemaksu aprēķināšana”. Tiks atvērts logs datu ievadīšanai. Jānorāda aprēķina mēnesis un organizācija, kurā darbinieki strādā. Likumsakarīgi, ka obligātie dati ir arī darbinieki, kuriem notiek uzkrājums.

Darbiniekus var atlasīt pa vienam, izmantojot pogu “Pievienot”, vai arī pogu “Aizpildīt”. Šajā gadījumā dokumenta tabulas daļu izvēlētās organizācijas darbinieki aizpildīs automātiski. Šī ir poga, ko izmantošu. Demonstrācijas datubāzē jau ir iekļautas organizācijas un darbinieki.

Lūk, ko es saņēmu:

Dosimies uz cilni “Iedzīvotāju ienākuma nodoklis” un pārbaudīsim, vai programma mums to pareizi aprēķināja un vai tā vispār to aprēķināja:

Pārbaudīsim saglabāšanas aprēķinu. Diemžēl demonstrāciju datubāzē nevienam no darbiniekiem nav standarta atskaitījumu, vismaz par bērnu. Bet atstāsim to kā ir, mums būs vieglāk pārbaudīt aprēķinu, un turklāt atskaitījumus es jau aprakstīju iepriekšējos rakstos. Ticiet man, tie visi ir pareizi ņemti vērā aprēķinā.

Kas tad mums ir? Darbinieces Jeļenas Frantsevnas Simutinas alga ir 55 000 rubļu un iedzīvotāju ienākuma nodokļa likme ir 13%. Nav nekādu atskaitījumu. Aprēķināsim 55 000 – 13% = 7150 rubļu. Programma pareizi aprēķināta.

Iegrāmatojot dokumentu, nodoklis tiks ieturēts, tas ir, iedzīvotāju ienākuma nodokļa dati tiks iekļauti nodokļu uzskaites reģistrā 1C 8.3. Šo atskaitījumu mēs redzēsim izrakstā kasierim par. Šajā pašā paziņojumā norādīsim, vai esam pārskaitījuši nodokli vai darīsim to vēlāk.

Iedzīvotāju ienākuma nodokļa ieskaitīšana budžetā

Lai reģistrētu iedzīvotāju ienākuma nodokļa ieskaitīšanu budžetā 1C ZUP 8.3, jums jāiet uz izvēlni “Maksājumi”, noklikšķiniet uz “Skatīt. Skatīt arī" saiti "Iedzīvotāju ienākuma nodokļa pārskaitījumi budžetā".

Noklikšķināsim uz pogas “Izveidot” un vispirms izveidosim “Izziņu kases aparātam”:

  • 1 Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli programmā 1C 8.2 ZUP 2.5
  • 2 Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli programmā 1C 8.3 ZUP 3.0.
  • 3 Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli programmā 1C 8.3 Grāmatvedība 3.0
  • 4 Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli
  • 5 Iespējamās kļūdas starpmaksājumu dokumentos, izmantojot piemēru 1C 8.3 ZUP 3.0
  • 6 Iespējamās kļūdas starpmaksājumu dokumentos, izmantojot 1C Accounting 3.0 piemēru
  • 7 Iespējamās kļūdas starpmaksājumu dokumentos, izmantojot piemēru 1C 8.2 ZUP 2.5

Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli programmā 1C 8.2 ZUP 2.5 Apskatīsim programmu 1C ZUP 2.5, izmantojot dokumenta “Atvaļinājums” piemēru. Tika uzkrāta atvaļinājuma nauda, ​​kuru sākotnēji bija plānots izmaksāt 29.01.2016. Līdz ar to atvaļinājuma uzskaites dokumentā mainām ienākumu izmaksas datumu uz 01/. 28/2016.

Dažiem programmas 1s 8.3 lietotājiem ir problēmas ar iedzīvotāju ienākuma nodokli. Un kā tev iet?

Ir kādi veidi, kā atgriezties no pēdējā atjauninājuma un pat dažas reizes atgriezties. Novembrī viss vēl bija labi Un tagad man tikai gribas stulbi raudāt no bezspēcības Pievienots: 19.01.2018, 11:27 Citāts: Genādijs ObGES 19.01.2018, 05:49 am. precizēt - dokumenti pārsūtīti (arī neaizpildītie), mēneši no jauna slēgti? Nu, kā jūs varat atbildēt uz šo, pamatojoties uz ekrānuzņēmumu un pat minimālas informācijas trūkumu, lūdzu, pastāstiet man, kāda veida informāciju sniegt? Sāku visu no nulles, konsekventi veidoju un veicu uzkrājumus - izrakstus - maksājumus.

Nekas nepalīdz. Tas ir fakts, ka pēc atjauninājumiem uzkrājumu tabulas krasi mainījās. Es nesaprotu tehniskās detaļas, taču noteikti kaut kas nav kārtībā ar atjauninājumu.

Iedzīvotāju ienākuma nodokļa uzskaite 1s 8.3 grāmatvedībā 3.0

Svarīgs! Lai izvairītos no iespējamām kļūdām iedzīvotāju ienākuma nodoklī, programmā 1C 8.3 (8.2) sekojiet līdzi ienākumu reģistra ienākuma datuma un ienākuma gūšanas datuma atbilstībai nodokļu reģistrā, pretējā gadījumā programmā būs kļūdas, aprēķinot nodokli. . Reģistrējot jebkurus ienākumus programmā, tiek fiksēts faktiskās ienākumu saņemšanas datums.
Ienākumiem ar kodu 2000 šī ir uzkrāšanas mēneša pēdējā diena. Pārējiem ienākumiem tas ir plānotais maksājuma datums no atbilstošā uzkrājuma dokumenta.
Aprēķinot nodokli, programma analizē, no kādiem ienākumiem šis nodoklis tiek aprēķināts, un nosaka faktiskās ienākuma saņemšanas datumu, kas tiek ierakstīts nodokļu reģistrā. Kāpēc var būt atšķirība ienākumu saņemšanas datumā, kas tiek ņemts vērā ienākumu reģistrā un iedzīvotāju ienākuma nodokļa reģistrā? Apskatīsim to tālāk.

Aprēķinātais iedzīvotāju ienākuma nodoklis nav vienāds ar ieturēto

Iespējamās kļūdas starpnorēķinu dokumentos, izmantojot 1C 8.3 ZUP 3.0 piemēru Izmantojot 1C ZUP 3.0 programmas piemēru dokumentā “Atvaļinājums”, plānotais maksājuma datums ir 28.01.2016., bet dokumenta datumu noteiksim uz 01/ 30/2016, tas ir, vēlāk par plānoto maksājuma datumu. Paskatīsimies cauri. Mūsu nodokļu reģistrācijas reģistra ieraksts tika izveidots 2016. gada 30. janvārī.

Svarīgs

Ja atvaļinājuma naudu izmaksājam ātrāk par dokumenta datumu - 28.01.2016, kā plānots, aizpildām izziņu, redzam, ka ieturētais iedzīvotāju ienākuma nodoklis nav aizpildīts. Uz 2016. gada 28. janvāri aprēķinātā nodokļa nav. Attiecīgi, veicot šādu izziņu, ieturētais iedzīvotāju ienākuma nodoklis netiek reģistrēts.


Uzmanību

Ja ar dokumenta datumu viss kārtībā un tas ir agrāk par plānoto maksājuma datumu: Tad aizpildot izziņu arī viss būs kārtībā, tiks noteikts nodoklis. Veicot Izziņu, tas tiek ierakstīts kā ieturētais nodoklis.

Problēma ar iedzīvotāju ienākuma nodokli

Iespējamās kļūdas starpmaksājumu dokumentos, izmantojot 1C Accounting 3.0 piemēru Programmā 1C Accounting 3.0 viss ir vienāds. Svarīgs ir dokumenta datums. Apskatīsim dokumenta “Atvaļinājums” piemēru. Plānotais apmaksas datums ir 28.01.2016., un dokumenta datumu apzināti noliksim vēlāk, piemēram, 30.01.2016. Aprēķinātais nodoklis reģistrēts uz 30.01.2016.


Pēc maksājuma veikšanas, nevis Izraksta, proti, maksājums “Skaidras naudas izņemšana” vai debets no norēķinu konta agrāk par dokumenta “Atvaļinājums” datumu, ieturētais nodoklis netiek reģistrēts, noteikts un netiek ierakstīts Reģistrā. . Līdz ar to ir svarīgs dokumenta datums, ja nosakām to uz 28.01.2016 un pārplānojam skaidras naudas izsniegšanu, tad ir izveidots ieturētā iedzīvotāju ienākuma nodokļa ieraksts, viss ir iekļauts Reģistrā un tad arī tiks; iekļauts veidlapā 6-NDFL.

Iespējamās iedzīvotāju ienākuma nodokļa kļūdas 1s 8.3 un 8.2 - kā atrast un novērst

Šeit ir arī maksājuma datums, un, ja šis datums mainās, viss mainās automātiski. Automātiski mainās arī ienākumu saņemšanas datums par iedzīvotāju ienākuma nodokli.

Bet katram gadījumam pārbaudiet. Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli Tāpat, aprēķinot iedzīvotāju ienākuma nodokli, ir jāpievērš uzmanība nodokļa uzkrāšanas datumam. Tas attiecas uz trešās versijas programmām. Nodokļa uzkrāšanas datumam jābūt tieši pirms nodokļa ieturēšanas datuma.

Ja nodokļa ieturēšanas brīdī pats nodoklis nav uzkrāts, tad faktiski nav ko ieturēt. Svarīgs! Izsekošana programmā 1C: starpnorēķinu dokumentu datumi ir nodokļa uzkrāšanas datums, ja maksāšanas brīdī nodoklis nav uzkrāts, tas netiks ieturēts. Tas jo īpaši attiecas uz ienākumiem, kas nav algas, jo dokumenta datums ir fiksēts kā nodokļu uzkrāšanas datums. Tātad trešajā variantā svarīgs ir arī dokumenta “Atvaļinājums”, dokumenta “Slimības lapa” datums un citi dokumenti.

Bet, ja dokumenta galvenajā formā mainām datumu, datums automātiski mainās formā “Sīkāk par iedzīvotāju ienākuma nodokļa aprēķinu”. Šeit tas ir vienkāršāk, programma ZUP 3.0. viņa mums garantē, ka šie datumi sakritīs.

Vienīgais, ka pašreizējā programmas 1C laidienā dokumentā “Slimības atvaļinājums” ir kļūda. Ja tiek izmaksāts ar algu, un mēs mainām izmaksas datumu, tad šajā gadījumā ienākumu saņemšanas datums veidlapā “Sīkāk par iedzīvotāju ienākuma nodokļa aprēķināšanu” pats nemainās.


Šeit ir jāveic pārrēķins vai manuāli jāmaina datums formā “Sīkāk par iedzīvotāju ienākuma nodokļa aprēķinu”. Visos citos gadījumos iedzīvotāju ienākuma nodokļa uzskaites datumam būtu jāmainās automātiski maksājuma datumā. Bet katram gadījumam pārbaudiet šo brīdi, pārliecinieties, ka datumi sakrīt. Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli programmā 1C 8.3 Accounting 3.0 Tāpat kā programmā 1C Accounting 3.0, ir arī divi starpkontu dokumenti “Slimības lapa” un “Atvaļinājums”.
Iedzīvotāju ienākuma nodoklī viena rinda ar “mīnusu” datēts ar 2016. gada 29. janvāri, bet otra rinda ar “plusu” – 2016. gada 28. janvāris. 6 iedzīvotāju ienākuma nodoklī tiek pievienotas vēl divas rindu grupas no 100 līdz 140 Vienā viss ir otrādi, bet otrā - viss atkal tiek uzlādēts. Lai šāda situācija nerastos, rūpīgi sekojiet līdzi ienākumu saņemšanas datumam, kas tiks ierakstīts Ienākumu reģistrā, un ienākumu saņemšanas datumu, kas tiks ierakstīts Nodokļu reģistrā.

Viņiem jāsakrīt. Iespējamās kļūdas, aprēķinot iedzīvotāju ienākuma nodokli programmā 1C 8.3 ZUP 3.0. Programmā 1C ZUP 3.0 ienākumu saņemšanas datums tiek ņemts vērā arī divos reģistros: Ienākumu uzskaites reģistrā un Nodokļu uzskaites reģistrā.

Piemēram, apsveriet dokumentu “Atvaļinājums”. Ienākumu uzskaites reģistrā ir norādīts maksājuma datums no dokumenta galvenās formas. Un nodokļu reģistrācijas reģistrā - datums no veidlapas “Sīkāka informācija par iedzīvotāju ienākuma nodokļa aprēķinu”.

Šiem diviem datumiem ir jāsakrīt.
Šajā rakstā mēs aplūkosim darbu ar iedzīvotāju ienākuma nodokli 1C 8.3 Grāmatvedība 3.0 - no iestatījumiem līdz operācijām un atskaitēm. Saturs

  • 1 Programmas iestatījumi
    • 1.1 Nodokļu dati
    • 1.2. Algas noteikšana
  • 2 Iedzīvotāju ienākuma nodokļa uzskaites operācijas 1C
  • 3 Ziņošana
  • 4 Iedzīvotāju ienākuma nodokļa aprēķina pareizības pārbaude

Jebkuram uzņēmumam rentabilitāte ir ļoti svarīgs rādītājs. Uzturot ierakstus programmā “1C: Trade Management, ed. 10,3" varat izsekot bruto peļņai no preču pārdošanas. Bet dažās situācijās informācija par bruto peļņu var būt nepareiza nepareiza preču izmaksu aprēķina dēļ.

Šajā rakstā aplūkosim galvenās kļūdas, kas izraisa nepareizus izmaksu aprēķinus un kā tās novērst.

Preču norakstīšana “mīnus”

Visizplatītākā situācija, kas noved pie nepareiza izmaksu aprēķina, ir preču norakstīšana mīnusā. Tas ir, saskaņā ar programmu jums nav preces noliktavā, bet jūs to joprojām pārdodat.

Ja lietotāji dokumentus datubāzē ievadīs nekavējoties (t.i., ar šodienas datumu un pašreizējo laiku), viņi nevarēs pārdot preci par “mīnus” cenu – programma ziņos par kļūdu. Bet, ja lietotāji dokumentus datubāzē ievada neaktīvi (t.i., ar atpakaļejošu spēku), tad programma ļauj preces norakstīt mīnusā. Šajā gadījumā tiek izsniegti kļūdu ziņojumi, bet dokuments joprojām tiek iegrāmatots un preces tiek norakstītas.

Piezīme: norakstīšana kā mīnuss un atbilstošas ​​kļūdas var rasties arī grāmatojot dokumentu pašreizējā laikā, ja lietotājam ir tiesības pārsniegt atlikumus noliktavai un organizācijai. Šīs tiesības tiek piešķirtas, iestatot papildu lietotāja tiesības.

Dokumenta “Preču un pakalpojumu pārdošana” piemērs:

Izmantojot šīs kļūdas, programma mūs informē, ka preces tika norakstītas no noliktavas kā mīnusu, un programma nespēja aprēķināt pašizmaksu.

Bruto peļņas pārskatā mēs redzēsim nulles izmaksas par šo pārdošanu un attiecīgi 100% bruto peļņu.

Izvēlne: Pārskati – Pārdošana – Pārdošanas analīze – Bruto peļņa

Negatīvo bilanču rašanās iemesli var būt dažādi, taču visizplatītākie ir šādi:

  • Preču saņemšanas dokuments vēl nav ievadīts datu bāzē.
  • Preču saņemšanas dokuments tiek ievadīts datu bāzē, bet vēlākā laikā par preču pārdošanu.
  • Noliktavā ir pārpalikums vai neatbilstošas ​​preces.

Preču pārpalikuma vai nepareizas klasifikācijas gadījumā ir jāveic preču inventarizācija noliktavā un pārpalikums jākapitalizē. Pārpalikuma kapitalizācija jāveic pirms preču pārdošanas.

Ja kļūda radusies nepareizu dokumenta datumu dēļ, tad pietiek labot datumus un pārgrāmatot preču pārdošanas dokumentu.

Pārskatā “Preču saraksts noliktavās” varat novērtēt atlikušās preces un saprast kļūdas cēloni.

Izvēlne: Atskaites – inventārs (noliktava) – Preču saraksts noliktavās

Atskaites iestatījumos veidosim grupējumus pēc noliktavas, preces un kustības dokumenta. Mēs uzstādīsim arī karogu “Negatīvs sarkans” (lai redzētu negatīvos atlikumus) un izvēlēsimies vēlamo produktu:

Izveidota pārskata piemērs:

Šajā gadījumā redzam, ka preču pārdošana tika noformēta 3 stundas ātrāk nekā preces saņemšana noliktavā. Lai pareizi norakstītu, pietiek nomainīt pārdošanas laiku uz vēlāku un iegrāmatot dokumentu.

Ja dokumentu datumi ir dažādās dienās (piemēram, saņemšana ir 1. aprīlī, bet pārdošana veikta 31. martā), tad jums šī situācija ir jāizprot sīkāk. Iespējams, ka kāds no dokumentiem programmā ievadīts ar nepareizu datumu (piemēram, preču saņemšana un dokumenti par to bija datēti ar 30. martu, bet programmā ierakstīts nepareizs datums). Vai arī piegādātājs nosūtīja primāros dokumentus, kas izsniegti ar nepareizu datumu (piemēram, preces ieradās 30. martā, un piegādātājs nosūtīja dokumentus ar 1. aprīli) - šajā gadījumā būs nepieciešami jauni piegādātāja dokumenti.

Jebkurā gadījumā pārskatā galu galā nevajadzētu būt negatīviem atlikumiem, un preču saņemšana jāreģistrē agrāk nekā tās pārdošana.

Pārskata piemērs pēc labošanas:

Kļūdu labošana partijas uzskaitē. Izpilde pa partijām

Pat ja programma dokumentu aizpildīšanas laikā neuzrādīja nekādas kļūdas, kļūdas izmaksu aprēķinos joprojām var rasties, strādājot “ar atpakaļejošu spēku”. Tālāk ir sniegti daži kļūdainu situāciju piemēri.

Piezīme: izmaksu aprēķināšanas metode piemēros ir FIFO.

1. piemērs

Pēc tam iepirkumu menedžeris programmā reģistrēja kārtējo ledusskapju kvīti - 15.datumā par 10 500 rubļiem.

Rezultātā, ja iepirkumu menedžeris būtu laicīgi ievadījis visu informāciju programmā, tad, pārdodot ledusskapjus, būtu bijušas citas izmaksas (10 500 * 3 = 31 500 rubļi) un cita bruto peļņa (10 500 rubļu).

Bet ieviešanas dokuments jau ir izpildīts, visticamāk, neviens to nepārtulkos. Tas nozīmē, ka izmaksas var palikt nepareizas.

2. piemērs

21.dien atnāca ledusskapji - 10gab. Katrs 11 000 rubļu.

25. datumā pārvaldnieks pārdeva 3 ledusskapjus par cenu 14 000 rubļu. Tajā pašā laikā tika norakstīta pašizmaksa - 33 000 rubļu, un tika aprēķināta bruto peļņa - 9 000 rubļu.

Pēc tam iepirkumu menedžeris iegāja kvīts dokumentā un mainīja tajā ledusskapju cenas par 12 000 rubļu. (cena sākotnēji ievadīta nepareizi).

Rezultātā, ja iepirkumu menedžeris būtu laicīgi ievadījis visu informāciju programmā, tad, pārdodot ledusskapjus, būtu bijušas citas izmaksas (12 000 * 3 = 36 000 rubļu) un cita bruto peļņa (6 000 rubļu).

Tādu situāciju var būt daudz. Faktiski katra dokumenta izveidošana, modificēšana vai dzēšana ar atpakaļejošu spēku var padarīt kļūdainu pašizmaksu vēlāk izdotajos pārdošanas dokumentos.

Lai pārliecinātos, ka visi dokumenti ir pareizi apstrādāti un to izmaksas ir pareizi aprēķinātas, jums ir jāveic visu dokumentu secīga atkārtota apstrāde. Lai to izdarītu, varat izmantot divus mehānismus:

Vispārīgs platformas dokumentu pārpublicēšanas mehānisms

Izvēlne: Darbības – Dokumentu grāmatošana

Šis mehānisms ļaus mēneša laikā atkārtoti noformēt visus vajadzīgā veida dokumentus, taču tam ir neliels trūkums – dokumenti tiks noformēti neatkarīgi no tā, vai tas ir vajadzīgs vai nē. Galu galā pilnīgi iespējams, ka darbinieki nekādas darbības nav veikuši neatbilstoši. Un visu dokumentu aizpildīšana var aizņemt ilgu laiku.

Mehānisms programmas “1C: Tirdzniecības vadība” izpildei partijās, red. 10,3 collas

Mehānisma būtība ir tāda, ka programma atceras tā saukto “atbilstības robežu” - datumu, līdz kuram visi dokumenti tika operatīvi apstrādāti un nebija kļūdu. Ja dokuments tiek grāmatots ar atpakaļejošu datumu, programma pārvieto šo datumu uz šī dokumenta datumu. Tādējādi programma vienmēr zina, no kura datuma dokumentos var būt kļūdas. Mēneša beigās tiek uzsākta speciāla apstrāde “Post by batch”, kas secīgi grāmato visus pārdošanas dokumentus, kas sastādīti vēlāk par “atbilstības datumu”, un aprēķina tajos pašizmaksu.

Apskatīsim otrā mehānisma darbību, izmantojot pirmo piemēru.

Otrais saņemšanas dokuments, kas izdots ar atpakaļejošu datumu:

Pēc otrā kvīts dokumenta izveidošanas bruto peļņas pārskats palika nemainīgs:

Atvērsim apstrādi “Post by paches”.

Izvēlne: Dokumenti – Papildu – Grāmatošana pa partijām

Apstrādē redzam, ka ir aktuāla dokumentu secība uz 22. martu – otrās saņemšanas datumu, ievadīts neoperatīvi.

Noklikšķiniet uz pogas “Palaist”, un programma pārplānos visu preču pārdošanu, kas veiktas pēc 15. datuma.

Bruto peļņas pārskats pēc apstrādes:

Tagad pašizmaksas aprēķināšanā viss ir pareizi.

Piezīme: apstrādes laikā var tikt parādīti ziņojumi par preču trūkumu noliktavā, jo ar atpakaļejošu datumu viņi var ne tikai izveidot kvīti, bet arī to izdzēst vai atlikt uz vēlāku datumu. Katra šāda situācija ir jāapsver atsevišķi (kā aprakstīts iepriekš).

Lai programmā viss būtu pareizi izmaksu un peļņas aprēķināšanā, visus dokumentus vēlams ievadīt datu bāzē operatīvi (t.i., šodien un pašreizējais laiks). Taču nereti ir situācijas, kad nepieciešams dokuments ievadīt ar atpakaļejošu spēku, vai arī labot jau izveidoto dokumentu. Šādas situācijas var novest pie nepareizi aprēķinātām izmaksām un peļņas datubāzē.

Ja periodiski veicat partijas un arī atbildat uz visiem ziņojumiem par preču neesamību, pašizmaksa jūsu datubāzē vienmēr tiks aprēķināta pareizi. Tas nozīmē, ka jūs vienmēr redzēsiet pareizo informāciju par bruto peļņu no pārdošanas.

Dažkārt pamanāt, ka 1C nepareizi aprēķina, dara, izplata kaut ko, nepareizi aizpilda veidlapas utt. Es arī risinu šādas problēmas, lai gan tas maksā nedaudz vairāk. Atgādināšu, ka mana specializācija šodien ir 1C: Grāmatvedība. Bet tas nenozīmē, ka es jums nepalīdzēšu. Jāskatās, pirms izdara pārsteidzīgus secinājumus.

Galvenās priekšrocības

  • Jums nav katru reizi manuāli jālabo radušās kļūdas
  • Dažreiz tas ietaupa laiku
  • Jūsu pieprasījums vienmēr ir laipni gaidīts

Iespējas

Dokumentu modificēšana un izstrāde 1. gadījums. Konfigurācija "Maksājuma dokumenti" 1C. PVN dati tika aprēķināti un ievadīti nepareizi, ja PVN aprēķināts pēc aprēķina metodes, dokumentos RĒĶINS, RĒĶINS, RĒĶINS. Problēma tika pilnībā atrisināta. Pievienotas jaunas maksājumu dokumentu veidlapas: MAKSĀJUMA PIEPRASĪJUMS, MAKSĀJUMA RĪKOJUMS, IEKĀCIJA.. Lieta 2. “Grāmatvedības” konfigurācija. Drukājot rēķinu, ja preču skaits ir lielāks par 6 (vai 7 - neatceros), tad puse rēķina tiek drukāta vienā pusē, bet pārējās preču vienības tiek drukātas otrā pusē. lapa, kas bija neērti, jo jums ir jāapgriež lapa printerī. Es izlaboju šo problēmu — dokuments ir pilnībā izdrukāts vienā lapas pusē. Atjauninot uz jaunu programmas versiju, manis veiktās izmaiņas netika zaudētas. Dažas lietas rēķinā arī izcēlu treknrakstā pēc klienta pieprasījuma. Katalogu pārsūtīšana 1. gadījums. Ar mani vērsās viena persona ar lūgumu pārsūtīt preču un darbuzņēmēju katalogus no Tirdzniecības un noliktavas versijas 8.6 uz jauno versiju 9.2. Par ko? Pirmkārt, viņam bija jauna maksājumu karte, taču neviens nevarēja atjaunināt veco versiju (dažādi izdevumi saka, ka mēs jums piegādāsim Jaunu datu bāzi, un jūs tajā visu ievadiet manuāli). Otrkārt, viņam ir uzkrāti vairāk nekā 5 tūkstoši preču, no kurām lielākā daļa vairs nav vajadzīgas (sen tika pārdotas), un tās nevar izdzēst, jo tika izmantotas dokumentos (piemēram, izrakstot rēķinus). Jaunajā izdevumā to var izdarīt vismaz katru mēnesi. Tā kā programma ir licencēta, nekādu grūtību nebija. Papildus šiem direktorijiem tika pārsūtīti katalogi Bankas, Norēķinu konti un cita informācija, lai tā nebūtu jāievada atkārtoti. 2. gadījums. No konfigurācijas “Tirdzniecība un noliktava” es augšupielādēju datus konfigurācijā “Komplekss” (vairāk nekā 6 tūkstoši preču cenrādī). Jaunu atskaišu izstrāde