Ang mekanismo ng kumplikadong pana-panahong mga kalkulasyon ay nagpapahintulot sa iyo na ipatupad ang iba't ibang mga modelo ng payroll. Ang pagpapatakbo ng mekanismo ay batay sa dalawang bahagi.

Sa isang banda, ang mekanismo para sa kumplikadong pana-panahong mga kalkulasyon ay naglalaman ng mga tool para sa paglalarawan ng iba't ibang uri ng mga kalkulasyon na gagamitin sa solusyon ng aplikasyon. Halimbawa, ito ay maaaring mga uri ng pagbabayad gaya ng suweldo, sustento, multa, atbp. Bilang karagdagan sa aktwal na paglalarawan ng mga ganitong uri ng mga kalkulasyon, posibleng magtakda ng mga panuntunan ayon sa kung saan ang ilang mga uri ng mga kalkulasyon ay makakaimpluwensya sa iba pang mga uri ng mga kalkulasyon.

Sa kabilang banda, ang mekanismong ito ay nagbibigay ng kakayahang mag-imbak ng intermediate data na ginagamit upang magsagawa ng mga kalkulasyon at ang mga huling resulta ng mga kalkulasyon.

Ang pagpapatakbo ng mekanismo para sa kumplikadong pana-panahong mga kalkulasyon ay sinisiguro ng dalawang bagay ng solusyon sa aplikasyon:

Plano ng mga uri ng pagkalkula at rehistro ng Pagkalkula.

Ang plano ng mga uri ng pagkalkula ay ginagamit upang ilarawan ang mga uri ng pagkalkula at ang kanilang impluwensya sa isa't isa. Sa isang solusyon sa aplikasyon, maaaring mayroong isang di-makatwirang bilang ng mga plano para sa mga uri ng pagkalkula, depende sa ipinatupad na modelo ng accounting:

Ang rehistro ng pagkalkula ay ginagamit upang mag-imbak ng mga talaan tungkol sa ilang mga uri ng mga kalkulasyon na kailangang isagawa, pati na rin upang mag-imbak ng intermediate na data at ang mga resulta ng mga kalkulasyon mismo. Ang isang solusyon sa aplikasyon ay maaaring maglaman ng ilang mga rehistro ng pagkalkula na idinisenyo upang ipakita ang data mula sa isang partikular na seksyon ng accounting:

Plano ng mga uri ng pagkalkula

Istraktura ng plano ng mga uri ng pagkalkula
Ang plano ng mga uri ng pagkalkula ay isang listahan ng mga uri ng pagkalkula. Ang bawat uri ng pagkalkula ay may code, pangalan at isang hanay ng mga detalye na naglalaman ng karagdagang impormasyon tungkol sa ganitong uri ng pagkalkula:

Halimbawa, maaaring ganito ang hitsura ng isang plano para sa mga uri ng pagkalkula Mga Pangunahing Akrual ng Mga Organisasyon:

Ang paglikha at pag-edit ng mga uri ng pagkalkula ay maaaring isagawa kapwa ng developer (mga paunang natukoy na uri ng pagkalkula) at ng user habang nagtatrabaho sa solusyon ng application. Gayunpaman, hindi maaaring tanggalin ng user ang mga uri ng pagkalkula na ginawa ng developer.

Ang mga uri ng pagkalkula na ginawa sa isang plan ng uri ng pagkalkula ay maaaring makaimpluwensya sa isa't isa. Sinusuportahan ng system ang dalawang uri ng naturang impluwensya: dependence sa base period at displacement sa validity period.

Para sa bawat uri ng kalkulasyon, maaari mong tukuyin ang isang listahan ng mga uri ng pagkalkula kung saan ito aasa para sa batayang panahon, at kung saan papalitan ito para sa panahon ng bisa.

Halimbawa, ang uri ng pagkalkula ng alimony ay maaaring depende sa base period sa mga sumusunod na uri ng pagkalkula:

At ang uri ng pagkalkula Salary ay maaaring mapalitan ng uri ng pagkalkula Absenteeism:

Bilang karagdagan sa mga dependency na ito, ang tinatawag na nangungunang mga uri ng pagkalkula ay maaaring tukuyin para sa isang uri ng pagkalkula - ang mga kung saan ito ay hindi direktang umaasa, ngunit maaaring makaimpluwensya dito sa pamamagitan ng iba pang mga uri ng mga kalkulasyon.

Mga form ng plano ng mga uri ng pagkalkula
Upang matingnan at mabago ng user ang data na nakapaloob sa plano ng mga uri ng pagkalkula, sinusuportahan ng system ang ilang mga anyo ng pagtatanghal nito. Ang sistema ay maaaring awtomatikong bumuo ng lahat ng kinakailangang mga form; Kasama nito, may pagkakataon ang developer na lumikha ng sarili niyang mga form, na gagamitin ng system sa halip na mga default na form:

Upang tingnan ang mga uri ng pagkalkula, gamitin ang form ng listahan. Pinapayagan ka nitong mag-navigate sa listahan, magdagdag, markahan para sa pagtanggal, at tanggalin ang mga uri ng pagkalkula. Binibigyang-daan ka ng form ng listahan na pagbukud-bukurin at piliin ang ipinapakitang impormasyon ayon sa ilang pamantayan:

Upang tingnan at baguhin ang data para sa mga indibidwal na uri ng pagkalkula, gamitin ang form ng uri ng pagkalkula. Bilang panuntunan, nagpapakita ito ng data sa isang form na madaling maunawaan at i-edit:

Bilang karagdagan sa dalawang form na ito para sa mga uri ng pagkalkula, sinusuportahan ang isang form para sa pagpili ng mga partikular na uri ng pagkalkula mula sa listahan. Karaniwang naglalaman ito ng pinakamababang hanay ng impormasyong kinakailangan upang pumili ng isa o ibang uri ng pagkalkula.

Rehistro ng pagkalkula

Ang istraktura ng rehistro ng pagkalkula
Ang impormasyon sa rehistro ng pagkalkula ay naka-imbak sa anyo ng mga talaan, ang bawat isa ay naglalaman ng mga halaga ng pagsukat at kaukulang mga halaga ng mapagkukunan.

Ang mga dimensyon ng rehistro ay naglalarawan sa mga seksyon kung saan nakaimbak ang impormasyon, at ang mga mapagkukunan sa pagrehistro ay direktang naglalaman ng nakaimbak na impormasyon. Halimbawa, para sa rehistro ng kalkulasyon Mga Pangunahing Akrual ng mga Empleyado ng Mga Organisasyon, na may sumusunod na istraktura:

Ang mga talaan na nakaimbak sa database ay magiging ganito:

Kaugnayan sa plano ng mga uri ng pagkalkula
Ang rehistro ng pagkalkula ay nauugnay sa isa sa mga plano ng uri ng pagkalkula na umiiral sa solusyon sa aplikasyon. Ang koneksyon na ito ay nagiging sanhi ng bawat talaan ng rehistro na magkaroon ng field ng Uri ng Pagkalkula, salamat sa kung aling mga mekanismo ng rehistro ang maaaring masubaybayan ang magkaparehong impluwensya ng mga talaan ng pagkalkula sa bawat isa.

Periodicity

Ang rehistro ng pagkalkula ay nag-iimbak ng data hindi lamang sa mga tuntunin ng nilikha na mga sukat, kundi pati na rin sa mga tuntunin ng oras. Ito ang dahilan ng pagkakaroon ng isa pang kinakailangang field para sa bawat entry sa rehistro ng pagkalkula - Panahon ng Bisa. Kapag lumilikha ng isang rehistro ng pagkalkula, maaaring tukuyin ng developer ang pinakamababang dalas kung saan ang mga entry ay ipapasok sa rehistro:

Subordination sa registrar
Ang isang pagbabago sa estado ng rehistro ng pagkalkula ay karaniwang nangyayari kapag ang isang dokumento ay nai-post. Samakatuwid, ang bawat entry ng rehistro ay nauugnay sa isang tiyak na dokumento - isang registrar at ang numero ng linya ng dokumentong ito. Ang pagdaragdag ng mga entry sa rehistro, pagpapalit ng mga ito at pagtanggal ng mga ito ay posible lamang nang sabay-sabay para sa lahat ng mga entry na nauugnay sa isang dokumento.

Relasyon sa Timeline
Ang rehistro ng pagkalkula ay maaaring maiugnay sa isang iskedyul ng oras. Ang timeline ay isang rehistro ng impormasyon na naglalaman ng time diagram ng source data na kasama sa mga kalkulasyon. Ang mga sukat ng iskedyul na ito ay maaaring, halimbawa, ang iskedyul at petsa ng trabaho, at ang mapagkukunan ay maaaring ang bilang ng mga oras ng pagtatrabaho sa petsang ito. Pagkatapos ay magiging posible na iugnay ang isang entry sa rehistro ng pagkalkula sa isang tiyak na iskedyul ng trabaho at sa hinaharap, gamit ang built-in na wika, kumuha ng impormasyon tungkol sa bilang ng mga oras ng pagtatrabaho na kinakailangan upang maisagawa ang mga kalkulasyon.

Halimbawa, isang timeline na may sumusunod na istraktura:

Muling pagkalkula
Ang rehistro ng pagkalkula ay maaaring magsama ng mga espesyal na bagay - Mga Muling Pagkalkula:

Sa mga bagay na ito, ang system ay mag-iimbak ng impormasyon tungkol sa kung aling mga entry sa rehistro ng pagkalkula ang nawala ang kanilang kaugnayan at napapailalim sa muling pagkalkula bilang resulta ng pagpapatakbo ng mga mekanismo ng dependency para sa batayang panahon at pagpapaalis para sa panahon ng bisa.

Kakaiba ng mga talaan
Ang sistema ay nagbibigay ng kontrol sa pagiging natatangi ng mga talaan na nakaimbak sa rehistro ng pagkalkula. Samakatuwid, ang rehistro ng pagkalkula ay hindi maaaring maglaman ng dalawang mga entry na nauugnay sa parehong linya ng parehong dokumento.

Mga mekanismo na ipinatupad ng rehistro ng pagkalkula

Preemption ayon sa panahon ng bisa
Ang mekanismo ng validity period preemption ay nagbibigay-daan sa iyong kalkulahin ang aktwal na validity period ng isang settlement register entry batay sa pagsusuri ng iba pang mga entry na nakapaloob sa register.

Sa pangkalahatan, ang isang settlement register entry ay naglalaman ng dalawang petsa na tumutukoy sa panahon kung kailan ang entry ay wasto. Ang panahong ito ay tinatawag na entry validity period. Gayunpaman, kung ang uri ng pagkalkula kung saan nauugnay ang isang naibigay na entry ay maaaring palitan ng isa pang uri ng pagkalkula, kung gayon ang panahon ng bisa ng ibinigay na entry ay isang "hiniling" na panahon lamang, iyon ay, "gusto naming maging wasto ang entry sa panahong ito. .” Sa katotohanan, ang aktwal na panahon ng bisa ng talaang ito ay matutukoy lamang pagkatapos suriin ang lahat ng mga talaan ng mga uri ng pagkalkula na pumapalit sa ganitong uri ng pagkalkula ayon sa panahon ng bisa. Ang aktwal na panahon ng bisa ay isang hanay ng mga panahon na isang subset ng orihinal na panahon ng bisa ng entry. Kung walang nakitang record na pumapalit sa ibinigay sa mga tuntunin ng validity period, ang aktwal na validity period ng record na ito ay magiging katumbas ng validity period nito. Ang isa pang matinding kaso ng panghabambuhay na pagpapalayas ay kapag ang isang naibigay na rekord ay ganap na pinatalsik ng ibang mga rekord. Sa kasong ito, walang aktwal na panahon ng bisa para sa entry.

Ang bawat entry sa rehistro ng settlement ay naglalaman ng uri ng settlement kung saan ito nauugnay. Upang matukoy kung aling mga entry ang dapat pumalit sa isang naibigay na entry ayon sa panahon ng bisa, ang rehistro ng payroll ay gumagamit ng isang link sa plano ng mga uri ng payroll, na naglalarawan sa magkaparehong impluwensya ng mga uri ng payroll sa isa't isa. Ang paggamit ng relasyong ito ay nagbibigay-daan sa rehistro ng payroll na matukoy ang aktwal na panahon ng bisa ng bawat entry.

Dependency ayon sa base period
Ang mekanismo ng base period dependence ay nagpapahintulot sa iyo na makuha ang batayang halaga para sa isang entry sa rehistro ng pagkalkula batay sa pagsusuri ng iba pang mga entry na nilalaman sa rehistro.

Ang base ay ang numeric na halaga na dapat gamitin upang kalkulahin ang resulta ng isang naibigay na tala. Kinakalkula ang base sa pamamagitan ng pagsusuri sa mga resulta ng pagkalkula ng iba pang mga entry kung saan nakasalalay ang entry na ito para sa base period. Kaya, sa pangkalahatang kaso, ang isang entry sa rehistro ng pagkalkula ay naglalaman ng dalawang petsa na tumutukoy sa panahon kung saan kinakailangan upang pag-aralan ang mga talaan ng mga uri ng pagkalkula kung saan ang ganitong uri ng pagkalkula ay nakasalalay sa base - ang batayang panahon. Ang paggamit ng link sa plano ng uri ng pagkalkula ay nagbibigay-daan sa rehistro ng pagkalkula na matukoy ang mga uri ng pagkalkula kung saan nakasalalay ang isang partikular na uri ng pagkalkula para sa batayang panahon.

Sinusuportahan ng rehistro ng pagkalkula ang dalawang uri ng pag-asa sa batayang panahon:

• pag-asa sa panahon ng bisa;
• depende sa panahon ng pagpaparehistro.

Sa kaso ng pag-asa sa panahon ng bisa, upang makuha ang base, pipiliin ang mga talaang iyon kung saan matatagpuan ang intersection ng aktwal na panahon ng bisa ng mga ito sa batayang panahon ng talaan na ito. Ang halaga ng base na makukuha mula sa isang partikular na nakakaimpluwensyang tala ay karaniwang hindi katumbas ng resulta na nilalaman ng talaan na ito. Ang base ay kakalkulahin sa proporsyon sa bahagi ng aktwal na panahon ng nakakaimpluwensyang talaan na magkakapatong sa tinukoy na panahon ng base. Gagamitin nito ang data ng tsart na nauugnay sa tala na ito.

Kung sakaling umasa sa panahon ng pagpaparehistro, upang makuha ang base, pipiliin ang mga resulta ng pagkalkula ng mga talaan na nasa base period ng record na ito ayon sa halaga ng kanilang field na "Panahon ng Pagpaparehistro".

Ang pinaka-kumplikadong bersyon ng pag-asa sa batayang panahon ay ang kaso kapag ang property na “Validity period ay ang base period” ay nakatakda para sa uri ng pagkalkula ng record na ito. Ang pag-aari na ito ay nangangahulugan na ang batayang panahon ng talaang ito ay gagamitin hindi ang batayang panahon, na tinukoy sa kaukulang mga patlang ng talaan, ngunit ang aktwal na panahon ng bisa ng talaan, na nakuha bilang resulta ng pagpapatakbo ng mekanismo ng pagpapaalis para sa ang panahon ng bisa at kung saan, sa pangkalahatang kaso, ay isang set ng ilang mga panahon.

Pagbuo ng mga talaan ng muling pagkalkula
Ang mekanismo para sa pagbuo ng mga talaan ng muling pagkalkula ay sinusubaybayan ang katotohanan na ang mga talaan ay lumilitaw sa rehistro na nakakaapekto sa resulta ng pagkalkula ng mga umiiral na mga tala. Ang posibilidad ng mga bagong talaan na nakakaimpluwensya sa mga umiiral na ay natutukoy bilang isang resulta ng isang pagsusuri ng magkaparehong impluwensya ng mga uri ng pagkalkula at batay sa pagpapatakbo ng mga mekanismo ng pag-alis para sa panahon ng bisa at ang pag-asa para sa batayang panahon.

Ang resulta ng mekanismo para sa pagbuo ng mga talaan ng muling pagkalkula ay isang hanay ng mga talaan ng muling pagkalkula na naglalaman ng impormasyon tungkol sa kung aling mga entry sa rehistro ang dapat muling kalkulahin (muling kalkulahin).

Mga form ng rehistro ng pagkalkula
Upang makita ng gumagamit ang data na nilalaman sa rehistro ng pagkalkula, sinusuportahan ng system ang isang form para sa pagpapakita ng rehistro ng pagkalkula - isang form ng listahan. Pinapayagan ka nitong pagbukud-bukurin at piliin ang ipinapakitang impormasyon ayon sa ilang pamantayan:

Maaaring awtomatikong buuin ng system ang form na ito. Kasama nito, may pagkakataon ang developer na lumikha ng sarili niyang mga form na gagamitin ng system sa halip na ang default na form, kasama ang isang record set form na nagbibigay-daan sa iyong magdagdag, magbago at magtanggal ng mga entry sa rehistro ng pagkalkula.

Pag-andar ng pagpaparehistro ng pagkalkula
Ang pangunahing pag-andar na ibinibigay ng rehistro ng pagkalkula sa developer ay:

• pagpili ng mga tala sa isang naibigay na pagitan ayon sa tinukoy na pamantayan;
• pagpili ng mga talaan ng registrar;
• pagkuha ng batayang halaga para sa mga entry sa rehistro na nakakatugon sa tinukoy na pagpili;
• pagkuha ng data ng iskedyul para sa mga entry sa pagpaparehistro na nakakatugon sa isang naibigay na pagpili;
• pagkuha ng data sa mga rekord na napapailalim sa muling pagkalkula;
• pagbabasa, pagbabago, at pagsulat ng isang set ng mga tala sa isang rehistro.

Pag-aaral na magtrabaho kasama ang mga rehistro (1C: Accounting 8.3, edisyon 3.0)

2016-12-08T13:50:45+00:00

Minamahal na mga mambabasa, sa araling ito nais kong hawakan ang isang napakahalagang paksa kapag nagtatrabaho sa 1C: Accounting 8.3 - Nagrerehistro.

Ipapakita ko kaagad sa iyo ang isang maliit na halimbawa kung bakit ito napakahalaga.

Magkaroon tayo ng payroll para sa Enero:

Sa simula ng Pebrero, gumawa kami ng payroll slip mula sa cash register at i-click ang “Fill” button:

At nakukuha namin ang sumusunod:

Ngunit para sa Enero:

• Accrual ng 50,000 rubles
• Buwis sa personal na kita 6,500 rubles
• Kabuuang babayaran 43,500 rubles

Saan napunta ang error? May nangyaring mali? Posible bang palaging ilagay ang halaga na babayaran nang manu-mano ngayon?

Ang isang bihasang accountant ay gagawa kaagad ng balanse para sa account 70:

At lalo siyang magugulat, dahil ayon sa ulat, ang parehong 43,500 ay dapat bayaran pa rin! At saan nagmula ang dagdag na 5,000 rubles?

Bukod dito, ang ganitong sitwasyon (na may anumang mga kalkulasyon) ay maaaring mangyari kapwa sa "troika" at sa "dalawa".

Ngayon ay susubukan kong iangat ang belo ng lihim - bakit kung minsan ang programa ay kumikilos nang kakaiba. Sasabihin ko sa iyo kung paano hanapin at ayusin ang error sa mga ganitong kaso. Sa pagtatapos ng artikulo ay malalaman natin kung saan nanggaling ang 5,000 rubles na ito.

Kaya, tayo na!

Pag-aaral upang makita ang mga rehistro

Kapag nagpo-post ng mga dokumento, ang 1C:Accounting 8 ay gumagawa ng mga entry sa accounting account (ang DtKt button para sa anumang dokumento):

Ito ay batay sa mga transaksyong ito na ang lahat ng mga ulat sa accounting ay binuo: Pagsusuri ng account, Account card, Balance sheet...

Ngunit mayroong isang malaking layer ng data na isinulat ng programa na kahanay sa mga pag-post at ginagamit para sa lahat ng iba pa: pagpuno sa KUDIR, isang libro ng mga pagbili at pagbebenta, kinokontrol na pag-uulat... sahod na babayaran, sa wakas

Tulad ng malamang na nahulaan mo na, ang layer na ito ay tinatawag nagrerehistro, narito siya:

Ngayon ay hindi na ako pupunta sa mga detalye ng paglalarawan ng mga rehistro mismo, upang hindi ka mas malito.

Sasabihin ko lang na napakahalaga para sa atin na unti-unting matutong "makita" ang mga paggalaw sa mga rehistrong ito upang mas maunawaan at, kung kinakailangan, iwasto ang pag-uugali ng programa.

Tingnan natin ang rehistro ng "Babayarang suweldo" - ito ang makatuwiran para sa paglutas ng aming problema sa dagdag na 5,000:

Nakikita namin ang dalawang entry sa rehistrong ito na ginawa sa pagdating, iyon ay, bilang karagdagan. Kung mag-scroll tayo sa kanan ng screen, makikita natin sa unang linya ang halagang babayaran "-6,500", at sa pangalawang "50,000".

Ang balanse sa rehistrong ito -6,500 + 50,000 ay katumbas ng 43,500, na dapat isama sa dokumentong "Pahayag para sa pagbabayad mula sa cash register" kapag nag-click kami sa pindutan ng "Punan".

Ulitin ko muli - ang pahayag ng pagbabayad ay tumutukoy sa aming mga atraso sa sahod sa empleyado hindi ayon sa account 70, ngunit ayon sa rehistro ng "Suweldo na babayaran".

Alam pala natin na ang sahod na babayaran ay pinupunan base sa rehistrong ito, ngunit kahit na makita ang mga entry sa rehistro ay hindi natin maintindihan kung ano ang mali.

Malamang, hindi namin nakikita ang buong larawan (marahil may iba pang mga tala para sa rehistrong ito) at ang ilang tool para sa pagsusuri ng rehistro, katulad ng mga ulat sa accounting, ay nagmumungkahi mismo.

Pag-aaral na pag-aralan ang mga rehistro

At mayroong ganoong tool, ito ay tinatawag na " Pangkalahatang ulat".

Pumunta sa seksyong "Mga Ulat" at piliin ang "Pangkalahatang ulat":

Piliin ang uri ng rehistro na "Accumulation Register", ang "Salary Payable" na rehistro at i-click ang "Bumuo" na buton:

Ito ay naging hindi masyadong nagbibigay-kaalaman:

Ito ay dahil kinakailangan ang paunang pag-setup ng ulat, i-click ang button na "Ipakita ang mga setting" at sa tab na "Pagpapangkat" idagdag ang field na "Empleyado":

Sa tab na "Mga Pinili" gumawa kami ng pagpili para sa aming organisasyon:

I-click ang button na "Bumuo":

Ngayon ito ay mas kawili-wili. Nakikita namin ang balanse na babayaran sa aming empleyado ay pareho 48,500 rubles!

Pumunta muli sa mga setting ng ulat at magdagdag ng bagong field na "Recorder" sa tab na "Mga Tagapagpahiwatig":

Binubuo namin muli ang ulat:

Ngayon ay malinaw nating nakikita na 5,000 ang lumitaw bilang resulta ng operasyon (tila pagpasok ng mga balanse) noong Disyembre 31, 2014.

At kailangan nating baguhin ang operasyong ito o manu-manong ayusin ang rehistrong "Babayarang suweldo" at isara ang 5,000 rubles na ito, halimbawa, noong Disyembre 31, 2015.

Pumunta tayo sa pangalawang paraan. Kaya, ang aming gawain ay upang matiyak na sa simula ng 2016 ay walang utang sa empleyado sa rehistro ng "Mga Salary Payable".

Ginagawa ito sa pamamagitan ng manu-manong operasyon.

Pag-aaral upang ayusin ang mga rehistro

Pumunta sa seksyong "Mga Operasyon" at piliin ang "Mga operasyong ipinasok nang manu-mano":

Lumilikha kami ng bagong operasyon sa katapusan ng 2015:

Mula sa menu na "Higit pa", piliin ang "Pumili ng mga rehistro...":

Tukuyin ang rehistro ng "Sahod na babayaran" at i-click ang OK:

Pumunta sa tab na rehistro na lilitaw at gumawa ng gastos na 5,000 rubles:

Sa paggawa nito, kami, kumbaga, ay nagbabawas ng 5,000 rubles mula sa rehistro bawat empleyado upang maabot ang zero sa simula ng 2016.

Isinasagawa namin ang operasyon at muling buuin ang unibersal na ulat:

Lahat ay nagtagumpay! Nakita namin na ang aming manual operation na may petsang Disyembre 31, 2015 ay nagdala ng balanse sa zero at ang suweldo na babayaran pagkatapos ng accrual ay katumbas ng inaasahang 43,500.

Kahanga-hanga. At ngayon ay susuriin namin ito sa pahayag ng pagbabayad.

Ngunit gusto ko munang ituon ang iyong pansin sa isa pang mahalagang punto:

Pakitandaan na ang mga balanse sa simula at sa dulo para sa pangkat na "Empleyado" ay nagpapakita ng kalokohan. Ito ay hindi isang pagkakamali, ito ay isang nuance na kailangang isaalang-alang na may kaugnayan sa mga tampok na arkitektura ng 1c.

Tandaan. Kung sakaling ang isang unibersal na ulat ay ipinapakita na may detalye hanggang sa dokumento (registrar), ang mga balanse sa pamamagitan ng pagpapangkat ay magpapakita ng walang kapararakan.

Kung kailangan namin ng mga balanse ayon sa pagpapangkat ng empleyado, kailangan muna naming alisin ang indicator na "Registrar" na idinagdag namin mula sa mga setting.

Maraming mga programmer ng 1C ang hindi kailanman nakatagpo ng bahagi ng "Pagkalkula" sa kanilang pagsasanay, samakatuwid, kapag kailangan nilang kumuha ng mga pagsusulit para sa isang Espesyalista sa Platform 8.0, kung saan ang bawat gawain ay naglalaman ng isang gawain sa mga kumplikadong pana-panahong mga kalkulasyon, ang mga paghihirap ay lumitaw, pangunahin ang mga paghihirap sa pag-unawa.

Subukan nating alamin ang bahaging ito sa 8.0. Sa halip na lutasin ang iba't ibang problema sa pagkalkula, subukan nating maunawaan ang bahaging ito upang malutas natin ang anumang problema sa pagkalkula. Pagkatapos pag-aralan ang manwal na ito, mauunawaan mo kung paano inaayos at gumagana ang mga rehistro ng pagkalkula.

Halimbawa, gagamitin namin ang frame configuration na naka-install sa panahon ng mga pagsusulit.

Sa totoo lang, matagal kong sinubukang malaman kung ano pa ang kailangan ng mga kalkulasyon, ngunit hindi ko ito maisip, kaya isaalang-alang natin ang problema sa pagkalkula ng suweldo.

Ano ang mga kalkulasyon

Karaniwan, ang panghuling produkto ng payroll ay isang hanay ng mga entry sa rehistro ng payroll ng form:

Empleado	Panahon	Uri ng pagkalkula	Resulta	Data	Komento
Pagsukat	Opisyal	Opisyal			Props

Ang halaga sa hanay ng "Data" ay sumasalamin sa batayang suweldo ng empleyado (ayon sa kontrata sa pagtatrabaho), ngunit ang halagang ito ay maaaring dagdagan ng mga bonus, bawasan ng mga multa at pagliban, atbp., samakatuwid, ang aktwal na halagang babayaran ay ipinasok pagkatapos ang pagkalkula sa column na "Resulta". Ito ang kalkulasyon. Ang halaga sa column na "Resource" para sa isang empleyado ay ang suweldong dapat bayaran sa kanya.

Kaya, ang rehistro ng kalkulasyon ay mahalagang isang hanay ng mga talaan, na katulad ng istraktura sa negotiable na rehistro ng akumulasyon. Para lamang makapagsagawa ng mga kumplikadong kalkulasyon, ang mga karagdagang setting ay tinukoy para dito, na pagkatapos ay nagbibigay-daan sa iyo na bumuo ng maraming mga virtual na talahanayan para sa rehistro ng pagkalkula, bagaman, sa esensya, ang rehistro na ito ay isang hanay lamang ng mga talaan na ipinahiwatig sa figure.

Ang bawat entry sa settlement register ay nauugnay sa isang partikular na uri ng settlement at tagal ng panahon.

Mga uri ng kalkulasyon

Ang bawat talaan ng mga uri ng pagkalkula ay may katangian ng serbisyo - uri ng pagkalkula.

Ang isang uri ng pagkalkula ay maaaring isipin bilang isang elemento ng isang espesyal na sangguniang aklat tulad ng "Plano ng mga uri ng mga kalkulasyon" - mayroon din itong mga detalye, mga bahagi ng tabular, paunang natukoy at mga elementong nilikha ng gumagamit. Maaaring may ilang ganoong "mga direktoryo" sa system.

Halimbawa, gumawa tayo ng plano para sa mga uri ng pagkalkula Pangunahin at sa loob nito ay paunang natukoy na mga uri ng pagkalkula suweldo, bonus, kawalan, paglalakbay sa negosyo.

Ginagamit ang mga uri ng pagkalkula upang ipakita ang impluwensya ng mga entry sa rehistro ng pagkalkula sa bawat isa. Ngunit sa madaling sabi pinag-uusapan nila ang impluwensya ng mga uri ng pagkalkula sa bawat isa:

Uri ng pagkalkula	Paglalarawan	Halimbawa
Sa pamamagitan ng base period	Ang resulta ng pagkalkula ng dependent period ay depende sa resulta ng base period. Kung ang resulta ng batayang panahon ay nagbabago, ang resulta ng umaasa na panahon ay dapat na muling kalkulahin.	Ang bonus ay depende sa base period na suweldo.
Pagpupunas ayon sa period	Ang validity period ng dependent period ay pumapalit sa validity period ng base period, kaya ang base period ay may aktwal na	Ang absenteeism ay nakakaapekto sa aktwal na panahon ng suweldo.
Mga nangungunang kalkulasyon	Ang pagkalkula ay nakasalalay sa nangungunang pagkalkula, ngunit hindi direkta ngunit hindi direkta, i.e. Ang pagkalkula A ay nakasalalay sa pangunahing pagkalkula B, at ang pagkalkula B ay nakasalalay sa pangunahing pagkalkula B, samakatuwid ang A ay hindi direktang nakasalalay sa B, i.e. Ang A ay nakasalalay sa nangungunang pagkalkula B. Sa katunayan, kapag ang pagkalkula C ay nagbago, ang B ay maaaring magbago at samakatuwid A ay maaaring magbago Ang system ay hindi awtomatikong sinusubaybayan ang mga kumplikadong dependency, kaya kailangan mong ipahiwatig kung aling mga kalkulasyon ang nangunguna.	Ang bonus ay depende sa base ng suweldo, ngunit din hindi direktang nakasalalay sa pagliban.

Dahil sa impluwensyang ito, nahahati sa apat na panahon ang validity period ng settlement register entry:

Panahon	Paglalarawan
Panahon ng pagpaparehistro	Sa anong panahon naitala ang kaganapan, i.e. kadalasan kapag may ipinasok na dokumento.
Ang bisa	Sa anong panahon gumagana ang kaganapan, i.e. sa anong panahon nabibilang ang kaganapan.
Batayang panahon	Makahulugan lamang para sa mga panahon na may base period - inilalarawan ang pagitan ng base period.
Aktwal na panahon ng bisa	Kung ang validity period ay napalitan ng iba pang uri ng kalkulasyon, ang aktwal na validity period ay binubuo ng ilang panahon kung kailan ang ganitong uri ng kalkulasyon ay aktwal na may bisa.

Ang panahon ng pagpaparehistro ay tinukoy ng isang numero - ang simula ng panahon, na tumutugma sa dalas ng rehistro ng pagkalkula. Kahit na magtakda tayo ng ibang petsa sa larangan ng serbisyong ito, papalitan pa rin ito ng simula ng panahon. Ang natitirang mga panahon ay tinukoy ng dalawang mga patlang - ang simula at ang katapusan ng panahon Ang aktwal na panahon ng bisa ay isang set ng mga panahon, dahil maaari itong binubuo ng ilang mga pagitan ng petsa.

Mga Time Chart

Ang sistema ay may kakayahang mag-link ng data mula sa mga rehistro ng pagkalkula sa mga time chart upang ang bilang ng mga oras ng pagtatrabaho ay maaaring makuha para sa anumang panahon.

Ang timeline ay isang simpleng rehistro ng impormasyon kung saan ang isang dimensyon ay nag-iimbak ng isang petsa, ang isa pa ay nauugnay sa isang dimensyon sa pamamagitan ng isang rehistro ng pagkalkula, at ang isa sa mga mapagkukunan ay ginagamit upang subaybayan ang oras.

Isang dimensyon na na nauugnay sa settlement register ay karaniwang dala ibig sabihin ay "uri ng graph".

petsa	Uri ng tsart	Ibig sabihin
11.01.05 Biyernes	Limang araw
11.01.05 Biyernes	Anim na araw
12.01.05 Sab	Limang araw
12.01.05 Sab	Anim na araw

Bakit gagamitin ang dimensyon ng petsa sa halip na ang periodic information register? Napakasimple ng lahat - kung sa Biyernes, Enero 11, mayroon tayong 8 oras ng trabaho sa loob ng limang araw, hindi ito nangangahulugan na sa susunod na araw ay magkakaroon muli tayo ng 8 oras ng pagtatrabaho. Ngunit kung gumamit kami ng pana-panahong rehistro, ang halaga para sa susunod na araw ay kukunin mula sa nakaraang araw sa kawalan ng mga talaan.

Kaya, ang pagkakaroon ng isang tiyak na panahon (aktwal na aksyon, pagpaparehistro, batayang panahon, atbp.) maaari naming awtomatikong makuha ang bilang ng mga oras para sa panahong ito ayon sa iskedyul.

Muling pagkalkula

Ang muling pagkalkula ay medyo nakapagpapaalaala sa isang hangganan ng pagkakasunud-sunod. Dahil mayroon tayong dependent na mga kalkulasyon, kapag binabago ang kanilang base at nangungunang mga kalkulasyon, dapat tandaan ng system na dapat nating kalkulahin muli ang mga umaasa na kalkulasyon.

Ito ay para sa recalculations.

Kung kalkulahin natin ang mga batayang talaan, mapapansin ng system sa mga alokasyon na kailangan nating kalkulahin ang mga nakadependeng tala. Sa sandaling kalkulahin namin ang mga umaasa na talaan, malilinaw ang mga alokasyon.

Sa esensya, ang mga muling pagkalkula ay isang listahan ng mga entry sa rehistro ng pagkalkula na kailangang muling kalkulahin.

Kung hindi ka nagpasok ng anumang mga sukat sa mga muling pagkalkula, pagkatapos ay kapag nagbago ang mga pangunahing kalkulasyon, ang lahat ng mga umaasa na tala ay idaragdag sa listahan ng muling pagkalkula.

Kung gagawin namin ang dimensyon na "Empleyado" sa muling pagkalkula, pagkatapos ay kapag binago ang pangunahing kalkulasyon para sa isang empleyado, ang mga umaasa na talaan para lamang sa empleyadong ito ay idaragdag sa mga muling pagkalkula.

Praktikal na gawain

Sapat na teorya. Subukan nating pag-aralan ang mga detalye sa pagsasanay. Isaalang-alang natin ang pagsasaayos ng frame bilang batayan.

Pagbubuo ng problema:

Hayaan ang bonus na itakda bilang isang nakapirming porsyento ng suweldo (binawasan ang pagliban at mga allowance sa paglalakbay).

Hayaang mabayaran ang mga allowance sa paglalakbay sa dobleng suweldo + isang nakapirming halaga ng mga pagbabayad para sa bawat araw ng biyahe.

Hayaang singilin ang empleyado ng multa sa halagang kalahati ng suweldo para sa panahon ng pagliban para sa pagliban.

Pag-unlad:

Paunang pagsasanay

Gumawa tayo ng bagong plano para sa mga uri ng pagkalkula na "Pangunahin".

Tukuyin natin ang mga uri ng mga kalkulasyon at ang mga dependency sa pagitan ng mga ito:

	Basic	Palipat-lipat	Mga nagtatanghal
suweldo		Absenteeism, Business trip
premyo		Absenteeism, Business trip	Salary, Absenteeism, Business trip
Business trip
pagliban

Idagdag natin ang mga ganitong uri ng kalkulasyon sa plano ng mga uri ng pagkalkula na "Pangunahin" at itakda ang mga dependency sa mga katangian ng mga uri ng pagkalkula ayon sa talahanayan.

Sa rehistro ng pagkalkula ng suweldo, gagawa kami ng dimensyon na "Empleyado" ng uri ng "Mga Indibidwal" - upang ang rehistro ay magkaroon ng seksyon ng analytics para sa mga empleyado.

Ang configuration ay naglalaman na ng "Payroll" na dokumento.

Mayroon itong dalawang petsa sa header - "petsa" at "panahon ng pagpaparehistro", pati na rin ang dalawang petsa na "petsa ng pagsisimula" at "petsa ng pagtatapos" sa bawat linya.

Nauunawaan na ang petsa ay ang petsa kung kailan isinagawa ang dokumento, ang panahon ng pagpaparehistro ay nagpapahiwatig kung aling buwan namin binibilang ang suweldo, at ang mga petsa sa bawat linya ay naglalarawan sa panahon ng bisa ng bawat uri ng pagkalkula.

Idagdag natin ang paunang setting ng attribute na "Data" sa module ng dokumento - ilalagay natin ang panimulang suweldo, itatakda ang panahon ng pagpaparehistro, panahon ng bisa at batayang panahon dito.

Ang module ng dokumento ay magiging ganito:

Para sa Sa bawat isa TechStringList Mula sa Ikot ng Listahan

// magrehistro ng Mga Pagkalkula

Movement = Movements .Pagkalkula.Idagdag();

Paggalaw .Storno= Mali;

Paggalaw .Sa idCalculation = TechStringList.CalculationType;

Paggalaw .PeriodActionsStart= Simula ng Araw ( TechStringList.StartDate);

Paggalaw .PeriodActionEnd= EndDay();

Paggalaw .Panahon ng pagpaparehistro = Panahon ng Pagpaparehistro;

Paggalaw .BasicPeriodStart= Simula ng Araw ( TechStringList.StartDate);

Paggalaw .BasePeriodEnd= EndDay ( TechStringList. Petsa ng Pagtatapos);

Paggalaw .Empleado = TechStringList.Employee;

Paggalaw .Iskedyul = TechStringList.Graph;

Paggalaw .Resulta = 0;

Paggalaw .Data = TechStringList.Size;

EndCycle ;

Ang Reversal attribute ay kailangan para baligtarin ang mga entry (katulad ng minus sign).

Ipinapahiwatig namin ang uri ng pagkalkula, at itinakda ang mga petsa sa simula at pagtatapos ng araw. Siyempre, ang base period ay maaaring ipasok lamang para sa mga uri ng pagkalkula na nakasalalay sa base, at ang Data ay maaari lamang ipasok para sa suweldo, ngunit lahat ay gumagana sa ganoong paraan.

Ipe-date namin ang lahat ng mga dokumento sa 01/20/2003, ang panahon ng pagpaparehistro ay itatakda sa 01/02/2003 (partikular kong ipinapahiwatig hindi ang data ng simula at pagtatapos, hindi ito mahalaga dito, gayon pa man, kapag nagre-record sa Panahon ng Pagpaparehistro na-convert sa simula ng panahon 01/01/2003). Ginagamit namin ang Enero 2003 dahil natapos ang mga iskedyul ng trabaho para sa panahong ito.

Gumawa tayo ng recalculation na "Recalculation" at idagdag dito ang "Employee" na dimensyon na nauugnay sa "Employee" na dimensyon.

Naglalaro ng Recalculations.

Para maglaro, buksan ang request console - processing " CustomRequest» sa isang frame configuration. Gumawa tayo ng bagong query gamit ang query constructor at magdagdag ng virtual table doon Recalculations, ang text ng kahilingan ay magiging ganito:

PUMILI

CalculationsRecalculation.Tungkol sa Recalculation object,

CalculationsRecalculation.Sa Calculation ID,

Pagkalkula ng Muling Pagkalkula Mula sa empleyado

MULA SA

Rehistro ng pagkalkula PAANO Mga PagkalkulaRecalculations

Bumuo tayo ng tatlong dokumento - magbabayad muna tayo ng suweldo sa mga empleyadong A at B. Nagtatrabaho ang Employee A mula Enero 1 hanggang 31, nagtatrabaho si B mula Enero 1 hanggang 20. Ang pangalawa ay magtatalaga ng bonus sa empleyado B para sa panahon mula Enero 1 hanggang 31, ang pangatlo ay magtatalaga ng pagliban sa empleyado A mula Enero 20 hanggang 25.

Pinaglalaruan namin ang Actual validity period.

Gumawa tayo ng bagong query - sa pagkakataong ito ay magdaragdag tayo ng data ng talahanayan dito Mga Rehistro ng Pagkalkula.

Gumawa tayo ng kahilingan at tingnan na ang panahon ng suweldo ng empleyado A ay nahahati sa dalawang yugto - mula Enero 1 hanggang 19 at mula Enero 26 hanggang 31. Sana maintindihan mo na ang panahon ay nahahati sa dalawa, dahil... napalitan ng suweldo ang pagliban.

Sa tingin ko ang mga mekanismo ng pagpapatakbo ng rehistro ng pagkalkula ay nagiging mas malinaw sa harap ng ating mga mata.

Pag-aralan natin ang mga graph.

Ngayon subukan nating kalkulahin ang suweldo batay sa suweldo ng empleyado.

Gumawa tayo ng bagong query para sa rehistro ng pagkalkula gamit ang isang virtual na talahanayan Mga Rehistro ng Pagkalkula. Maaari kang magtakda ng parameter para sa virtual na talahanayan na ito - isang kundisyon para sa pagpili ng mga tala, halimbawa Employee=&SelectEmployee At Uri ng Pagkalkula=&Uri ng Pagkalkula At Graph=&ViewGraphic.

Magtakda tayo ng mga partikular na empleyado, mga uri ng kalkulasyon at iskedyul sa mga parameter ng kahilingan at tingnan kung ilang oras ang resulta.

Kolum ng resulta	Ibig sabihin
ValuePeriodAction	Para sa anong panahon ng bisa sa mga oras ang pagpasok sa rehistro.
ValueActualPeriodAction	Ilang oras talaga nagtrabaho ang empleyado?
ValueBasePeriod	Para sa suweldo ay hindi makatuwiran, para sa mga bonus - ang bilang ng mga oras ng pagtatrabaho sa base period.
Panahon ng Pagpaparehistro ng Halaga	Ilang oras ng trabaho ang mayroon sa panahon ng pagpaparehistro (buwan ng Enero)

Ang bagay na Recalculation ay ginagamit upang mag-imbak ng impormasyon tungkol sa kung saan ang rehistro ng pagkalkula ay nagtatala ng mga resulta ng pagkalkula (mga mapagkukunan) na kailangang muling kalkulahin. Ito ay isang configuration object na nasa ilalim ng rehistro ng pagkalkula. Ang pangangailangan na muling kalkulahin ang mga mapagkukunan ay maaaring lumitaw dahil sa isang hindi tamang pagkakasunud-sunod ng pag-input ng dokumento ng gumagamit (retroactive na pagpasok ng mga dokumento), na humahantong sa pangangailangan na muling kalkulahin ang mga resulta ng pagkalkula ng mga talaan na nakasalalay sa mga resulta ng pagkalkula ng iba pang mga talaan na ipinasok sa sistema mamaya.

Mga setting ng object ng muling pagkalkula

Ang impormasyon tungkol sa mga rekord na nangangailangan ng muling pagkalkula ay maaaring maimbak sa iba't ibang detalye.

Ang mga talaan ng alokasyon ay naglalaman ng mga paunang natukoy na mga patlang:

• Recalculation object – isang link sa registrar na ang mga resulta ng pagkalkula ay kailangang baguhin;
• Uri ng pagkalkula – isang link sa uri ng pagkalkula mula sa plano ng mga uri ng pagkalkula na itinalaga sa rehistro na nagmamay-ari ng bagay na Recalculation.

Kaya, sa pinakamababa, ang impormasyon tungkol sa mga muling pagkalkula ay nakaimbak nang tumpak sa registrar (dokumento) at uri ng pagkalkula.

Upang mas tumpak na matukoy ang mga hindi napapanahon na mga entry sa rehistro ng settlement, maaari kang maglagay ng mga sukat ng alokasyon. Papayagan ka nitong paliitin ang listahan ng mga talaan na nangangailangan ng muling pagkalkula.

Tingnan natin ang isang halimbawa.

Kung ang rehistro ng pagkalkula ay nag-iimbak ng data sa naipon na pangunahing suweldo ng mga empleyado ng organisasyon at, sa gayon, ang rehistro ng pagkalkula ay may dimensyon na "Empleyado", kung gayon ang muling pagkalkula ay maaari ding magkaroon ng dimensyon na "Empleyado". Ito ay hahantong sa katotohanan na ang mga talaan ng muling pagkalkula ay mangangahulugan ng pangangailangan na muling kalkulahin ang mga entry sa rehistro na kabilang sa isang partikular na registrar, may isang tiyak na uri ng pagkalkula at naglalaman ng isang link sa isang partikular na empleyado.

Ang talahanayan ng conversion ay maaaring awtomatikong punan ng system batay sa mga setting na ginawa sa panahon ng pagsasaayos. Awtomatikong pagsubaybay sa mga talaan kung saan kailangan ng rebisyon ng resulta ang pangunahing layunin ng bagay sa muling pagkalkula.

Ang mga dimensyon ng alokasyon ay isa sa mga tool na nagbibigay-daan sa iyong i-configure itong awtomatikong pagpuno ng alokasyon.

Ginagawa ito gamit ang mga katangian ng dimensyon ng alokasyon:

• Dimensyon ng rehistro - isang link sa dimensyon ng rehistro ng pagkalkula ng "magulang" kung saan isinailalim ang muling pagkalkula.
• Nangungunang data ng rehistro - mga link sa mga sukat at mga detalye ng nangungunang mga rehistro ng pagkalkula.

Upang ilarawan ang mga kakaibang katangian ng pag-set up ng mga sukat ng muling pagkalkula, sasang-ayon kami sa mga sumusunod na tuntunin:

• Ang pangunahing rehistro ay ang rehistro ng pagkalkula kung saan ang recalculation ay subordinated at kung saan ito "sinusubaybayan" ang kaugnayan ng mga resulta.
• Ang mga nangungunang rehistro ay mga rehistro ng pagkalkula na ang mga entry ay nakakaapekto sa resulta ng pagkalkula ng mga pangunahing entry sa rehistro.

Kung ang sistema ay mayroon nang mga pangunahing rekord ng rehistro, kung gayon ang anumang pagbabago sa komposisyon ng nangungunang mga talaan ng rehistro ay dapat humantong sa paglitaw ng mga talaan ng muling pagkalkula. Ang mga recalculation entries na ito ay magse-signal ng pangangailangan na muling kalkulahin ang isa o isa pang set ng pangunahing register entries.

Upang ilarawan nang eksakto kung anong mga pagbabago sa nangungunang mga entry sa rehistro ang hahantong sa paglitaw ng mga muling pagkalkula, ginagamit ang mga sukat ng muling pagkalkula. Upang tukuyin ang pangangailangan na muling kalkulahin ang mga talaan para sa parehong empleyado kung saan ang nangungunang mga talaan ng rehistro ay ipinasok (binago), gawin ang sumusunod. Ang isang link sa dimensyon ng "Empleyado" ng pangunahing rehistro ay inilalagay sa property na "Dimensyon ng Pagrehistro", at ang mga link sa dimensyon ng "Empleyado" ng lahat ng nangungunang mga rehistro ay inilalagay sa property na "Nangungunang Data ng Pagrehistro". Sa setup na ito, kung sakaling magkaroon ng anumang pagbabago sa komposisyon ng nangungunang mga talaan ng rehistro (ibig sabihin, kapag nagsusulat ng kaukulang hanay ng mga talaan), ang mga sumusunod ay mangyayari:

• Nasuri ang isang hanay ng mga nangungunang talaan ng rehistro (sabihin nating ang hanay ng mga talaan ay naglalaman ng mga tala para sa empleyadong si Ivanov na may tiyak na panahon ng bisa (halimbawa, Marso)
• Ang pangunahing rehistro ay awtomatikong hihilingin
• Kung naglalaman na ito ng mga rekord, ayon kay Ivanov, at ang kanilang resulta ay posibleng nakasalalay sa mga talaan ng nangungunang rehistro (kung ano ang ibig sabihin ng "potensyal na nakasalalay ..." ay tatalakayin sa ibaba), kung gayon ang mga linya na may sumusunod na data ay ilalagay sa muling pagkalkula:

Sa kasong ito, ang mga row ay ilalagay lamang kung ang mga naturang row ay wala pa sa conversion table.

Dapat tandaan na ang hitsura ng mga entry sa muling pagkalkula ay hindi nangangahulugan ng anumang mga pagbabago nang direkta sa pangunahing rehistro. Ang mga talaan ng muling pagkalkula ay walang iba kundi isang senyales na ibinibigay ng system. At kung paano eksaktong tumugon sa signal na ito tungkol sa pangangailangan na muling kalkulahin ang mga entry sa rehistro ay nakasalalay sa nag-develop ng isang partikular na solusyon. Tatalakayin natin ang mga halimbawa ng pagproseso ng mga talaan ng muling pagkalkula sa ibang mga publikasyon.

Mga setting ng plano ng uri ng pagkalkula na nauugnay sa mga alokasyon

Ang pag-asa ng ilang mga entry sa rehistro sa iba ay binuo sa pamamagitan ng mga setting ng mga plano para sa mga uri ng pagkalkula. Ang mga sumusunod na konsepto ay ginagamit para dito:

• Variant ng pag-asa sa base - pag-aari ng plano ng mga uri ng pagkalkula;
• Mga pangunahing plano ng mga uri ng pagkalkula - pag-aari ng plano ng mga uri ng pagkalkula;
• Mga nangungunang uri ng pagkalkula - pag-aari ng uri ng pagkalkula;
• Base period - mga detalye ng entry sa rehistro ng pagkalkula;
• Panahon ng bisa - mga detalye ng entry sa rehistro ng pagkalkula;
• Panahon ng pagpaparehistro - mga detalye ng entry sa rehistro ng pagkalkula.

Sabihin nating ang pangunahing rehistro ng pagkalkula ay itinalaga ang "Pangunahing" plano ng uri ng pagkalkula, at ang nangungunang rehistro ay itinalaga ang "Katulong" na plano ng uri ng pagkalkula. Pagkatapos ay kailangang itakda ng pangunahing plano ng mga uri ng pagkalkula ang mga sumusunod na katangian ng pangkat ng ari-arian na "Pagkalkula":
Pagdepende sa base – “sa panahon ng bisa” o “sa panahon ng pagpaparehistro”;
Mga pangunahing plano para sa mga uri ng pagkalkula - plano para sa mga uri ng pagkalkula "Katulong".

Nangangahulugan ito na ang pangunahing rehistro ng pagkalkula, na kumikilos ayon sa "Pangunahing" plano ng uri ng pagkalkula, ay nakasalalay sa mga rehistro kung saan itinalaga ang "Katulong" na uri ng plano sa pagkalkula (i.e. sa aming kaso, ang nangungunang rehistro ng pagkalkula) at sa parehong oras ang mga entry Ang pangunahing rehistro ay nakasalalay sa mga master record ayon sa panahon ng bisa o sa panahon ng pagpaparehistro.

Kapag nagse-set up ng isang plano para sa mga uri ng pagkalkula na "Pangunahin", ang mga uri ng pagkalkula nito (halimbawa, ang uri ng pagkalkula na "Karagdagang allowance") ay dapat na itakda sa listahan ng mga nangungunang uri ng pagkalkula para sa mga uri ng pagkalkula ng plano na "Auxiliary" (halimbawa, ang mga uri ng pagkalkula "Personal surcharge" at "Buwanang surcharge"). Nangangahulugan ito na ang mga resulta ng pagkalkula ng mga pangunahing entry sa rehistro na may uri ng pagkalkula na "Karagdagang allowance" ay nakasalalay sa mga resulta ng nangungunang mga entry sa rehistro na may mga uri ng pagkalkula na "Personal na surcharge" at "Buwanang surcharge" at dapat na muling kalkulahin kung sakaling anumang pagbabago (hitsura o pagtanggal).

Kasabay nito, upang malaman kung aling mga talaan ang kailangang muling kalkulahin, ihahambing ng system ang mga talaan ng mga nangungunang at pangunahing mga rehistro ng pagkalkula:

• sa pamamagitan ng uri ng pagkalkula,
• kapag ang panahon ng bisa (o panahon ng pagpaparehistro) ng nangungunang mga talaan ng rehistro ay nasa loob ng batayang panahon ng mga pangunahing talaan ng rehistro
• at ng dimensyon ng Empleyado, na inilarawan sa itaas.

Papayagan ka ng materyal na ito na gumawa ng mga setting na hahantong sa awtomatikong pagpuno ng mga talahanayan ng conversion. Para sa ilang gawain, maaaring hindi sapat ang awtomatikong pagkumpleto. Sa ganitong mga kaso, dapat kang bumuo ng mga talaan ng alokasyon gamit ang built-in na wika ng system. Ito ay tinalakay nang detalyado sa seksyong "Pagpasok ng mga alokasyon gamit ang built-in na wika".

Ang isa sa mga gawaing nalutas gamit ang mga rehistro ng pagkalkula ay ang pagkuha ng mga rebolusyon ng rehistro gamit ang mga query sa isang virtual na talahanayan ng pangunahing data o ang GetBase() na pamamaraan. Ang mga turnover ng rehistro ay nakuha batay sa isang malaking bilang ng iba't ibang mapagkukunan ng data, kabilang ang mga setting at nilalaman ng plano ng mga uri ng pagkalkula, mga setting ng rehistro ng pagkalkula, mga parameter ng virtual na talahanayan ng pangunahing data, atbp. Ngunit ang isa sa mga makabuluhang tungkulin sa pagkuha ng pangunahing data ay nilalaro ng mga sukat ng rehistro ng pagkalkula.

Ang papel ng mga dimensyon sa pag-parameter ng isang virtual na talahanayan ng pangunahing data

Ang isa sa mga mahalagang parameter ng virtual na talahanayan ng pangunahing data ay ang listahan ng mga sukat kung saan inihahambing ang mga entry ng rehistro kapag nagsusuma ng data. Upang malutas ang iba't ibang mga problema, maaaring kailanganin mong isama ang mga mapagkukunan ng pagpaparehistro sa iba't ibang hanay ng mga dimensyon. Tingnan natin ang halimbawa ng isang rehistro na inilaan para sa pagkalkula ng mga suweldo at pagkakaroon ng tatlong dimensyon:

• organisasyon,
• indibidwal,
• Subdivision.

Isipin natin na kinakailangan upang malutas ang mga sumusunod na problema:

• Pagkuha para sa ilang mga talaan ng rehistro ng paglilipat ng rehistro para sa lahat ng mga talaan na may parehong dibisyon tulad ng orihinal na talaan. Ito ay maaaring, halimbawa, ang pagkalkula ng isang allowance, depende sa mga accrual ng buong departamento.
• Pagkuha ng turnover mula sa mga talaan na may parehong Indibidwal at Dibisyon. Yung. pagtanggap ng halaga ng mga accrual ng empleyado na naipon sa kanya sa parehong departamento (ang mga accrual para sa parehong empleyado na natanggap niya sa ibang mga departamento ay hindi kasama).
• Pagtanggap ng turnover mula sa mga talaan na may parehong Indibidwal at parehong Organisasyon (lahat ng mga accrual sa Indibidwal sa loob ng parehong organisasyon).

Ang lahat ng mga gawain sa itaas ay nalutas gamit ang mga query sa isang virtual na talahanayan ng pangunahing data. Sa kasong ito, ang mga parameter na "Mga sukat ng pangunahing rehistro" at "Mga sukat ng rehistro ng base" ay magkakaiba para sa lahat ng tatlong gawain. Sa unang kaso, mayroong isang dimensyon - "Dibisyon"; sa pangalawa - "Indibidwal" at "Yunit"; sa pangatlo - "Organisasyon" at "Indibidwal".

Pag-optimize ng pagkuha ng baseline data

Para sa mga kasong nakalista sa itaas, kapag bumubuo ng isang query sa isang virtual na talahanayan ng base data, ang system ay, sa mga tuntunin ng wika ng query, magsasagawa ng "kaliwang pagsali" ng talahanayan ng pagpaparehistro ng pagkalkula na may parehong talahanayan. Sa kasong ito, ang isa sa mga kondisyon ng koneksyon ay ang pagkakapantay-pantay ng mga halaga sa mga patlang na tinukoy bilang mga sukat ng pangunahing at base na rehistro. Siyempre, bilang karagdagan sa kundisyong ito, mayroong isang paghahambing ng panahon ng bisa o panahon ng pagpaparehistro sa simula at pagtatapos ng batayang panahon, paghahambing ng mga uri ng pagkalkula, atbp., ngunit ang pinaka "mahigpit" na limitasyon, bilang panuntunan, ay ang limitasyon sa mga halaga ng pagsukat.

Kaya, para epektibong gumana ang resultang query, mahalagang magkaroon ng index sa talahanayan ng rehistro ng kalkulasyon na naglalaman ng mga field ng pinaghahambing na dimensyon bilang mga unang field.

Ang kakayahang i-index ang mga sukat ng rehistro ng pagkalkula ay nagpapahintulot sa amin na malutas ang naturang problema, ngunit para lamang sa kaso kapag ang isang dimensyon ay inihambing (sa aming halimbawa, ang gawain ng pagkuha ng data para sa isang departamento). Sa kaso kung saan mayroong dalawa o higit pang maihahambing na mga sukat, kinakailangan na bumuo ng isang index para sa ilang mga sukat nang sabay-sabay.

Ito ang eksaktong problema na pinapayagan ka ng Basic na dimensyon na pag-aari ng rehistro ng pagkalkula na malutas mo. Sa pamamagitan ng pagtatakda ng property na ito sa maraming dimensyon, ang configuration designer ay gumagawa ng index sa lahat ng dimensyon na minarkahan bilang "base" (para sa higit pang mga detalye, tingnan ang seksyong "Database Table Indexes").

Mula sa itaas, malinaw na isa lang sa ganoong index ang maaaring gawin para sa isang rehistro ng pagkalkula upang ma-optimize ang pagkuha ng pangunahing data sa pamamagitan ng pagpili ng ilang partikular na dimensyon. Kaya, sa panahon ng pag-unlad, mahalagang masuri nang tama kung aling mga virtual na talahanayan ang pinakamadalas na gagamitin, at kung kaninong pag-optimize ng pagganap ang pinakamahalaga.

Bumalik tayo sa ating halimbawa. Isipin natin na ang mga accrual na nangangailangan ng pagkuha ng data sa isang indibidwal at isang departamento ay magiging mas karaniwan sa panahon ng pagpapatakbo ng configuration kaysa sa mga accrual na nangangailangan ng pagkuha ng data sa isang indibidwal at isang organisasyon. Pagkatapos ay ang mga dimensyon na "Organisasyon" at "Indibidwal" ay dapat na mapansin bilang mga pangunahing dimensyon. Kasabay nito, kailangan nating tiisin ang katotohanan na ang pagkuha ng pangunahing data sa isang indibidwal at isang departamento ay medyo mabagal.

Kapag pumipili ng mga base measurements, dapat ding suriin ng isa ang kanilang "selectivity", i.e. isipin kung gaano karaming mga halaga ang magkakaroon sa isang partikular na dimensyon kapag nagpapatakbo ng pagsasaayos. Isipin natin na sa ating halimbawa, ang isang indibidwal ay maaaring may napakakaunting (isa o dalawa) na organisasyon at medyo maraming dibisyon. Yung. Ang isang indibidwal ay halos palaging binabayaran ng suweldo para sa isang organisasyon, at sa parehong oras, ang mga suweldo ay madalas na kinakalkula para sa iba't ibang mga departamento. Sa ilalim ng gayong mga kalagayan, mas makatuwirang piliin ang mga dimensyon na "Indibidwal" at "Dibisyon" bilang mga base.

Ngunit mahalagang tandaan ang pagkakasunud-sunod ng pagsukat ng rehistro ng pagkalkula...

Tungkol sa pagkakasunud-sunod ng mga sukat sa rehistro ng pagkalkula

Ang katotohanan ay kapag lumilikha ng isang index na magpapadali sa pagkuha ng pangunahing data, ang sistema ay may kasamang mga sukat dito sa pagkakasunud-sunod kung saan sila matatagpuan sa puno ng pagsasaayos. Nangangahulugan ito na sa pamamagitan lamang ng "pagpalit" ng mga dimensyon ng "Indibidwal" at "Dibisyon", babaguhin namin ang pagkakasunud-sunod ng mga field sa index.

Sa aming halimbawa, kung ang mga sukat na "Indibidwal" at "Mga Dibisyon" ay pipiliin bilang mga base, pagkatapos ay sa pamamagitan ng muling pagsasaayos sa mga ito, hindi namin babaguhin ang bilis ng pagkuha ng pangunahing data para sa isang indibidwal at isang dibisyon, ngunit kami ay radikal na magpapalala sa sitwasyon sa pagkuha ng data para sa isang indibidwal at organisasyon. Kapag naghahambing ng mga halaga sa mga field na "Organisasyon" at "Indibidwal", hindi magagamit ng system ang index ng Division+Individual, dahil ang field na "Indibidwal" ay hindi ang una dito, at ang kundisyon ay hindi ipinapataw sa ang dibisyon. At sa kaso ng Indibidwal+Division index, parehong ang pagtanggap ng pangunahing data para sa dibisyon at indibidwal, at ang pagtanggap ng pangunahing data para sa organisasyon at indibidwal ay makikinabang, dahil ang field na "Indibidwal" ang magiging una sa ang index, magagamit ito ng system "bahagyang" (isang field sa isang pagkakataon) . Kasabay nito, ang field na "Indibidwal" ay may mas mataas na "selectivity" kaysa sa field na "Organization" at hindi ito magdadala ng maraming oras upang ayusin ang mga kondisyon para sa organisasyon.

Kung ang batayang sukat ay isa

Huwag nating kalimutan ang tungkol sa gawain sa ating halimbawa, na kinabibilangan ng pagkuha ng pangunahing data para lamang sa isang departamento. Mukhang ang paglikha ng isang index na Indibidwal+Dibisyon upang malutas ang iba pang dalawang problema ay hindi kasama ang epektibong pagpapatakbo ng isang virtual na talahanayan ng pangunahing data para sa isang dimensyon na "Dibisyon." Ngunit dito kailangan nating tandaan ang tungkol sa posibilidad ng pag-index ng mga sukat ng rehistro (Pag-indeks ng ari-arian). Ang kakayahang mag-index ng isang dimensyon ay nagpapahintulot sa iyo na epektibong malutas ang problema ng pagkuha ng isang database batay sa isang pangunahing dimensyon.

Kaya, sa halimbawang isinasaalang-alang namin, kinakailangang itakda ang Basic na property sa "Indibidwal" at "Division" na dimensyon, ang Indexing property sa "Division" na dimensyon, at tiyakin din na ang "Indibidwal" na dimensyon ay "mas mataas ” kaysa sa dimensyon na “Dibisyon” (hindi mahalaga ang pagkakasunud-sunod ng dimensyon ng “Organisasyon”).