Kuidas tavaliselt peetakse arvestust äriettevõttes?

Esimestel aastatel jahivad kõik kasumit: rohkem osta, kiiresti müüa, poodides ja ladudes rippuv kaubavaru ei huvita veel kedagi. Andmebaasi maht kasvab hüppeliselt, sest... Samal ajal kui suurtähtedega kaupade järjekord on kaootiline.

Näiteks eile ostsid punase tooli, täna ostsid rohelise tooli, algul sisestavad nad andmed andmebaasi: 1) vana asend - punane tool 2) uus asend - roheline tool; Kuid pärast inventuuri toimub alati kaupade ümbersorteerimine ja siin jõutakse uue ametikoha loomise võimaluseni, ilma konkreetse kirjelduseta toote nimes selle eriomadusi, s.t. nad sisestavad toote näiteks lihtsalt "toolina" ja märgivad kaks eelmist tootepositsiooni kustutamiseks.

Mõne aja pärast on vaba käibekapital piiratud koguses. Siin tekib küsimus: milliste toodete järele oli suurem nõudlus, et neisse investeerida, mitte rippuvasse tootesse.

See tähendab jälle peate teadma toote täiendavaid omadusi, kuid need omadused tuleb sisestada andmebaasi mitte enam kaootilises järjekorras - lihtsalt lisades tootenimele mõned kirjeldused, vaid selgelt ja õigesti: nimi peaks olema lühike, kokkuvõtlik ja lisaväljal - kõik võimalikud omadused selle toote kohta on kirjeldatud: näiteks selle värv, maht, kaal, tootja ja palju muud.

Kui siin nomenklatuuri kataloogis toote omadused väljale “Märkused” kirja panna, siis ei ole analüütikul lihtne koostada vajalikku aruannet konkreetse konkreetselt antud omadustega toote populaarsuse ja käibe kohta. tootest.

Nomenklatuuri kataloogile saame lisada alluva kataloogi, kuhu kasutaja saab sisestada toote vajalikud omadused ja kirjeldused, kuid sellisel lähenemisel seisame silmitsi probleemiga, et me ei suuda ära arvata, millist tüüpi teavet kasutaja soovib täiendavalt sisestada. teavet.

Näiteks toote "Tool" all - kasutaja soovib näidata toote omadust - värvi, see on stringi andmeväärtus. See tähendab, et alluvas kataloogis teeme rekvisiidid stringiks. Mis saab siis, kui ta soovib näidata toote lisaomadust, näiteks tootjat? Seejärel peame muutma allkataloogi üksikasjad viitetüübiks, osutades teisele kataloogile "Tootjad". Mis siis, kui kasutaja soovib oma toote lisaomadustes märkida, mitu jalga toolil on? Alamkataloogis peame atribuudi numbriliseks muutma.....

Siit, kui peame andma kasutajale võimaluse luua Andmetüüp , mille väärtustesse ta oma teavet tutvustab, siis peame looma PVC(tunnuste tüüpide plaan).

Loome oma näites keeruka PVC, nii et toote täiendavate omaduste kirjeldamiseks on olemas täieõiguslik mehhanism.

Aga esmalt Vaatame raamatust PVC loomise õppetundi(lk 476) " 1C_ Enterprise 8.3. Praktiline juhend arendajatele. Näited ja tüüpilised tehnikad" Radtšenko/Khrustaleva

Siin on meil juba teatmeteos Nomenklatuur. Ülesande eesmärk: oskama tunda teatud iseloomuliku väärtusega materjalide jäänuseid. Selleks loome Konfiguraatoris: 1) teaberegistri "Nomenklatuuri omaduste väärtused" 3) materjalide partiide kirjeldamiseks "Nomenclature Options"; ) alluv PVC teatmeteos "Additional Nomenclature Properties", et määrata tüübiväärtuste omadused, mille jaoks konfiguratsioonis sobivaid tüüpe pole.

Selle tulemusel piisab, kui valime teaberegistrist välja kõik selle tunnusväärtusega alluvakataloogi elemendid ning seejärel saame nende ja nende omanike põhjal kogumisregistri ülejäänud osa.

Loodavas PVC-s märgime väljale „Characteristic value type” liitandmetüübi: Number, String, Date, Boolean, DirectoryLink.AdditionalNomenclatureProperties. Ja ka PVC väljale "Omaduste lisaväärtused" - tähistame allutatud PVC kataloogi "Nomenklatuuri lisaomadused".

2) TypeProperties, type = Plan of Types of CharacteristicsLink.PropertiesNomenclature

Ja looge teaberegistri ressurss:

Väärtus, tüüp = Characteristic.Nomenclature Properties.

Oleme loonud kõik uued objektid. Neid pole vaja alamsüsteemidesse (kasutajaliidesesse) lisada, kuna uute objektide vahel on ühendus ja peamine on nomenklatuurile alluv kataloog “Nomenclature Options”, mida näeme mis tahes toote avamisel. Nomenklatuuri kataloogist:

Inforegistri "NomenclaturePropertyValues" seadistamisel on mitmeid nüansse, siin on soovitav määrata registri dimensioon Property Set(valik loendist OptionsNomenclature langeb siia) - kuidas Saatejuht, annab see meile võimaluse viitest "Nomenklatuuri valikud" - helistage sellele teaberegistrile. Ja ka registri ressursi jaoks Väärtus - määrake "Link tüübi järgi" = Property Type ja "Selection Parameter Links" = Selection.Owner(Property Type) Need teaberegistri seadistused lihtsustavad kasutaja andmete sisestamist.

Lisaks on selle õppetüki raamatus üksikasjalik kirjeldus, kuidas kõige paremini seadistada loendivorme ja uute objektide põhivorme, et kasutaja näeks toote omaduste täitmisel ainult seda teavet, mida ta vajab. Kõiki neid detaile me siin ei näita.

Proovime lihtsalt meie tootes näiteks "Elektrikaablid" – määrake lisaomadus "Valged kaablid" ja atribuudi koostis: "omaduse tüüp" = Color ja "property value" = White. See on üksteise järel avanevate akende muster:

....ma ei tea kuidas sinuga, aga mu pea käib juba ringi ja pole enam päris selge, mida me teeme ja miks))))

Kujutage ette, kuidas sellist ahelat kasutajale selgitada?!?.....Et meie kasutaja saaks aru sellest, millest me ise enam aru ei saa, peab tal olema vähemalt kolm 1C sertifikaati)))

Kui teid ehmatab ja häirib tooteomaduste tutvustamine vastavalt ülalkirjeldatud skeemile, võite vaadata sama diagrammi õpikust endast:

See on lihtsalt uskumatult raske!!! Ja iga algaja programmeerija otsustab, et lihtsam on PVC-ga mitte kunagi sekkuda, kui proovida sellist skeemi välja mõelda...

Ülesande lõpptulemuse - kaupade jääkide nende omaduste järgi saamiseks soovitab raamat lisada järelejäänud registris nomenklatuurile alluvasse kataloogi "Nomenklatuuri valikud" dimensiooni "Omaduste kogum" koos viitetüübiga. Järgmisena lisa tabelijaotiste materjalide laekumise/kulu dokumentidele sama nime ja andmetüübiga väli ning nende dokumentide moodulitele lisa kanne saldoregistrisse “Omadused”. Kataloogis endas “Nomenklatuuri valikud” - kirjutage selle menüüsse Karakteristikud, mis võimaldab teil neid hiljem SKD aruandes näha. Ja viimase sammuna looge SKD aruanne ülejäänud toodete kohta, valides karakteristikute järgi:

Jah, aruanne tuleb huvitav, kuid toote lisaomaduste (omaduste) loomise protsess on väga segane, lisaks ei teki kasutajal nii palju lisaandmeid sisestades laekumise/kuluarvete täitmisel ainsatki viga.....Alates "Atribuutide komplekti" sisestamisest dokumendi väljadele....

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Proovime mõista tootele täiendavate omaduste loomise mehhanismi, ehk jõuame probleemile lihtsamalt lahenduseni.

Mida me siis vajame:

1. Lubage kasutajal lisada nomenklatuuri omaduste kirjeldus.

2. Lubage analüütikul uurida müüginäitajaid valikus Tooteomaduste järgi.

Mõelgem, millised võimalused meil on probleemi esimese punkti lahendamisel:

1. Nomenklatuuri kataloogi saame lisada alamkataloogi, milles kasutaja kirjeldab ainult konkreetseid stringi tüüpi andmeid, mille oleme konfiguraatoris määranud... see ei sobi, kuna toote omaduste kirjeldamisel , Tüüp "ennustamatu" meie poolt konfiguraatoris võib vajada andmeid: näiteks kuupäev, number, rida, link teisele kataloogile.

2. Seetõttu peame nomenklatuuri lisaomaduste loomiseks looma PVC, kuna PVC on teatmeteos + andmetüüpide kirjeldus.

Kui oleme kataloogis Nomenklatuur, siis loome tabeliosa, milles on kaks välja - sisestatud tooteomaduste andmetüüp ja otse väärtus ise. See on väga lihtne – üks väli viitab PVC-le, teine ​​selle PVC omadustele.

Kuid sel juhul ei saa me kirjeid ainulaadseks muuta... Kujutage ette võimalust, kus toote alla, näiteks Vorstid, saate atribuudi „Värv” jaoks sisestada kahte tüüpi väärtusi: mõlemad punane ja roheline)))

Seetõttu on see meetod kõige lihtsam, kuid ei paku nomenklatuuri omaduste ainulaadsust.

3.Loome PVC, kuid sisestame selle väärtused teaberegistri kaudu. Teaberegister – sisaldab ainult unikaalsed andmed.

See on kõige mitmekülgsem variant. Salvestame tooteomadused erinevat tüüpi andmetega ja nende omaduste väärtused konkreetse toote puhul on kordumatud.

p.s. Siin saate luua alluva PVC kataloogi, et salvestada kõik selle üksuse stringi omadused. Aga ärgem tehkem praegu asju keeruliseks.

Selleks lisame inforegistrisse kaks mõõdet:

2) Nomenklatuuri omadused, tüüp = Universaalse PVC omaduste tüüp.

Registriressurssides märgime "Property Value", tüüp = Characteristic.UniversalPVC:

See on praeguseks kõik, oleme loonud mehhanismi toote ainulaadsete omaduste jaoks. Peame veel konfigureerima kasutaja jaoks andmete valimise mugavuse.

Valime inforegistri ressursi "PropertyValue" ja parempoolses menüüs vahekaardil "Vaated" - loo ühendused, et kasutajarežiimis selle registri väärtust valides saaksime kohe nimekirja dimensioonist see register "Nomenklatuuri vara". Sest Peame meeles, et dimensioon "Nomenklatuuri omadus" on PVC ja ressurss "Omaduse väärtus" on selle PVC tunnuseks. Niisiis, sellel tahvlil märkige "Seos tüübi järgi" = "Nomenklatuuri omadus". Kui nüüd oleme valinud registri dimensioonis Andmetüübi, näiteks stringi, siis ressursile väärtuse sisestamisel on meil kohe tüübistring, mitte kõik võimalikud tüüpide loendid!

Läheme kasutajarežiimi, valime Nomenklatuuri kataloogist suvalise toote, avame selle, kataloogielemendi ülaosas on meil link loodud inforegistrile, kuhu lisame oma toote uued omadused:

Selles näites toote "Philips 2N2369 Transistor" jaoks looge esmalt soovitud toote atribuudi tüüp, olgu selleks "Transistors" ja märkige kohe selle atribuudi andmetüüp - selles näites valime käsitsi andmetüübi = String. Hoiame kokku. Ja siis peame määrama seda tüüpi tooteomaduste väärtused, olgu selleks "Nõrkvoolutransistorid":

Lisame sellele tootele veel ühe omaduse, näiteks tootja "Korea".

Võtame teise toote, loome selle jaoks atribuudi "Transformers", type = string, value = "String transformers". Ja teine ​​atribuut, mille tahame selle toote jaoks sisestada, on samuti "Tootja" - seda pole vaja luua, see on meil juba valikus, kuid kui proovime sisestada selle atribuudi sama väärtuse, mis on võrdne “Korea”, siis peame selle käsitsi sisestama...See pole eriti mugav...On hea, kui üks kord sisestatud väärtust saab mitu korda asendada.

Selle mugavuse lisamiseks läheme konfiguraatorisse ja loome kataloogi, vahekaardil "Omanik" märgime meie varem loodud "Universaalne PVC". Nüüd, kui meie väärtusomadused on stringid, siis ei pea me pidevalt valima tüüpi = String, piisab lingi andmisest sellele alluvale teatmeraamatule: stringiväärtuste salvestamine on selles väga mugav ja lisaks võimaldab see meetod meil valida toote omaduste jaoks valmis stringi väärtused.

Teeme PVC-s mõned väikesed muudatused seoses ilmuva alamkataloogiga:

Samuti peame inforegistris lisama seadistused, et registri ressursi väärtuse valimisel oleks meil koheselt antud kinnisvara Omaniku valik.

Täitsime ülesande esimese punkti – lõime mehhanismi tootele ainulaadsete omaduste loomiseks.

Täidame 1c kasutajarežiimis üksuse erinevaid omadusi. Pange tähele, et varem sisestatud omadused, nagu näiteks Tootja, on juba vara valikus kohe saadaval, samuti antakse meile võimalus valida koheselt sellele kinnisvarale valmisväärtus, näiteks “Korea” .

Liigume nüüd ülesande lahendamise teise etapi juurde: võimaldada aruandes teha valik näiteks tootesaldode või tootemüügi järgi selle toote omadustest.

Ütlen kohe ära, et dokumentide tabeliosade väljadele tooteomaduste lisamisega me keerulise mehhanismi peale ei tule!!! Praktikas seda teha ei saa, muidu tekib dokumentidega selline segadus, et siis ei jätku kellelgi jõudu korda teha....

Kõik on palju lihtsam. Meil on toode, selle nimi on lühike, lakooniline, kõik nüansid on selle omadustes kirjeldatud. Kui meil on erinevat tüüpi omadustega toode, tähendab see, et see toode on erinev ja mitte sama!

Näiteks on meil üks toode “Samsung Line Transformer”, millel on kaks omadust: 1) “Transformers” = “Line Transformers” 2) “Tootja” = “Korea” ja teine ​​toode “Russia Line Transformer”, millel on kaks omadust: 1) "Transformers" = "Low-line trafod" 2) "Tootja" = "Venemaa". Seega ei saa me kuidagi väita, et need kaks toodet on samad, vaid erinevad ainult omaduste poolest!!! Ei, need kaks toodet on erinevad, mille erinevust kirjeldame lühidalt Nimes ja kirjeldame üksikasjalikumalt selle toote omadustes.

Seega ei pea me esmastesse dokumentidesse lisavälja looma ühe toote omaduse registreerimiseks (neid omadusi võib meil olla rohkem kui üks!).

Väljastame uuesti kõik oma arved ja dokumendid Teenuste osutamine. (siin raamatu esimese meetodi dokumentides on täiendavate omadustega väljad, kuid need ei mõjuta kuidagi meie vastloodud PVC mehhanismi)

Konfiguraatoris koostame aruande registri "Universaalse PVC unikaalsus" kohta. Kirjutame ACS-i aruandepäringusse järgmise koodi:

SELECT Ülejäänud materjal ja käive, järelejäänud materjali kogus ja käive allesjäänud, järelejäänud materjali kogus saada ja käive jäänud. Kogus Lõplik Jääk ok AS Lõplik Jääk, Universaalse PVC unikaalsus. Nomenklatuuri ainulaadsus, Unikaalsus Universaalse PVC. Väärtusomadused Registrist Akumulatsioon. Ülejäänud materjalid. Ülejäänud materjalidJättekäive AS Ülejäänud materjalidÜlejäänud ja käive Universaalne PVCÜHENDUSE registrijääk Materjalide jäägidJakäive.Materjal = Universaalse PVC ainulaadsus. Nomenklatuur

ACS-i aruande seadetes lubame seda kasutada kasutajarežiimis "Valik". Aruande loomisel 1C-ettevõttes valige valikust Nomenklatuuri omadus = Tootja. Saame väga huvitava aruande:

Asendades saldoregistri Müügiregistriga, loome teise Müügiaruande, millel on võimalus valida tooteomaduste järgi.

Oleme täitnud ja isegi ületanud ülesande teise punkti – võimaldada Analüütikul koostada aruandeid Tooteomaduste kontekstis.

Meie versioonis osutus PVC mehhanism lihtsaks, selgeks ja kiiresti kohandatavaks.

p.s. Selle artikli loomisel aitas mind palju siit loetud teave:

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Loodan, et minu artikkel on kasulik platvormi 1c 8.3 algajatele programmeerijatele

p.s. Lisan koolituse andmebaasi, milles kõik praegused näited loodi allalaadimisel. Alustasin selle andmebaasi kirjutamist nullist, kasutades õppetunde Radchenko/Khrustaleva raamatust “1C_ Enterprise 8.3 Praktilised juhendid ja tüüpilised tehnikad” http://v8.1c.ru/metod/books/book.jsp. ?id=441, lihtsalt täiendades seda enda saavutustega.

Edu PVC valdamisel selle keerulise probleemi lahendamisel - allolev hüüdlause on väga sobiv)):

Igaks juhuks autoriõigus

Andmekoosseisu skeemi päringukujundajas, kui seda kutsutakse andmeallika seadistusvormilt. Seal on vahekaart "omadused", mille kasutamist ei ole dokumentatsioonis selgelt kirjeldatud. Selles artiklis püüan selgitada, kuidas ja miks ACS-is omadusi kasutatakse.

Tüüpilised konfiguratsioonid kasutavad aktiivselt atribuutide ja omaduste väärtuste mehhanismi, mis on saadaval peaaegu iga objekti jaoks. Primitiivselt rakendati seda mehhanismi teatmeteostes konfiguratsioonides 7.7. Nüüd rakendatakse seda mehhanismi tunnustüüpide plaani ja teaberegistri abil, kuid idee jääb samaks.

Kui ma esimest korda puutusin kokku vajadusega kasutada seda mehhanismi juurdepääsukontrolli skeemis, nägin ma väga pikka aega vaeva, korraldades pesastatud päringuid, ühendades need põhivalikuga ja mõtlesin, kuidas võtta arvesse võimalikku uut tüüpi omadused, mida aruande koostamise ajal ei eksisteerinud. Kogu atribuutide mehhanism, olles kasutaja seisukohast lihtne ja loogiline, ei sobinud normaalseks töötlemiseks enne, kui leidsin vahekaardi „Omadused”.

Vahekaardil olev tabel on väga kapriisne, kas sisestate kogu rea õigesti või keeldute rea sisestamisest üldse, süsteem ei luba teil mittetäielikult täidetud rida "hiljemaks" jätta.

Niisiis, asume üksikasjadesse. Esimene veerg: Tüüp– siin valime objekti tüübi, millele tunnused lisatakse, näiteks “DirectoryLink.Nomenclature”

See tähendab, et nüüd on võimalik saada kõigi määratud tüüpi objektide omaduste väärtusi.

Edasi järgmises veerus Liikide allikas peame määrama varavaate allika parameetrid. Võimalikud valikud laud m nõuda, milleks me valikut vajame? nõuda Ma räägin teile hiljem, nüüd valime üksuse laud.

Kolumnis Tunnuste tüübid peame valima teabebaasi tabeli, kuhu on salvestatud nõutud tüüpi karakteristikud, meie näites on see "Tulemuste tüüpide plaan. Objektide omadused".

Järgmiseks meile veergudes valimiseks saadaolevad väärtused Võtmeväli, Nime väli Ja Väärtuse tüübi väli, sõltuvad otseselt meie valitud tabeli väljadest. IN Võtmeväli me valime Link, V Nime väli– Esitus(kasutaja näeb seda atribuudi nimena) ja sisse Sisestage väli vastavalt TypeValue.

Liigume nüüd väärtuste allika juurde. Meie väärtuste allikaks on teaberegister “ObjectPropertyValues”, seega valime veerus Väärtuste allikas – laud, ja veerus Atribuutide väärtused– "Teaberegister. Objekti omaduste väärtused." Veergudes Objekt, Kinnisvara,Tähendus, valige sobivad registriväljad Objekt, Kinnisvara, Tähendus.

Näib, et see on kõik. Me läheme skeemi seadistustesse, lisame grupeeringu toodete järgi ja lisame alluva rühmituse, näiteks kaubamärkide järgi, meil on selline omadus.

Laiendame nomenklatuurirühma üksikasjade loendit ja... me ei näe seal ühtegi atribuuti:

Fakt on see, et oleme konfiguraatoris, kust andmetele juurdepääsu pole. Kuidas teha vajalikke seadistusi? Kõige mugavam viis seda teha on kasutada andmete koostamise konsooli, seda ITS-i kettal või seda, mis sisaldub alamsüsteemis "Arendaja tööriistad". Kuid võite lihtsalt avada aruande seaded ettevõtte režiimis.

Niisiis, avame sama sätte, kuid ettevõtte režiimis:

Nagu näete, oleme lisanud uued "Üksikasjad" ja atribuudi " Bränd” väliselt ei erine tavalistest kataloogidetailidest. Ja kinnisvara" Toote tüüp” on nurksulgudes, kuna atribuudi esitus sisaldab tühikut.

Meil on aga ka kinnisvara " Lepingu tüüp", mis on lingitud kataloogiga" Kokkulepped ja sellel pole midagi pistmist Nomenklatuur“. Kui seda ei kasutata seadistuses " Lepingu tüüp” siis kõik toimib õigesti, aga kui selle valite, siis selle tulemusena osutub see täitmata, sest nomenklatuuris pole ühelgi kirjel seda omadust tegelikult täidetud. Kuid kuidas filtreerida välja mittevajalikud omadused, et need ei jääks jalge alla?

Selleks peame muutma päringukujundaja vahekaardil „Karakteristikud” vaate allika sätet. Pidage meeles, et artikli alguses lubasin teile öelda, miks vaateallika tüüpi on vaja nõuda? Nüüd on just selline juhtum. Muutke vaate allika tüübiks nõuda. Karakteristikute tüüpide veerus klõpsake nuppu "[...]" ja avaneb uus päringukujundaja aken.

Sisestage sinna järgmine päring:

VALI
Objekti omadused. Ref.
Objekti atribuudid + "(oma)" AS nimi,
Objekti omadused.TypeValues
FROM
Objektide omaduste tüüpplaan AS Objektide omadused
KUS
Objekti omadused. Omaduste eesmärk = VÄÄRTUS (tunnuste tüüpide plaan. Objekti kategooriate omaduste eesmärk. Kataloog_nomenklatuur)
JA (MITTE ObjectProperties.DeletionMark)
JA (MITTE ObjectProperties.Category)

Veergudes Võtmeväli, Nime väli Ja Väärtuse tüübi väli, valige sobivad valikuväljad: Link, Nimi Ja TypeValue. See selgub järgmiselt:

Nüüd, kui liigume edasi aruande seadistamise juurde, muutub pilt nomenklatuuri üksikasjade loendis:

Nüüd on tootel ainult need omadused, mis sellele on määratud, pealegi erinevad need tänu postscriptile nüüd märgatavalt tavapärastest detailidest (kinnistu), mille lisasime päringule vara nimele.

See on kõik, kuid paljusid võib segadusse ajada võimatus seda konfiguraatoris seadistada. Selles pole tegelikult midagi halba. Piisab sätte (või kogu vooluringi) salvestamisest faili ja taastamisest konfiguraatoris.

Konfiguraator kuvab punaste ristidega üksikasjad, millest ta aru ei saa:

Kuid see pole enam hirmutav, sest selliste seadistustega aruande saab salvestada konfiguratsioonis ja see töötab õigesti, kui kasutaja avab.

Tunnuste tüüpide plaani koostamine, töö kontoplaaniga

1C:Enterprise 8 süsteemis.2 »

Töö eesmärk: tunnustüüpide plaani koostamise põhitehnikate valdamine, kontoplaani koostamine tarkvarapaketis "1C:Enterprise 8.2".

Vastused turvaküsimustele

Ülesande tulemused.

Juhised

Iseloomulikud tüübiplaanid

Analüütilise arvestuse säilitamiseks süsteemis 1C:Enterprise kasutatakse subkonto mehhanismi. Subconto Mis tahes analüütilise arvestuse objektiks nimetatakse: põhivara, immateriaalne põhivara, materjalid, organisatsioonid, vastutavad isikud, lepingud jne.

Vaade allkontole, omakorda nimetatakse sama tüüpi analüütiliste arvestusobjektide kogumit. Näiteks ostjate ja klientide loendit (eeldusel, et need on ainult organisatsioonid) süsteemis 1C:Enterprise nimetatakse "alamkonto tüübiks "Organisatsioonid" ja mis tahes organisatsiooni sellest loendist nimetatakse "alamkontoks".

Subconto analüütilise arvestuse rakendamiseks kasutatakse uut rakendusobjekti “Karakteristikutüüpide plaan”. See kirjeldab võimalikke tunnuseid, mille kontekstis on vaja analüütilist arvestust, näiteks vastaspooled, nomenklatuur.

Karakteristiku tüüpide plaani põhiomadus on tunnusväärtuse tüüp, mis näitab alamkontona kasutatavaid konfiguratsiooniobjekte, näiteks DirectoryLink. Nomenklatuur.

Sarnaselt eelmääratletud kontodele tunnuste tüüpide osas, näidatakse ka arendusetapis tavaliselt eelnevalt määratletud tunnuste tüüpe (alamkontode tüüpe), näiteks vastaspooled.

Subconto View objekt ise ei kirjelda ühtegi andmeobjekti. Alamkontovaade viitab ainult konkreetsele andmetüübile. Alamkonto tüüp näitab võimalust kasutada kindlat tüüpi andmeid ettevõttekontode analüütilise arvestuse korraldamiseks. Analüütilise arvestuse pidamiseks mõeldud andmeobjektid võivad olla kataloogide, dokumentide, ülekannete jms elemendid. Konkreetse konto analüütilise raamatupidamise (alamkonto) seadistamisel märgitakse alamkonto tüüp. Näiteks konto 3310 analüütilise raamatupidamise korraldamiseks saab valida alamkonto tüübiks “Osapooled”, mille andmetüüp on “DirectoryLink.Counterparties”. Seega teeb alamkontotüüp teatud tüüpi andmed analüütilises arvestuses kasutamiseks kättesaadavaks.

Kontoplaanid

Kontoplaanid on "konto" tüüpi andmeobjektide loendid - raamatupidamisregistrid, mille alusel rühmitatakse rahalisi vahendeid süsteemiga 1C:Enterprise töötamisel. Kontoplaani mõiste 1C:Enterprise süsteemis on täielikult kooskõlas sarnase mõiste üldtunnustatud arusaamaga raamatupidamises. Seega on kontod ette nähtud ettevõtte rahaliste vahendite sünteetilise arvestuse objektide hoidmiseks.

Kontoplaanid sisaldavad raamatupidamis- või maksukontode loendit, näiteks isemajandavaid, maksu- ja lihtsustatud maksusüsteemiga kontode maksuplaane.

Konto atribuute saab paindlikult konfigureerida sõltuvalt konkreetses riigis ja konkreetset tüüpi ettevõttest kasutatavast raamatupidamissüsteemist.

Kontoplaani jaoks on määratud konto koodi pikkus ja alamkontode tasemete arv ning iga taseme alamkonto märkide arv. Kontode jaoks on konfigureeritud täiendavad üksikasjad, samuti loendi vaatamise ja kontode redigeerimise vormid.

Raamatupidamisarvestus on raamatupidamissüsteemi aluseks. Nende seadistamisel määratakse täiendavate raamatupidamissektsioonide omadused - valuuta, analüütiline ja kvantitatiivne.

Süsteem toetab mitmemõõtmelist ja mitmetasandilist analüütilist arvestust. Lisaks on konfigureeritud võimalus kasutada raamatupidamiseraldajat. Raamatupidamise eraldaja võimaldab pidada raamatupidamist iseseisvalt mitme organisatsiooni kohta ühes infobaasis.

Raamatupidamiskontode oluline omadus on võimalus luua objekte nii konfiguratsioonis kui ka teabebaasis endas. Konkreetsete kontode lisamine konfiguratsiooni on soovitatav, kui konfiguratsiooni enda käitumine nõuab kontode endi või nende kontode konkreetsete atribuutide olemasolu.

Näide 1: Iseloomulike tüüpide plaani koostamine

Karakteristikutüüpide jaoks uue plaani koostamiseks valige aknas "Konfiguratsioon" haru "Karakteristikutüüpide plaanid" ja klõpsake nuppu "Lisa". Avaneb kujundaja aken, kus määrame nime "Tulemuste tüüpide plaan1". Sünonüüm genereeritakse automaatselt, kui klõpsate väljal.

Klõpsake väljal "Iseloomuliku väärtuse tüüp" nuppu. Avaneb aken "Muuda andmetüüpi", milles peate lubama valiku "Koosandmetüüp" ja seejärel märkima kõik kataloogid (joonis 1), mida on vaja analüütiliseks arvestuseks (kontoplaani seaded). Märgistame kolm kataloogi: Töötajad, Töövõtjad, Nomenklatuur. Klõpsame "OK".

Sulgeme disaineri akna. Selle tulemusel kuvatakse konfiguratsioonipuu harus "Plaanid omaduste tüübi järgi" rida "Tüüpiliste karakteristikute tüüpide plaan". Lisama. eelmääratletud karakteristikute tüübid (alamkonto tüübid), peate paremklõpsama real "PlanTypes of CharacteristicsTypical" ja valima "Ava eelmääratletud andmed". Avaneb aken, kuhu peate lisama eelnevalt määratletud karakteristikute tüübid (alamkonto tüübid).

Lisame esimest tüüpi alamkonto "Töötajad". Alamkonto tüüp "Töötajad" vastab samanimelisele kataloogile, mis sisaldab teavet ettevõtte töötajate kohta ja mida kasutatakse nii konstantide täitmiseks ja algdokumentide väljavõtmiseks kui ka analüütilise raamatupidamise pidamiseks kontol 1251.

Klõpsake nuppu "Lisa". Avaneb aken “Eelmääratletud karakteristik”, milles tuleb määrata nimi (Töötajad), nimi (Töötajad) ja valida nupu abil tüüp DirectoryLink.Töötajad (joonis 2). Seejärel klõpsake "OK".

Samamoodi lisage alamkontotüübid: "Vastaspooled" ja "Nomenklatuur".

Joonis 1 – Andmetüübi redigeerimine

Joonis 2 – Eelmääratletud karakteristikud

Joonis 3 – tüübi muutmise andmetüüp (töötajad)

Seega on tunnuste tüüpide plaanil järgmine vorm (joonis 4)

Joonis 4 – aken "Karakteristikutüüpide plaan"

Näide 2: Kontoplaani koostamine

Konfiguratsiooni põhikomponent on kontoplaan. Kontode koosseis, alamkontod, analüütilise raamatupidamise pidamise võimalus, arvestus kvantitatiivses ja valuutas – kõik see on määratletud kontoplaanis.

Selle ülesande elluviimiseks on vaja luua kontoplaan analüütilise ja kvantitatiivse arvestusega konto 1330 jaoks, samuti analüütilise arvestusega kontode 1210, 1251, 3310 jaoks.

Selleks avage aken "Konfiguratsioon" (menüü "Konfiguratsioon - Ava konfiguratsioon"). Otsime üles haru „Kontoplaanid” ja laiendame seda. Topeltklõpsake rippmenüüs real "Isearvestus".

Avaneb konkreetse kontoplaani redigeerimisaken (konstruktor), antud juhul aken “Konto põhikiri isetoetav”.

Kuna me kopeerisime selle kontoplaani, on nimi ja sünonüüm juba märgitud vahekaardil „Põhiline”. Jätame need muutmata ja liigume vahekaardile „Andmed” (joonis 3).

Joonis 1 – kontoplaani aken (vahekaart Andmed)

Oleme siin näidatud seadistustega rahul. Seetõttu liigume vahekaardile "Subconto".

Siin valime väljal Subconto tüübid "PlanTypes of Characteristics1", siis on redigeerimiseks saadaval väli "Maksimaalne alamkontode arv". Määrame selle numbriks kaks.

Sulgeme redigeerimisakna ja läheme aknasse "Eelmääratletud kontod".

Lubame kontol 1330 (41) analüütilise arvestuse, ühendades sellega subconto1 tüübi - Nomenklatuur. Selleks klõpsake akna allosas nuppu "Lisa" ja valige soovitud alamkonto tüüp. Selle rea ülejäänud funktsioonid jätame muutmata (joonis 4).

Riis. 2 – eelmääratletud konto seadistamine

Harjutus.

Koostage iseloomulik tüübiplaan

Seadistage kontoplaan...

Kontrollküsimused:

Subkontomehhanism.

Rakendusobjekti otstarve “Karakteristikutüüpide plaan”.

Tooge näiteid ülekannetest.

Dokumendivormi loomise etapid.

Kontoplaani atribuutide redigeerimine.

Iseloomulike tüüpide plaani abil saate korraldada objekti omaduste salvestamist, mis konfiguratsiooni väljatöötamise ajal pole veel teada. Need. kasutaja saab iseseisvalt sisestada uusi omadusi, näiteks värvi, suurust, mõõtmeid, võimsust. Igal tooterühmal võib olla oma omaduste komplekt: külmikute puhul - sügavkülmiku maht, kompressorite arv, müratase; arvutite jaoks - RAM-i maht, kõvaketta maht; riietele - suurus, kõrgus, värv jne. Seejärel saate nende omaduste põhjal koostada aruandeid, analüüsida müügimahtu ja hankida väärtuslikku teavet otsuste tegemiseks.

Iseloomuliku tüübiplaani oluline omadus, mis eristab seda teistest objektidest, on selle omadus "Väärtustüüp". See atribuut võimaldab teil määratleda iseloomulike tüüpide jaoks kasutatavate võimalike andmetüüpide loendi. Need. Tavaliselt kasutatakse liitandmetüüpi ja saab määrata nii primitiivseid andmetüüpe (arv, string, kuupäev, tõeväärtus) kui ka viiteandmetüüpe (DirectoryLink, DocumentLink jne). Iga karakteristiku tüübi jaoks on märgitud väärtuste tüüp valitud tüüpide loendist, näiteks tunnuse Tarnija jaoks valige DirectoryLink.Osaspooled. Kasutaja saab režiimis "Ettevõte" sisestada uued karakteristikud ja määrata neile väärtuse tüübi karakteristiku tüübi plaani konfiguraatoris määratud tüüpide loendist.

Tunnustüüpide plaani teine ​​oluline omadus on atribuut “Täiendavad tunnusväärtused”, mis määrab võimalikke tunnusväärtusi sisaldava alamkataloogi, näiteks ObjectPropertyValues. Tavaliselt kasutab kasutaja seda teatmeteost režiimis "Ettevõte" uut tüüpi omaduste sisestamisel, mille jaoks konfiguratsioonis pole sobivaid teatmeteoseid, seejärel saab kasutaja ObjectPropertiesValues'i teatmeraamatusse sisestada võimalike omaduste loendi. väärtused iga omaduse tüübi jaoks.

Näitena näete, kuidas atribuutide mehhanismi rakendatakse standardses "Kaubanduse haldamise" konfiguratsioonis. Selleks kasutatakse järgmisi objekte:
- Objektide omaduste omaduste tüüpide plaan, mis kasutab iseloomuliku väärtustüübina liitandmetüüpi, mis sisaldab primitiivseid andmetüüpe (arv, string, kuupäev, tõeväärtus) ja linke erinevatele rakendusobjektidele: kataloogidele, dokumentidele, loenditele.
- Objekti omaduste võrdlusväärtused, allub Objekti omaduste omaduste tüüpide plaanile. See viide sisaldab antud atribuudi võimalike väärtuste loendit, näiteks kõigi atribuudi Color värvide loendit: punane, roheline, valge jne.
- Teaberegister ObjectPropertyValues, millel on dimensioonid Objekt (kataloogi link, dokumendilink) ja atribuut (tunnuste tüüpide plaan. objekti atribuudid) ning väärtuse ressurss, mis sisaldab konkreetse objekti konkreetse omaduse väärtust.

Märge. Mõistmise lihtsustamiseks ei käsitleta siin objekti omaduste määramise mehhanismi. See mehhanism kasutab omaduste tüüpide plaani atribuuti ja teist teaberegistrit.

Tunnuste tüüpide plaani teine ​​oluline rakendus on alamkontside analüütiline arvestamine raamatupidamises. Tunnuste tüüpide osas luuakse etteantud tüüpi alamkontsid, näiteks vastaspooled, kaubad, lepingud jne. Need alamkontotüübid lisatakse seejärel kontoplaani salvestatud kontole. Režiimis "Ettevõte" olev kasutaja saab iseloomulike tüüpide plaani sisestada ka uut tüüpi alamkontsid.

Näiteks kaaluge, kuidas alamkonto arvestust rakendatakse ITS-i kettal olevas demokonfiguratsioonis „Raamatupidamine”. Kasutatakse järgmisi objekte:
- Tunnuste tüüpide plaan TüübidSubkonto. Väärtuste tüüpidena kasutatakse võrdlusandmetüüpe. Alakontoarvestuse jaoks ei ole väga soovitatav kasutada primitiivseid andmetüüpe, see vähendab süsteemi jõudlust.
- Kontoplaan Põhi, milles see tunnustüüpide plaan on märgitud alamkontotüüpide allikana
- Subkonto kataloog, alluvad tunnustüüpide plaanile.

Valuutaarvestus hõlmab teatud kontode (tavaliselt arvelduskontode) tehingute kajastamist mitte ainult reguleeritud raamatupidamise valuutas (rublades), vaid ka muudes valuutades. Sellistele kontodele kannete tegemisel arvutatakse rubla saldonäitaja (ehk see, mis kajastub ühe konto deebetis ja teise kreedit, et tagada saldo, deebet- ja kreeditsaldode ja käibe võrdsus) hetkeseisust lähtuvalt. (või dokumendis märgitud) vastaspoolega tehtavate vastastikuste arvelduste valuutaks valitud valuuta vahetuskurss. Kui vahetuskurss muutub, seisame silmitsi vajadusega võlg ümber hinnata, kusjuures kursivahe kantakse kasumiaruandesse. Kui me räägime reaalsest raamatupidamisest, siis need protseduurid tunduvad keerulisemad, kuid nende olemus taandub ülalkirjeldatud toimingule.

Oletame, et võlgneme vastaspoolele A 1000 dollarit, kui võla tekkimise ajal oli dollari kurss 30 rubla. Raamatupidamises rääkides saame järgmise raamatupidamiskirje:

D Materjalid K Arveldused tarnijatega 30 000 hõõruda. (1000 dollarit)

Kuu aega hiljem muutus dollari kurss 31 rublale. Kui võlg tarnija ees pole veel tasutud, siis tegelikult oleme talle nüüd võlgu mitte 30 000, vaid 31 000 rubla. Selle erinevuse kajastamiseks raamatupidamiskontodel võite kasutada järgmist kirjet (kordame - siin kajastub ainult ümberhindamisega seotud tegelikult olemasolevate protsesside olemus)

D Kasum ja kahjum C Arveldused tarnijatega 1000 hõõruda.

Pange tähele, et teeme raamatupidamiskirje, mis kajastab ainult rubla summat, kuna valuutakursi muutumisel muutub see summa. Ilmselgelt saime valuutakursi kasvuga antud juhul “ootamatu” kahju summas 1000 rubla, kuigi võla summa välisvaluutas ei muutunud. Vahetuskursi odavnemisel tekib vastupidine olukord. Kui ümberhindluse ajal on dollari vahetuskurss 29 rubla, saame “ootamatu” kasumi:

D Maksed tarnijatele K Kasum ja kahjum 1000 hõõruda.

Raamatupidamises on kontod nn bilansiväline. Selliseid kontosid kasutatakse teabe salvestamiseks ilma topeltsisestuseta. Näiteks võib see olla teave liisitud põhivara kohta. Organisatsioon ühelt poolt peab säilitama nende kohta teavet, teisest küljest ei tohiks need bilansi seisu mõjutada, kuna organisatsioon ei oma neid, ta ei võta neilt põhivaradelt amortisatsiooni. Seetõttu säilitatakse selline teave bilansivälistel kontodel. Selliste kontode laekumise kanded tehakse deebeti poolel, kulukanded aga kreeditkontol. Bilansivälised kontod ei kattu teiste kontodega.

Analüütika kohta

Raamatupidamist saab pidada ühes või mitmes analüütilised osad. Näiteks materjalide konto jaoks on üsna loogiline anda jaotis Nomenklatuur, tänu millele saad teada, millised kaubaartiklid kontol arvesse lähevad. Loogiline on pidada arvestust osapooltega tehtavate arvelduste kohta osapoolte endi kontekstis ning võimalusel ka lepingute kohta osapooltega ja valuutadega. Analüütilised lõigud 1C:Enterprise terminoloogias on tavaks helistada subkonto. Väljendit "Subconto Nomenclature" tuleks mõista kui "analüütilist osa nomenklatuuri".

Objektid 1C: Ettevõtluse ja raamatupidamise allsüsteem

Raamatupidamise alamsüsteemi rakendamiseks vajame järgmisi 1C:Enterprise 8 objekte:

1. Tunnuste tüüpide plaan. Kasutame seda analüütika tüüpide (subconto) salvestamiseks, mis peaksid meie kontodel olema.
2. Kontoplaan. See on raamatupidamise alamsüsteemi aluseks. Kontoplaan salvestab kontode kirjeldused, millel raamatupidamist peetakse. Konfiguratsioonid võivad sisaldada piiramatul arvul kontoplaane, kuid tavaliselt ei ületa kontoplaanide arv ühes konfiguratsioonis 1-2. Kontoplaani võib võrrelda eriotstarbelise kataloogiga, mis on mõeldud raamatupidamiskontode kohta info salvestamiseks.
3. Raamatupidamisregister. See on seotud kontoplaaniga ja seda kasutatakse raamatupidamisdokumentide salvestamiseks. Raamatupidamisregister võib võrrelda ajakirjaga, milles peetakse raamatupidamisarvestust.

Raamatupidamise konfiguratsiooni alamsüsteemi loomisel loome esmalt omaduste tüüpide plaan- kontoplaani koostamisel tuleb sellele viidata, seejärel - kontoplaanile - ilma kontoplaani täpsustamata ei saa me luua raamatupidamise register.

Tunnuste tüüpide plaan

Loome uue omaduste tüüpide plaan, nimetame seda TüübidSubconto, riis. 1.1

Riis. 1.1.

Tunnuste tüüpide plaan lisab süsteemi uue andmetüübi, mis on sisuliselt liitandmetüüp. Seda tüüpi liitandmed sisaldavad tavaliselt katalooge, mille elemente kasutatakse lõpuks analüütilises arvestuses. Iseloomulikke väärtusi ei saa esitada ainult teatmeteoste kaudu - lisaks võivad need olla näiteks dokumendid ja loendid.

Lisame loodu omaduste tüüpide plaan allsüsteemi Raamatupidamine.

Seadistamisel omaduste tüüpide plaan selle omadused on eriti olulised Iseloomulik väärtuse tüüp Ja Täiendavad statistilised väärtused. Need määratlevad andmetüüpide komplekti, mida ühendab iseloomulike tüüpide plaan.

Nende atribuutide õigeks seadistamiseks loome enne jätkamist uue kataloogi – nimetagem seda Subconto.

Lisame alamsüsteemi kataloogi Raamatupidamine.

Valime vahekaardil Omanikud kataloogiseadete aknad, omaduste tüüpide plaan TüübidSubconto omanikuna määrake parameeter Esitamise kasutamine tähenduses Elemendid, riis. 1.2.

Muid kataloogiväärtusi me ei seadista, kuigi seda saab vajadusel teha. Me vajame seda selleks, et mitte piirata konfiguratsiooni kasutajat subconto väärtustega, mida ta saab määrata olemasolevate kataloogide abil, mis on määratud omaduste tüüpide järgi. Tegelikult võimaldab see kasutajal vajaliku iseseisvalt seadistada analüütilised osad ilma süsteemi konfigureerimist ja häälestamist kasutamata omaduste tüüpide plaan.

Lähme juurde omaduste tüüpide plaan, järjehoidja peal Põhiline avada oma vara Iseloomulik väärtuse tüüp, riis. 1.3.

Märkige ruut Komposiitandmete tüüp, tühjendage märkeruut Liin(ei ole soovitatav kasutada iseloomulike tüüpide plaanides