Det nye katalogkonfigurasjonsobjektet er ment for. Hvordan jobbe med en konfigurasjonsobjektreferanse
Noen ganger begynner jeg å klandre meg selv for å være så lat. Men jeg stopper fort - latskap.
Leksjon 22 handler om roller. Og her vil jeg til og med fortelle deg litt morsomme historier fra praksisen min dedikert til roller (egentlig ikke).
Hva er formålet med rollekonfigurasjonsobjektet?
Rollen er ment å organisere grensesnittet til applikasjonsløsningen og å differensiere rettighetene og handlingene til individuelle brukere.
Hvordan opprette en rolle ved å bruke konfigurasjonsdelsystemer?
Utvid grenen Generelt - høyreklikk på Roller (fig. 1). Deretter kan du konfigurere restriksjoner på ulike konfigurasjonsobjekter (fig. 2)
| Figur 1 |
 |
| Fig.2 |
Hvordan lage en liste over systembrukere og bestemme deres rettigheter?
På hovedkommandopanelet går du til Verktøy – Administrasjon – Brukere.
En liste over brukere vil vises (fig. 3). Du kan legge til en ny bruker ved å klikke på
På hovedfanen skriver vi forskjellige data om brukeren, på fanen "annet" gir vi rettigheter (fig. 4).
 |
| Fig.3 |
 |
| Fig.4 |
Hvordan skiller 1C: Enterprise-autentisering seg fra operativsystemautentisering?
Som navnet antyder, ved autentisering ved bruk av 1c, må brukeren oppgi pålogging/passord direkte i 1c-systemet. Ved autentisering ved bruk av operativsystemet trenger du ikke skrive inn noe, siden 1c vil bestemme hvilken bruker operativsystemet kjører under, se dens interne liste over brukere, og hvis den finner den tilsvarende oppføringen, logg inn med disse rettigheter.
Oftest skjer OS-autentisering hvis 1c er virtualisert. Hva betyr det? At serveren og klientene fysisk befinner seg ikke under nesen din, men på et annet sted. På datamaskinen din starter du en ekstern tilkobling, som allerede er koblet til 1c.
Og nå historier fra praksis. Hvis du er engasjert i 1C-støtte, så er det ofte tilfeller der brukere klager på at et slikt og et dokument ikke blir utført, en slik og en slik rapport genereres ikke. Dette skjer ofte på grunn av det faktum at utviklerne tildelte rettigheter til et dokument til en slik og en bruker, men glemte registeret, som faktisk gjenspeiler postene til dokumentet. Gå til handlingsloggen og se på denne brukeren, hvordan han behandler dokumentet - det utilgjengelige registeret vil vises i loggen med ordlyden "brudd på brukerrettigheter".
Det er mye tristere når utviklere setter begrensninger på roller i koden - da kan du bare bruke en debugger for å se hvor, når og hva slags rettighetsbegrensninger det er, direkte i modulen til det nødvendige dokumentet/rapporten.
1C:Enterprise 8.0
Praktisk veiledningutvikler
Eksempler og typiske teknikker
Som et eksempel, la oss se på utviklingsmetoder i 1C:Enterprise 8.0, la oss ta et lite selskap - OO "Jack of All Trades", som tilbyr reparasjonstjenester for ulike husholdningsapparater.
Oppgaven er å automatisere arbeidet mot slutten av de praktiske eksemplene ved å bruke 1C:Enterprise 8.0.
1C:Bedrift
1C:Enterprise-systemet er et universelt system for å automatisere de økonomiske og organisatoriske aktivitetene til en bedrift. Siden slike aktiviteter kan være ganske forskjellige, har 1C:Enterprise-systemet evnen til å "tilpasse seg" egenskapene til det spesifikke aktivitetsområdet det brukes i. Begrepet som brukes for å betegne denne evnen er konfigurerbarhet, det vil si evnen til å tilpasse systemet til egenskapene til en spesifikk bedrift og klassen av problemer som skal løses.
Dette oppnås ved at 1C:Enterprise ikke bare er et program som eksisterer i form av et sett med uforanderlige filer, men en samling av ulike programvareverktøy som utviklere og brukere jobber med. Logisk sett kan hele systemet deles inn i to store deler, som
samhandle tett med hverandre: konfigurasjonen og plattformen som styrer driften av konfigurasjonen.
Det er én plattform (1C:Enterprise 8.0) og mange konfigurasjoner. For at enhver applikasjonsløsning skal fungere, kreves det alltid en plattform og noen (én) konfigurasjon.
Plattformen selv kan ikke utføre noen automatiseringsoppgaver, siden den er opprettet for å sikre driften av enhver konfigurasjon. Konfigurasjonen i seg selv er også ubrukelig, fordi for at den skal utføre oppgavene den ble opprettet for, må det være en plattform som styrer driften.
Eksempler på eksisterende applikasjonsløsninger inkluderer "Trade Management"-løsningen, designet for å automatisere drifts- og ledelsesregnskapsoppgaver, "Human Resources Management", designet for å implementere selskapets personalpolitikk, eller "Manufacturing Enterprise Management", som dekker hovedkonturene av regnskap og ledelse i en produksjonsbedrift.
Applikasjonsløsningen er, der det er mulig, universell for å møte behovene til et bredt spekter av virksomheter som opererer i samme aktivitetsfelt. Og dette er bra. På den annen side vil en slik allsidighet uunngåelig føre til at ikke alle funksjonene til applikasjonsløsningen vil bli brukt i en bestemt bedrift, og noen funksjoner vil mangle.
Det er her konfigurerbarheten til systemet kommer i forgrunnen, siden plattformen, i tillegg til å administrere konfigurasjonen, inneholder verktøy som lar deg gjøre endringer i konfigurasjonen som er i bruk. Dessuten lar plattformen deg lage din egen konfigurasjon fra bunnen av, om det er av en eller annen grunn.
1C:Enterprise-systemet har forskjellige driftsmoduser: 1C:Enterprise og Configurator.
Modus 1C: Enterprise er den viktigste og tjener til arbeidet til systembrukere. I denne modusen legger brukere inn data, behandler dem og mottar utdata.
Konfiguratormodus brukes av utviklere og databaseadministratorer. Det er denne modusen som gir de nødvendige verktøyene for å endre en eksisterende eller opprette en ny konfigurasjon.
Først trenger vi en infobase med en tom konfigurasjon:
La oss lage en informasjonsbase med en tom konfigurasjon
La oss starte 1C:Enterprise i konfiguratormodus. La oss utføre den første kommandoen, som begynner å fungere med en hvilken som helst konfigurasjon - Konfigurasjon - Åpne konfigurasjon.
Konfigurasjonstreet er hovedverktøyet som utvikleren arbeider med. Den inneholder nesten all informasjon om hva konfigurasjonen består av:
For å gjøre utviklerens arbeid enklere, er "alt som utgjør konfigurasjonen" samlet i flere separate grupper, og nå viser treet deg disse gruppene.
Konfigurasjonsobjekter
Konfigurasjonen er en beskrivelse. Den beskriver strukturen til dataene som brukeren skal bruke i 1C:Enterprise-modus. I tillegg beskriver konfigurasjonen ulike algoritmer for å behandle disse dataene, konfigurasjonen inneholder informasjon om hvordan disse dataene skal se ut på skjermen og på skriveren osv.
I fremtiden vil 1C:Enterprise-plattformen, basert på denne beskrivelsen, lage en database som vil ha den nødvendige strukturen og gi brukeren mulighet til å jobbe med denne databasen.
For at 1C:Enterprise-systemet raskt og enkelt skal konfigureres for de nødvendige applikasjonsoppgavene, består hele beskrivelsen som konfigurasjonen inneholder av visse logiske enheter kalt konfigurasjonsobjekter.
Hvordan jobbe med konfigurasjonstreet og hvordan lage et objekt
Før vi begynner å lage de første konfigurasjonsobjektene, bør vi forklare noen teknikker for å jobbe med konfiguratoren.
For å åpne og lukke en konfigurasjon, bruk følgende menyelementer:
Konfigurasjon - Åpne konfigurasjon, og
Konfigurasjon - Lukk konfigurasjon.
Etter at konfigurasjonen er åpnet, vises sammensetningen i konfigurasjonstrevinduet. Du kan lukke dette vinduet som alle andre Windows-vinduer, men konfigurasjonen forblir åpen (dvs. tilgjengelig for redigering). For å vise konfigurasjonstrevinduet på skjermen igjen, bruk menykommandoen Konfigurasjon - Konfigurasjonsvindu.
Det er flere måter å lage et nytt konfigurasjonsobjekt på, og du kan alltid bruke metoden som er klarere og mer praktisk for deg.
Andre vei. Du kan bruke kontekstmenyen, som hentes frem når du klikker med høyre museknapp.
Plasser markøren på den typen konfigurasjonsobjekter du er interessert i og trykk på høyre museknapp. I menyen som vises, velg Legg til.
Konfigurasjonsobjekt Katalog
Katalogkonfigurasjonsobjektet er et applikasjonsobjekt og er ment å beskrive lister over data. Directory-konfigurasjonsobjektet brukes slik at plattformen, basert på det, lager en informasjonsstruktur i databasen der for eksempel en liste over ansatte, en vareliste, en liste over kunder eller leverandører vil bli lagret.
Et karakteristisk trekk ved katalogkonfigurasjonsobjektet er at brukeren selvstendig kan legge til nye elementer i katalogen mens han arbeider. For eksempel kan en bruker legge til nye ansatte i katalogen, opprette et nytt produkt eller legge til en ny klient.
Hvert katalogelement inneholder vanligvis tilleggsinformasjon som beskriver det elementet mer detaljert. For eksempel kan hvert element i "Produkter"-katalogen inneholde tilleggsinformasjon om produsenten, utløpsdato osv. Settet med slik informasjon er det samme for alle elementene i katalogen, og for å beskrive et slikt sett bruker vi nødvendigheter Katalogkonfigurasjonsobjekt, som også i sin tur er konfigurasjonsobjekter. Fordi disse objektene er logisk relatert til Directory-objektet, kalles de underordnede. Utvikleren oppretter de fleste detaljene til katalogkonfigurasjonsobjektet uavhengig, men hvert katalogkonfigurasjonsobjekt har to "standard"-felt: kode og navn.
I tillegg kan hvert katalogelement inneholde et visst sett med informasjon, som er den samme i struktur, men forskjellig i mengde, for forskjellige katalogelementer. For eksempel kan hvert element i katalogen for ansatte inneholde informasjon om sammensetningen av den ansattes familie. For en ansatt vil dette kun være ektefellen, mens for en annen kan familien bestå av ektefelle, sønn og datter. For å beskrive slik informasjon kan brukes tabelldeler Katalogkonfigurasjonsobjekter, som er underordnede konfigurasjonsobjekter.
For enkel bruk kan katalogelementene grupperes av brukeren i henhold til et eller annet prinsipp. For eksempel, i katalogen "Husholdningsapparater" kan følgende grupper opprettes: "Kjøleskap", "TVer", "Vaskemaskiner", etc. Muligheten til å opprette slike grupper i katalogen er spesifisert av egenskapen "Hierarkisk" til katalogkonfigurasjonsobjektet. I dette tilfellet vil katalogelementet, som er en gruppe, være forelder for alle elementer og grupper som er inkludert i denne gruppen. Denne typen hierarki kalles hierarki av grupper og elementer.
En annen type hierarki er også mulig - hierarki av elementer. I dette tilfellet er ikke overordnet en gruppe katalogelementer, men et av katalogelementene i seg selv. For eksempel kan denne typen hierarki brukes når du oppretter en "divisjons"-katalog, når en divisjon er overordnet til flere andre divisjoner som er en del av den.
Elementer i en katalog kan underordnes elementer eller grupper i en annen katalog. For eksempel kan katalogen "Måleenheter" være underordnet katalogen "Produkter". Deretter, for hvert element i "Produkter"-katalogen, vil vi kunne angi måleenhetene som dette produktet kommer til lageret i. I 1C:Enterprise-systemet oppnås dette ved at for hvert konfigurasjonsobjekt kan katalogen spesifiseres liste over katalogeiere.
Noen ganger er det situasjoner der det er nødvendig at noen elementer alltid eksisterer i katalogen, uavhengig av brukerhandlinger. Anta at logikken til forretningsprosesser i en bedrift er slik at alle varer først kommer til hovedlageret, og deretter, etter behov, flyttes til andre varehus. I dette tilfellet må "Hoved"-lageret alltid eksistere i "Warehouses"-katalogen, ellers vil mottak av varer bli utført feil. Katalogkonfigurasjonsobjektet lar deg beskrive et hvilket som helst antall slike katalogelementer. De heter forhåndsdefinerte katalogelementer.
Avhengig av hvilke handlinger vi ønsker å utføre med katalogen, må vi vise katalogen i "forskjellige visninger". For eksempel, for å velge et katalogelement, er det mer praktisk å presentere katalogen i form av en liste, og for å endre et katalogelement er det mer praktisk å presentere alle detaljene til dette katalogelementet på ett form. Derfor kan katalogkonfigurasjonsobjektet ha et vilkårlig antall former, hvorav noen kan angis som hovedformene for katalogen.
Følgende tabell forklarer navnene på disse skjemaene som definert i konfiguratoren:
|
KonfigurasjonsobjektKatalog |
Katalog |
|
Grunnleggende objektform |
Katalogelementskjema |
|
Grunnleggende gruppeform |
Katalogelementgruppeskjema |
|
Grunnleggende listeskjema |
Kataloglisteskjema |
|
Hovedvalgskjema |
Skjema for valg av katalogelement eller gruppe |
|
Hovedskjema for valg av gruppe |
Skjema for valg av en gruppe katalogelementer |
Skjemaet tjener til å "visualisere" dataene i databasen. Skjemaet presenterer disse dataene i en brukervennlig form og lar deg beskrive algoritmene som vil følge brukerens arbeid med dataene som presenteres i skjemaet.
Enhver form kan beskrives i konfiguratoren. For å lage en slik beskrivelse er det et underordnet konfigurasjonsobjekt, Form. Som regel er den underordnet et av applikasjonsobjektene, men den kan eksistere uavhengig. Basert på beskrivelsen i Form-konfigurasjonsobjektet, til rett tid når brukeren jobber, vil 1C:Enterprise-plattformen opprette et Form-programobjekt som brukeren skal jobbe med.
Opprette en katalog Klienter
Nå som vi er litt kjent med egenskapene til katalogkonfigurasjonsobjektet, la oss lage flere slike objekter for å beskrive katalogene som skal brukes i databasen vår.
Siden vår LLC "Master of All Trades" tilbyr reparasjonstjenester for husholdningsapparater, er det åpenbart at for journalføring må vi angi noen listeinformasjon.
Først trenger vi en liste over selskapets ansatte som skal yte tjenester. Da vil vi trenge en liste over kunder som selskapet vårt samarbeider med. Etter dette trenger vi en liste over tjenester som selskapet vårt kan tilby og en liste over materialer som kan konsumeres. I tillegg trenger vi en liste over varehus som kan inneholde materialer fra 000 "Jack of All Trades."
La oss starte med enkle ting – en liste over ansatte og en liste over kunder. La oss åpne treningskonfigurasjonen vår i konfiguratoren og lage et nytt konfigurasjonsobjekt, Directory.
Vår oppgave vil være å lage en katalog der navnene på våre kunder vil bli lagret.
Etter at du har klikket "Legg til", åpnes systemet vindu for redigering av konfigurasjonsobjekt.
Dette er et verktøy som ble laget for å hjelpe utvikleren. Den ble laget spesielt for komplekse konfigurasjonsobjekter og lar deg raskt lage slike objekter ved å utføre sekvensielle handlinger. For å følge riktig rekkefølge av handlinger, er det "Neste" og "Tilbake"-knapper nederst i vinduet. "Neste"-knappen lar deg angi objektets egenskaper i ønsket rekkefølge (for ikke å gå glipp av noe eller hoppe videre der data som skulle ha blitt lagt inn tidligere kreves). "Tilbake"-knappen lar deg gå noen trinn tilbake hvis du oppdager at du tidligere har lagt inn ufullstendige eller feil data.
La oss sette Navn katalog - "Klienter". Navnet er hovedegenskapen til ethvert konfigurasjonsobjekt. Når et nytt objekt er opprettet, tildeler systemet det automatisk et navn. Du kan bruke navnet som er tildelt av systemet, men det er bedre å erstatte det med ditt eget brukervennlige navn. Du kan angi hvilket som helst navn, så lenge det begynner med en bokstav og ikke inneholder noen spesialtegn (for eksempel et mellomrom). For å gjøre konfigurasjonen lettere å lese, er det vanlig å lage intuitive navn og, hvis de består av flere ord, fjerne mellomrom mellom ordene og starte hvert ord med stor bokstav.
Basert på navnet vil plattformen automatisk opprette synonym -"Kunder". Ethvert konfigurasjonsobjekt har også "Synonym"-egenskapen. Det er ment å lagre et "alternativt" navn for konfigurasjonsobjektet, som vil bli brukt i grensesnittelementene til programmet vårt - det vil si at det vil bli vist til brukeren.
Derfor er det praktisk talt ingen begrensninger på synonymet, og det kan spesifiseres i en form som er kjent for mennesker.
La oss angi navnet og synonymet til katalogen
Vi vil ikke konfigurere alle egenskapene til katalogkonfigurasjonsobjektet for nå, vi vil være helt fornøyd med verdiene som systemet tilbyr for dem som standard. Klikk derfor på «Neste» tre ganger og finn deg selv på «Data»-fanen.
Det som er av interesse for oss her er lengden på koden og lengden på navnet. Kodelengde er en viktig egenskap ved en oppslagsbok. Som regel brukes en katalogkode for å identifisere katalogelementer og inneholder verdier som er unike for hvert katalogelement. Selve plattformen kan kontrollere det unike til koder og støtte automatisk nummerering av katalogelementer.
Selve plattformen kan spore kodenes unike karakter, så antallet elementer som kan inneholdes i katalogen vil avhenge av lengden på koden. Kodelengden er 5 tegn - dette er fra 0 til 99999, det vil si hundre tusen elementer. For vår lille OOO "Jack of all trades" er dette nok.
La oss gå videre til lengden på navnet. 25 tegn er tydeligvis ikke nok for oss, la oss øke lengden på navnet til 50.
La oss bli enige om lengden på koden og angi lengden på navnet
Vi vil la alle andre egenskaper for katalogkonfigurasjonsobjektet være slik de tilbys av systemet som standard, og klikker på "Lukk".
La oss nå se hva systemet vil lage basert på katalogkonfigurasjonsobjektet som vi la til. La oss kjøre menyelementet Feilsøking – Begynn å feilsøke. For å svare på spørsmålet:
Et systemvindu åpnes foran oss, i 1C:Enterprise-modus. Siden vi ikke opprettet noen brukergrensesnitt, bør vi bruke menyen som systemet oppretter som standard for å se resultatene av arbeidet vårt.
La oss kjøre menyelementet Operasjoner - Kataloger... og velg "Clients"-katalogen.
La oss utføre Operations I Directorys ... og velg "Clients"-katalogen
Systemet vil åpne en av hovedformene til katalogen - hovedlisteskjemaet.
Foreløpig er "Klienter"-katalogen tom, så la oss legge til flere elementer i den (du kan legge til et nytt element i katalogen ved å bruke menyelementet Handlinger jeg legger til, det tilsvarende ikonet eller "Sett inn"-tasten).
Legg til nye elementer i katalogen ved hjelp av en meny eller et ikon
Etter å ha lagt til elementer, vil katalogen se slik ut.
Nå kan vi gå videre til å lage den andre katalogen som skal brukes i vår konfigurasjon - "Ansatte"-katalogen.
Opprette en katalog Ansatte
"Ansatte"-katalogen vil være noe mer kompleks enn "Kunder"-katalogen. Faktum er at vi i den lagrer ikke bare etternavnet, fornavnet og patronymet til den ansatte, men også informasjon om hans tidligere arbeidsaktivitet. Denne informasjonen er homogen i sin struktur (organisasjon, start, slutt på arbeidet, stilling), men antall tidligere jobber kan variere for ulike ansatte. Derfor vil vi bruke den tabellformede delen av katalogen for å lagre slik informasjon.
La oss gå tilbake til konfiguratoren og lage et nytt katalogkonfigurasjonsobjekt. La oss kalle det "Ansatte".
Vår oppgave vil være å lage en katalog som har en tabelldel.
På "Data"-fanen, sett lengden på katalognavnet til 50 tegn og legg til en ny tabelldel i katalogen med navnet "Arbeidsaktivitet":
La oss legge til en ny tabelldel i "Ansatte"-katalogen og angi navnet...
La oss lage detaljene i tabelldelen "Arbeidsaktiviteter":
"Organisasjon" - type streng, lengde 100,
"Kom i gang" - skriv inn dato, datosammensetning - "Dato",
"Fullføring av arbeid" - datotype, datosammensetning - "Dato",
"Posisjon" - type streng, lengde 100:
La oss lage detaljene i den tabellformede delen av katalogen...
For detaljene "Start of Work" og "End of Work" valgte vi datosammensetningen - "Date", siden i 1C: Enterprise 8.0-systemet inneholder verdier av datotypen både dato og klokkeslett. I dette tilfellet bryr vi oss ikke om start- og slutttider for arbeidet.
Nå bør vi velge alternativet for å redigere katalogen. Åpenbart vil redigering i listen ikke lenger fungere for oss, siden vi i listen ikke vil kunne redigere tabelldelen av katalogen og legge inn informasjon om arbeidsaktivitet.
Derfor vil vi i katalogen "Ansatte" velge alternativet for å redigere katalogen på begge måter - både i listen og i dialogen. For å gjøre dette, gå til "Skjemaer" -fanen og sett den tilsvarende bryteren:
La oss angi alternativet for å redigere katalogen.
Opprettelsen av "Ansatte"-katalogen er fullført - nå kan du starte 1C:Enterprise i feilsøkingsmodus og fylle ut katalogen.
Utfør menyelementet Feilsøking - Fortsett feilsøkingen, til systemspørsmålet:
svar "Ja", svar på de påfølgende spørsmålene på samme måte som før.
I programvinduet som vises åpner du katalogen "Ansatte" og kontrollerer at modusen for redigering av katalogen i dialogen er satt (Handlinger-menyen - Rediger i dialog eller et lignende ikon i kommandopanelet).
Opprett ansatte Nikolai Dmitrievich Gusakov, Ivan Sergeevich Business og Valery Mikhailovich Simonov, som vist på bildene. Vær oppmerksom på at radene i den tabellformede delen av katalogen kan sorteres etter innholdet i hvilken som helst av kolonnene, eller ordnes i hvilken som helst rekkefølge ved hjelp av kommandolinjeikonene:
Du kan kontrollere rekkefølgen på rader i tabelldelen...
Nå kan vi begynne å lage den neste xNomenclature-katalogen."
Opprette en katalognomenklatur
Katalogen "Nomenklatur" vil inneholde informasjon om tjenestene som tilbys av "Jack of All Trades" LLC og om materialene som kan brukes.
Denne katalogen vil ikke være komplisert den eneste funksjonen den vil ha er tilstedeværelsen av en hierarkisk struktur. For å gjøre katalogen praktisk å bruke, vil vi gruppere tjenester i én gruppe og materialer i en annen. I tillegg, siden Master of All Trades LLC tilbyr et bredt utvalg av tjenester, vil de også logisk grupperes i flere grupper. Det samme kan sies om materialer.
Vår oppgave blir å lage en hierarkisk katalog. La oss lage en ny konfigurasjonsobjektkatalog og kalle den "Nomenklatur". La oss gå til kategorien "Hierarki" og angi flagget "Hierarkisk katalog".
La oss gjøre katalogen hierarkisk...
På "Data"-fanen setter du lengden på katalognavnet til 100 tegn.
La oss nå starte 1C:Enterprise i feilsøkingsmodus og fylle ut "Nomenklatur"-katalogen. I prosessen med å fylle ut katalogen, vil vi vise hvordan du oppretter kataloggrupper og overfører elementer fra en gruppe til en annen.
La oss lage to grupper i roten av katalogen: "Materials" og "Tjenester" (meny Handlinger – Ny gruppe):
"Samsung horisontal transformator"
"GoldStar horisontal transformator"
"Philips 2N2369 transistor",
"Gummislange"
"Elektrisk kabel":
"Diagnostikk",
"Reparasjon av innenlandsk TV"
“Importert TV-reparasjon”
og installasjonstjenester for vaskemaskiner:
"Vanntilkobling"
"Elektrisk forbindelse":
For å lagre informasjon av listekarakter, brukes objekter av Katalog-typen. Innholdet i hver katalogposisjon kan karakteriseres av et sett med egenskaper - detaljer, og har også noen underordnede enheter, også av listekarakter - de vises i tabellen. For eksempel kan en betalingsplan karakteriseres av navnet og betalingsformen, og settet med betalingsstadier etter vilkår vil bli lagret i en underordnet tabell:
Følgelig ser det konfigurasjonsmessig ut som et tre med detaljer og en underordnet tabellseksjon med sine detaljer:
Oppgave 01.01 av eksamen 1C: Plattformprofesjonell. Til hvilken verdi kan du sette "Code Series"-egenskapen til "Directory"-konfigurasjonsobjektet?
- Gjennom hele katalogen
- Innenfor grensene for underordning
- Innenfor eierens underordning
- Alle svarene ovenfor er riktige
- Svar 1 og 2 er riktige
Riktig svar er fjerde. Gjennom hele katalogen betyr generelt kontinuerlig nummerering; innenfor grensene for underordning- kontinuerlig nummerering i hierarkigruppen; innenfor eierens underordning- nummerering vil være kontinuerlig for alle posisjoner underordnet én eier (for eksempel for alle kontrakter til én motpart).
Oppgave 01.17 av eksamen 1C: Plattformprofesjonell. Hva er formålet med tabelldelene i oppslagsbøker?
- Å lagre underordnede enheter som har en objektnatur
- Å lagre underordnede enheter som ikke har en objektnatur
- For å generere trykte former for katalogelementer
Det riktige svaret er det andre. Tabelldeler lagrer underordnede enheter. Med objektnatur mener vi uavhengigheten til den tabellformede delen. Siden linjen i fanedelen av katalogen ikke har en uavhengig betydning, atskilt fra katalogen, har den ikke en objektnatur.
Oppgave 01.70 av eksamen 1C: Plattformprofesjonell. Hva inneholder infobase-objektet når du redigerer et nytt katalogelement med tabelldeler?
- Detaljer
- Referanse til katalogelement
- Tabellrader
- Svar 1 og 3 er riktige
- Alle alternativer er riktige
Det fjerde riktige svaret er at siden elementet er nytt, betyr det at det ennå ikke er registrert, det vil si at det ikke er noen kobling til det i databasen ennå.
Spørsmål 01.71 av eksamen 1C: Plattform Professional. Hva inneholder et infobaseobjekt når man redigerer et eksisterende katalogelement med tabelldeler som finnes i databasen?
- Detaljer
- Referanseelementreferanse
- Tabellrader
- Svar 1 og 3 er riktige
- Alle alternativer er riktige
Riktig svar er nummer fem i tilfelle av et eksisterende element, koblingen eksisterer allerede.
Oppgave 06.15 av eksamen 1C: Plattformprofesjonell. Hvordan vil det å slette et katalogelement som allerede er brukt i andre objekter, og deretter opprette et nytt med de samme detaljene, påvirke oppførselen til programmet?
- Ingenting, dette vil ikke påvirke programlogikken på noen måte.
- Elementet vil ha en annen intern identifikator (lenke), og dette kan påvirke programlogikken
- Et unntak forekommer
Det riktige svaret er det andre. Hvert element i katalogen, selv identisk med andre, har sitt eget nummer og sin egen GUID.
konfigurasjonstreet Er vanlig. De spiller en støttende rolle i utviklingen av konfigurasjonen.
Ris. 2.1.
Spesielt, med deres hjelp kan du administrere den logiske strukturen til den utviklede konfigurasjonen, tilpasse funksjonene for brukerinteraksjon med konfigurasjonen, de inkluderer objekter som kan konfigureres for deling med andre konfigurasjonsobjekter.
Felles objekter spiller en støttende rolle fra et utviklingssynspunkt applikasjonsløsning rolle Resultatet av arbeidet deres er mer interessant for programmereren enn for brukeren, selv om det ikke kan sies at disse objektene ikke deltar i brukerens arbeid eller er uviktige for å løse det anvendte problemet. De er en viktig del av konfigurasjonen. La oss gi en kort beskrivelse av disse objektene.
- Delsystemer. De lar deg strukturere konfigurasjonen i henhold til hvilke typer oppgaver som er løst med hjelpen. For eksempel, hvis konfigurasjonen løser problemene med regnskap og lønn, vil det være logisk å lage to delsystemer. Når du oppretter nye objekter, kan du "binde" dem til undersystemer avhengig av formålet. Bruk av delsystemer gjør det lettere å jobbe med store konfigurasjoner.
- Vanlige moduler. Inneholder prosedyrer og funksjoner som er tilgjengelige fra andre objekter. Du kan ikke definere variabler i disse modulene.
- Sesjonsalternativer. De trengs hovedsakelig for å konfigurere datatilgangsrettigheter. Disse parameterne settes ved systemoppstart. For eksempel kan denne parameteren registrere navnet på brukeren som er logget på systemet.
- Roller. Designet for å konfigurere tillatelsene til ulike brukergrupper for å få tilgang til data. Etter å ha opprettet og konfigurert en rolle, kan du tilordne den til en bruker (for å konfigurere listen over brukere, bruk menykommandoen Administrasjon > Brukere).
- Utvekslingsplaner. Definer reglene for datautveksling mellom informasjonsbaser. For eksempel kan denne mekanismen brukes til å utveksle data mellom en overordnet organisasjon og filialer eller mellom divisjoner i en organisasjon.
- Utvalgskriterier. Lar deg lage utvalgsregler som brukeren kan bruke når han arbeider med lister over data i 1C:Enterprise-modus.
- Arrangementsabonnement. Ved bruk av arrangementsabonnementer Du kan tilordne behandlere for objekthendelser. For eksempel kan behandleren kalles opp når et dokument kopieres.
- Planlagte oppgaver. Planlagte oppgaver lar deg utføre ulike planlagte operasjoner.
- Generelle skjemaer. Disse skjemaene kan brukes av ulike objekter for å løse lignende problemer.
- Grensesnitt. Lagrer brukergrensesnitt (hovedmeny, sett med verktøylinjer) som kan tilordnes forskjellige brukere. Hvert grensesnitt kan utstyres med bare de kommandoene som er nødvendig for en spesifikk bruker.
- Generelle oppsett. Lagrer generelle oppsett (utskrivbare skjemamaler), som er tilgjengelige for andre konfigurasjonsobjekter for å generere trykte versjoner av elektronisk materiale.
- Generelle bilder. Lagrer offentlig tilgjengelige bilder. De kan for eksempel brukes i skjemaer ved innstilling av bilder på knapper og i andre tilfeller.
- XDTO-pakker. XML Data Transfer Object (XDTO) er en universell datarepresentasjonsmetode som er designet for å organisere interaksjon med eksterne programvaresystemer. Spesielt med andre 1C:Enterprise 8-konfigurasjoner, med andre informasjonssystemer.
- Nettjenester. Her kan du opprette og konfigurere WEB-tjenester som gir eksport av konfigurasjonsfunksjonalitet.
- WS-lenker. Inneholder statiske lenker til publiserte WEB-tjenester. Lar deg bruke funksjonaliteten til disse tjenestene.
- Stiler. Inneholder sett med formateringsinnstillinger som du kan bruke under utvikling. Ved å bruke stilmekanismen kan du for eksempel raskt tilpasse et skjema på en forhåndsbestemt måte.
- Språk. Lar deg angi forskjellige språk der du kan konfigurere programgrensesnittet. Hvis flere språk er spesifisert i systemet, når du setter opp et objekt, blir det mulig å sette noen parametere på forskjellige språk. Som et resultat fører dette til at systemgrensesnittet kan eksistere for forskjellige språk.
2.2. Oversikt over 1C:Enterprise 8-objekter: brukte objekter
Applikasjonsobjekter brukes til utvikling applikasjonsløsning. Det er disse objektene som er "synlige" for brukeren som jobber med de fleste av dem i 1C:Enterprise-modus. La oss gi en beskrivelse av brukte objekter (fig. 2.2).
Ris. 2.2.
- Konstanter. Designet for å lagre informasjon som enten ikke endres i løpet av organisasjonens aktiviteter eller endres svært sjelden. For eksempel kan du lagre navnet på organisasjonen, fullt navn på direktøren og andre lignende data i en konstant.
- Kataloger. Designet for å lagre lister med lignende data. For eksempel lagrer kataloger lister over kunder, ansatte, varer og materialer.
- Dokumentasjon. Med deres hjelp kommer informasjon inn i systemet. Dokumenter kan fungere som elektroniske analoger til primære regnskapsdokumenter. Objekter som: Nummerere(for å sikre kontinuerlig nummerering av ulike dokumenter) og Sekvenser(for å sikre korrekt dokumentrekkefølge).
- Dokumentlogger. De brukes til å gruppere dokumenter av forskjellige typer.
- Overføringer. De brukes til å lagre sett med verdier spesifisert under konfigurasjonsprosessen og ikke endret mens brukeren arbeider med konfigurasjonen.
- Rapporter. De brukes til å lage rapporter, som er et middel til å presentere utdataene til regnskapssystemet.
- Behandlinger. Designet for å behandle informasjon og utføre ulike operasjoner med data.
- Karakteristiske typeplaner. De brukes til å beskrive typene egenskaper til objekter.
- Kontoplaner. Brukes til regnskapsformål. De representerer lister over regnskapskontoer. Brukes sammen med regnskapsregistre.
- Beregningstypeplaner. Brukes til å beskrive typer beregninger og deres sammenhenger, brukt i forbindelse med beregningsregistre.
- Informasjonsregistre. Designet for å akkumulere informasjon langs flere dimensjoner med muligheten til å lagre historikken for dataendringer og med muligheten til å lagre ikke-numeriske data.
- Akkumulasjonsregistre. Designet for å lagre data i sammenheng med flere dimensjoner, støtter de innhenting av informasjon om saldo og omsetning av lagrede mengder.
- Regnskapsregistre. Lagre informasjon om regnskapstransaksjoner.
- Beregningsregistre Lagre informasjon om beregninger. De brukes hovedsakelig til lønnsformål.
- Forretningsprosesser. Lar deg lage strukturer som automatiserer utførelsen av flertrinnsoperasjoner. For eksempel flytting av et dokument mellom ulike tjenestemenn i en organisasjon.
- Oppgaver. Brukes sammen med Forretningsprosesser. Nødvendig for å holde oversikt over oppgaver etter utøver.
2.3. Oversikt over 1C:Enterprise 8 objekter: underordnede objekter
Underordnede objekter er underordnet andre konfigurasjonsobjekter. For eksempel, i fig. I figur 2.3 kan du se dokumentkonfigurasjonsobjektet, som eier flere underordnede objekter. La oss liste opp og beskrive dem.
Ris. 2.3.
Forutsetninger. Attributter lar deg legge til flere egenskaper til et objekt. For eksempel, hvis vi trenger å kunne legge inn transaksjonsbeløpet i et dokument, kan vi legge inn de tilsvarende detaljene i det.
Borddeler. De brukes hvis du trenger å legge til et vilkårlig antall poster (faktisk tilleggsegenskaper) i form av en tabell til et dokument (eller et annet objekt som tabelldelen er underordnet). Tabelldelene har på sin side detaljer.
Skjemaer. Skjemaer brukes til å organisere inntasting og visning av informasjon. I 1C:Enterprise 8 er det en spesiell editor som er designet for å utvikle og endre skjemaer.
Oppsett. Layouter brukes til å beskrive trykte former for ulike objekter. Layouten inneholder "blanks", som, når du danner et trykt skjema for et bestemt objekt, fylles med data.
I fig. 2.4 presenterer flere underordnede objekter - denne gangen for applikasjonsobjekter Dokumentlogg Og Akkumulasjonsregister.
Ris. 2.4.
Grafer. Grafer dokumentjournal brukes til å vise informasjon om dokumenter som er inkludert i journalen.
Målinger. Registerdimensjoner er objekter i sammenheng med hvilke indikatorer i registre registreres.
I den siste leksjonen lærte vi HVA 1C-objekter er.
La oss nå se hvilke 1C-objekter som finnes og hva er de for?
Hovedobjektene i 1C-konfigurasjonen utgjør selve essensen av konfigurasjonen det er nettopp på grunn av forskjellene i hovedobjektene at 1C Accounting skiller seg fra 1C Trade Management-konfigurasjonen.
Hoved 1C konfigurasjonsobjekter - for regnskap
Disse 1C-konfigurasjonsobjektene er et regnskapsmiddel.
1C-dokumenter
Essensen av regnskap er å legge inn dokumenter i en database. Hvert dokument betyr at noe skjedde i selskapets liv. Dokumentet registrerer denne hendelsen.
For eksempel «Kjøp av varer», «Salg av varer» osv.
1C-kataloger
Det er tydelig at ulike dokumenter fungerer med samme data. For eksempel blir produktet "Shovel" først kjøpt og deretter solgt. Produktet er det samme.
For ikke å gå inn på nytt flere ganger, legges den inn i katalogen én gang, og deretter brukes katalogverdien "Shovel". Betydningen forblir den samme.
Kataloger er slike lister med forskjellige verdier.
Registrerer 1C
Dokument 1C registrerer én operasjon. Det er helt klart at i livet til et selskap er det hundrevis og millioner av dokumenter.
Resultatet av [flyttingen] av dokumentet er en endring i minst ett siffer i resultatene av operasjoner. For eksempel var det 0 produkt, nå +10.
Hvert dokument flytter dette sifferet i minst ett av registrene. Resultatet er en tabell over slike bevegelser, hvorfra totaler kan beregnes.
Essensen av registre er å måle resultatene av en virksomhets virksomhet.
Det finnes flere typer 1C-registre:
- 1C informasjonsregistre er enkle tabeller som Excel, ofte brukt til å lagre informasjon relatert til 1C-kataloger
- 1C akkumuleringsregistre - tabeller som mottar totaler for sine bevegelser, saldo (2+10, saldo 12) og omsetning (2+10, omsetning 10), brukes til operasjonell (lager) regnskap
- 1C regnskapsregistre - tabeller basert på regnskapskontoplanen, brukt til regnskap
- 1C-beregningsregistre - tabeller basert på planer for typer beregninger, brukes til å vedlikeholde lønnsposter.
Grunnleggende 1C-konfigurasjonsobjekter - for brukeren
1C-brukerobjekter tillater ikke regnskap, men kreves for å gjøre det praktisk for brukeren å jobbe med programmet.
1C dokumentlogger
Lar deg kombinere lister over dokumenter for brukeren etter type. For eksempel magasinet "Lagerdokumenter" eller "Bankdokumenter". Hver journal inneholder vanligvis flere typer dokumenter.
1C rapporterer
Informasjonsregistre lar deg beregne resultatet. Imidlertid må brukeren jobbe med det i en form som er praktisk for ham.
Det finnes 1C-rapporter for dette.
Rapporten er et ferdig beregnet resultat av virksomhetens aktiviteter i en form som ligner på Excel eller Word.
Rapporten kan eksistere separat fra konfigurasjonen og databasen - den kan lagres i en fil. I dette tilfellet kalles det en "ekstern rapport".