BSU apstrāde atiestatīja uzkrāšanas reģistrus. Uzkrāšanas reģistru (UF) atlikumu un kustību atiestatīšana

Mēs nolēmām kaut kā atjaunot kārtību UT versijas 11 konfigurācijā. Un tur... Preču atlikumi nesakrīt ar organizāciju bilancēm (tiek izmantotas vairākas organizācijas), un ar preču sūtījumiem tie nemaz nav tuvu un pat komisijas tirdzniecība tiek izmantota līdztekus parastajai tirdzniecībai. Īsāk sakot, viss ir tik novārtā, ka vieglāk sākt no nulles, BET... No nulles nevar sākt - ir saistība ar uzņēmuma grāmatvedību 3.0 (direktorijas, dokumenti), un tur jau ir iesniegta atskaite. Mēs nolēmām sakārtot lietas grāmatvedībā atsevišķi, un atsevišķi grāmatvedībā. Konkrēti UT mēs nolēmām: nullē visu, kas saistīts ar precēm (preces noliktavā, organizāciju preces, organizāciju preču sūtījumi, plus ar komisiju saistītie reģistri), pēc tam veidojam fiktīvu kvīti (arī par komisiju), un savstarpējos norēķinus koriģējam, koriģējot savstarpējos norēķinus. Sākumā sāku rakstīt apstrādi konkrētiem reģistriem, kamēr rakstīju, domāju apmēram tikpat laika uzrakstīt universālo, bet derētu visiem reģistriem, lai vēlāk nebūtu jāpārraksta desmit reizes. . Tam jābūt piemērotam arī Retail 2, Complex un citām pārvaldīto veidlapu konfigurācijām. Pārbaudīts uz UT11.

Kā izmantot. Vispirms manuāli izveidojam tukšu “reģistra korekcijas” dokumentu, iestatām datumu un laiku (es iestatīju 23:59:59 ceturkšņa beigās), reģistra atlikumi tiks nogādāti tieši šajā pozīcijā (dokumenta pozīcija), vispārīgi, no dokumenta mums ir vajadzīga tikai pozīcija un vajadzīga. Pēc tam mēs izvēlamies, kuri reģistri ir jānonullē, un noklikšķiniet uz “Ģenerēt”. Atveram korekciju, skatāmies, pārbaudām reģistrus izmantojot atskaites un/vai universālo atskaiti. Atlikumi ir slēgti visām dimensijām un visiem resursiem. Arī formā ir izlase pēc organizācijas un noliktavas (atmetums no oriģinālās versijas, bet strādā), citas izlases nepievienoju (tā kā man nemaz nevajadzēja), kam vajag, var pievieno pats, modulī viss ir skaidri rakstīts un nevis es sāku lietot jo, piemēram, ja veicat atlasi pēc organizācijas, tad reģistram “Organizāciju preces” atlase derēs, bet reģistram “ Preces noliktavās” tā nebūs (tāda mērījuma nav), tāpēc bez atlases noliku uz nulli.

Ir pagājis kāds laiks...

Ir izlaista jauna versija, tagad apstrāde ir iemācījusies (iepriekš deva kļūdu - tas ir, faktiski strādāja tikai ar bilances reģistriem) apgriezt kustības cirkulējošā akumulācijas reģistrā. Turklāt kustības ir apgrieztas, t.i. ja paskatās reģistrā, teiksim, “Pārdošana” UT11, tad pēc reversa izpārdošana vispār netiks rādīta, t.i. it kā pārdošanas nebūtu vispār - apgrozījums kopumā par periodu būs tukšs. Kārtējo reizi - izrādās, piemēram, mums bija izpārdošanas par periodu no 1.-30.janvārim, 31.datumā veicu reversu, pēc tam ja paskatīšos atskaitē no 1 līdz 30 - redzēšu izpārdošanas, no 31. līdz 31. 31 - es redzēšu apgrieztās kustības, no 1 līdz 31 - rādīs tukšu. Piemēram, es apvērsu “Kases” reģistra kustības UT11 un Retail 2.2, kad bija jāsakārto “Kase” (50 konts, kas zina).

Jā, aizmirsu pateikt, ir parādījies lauks "Sākuma datums" - tas tiek izmantots, lai iestatītu perioda sākuma datumu apgrozījuma reģistriem (atlikumiem, protams, tas neattiecas), dokumenta pozīcija "Reģistra korekcija" tiek izmantots kā perioda beigu datums (apgrozījuma reģistriem) - t.i. kā bilances reģistram (atlikumi tiek noņemti uz dokumenta pozīciju). Apgrozījuma reģistriem "Sākuma datums" var palikt tukšs - šajā gadījumā tas tiek uztverts kā agrākais datums, kāds var pastāvēt, un apgrozījuma reģistram tas nozīmēs, ka visas kustības no uzskaites sākuma līdz " Reģistra korekcija” dokumenti tiek apgriezti.

Labā ziņa – izmaksas punktos ir samazinājušās.

• Ātra un ērta atlikumu nulles noteikšana;
• Vienkāršas un uzlabotas saskarnes;
• Uzkrāšanas un uzskaites reģistru atbalsts(tostarp ar iespējotu un atspējotu korespondenci; ar un bez kontu plāna);
• Atbalsta lielāko daļu konfigurāciju;
• Spēja strādāt ar jebkuriem konfigurācijas reģistriem, ne tikai standarta;
• Elastīgi atlases iestatījumi(atlase pēc dimensijām, detaļām, resursiem, kā arī pēc to ligzdotajiem laukiem. Grupu “UN”, “OR”, “NOT” izmantošana. Pamatojoties uz ACS);
• Iespēja atiestatīt ne visu, bet tikai nepieciešamos resursus;
• Lauku aizpildīšana korr. konti uzskaites reģistram (apakškonts, ārpusbilances mērījumi un resursi), kā arī jebkādi rekvizīti ar izvēlētām vērtībām;
• Iespēja izvēlēties kārtošanas dokumenta veidu (ja konfigurācija ļauj pielāgot reģistru ar vairāku veidu dokumentiem);
• Iespēja ierakstīt kustības jaunā vai iepriekš izveidotā dokumentā;
• Vairāku režīmu atbalsts darbi:
  • Atiestatāms konts Dt (grāmatvedības reģistriem);
  • Nulles konts Kt (grāmatvedības reģistriem);
  • Pozitīvas resursu vērtības;
  • Negatīvās resursu vērtības.
• Darbs nestandarta konfigurācijās (ja tam pievieno standarta konfigurācijas pielāgošanas dokumentu (no atbalstīto saraksta));
• Elastīgs interfeiss: tiek parādīti tikai tie lauki, kas ir nepieciešami pašreizējā konfigurācijā atlasītajam reģistram;
• Savienojamība kā ārēja apstrāde.

Pārskats

Pēc noklusējuma apstrāde tiek atvērta vienkāršā saskarnē. Tas satur minimālu lauku skaitu un ļauj atiestatīt visu reģistru. Ja jums ir nepieciešami papildu iestatījumi, jums jānoklikšķina uz pogas “Iespējot papildu režīmu”.

Uzlabotā režīma saskarni var iedalīt vairākās daļās:

1. Gadījuma izvēles lauki.

Nolaižamajā sarakstā ar reģistru nosaukumiem ir iekļauti visi reģistri, izņemot apgrozības reģistrus (tiem nav atlikumu).

2. Korekcijas dokumenta iestatījumu lauki.

Atkarībā no situācijas daži no tiem var būt paslēpti.
Īpaši jāatzīmē lauks “Veikt labojumus dokumentā...”. Tajā varat izvēlēties vienu no kustību veidošanas veidiem:

• Visas kustības ar skatu "Ienākošais" (režīms uzkrāšanas reģistriem);
• Visas kustības ar skatu "Patēriņš" (režīms uzkrāšanas reģistriem);
• Atiestatāms konts Dt (grāmatvedības reģistriem). Korekcijas dokuments ģenerēs veidlapas transakcijas Dt<Счет>CT<КоррСчет> ;
• Nulles konts Kt (grāmatvedības reģistriem). Korekcijas dokuments ģenerēs veidlapas transakcijas Dt<КоррСчет>CT<Счет> ;
• Pozitīvas resursu vērtības (šis režīms ir noderīgs, piemēram, ja reģistrā nevar ierakstīt negatīvas summas);
• Negatīvās resursu vērtības (ja atiestatīšanas laikā ir jāsamazina apgrozījums).

3. Atiestatīt datuma un korekcijas dokumenta laukus.

Laukā "Atiestatīt atlikumus uz datumu" jānorāda datums un laiks, kurā tiks saņemti atiestatīšanas atlikumi. Saņemot pārpalikumus, kustība tiek aktivizēta pēdējā sekundē.
Atkarībā no korekcijas dokumenta veida būs pieejami lauki "Komentārs" un/vai "Organizācija". Šo lauku vērtības tiks pārsūtītas uz korekcijas dokumentu.

4. Grāmatzīmes “Konts un kor. konts”, “Detaļas”, “Resursi” un “Zīmējumi”.
Atkarībā no izvēlētā reģistra daži no tiem var būt paslēpti.

Ieslēgts cilne "Konts un korespondentkonts" atlasiet “Konts” (kas tiks atiestatīts uz nulli). Tāpat, ja nepieciešams, var izvēlēties “Korespondentkontu”, tā apakškontu, nebilances mērījumus un resursus. Šo lauku vērtības tiks ievietotas visos darījumos blakus “Atbilstošais konts”.

Ieslēgts Cilne "Detaļas". Jūs varat izvēlēties detaļu vērtības, kuras tiks aizstātas visās korekcijas dokumenta kustībās.

Ieslēgts Cilne "Resursi". jums ir jāatzīmē tie, kas ir jāatiestata (pēc noklusējuma ir atlasīti visi). Piemēram, varat atiestatīt tikai “Summas”, nemainot “Daudzums”.

Ieslēgts Cilne "Atlases". jūs varat izvēlēties nepieciešamos nosacījumus. Piemēram, ja nepieciešams atiestatīt ne visus atlikumus, bet tikai tos, kas attiecas uz konkrētu organizāciju. Vai tikai tiem, kuriem ir negatīvs atlikums.
Norādot atlasi, varat atlasīt ligzdotos laukus un grupas “UN”, “OR”, “NOT”.

Jebkurš lauks vai reģistrs var būt nepieejams, ja uz tiem nav tiesību vai tie ir atspējoti programmas iestatījumos (funkcionālās opcijas).

Lai uzzinātu, kuri korekcijas dokumenti “zāģēja” pašreizējā konfigurācijā, jānoklikšķina uz jautājuma zīmes, kas atrodas pa labi no lauka “Pielāgošanas dokuments”.

Saderība

Apstrāde galvenokārt paredzēta interfeisa vadītām sistēmām. Sistēmās, kas izstrādātas vecajā saskarnē, tas arī darbosies, taču ar dažiem ierobežojumiem. Sīkāka informācija 1. tabulā.

Jūs varat atiestatīt visus reģistrus, ko izmanto, lai veiktu kustības korekcijas dokumentos.

1. tabula. Konfigurācijas, kurās tika pārbaudīta apstrāde

Procedūra paredzēta bieziem un tieviem klientiem.
Kods ir atvērts.

Mēs nolēmām kaut kā atjaunot kārtību UT versijas 11 konfigurācijā. Un tur... Preču atlikumi nesakrīt ar organizāciju bilancēm (tiek izmantotas vairākas organizācijas), un ar preču sūtījumiem tie nemaz nav tuvu un pat komisijas tirdzniecība tiek izmantota līdztekus parastajai tirdzniecībai. Īsāk sakot, viss ir tik novārtā, ka vieglāk sākt no nulles, BET... No nulles nevar sākt - ir saistība ar uzņēmuma grāmatvedību 3.0 (direktorijas, dokumenti), un tur jau ir iesniegta atskaite. Mēs nolēmām sakārtot lietas grāmatvedībā atsevišķi, un atsevišķi grāmatvedībā. Konkrēti UT mēs nolēmām: nullē visu, kas saistīts ar precēm (preces noliktavā, organizāciju preces, organizāciju preču sūtījumi, plus ar komisiju saistītie reģistri), pēc tam veidojam fiktīvu kvīti (arī par komisiju), un savstarpējos norēķinus koriģējam, koriģējot savstarpējos norēķinus. Sākumā sāku rakstīt apstrādi konkrētiem reģistriem, kamēr rakstīju, domāju apmēram tikpat laika uzrakstīt universālo, bet derētu visiem reģistriem, lai vēlāk nebūtu jāpārraksta desmit reizes. . Tam jābūt piemērotam arī Retail 2, Complex un citām pārvaldīto veidlapu konfigurācijām. Pārbaudīts uz UT11.

Kā izmantot. Vispirms manuāli izveidojam tukšu “reģistra korekcijas” dokumentu, iestatām datumu un laiku (es iestatīju 23:59:59 ceturkšņa beigās), reģistra atlikumi tiks nogādāti tieši šajā pozīcijā (dokumenta pozīcija), vispārīgi, no dokumenta mums ir vajadzīga tikai pozīcija un vajadzīga. Pēc tam mēs izvēlamies, kuri reģistri ir jānonullē, un noklikšķiniet uz “Ģenerēt”. Atveram korekciju, skatāmies, pārbaudām reģistrus izmantojot atskaites un/vai universālo atskaiti. Atlikumi ir slēgti visām dimensijām un visiem resursiem. Arī formā ir izlase pēc organizācijas un noliktavas (atmetums no oriģinālās versijas, bet strādā), citas izlases nepievienoju (tā kā man nemaz nevajadzēja), kam vajag, var pievieno pats, modulī viss ir skaidri rakstīts un nevis es sāku lietot jo, piemēram, ja veicat atlasi pēc organizācijas, tad reģistram “Organizāciju preces” atlase derēs, bet reģistram “ Preces noliktavās” tā nebūs (tāda mērījuma nav), tāpēc bez atlases noliku uz nulli.

Ir pagājis kāds laiks...

Ir izlaista jauna versija, tagad apstrāde ir iemācījusies (iepriekš deva kļūdu - tas ir, faktiski strādāja tikai ar bilances reģistriem) apgriezt kustības cirkulējošā akumulācijas reģistrā. Turklāt kustības ir apgrieztas, t.i. ja paskatās reģistrā, teiksim, “Pārdošana” UT11, tad pēc reversa izpārdošana vispār netiks rādīta, t.i. it kā pārdošanas nebūtu vispār - apgrozījums kopumā par periodu būs tukšs. Kārtējo reizi - izrādās, piemēram, mums bija izpārdošanas par periodu no 1.-30.janvārim, 31.datumā veicu reversu, pēc tam ja paskatīšos atskaitē no 1 līdz 30 - redzēšu izpārdošanas, no 31. līdz 31. 31 - es redzēšu apgrieztās kustības, no 1 līdz 31 - rādīs tukšu. Piemēram, es apvērsu “Kases” reģistra kustības UT11 un Retail 2.2, kad bija jāsakārto “Kase” (50 konts, kas zina).

Jā, aizmirsu pateikt, ir parādījies lauks "Sākuma datums" - tas tiek izmantots, lai iestatītu perioda sākuma datumu apgrozījuma reģistriem (atlikumiem, protams, tas neattiecas), dokumenta pozīcija "Reģistra korekcija" tiek izmantots kā perioda beigu datums (apgrozījuma reģistriem) - t.i. kā bilances reģistram (atlikumi tiek noņemti uz dokumenta pozīciju). Apgrozījuma reģistriem "Sākuma datums" var palikt tukšs - šajā gadījumā tas tiek uztverts kā agrākais datums, kāds var pastāvēt, un apgrozījuma reģistram tas nozīmēs, ka visas kustības no uzskaites sākuma līdz " Reģistra korekcija” dokumenti tiek apgriezti.

Labā ziņa – izmaksas punktos ir samazinājušās.

Mācīšanās strādāt ar reģistriem (1C: Grāmatvedība 8.3, izdevums 3.0)

Cienījamie lasītāji, šajā nodarbībā es vēlos pieskarties ārkārtīgi svarīgai tēmai, strādājot 1C: Grāmatvedība 8.3 - Reģistri.

Tūlīt es jums parādīšu ar nelielu piemēru, kāpēc tas ir tik svarīgi.

Ļaujiet mums izveidot algu sarakstu par janvāri:

Februāra sākumā no kases izveidojam algas lapiņu un nospiežam pogu “Aizpildīt”:

Un mēs iegūstam sekojošo:

Bet janvārim:

• Uzkrājums 50 000 rubļu
• Iedzīvotāju ienākuma nodoklis 6500 rubļu
• Kopā maksājami 43 500 rubļu

Kur iezagās kļūda? Kaut kas nogāja greizi? Vai tiešām tagad vienmēr ir iespējams manuāli ievadīt maksājamo summu?

Pieredzējis grāmatvedis nekavējoties izveidos bilanci kontam 70:

Un viņš būs vēl vairāk apmulsis, jo saskaņā ar ziņojumu joprojām ir jāmaksā tie paši 43 500! Un no kurienes radās papildu 5000 rubļu?

Turklāt šāda situācija (ar jebkādiem aprēķiniem) var notikt gan “troikā”, gan “divos”.

Šodien mēģināšu pacelt noslēpumainības plīvuru – kāpēc reizēm programma uzvedas tik dīvaini. Es jums pastāstīšu, kā šādos gadījumos atrast un novērst kļūdu. Raksta beigās mēs sapratīsim, no kurienes nāk šie 5000 rubļu.

Tātad, ejam!

Mācīšanās redzēt reģistrus

Ievietojot dokumentus, 1C:Accounting 8 veic ierakstus grāmatvedības kontos (poga DtKt jebkuram dokumentam):

Uz šo darījumu pamata tiek veidoti visi grāmatvedības pārskati: Konta analīze, Konta karte, Bilance...

Bet ir milzīgs datu slānis, ko programma raksta paralēli ierakstiem un tiek izmantota visam pārējam: KUDIR aizpildīšanai, pirkumu un pārdošanas grāmatiņai, regulētai atskaitei... maksājamās algas, beidzot

Kā jūs droši vien jau uzminējāt, šo slāni sauc reģistros, lūk, viņš ir:

Tagad es neiedziļināšos pašu reģistru aprakstos, lai jūs vēl vairāk nemulsinātu.

Apskatīsim tuvāk reģistru "Maksājamās algas" - tieši tas ir jēga, lai atrisinātu mūsu problēmu ar papildu 5000:

Mēs redzam divus ierakstus šajā reģistrā, kas izdarīti ierašanās, tas ir, plus. Ritinot pa labi no ekrāna, pirmajā rindā redzēsim maksājamo summu “-6500”, bet otrajā – “50 000”.

Atlikums šajā reģistrā -6 500 + 50 000 ir vienāds ar 43 500, kas jāiekļauj dokumentā “Izraksts par maksājumu no kases”, kad noklikšķinām uz pogas “Aizpildīt”.

Es atkārtoju vēlreiz - maksājuma izrakstā mūsu algas parādi darbiniekam nosaka nevis pēc konta 70, bet gan pēc reģistra “Izmaksājamās algas”.

Izrādās, ka mēs zinām, ka izmaksājamā alga tiek aizpildīta, vadoties pēc šī reģistra, bet pat redzot reģistra ierakstus nevar saprast, kas par vainu.

Visticamāk, mēs neredzam kopainu (varbūt šim reģistram ir citi ieraksti) un kāds reģistra analīzes rīks, līdzīgi kā grāmatvedības pārskati, ierosina sevi.

Mācīšanās analizēt reģistrus

Un ir tāds rīks, to sauc par " Universāls ziņojums".

Dodieties uz sadaļu "Pārskati" un atlasiet "Universālais pārskats":

Izvēlieties reģistra veidu “Uzkrāšanas reģistrs”, reģistru “Izmaksājamā alga” un noklikšķiniet uz pogas “Izveidot”:

Tas izrādījās ne pārāk informatīvs:

Tas ir tāpēc, ka ir nepieciešama iepriekšēja pārskata iestatīšana, noklikšķiniet uz pogas "Rādīt iestatījumus" un cilnē "Grupēšana" pievienojiet lauku "Darbinieks".

Cilnē “Atlases” mēs veicam atlasi savai organizācijai:

Noklikšķiniet uz pogas "Ģenerēt":

Tagad tas ir interesantāk. Mēs redzam, ka atlikums, kas jāmaksā mūsu darbiniekam, ir tie paši 48 500 rubļu!

Atkal dodieties uz pārskata iestatījumiem un cilnē "Rādītāji" pievienojiet jaunu lauku "Ierakstītājs".

Mēs ģenerējam pārskatu vēlreiz:

Tagad skaidri redzams, ka 2014. gada 31. decembrī operācijas rezultātā (acīmredzot ieejot atlikumos) parādījās 5000.

Un mums ir vai nu jāmaina šī darbība, vai arī manuāli jāpielāgo reģistrs “Izmaksājamās algas” un jāslēdz šie 5000 rubļu, piemēram, 2015. gada 31. decembrī.

Ejam otro ceļu. Tātad, mūsu uzdevums ir pārliecināties, ka 2016. gada sākumā “Izmaksājamās algas” uzskaitē darbiniekam nav parādu.

Tas tiek darīts ar manuālu darbību.

Mācīšanās pielāgot reģistrus

Dodieties uz sadaļu "Operācijas" un atlasiet "Manuāli ievadītās darbības":

2015. gada beigās izveidojam jaunu darbību:

Izvēlnē "Vairāk" atlasiet "Atlasīt reģistrus...":

Norādiet reģistru "Samaksātā alga" un noklikšķiniet uz Labi:

Dodieties uz parādīto cilni Reģistrs un veiciet izdevumus 5000 rubļu apmērā:

To darot, mēs it kā no reģistra atskaitām 5000 rubļu uz vienu darbinieku, lai līdz 2016. gada sākumam sasniegtu nulli.

Mēs veicam operāciju un atjaunojam universālo ziņojumu:

Viss izdevās! Mēs redzam, ka mūsu manuālā darbība, kas datēta ar 2015. gada 31. decembri, noveda līdz nullei, un alga, kas jāmaksā pēc uzkrāšanas, ir vienāda ar paredzētajiem 43 500.

Apbrīnojami. Un tagad mēs to pārbaudīsim maksājuma pārskatā.

Bet vispirms es vēlos vērst jūsu uzmanību uz vēl vienu svarīgu punktu:

Lūdzu, ņemiet vērā, ka atlikumi sākumā un beigās grupai “Darbinieks” parāda muļķības. Tā nav kļūda, tā ir nianse, kas jāņem vērā saistībā ar 1c arhitektūras iezīmēm.

Ja mums ir nepieciešami atlikumi pēc darbinieku grupēšanas, vispirms no iestatījumiem ir jānoņem indikators “Reģistrs”, ko pievienojām.