Slik legger du til ytterligere detaljer til et katalogelement i 1C Accounting 8.3 (revisjon 3.0)

2016-12-07T18:20:33+00:00

Det hender at vi mangler mulighetene som allerede er tilgjengelige i 1C. Og du trenger ikke alltid å kontakte en programmerer. Jeg skal fortelle om en av disse sakene i forhold til den nye 1C: Regnskap 8.3 (utgave 3.0).

La oss ikke ha nok felt til å legge inn informasjon om våre motparter. Og vi ønsker å legge til et nytt felt, som vil bli kalt "Status" og har en av tre verdier - "Høy", "Middels" og "Lav". Jeg vil fortelle deg nedenfor trinn for trinn hvordan du legger til et slikt felt uten å gå inn i konfiguratoren.

1. Gå til "Administrasjon"-delen og velg " Generelle innstillinger" ():

2. Finn og merk av for "Ytterligere detaljer og informasjon" hvis den ikke allerede er merket. Klikk på koblingen "Ytterligere detaljer":

3. I venstre del av innstillingsvinduet som åpnes, velg "Konto". Klikk på Ny-knappen på verktøylinjen.

4. Et vindu for å lage nye detaljer for elementer i "Motparter"-katalogen har åpnet seg. Skriv inn "Status" i Navn-feltet. La "Tilleggsverdi" være verditypen, men husk i fremtiden at andre verdityper er mulige (streng, tall, dato osv.). Men det vi trenger nå er tilleggsverdien, siden vi ønsker å gi brukeren et begrenset utvalg av tre alternativer.

5. For å opprette hvert alternativ, gå til «Verdier»-fanen, klikk på «Opprett»-knappen der, skriv inn navnet på verdien (for eksempel «Høy») og klikk på «Lagre og lukk»-knappen.

6. Og så videre til alle tre verdiene er opprettet med navnene "Høy", "Middels" og "Lav" som vist i figuren nedenfor. Klikk på "Lagre og lukk"-knappen.

7. Som du kan se, i listen ekstra detaljer Motparten har nå Status-attributtet.

8. Hvis vi nå går til et element i motpartskatalogen, vil vi se helt nederst i skjemaet et nytt statusfelt ( Hvis du ikke ser det, utvider du «Tilleggsdetaljer»-gruppen som er skjult i skjemaet.):

9. I dette feltet kan vi erstatte en av de tre verdiene vi opprettet. Du kan gjøre et valg ved å bruke dette feltet i form av en liste, det kan vises i rapporter osv.

Nedenfor er de viktigste 1C-objektene som brukes når du arbeider med administrerte skjemaer. Det er gitt korte kodeeksempler som demonstrerer den tradisjonelle bruken av disse objektene når du skriver 1C-konfigurasjoner.

Denne formen

Brukes i skjemamodulen, i prosedyrer&På klienten og &På serveren.

Gir deg tilgang til både skjemaelementer og detaljer.

Skjemaelementet er tilgjengelig gjennom et objekt Elementer og ser slik ut:

ThisForm.Elements.VersionNumber.Header = "v."+ProgramVersion;

Tilgang til attributter som finnes på skjemaet skjer slik:

ThisForm.Advertisement Text="Hei, kamerater!";

Forenklet tilgang til skjemaelementer og detaljer

I prinsippet trenger du ikke spesifisere nøkkelordet i skjemamodulen Denne formen . Du kan få tilgang til skjemaelementer og detaljer på en forenklet måte:

// Formelement

Elements.VersionNumber.Header = "v."+ProgramVersjon;

// Skjemadetaljer

Annonse Text="Hei, kamerater!";

Funksjoner for å få skjemadetaljer (viktig!)

Hvis formattributtet har en enkel type - Streng, tall, dato ... så kan du få (sette) verdien av attributtet bare ved navn:

Text=Produktnavn; // Produktnavn er et skjemaattributt

På denne måten er det imidlertid umulig å få detaljer av en "kompleks" type -Verditabell, Verdienes tre . Hvis du prøver å få et attributt med denne typen ved navn, vil et objekt av typen bli returnertDataFormsCollection.

For å få verdien av et attributt med en "kompleks" type, må du bruke funksjonenFormAttributesValue():

CurrentTable=FormAttributesValue("SelectedConstructionObjects");

For å angi verdien til et "komplekst" attributt, kan du bruke funksjonenValueInFormAttributes(<Значение>, <ИмяРеквизита>) , er begge parametere påkrevd.

Funksjoner FormAttributesValue() Og ValueInFormAttributes()kun tilgjengelig på serveren.

En gjenstand

Strengt tatt dette nøkkelord innenfor skjemanr. Ganske enkelt, når et skjema opprettes, for eksempel et elementskjema, oppretter 1C automatisk et attributt på skjemaet med navnet En gjenstand . Gjennom denne rekvisitten egenskapene til det gjeldende objektet som redigeres på skjemaet er tilgjengelige.

eller, en mer fullstendig notasjon:

Dette objektet

Inneholder selve objektet. Beregnet for å få et objekt i en objektmodul eller en skjemamodul.

Bruk: Lesebeskyttet.

Tilgjengelighet: Server, tykk klient, ekstern tilkobling.

Brukerens arbeid med oppslagsverk og dokumenter i 1C består i å fylle ut felt på skjemaet.

1C-detaljer er katalog- og dokumentfelt som vises på skjemaet som brukeren kan fylle ut.

La oss se nærmere på temaet detaljer i 1C.

Hva er 1C-detaljer

Hver katalog og 1C-dokument består av et sett med felt. Slike felt kalles 1C-detaljer (for en 1C-programmerer).

I konfiguratoren, i 1C-konfigurasjonstreet, åpne en hvilken som helst katalog eller dokument, og du vil se grenen Detaljer. Dette er en liste over katalogdetaljer (felt).

Se hvordan de samme 1C-detaljene ser ut på 1C-katalogskjemaet.

Hvert 1C-attributt har egenskaper som indikerer hvilken type verdi som er lagret i attributtet (streng, tall osv.) og hvordan brukeren vil jobbe med det.

Høyreklikk på et hvilket som helst 1C-attributt og klikk på Egenskaper. En liste over egenskaper for det valgte attributtet åpnes i vinduet til høyre.

Hovedegenskapene til 1C-detaljer:

Standard 1C detaljer

Som du la merke til, på katalogskjemaet er det 1C-detaljer som ikke er oppført i konfiguratoren: gruppe, navn, BIC.

Kataloglisteskjemaet inneholder også 1C-detaljer som ikke er på listen: slettemerke.

Dette er standard 1C-detaljer. Hva det er? Alle har et standardsett med 1C-detaljer. For kataloger er dette for eksempel kode og navn. For dokumenter er dette dato og nummer.

Standard 1C-detaljer kan sees som følger:

• Gå til editoren til 1C-objektet (katalog eller dokument) ved å dobbeltklikke på det med musen
• Velg kategorien Data i redigeringsprogrammet som åpnes
• Her kan du konfigurere standarddetaljer Kode og navn på katalogen
• Klikk på 1C Standard Details-knappen for å se hele listen.

Generelle 1C-detaljer

Fra og med versjon 1C 8.2.14 ble 1C introdusert nytt objekt 1C – Generelle 1C-detaljer. Ved å bruke den kan du legge til en egenskap (felt) som vil være til stede i mange kataloger og dokumenter samtidig.

Egenskaper for generelle 1C-attributter:

• Automatisk bruk – legger til generelle 1C-detaljer til alle kataloger og dokumenter samtidig
• Komposisjon – lar deg legge til generelle 1C-detaljer kun til de nødvendige katalogene og dokumentene (autobruk er da satt til Ikke bruk).

Hvordan legge til 1C-detaljer

Høyreklikk på grenen 1C Details til ønsket katalog og velg Legg til.

Vi må skrive inn navnet på 1C-attributtet, for eksempel "Kontoradresse" og synonymet "Kontoradresse". La standardtypen være streng, men merk av for Ubegrenset lengde.

La oss legge til et annet 1C-attributt på samme måte, bare vi velger den boolske typen og kaller den "Works on Weekends".

Hvordan vise detaljer på skjema 1C (tykk klient 1C)

La oss utvide Forms-grenen til den samme katalogen. For å åpne skjemaet, velg elementskjemaet og dobbeltklikk på det med musen.

Dra kanten av formen med musen og strekk den (valgfritt).

Klikk på "Dataplassering"-knappen i konfiguratorpanelet. Du kan også bruke menyen Skjema / Dataplassering.

Du ser at våre detaljer ikke vises på skjemaet. Sjekk dem. Og også avmerkingsboksene Sett inn etiketter og Plasser automatisk.

Hvordan vise detaljer på skjema 1C ( tynn klient 1C)

La oss utvide Forms-grenen til den samme katalogen. Velg formen på elementet og dobbeltklikk på det med musen.

Utvid objektlinjen i kategorien Detaljer. Du vil se en liste over detaljer som tidligere ble lagt til i katalogen.

Nå er det bare å dra det nødvendige attributtet fra det høyre vinduet til det venstre, og det vil vises på skjemaet.

Skjema 1C detaljer

I den tykke klienten har skjemaet sine egne detaljer. De er plassert i fanen Detaljer.

Disse detaljene lagres ikke i databasen, men de kan brukes på skjemaet for feltene som trengs for å jobbe med skjemaet.

Du la for eksempel til et hakemerke i skjemaet. Når du klikker på det, skjer det noe på skjemaet. Betydningen av avkrysningsboksen spiller ingen rolle for deg (du trenger ikke å skrive den ned) - den brukes bare til å bytte skjema når du arbeider med den. I dette tilfellet bruker du ikke katalogattributtet som data, men formattributtet.

Periodiske detaljer 1C

I 1C versjon 7.7 var det periodiske detaljer. Betydningen deres er denne: betydningen av rekvisittene er forskjellig på forskjellige datoer. For eksempel er verdien 1. september én, og 1. oktober en annen. Samme rekvisitter.

I 1C 8 er det ingen periodiske detaljer. Dette implementeres som følger:

Skjemadetaljer

Et sett med skjemadetaljer beskriver sammensetningen av dataene som vises, redigeres eller lagres i skjemaet. Samtidig gir ikke selve skjemadetaljene muligheten til å vise og redigere data. Skjemaelementer (se delen "Skjemaelementer" i dette kapitlet) knyttet til skjemadetaljer brukes til visning og redigering. Settet med alle skjemadetaljer vil bli kalt skjemadata.

Viktig! Det må huskes at, i motsetning til konvensjonelle former, alle data kontrollert form må beskrives i form av detaljer. Det er ikke tillatt å bruke skjemamodulvariabler som datakilder for skjemaelementer.

Det er mulig å tildele Grunnleggende skjemadetaljer, dvs. attributter som vil bestemme standardfunksjonaliteten til skjemaet (skjemautvidelse). Det bør huskes at et skjema bare kan ha én hovedattributt.

Skjemautvidelse– dette er tilleggsegenskaper, metoder og skjemaparametere til ManagedForm-objektet, karakteristiske for objektet som er hovedelementet i skjemaet.

Under skjemautviklingsprosessen kan du eksplisitt angi muligheten til å vise og redigere spesifikke skjemadetaljer, når det gjelder roller, ved å bruke egenskapene Vis og Rediger (for mer informasjon, se delen "Rollebaserte skjemainnstillinger" i "Redaktører" ” kapittel). I tillegg kan tilgjengeligheten til et bestemt attributt i selve skjemaet konfigureres ved hjelp av funksjonelle alternativer (mer informasjon om funksjonelle alternativer finnes i kapittelet "Konfigurasjonsgrensesnittadministrasjon").

Skjemaattributt egenskap Lagrede data er en indikasjon på at interaktiv endring av detaljene vil resultere i et forsøk på å låse skjemadataene for redigering, samt automatisk installasjon et tegn på modifisert form.

Datatyper tilgjengelig i administrert form

Et administrert skjema skiller seg også fra et vanlig skjema i hvilke typer data det fungerer med. Hvis vanlig form fungerer med de fleste typene som 1C:Enterprise tilbyr (inkludert typene DirectoryObject, DocumentObject, etc.), og i administrert form kan følgende kategorier av typer skilles:

• typer som brukes direkte i skjemaet er de typene som finnes på siden av tynn- og webklienten (for eksempel Number, DirectoryLink.Products, GraphicScheme, TabularDocument);

• typer som vil bli konvertert til spesielle datatyper – administrerte skjemadatatyper. Slike typer vises i listen over skjemadetaljer i parentes, for eksempel (DirectoryObject.Products);

• dynamisk liste (for mer informasjon, se delen "Dynamisk liste" i dette kapittelet).

Konvertering av applikasjonsobjekter til skjemadata

Noen applikasjonstyper (som DirectoryObject osv.) eksisterer ikke på tynn- og webklientsiden (se kapittelet Managed Application Concept for flere detaljer). Derfor, for å representere slike applikasjonstyper i plattformen, har det blitt introdusert spesielle datatyper, designet for å fungere i administrerte former. Denne funksjonen til en administrert applikasjon gjør det nødvendig å konvertere applikasjonsobjekter til skjemadata (og omvendt).

Følgende datatyper brukes:

• Form DataStructure – inneholder et sett med egenskaper av en vilkårlig type. Egenskaper kan være andre strukturer, samlinger eller strukturer med samlinger. Denne typen er representert for eksempel i skjemaet DirectoryObject.

• En FormDataCollection er en liste over innskrevne verdier som ligner på en matrise. Et samlingselement er tilgjengelig med indeks eller identifikator. Tilgang med ID er kanskje ikke tilgjengelig i noen tilfeller. Dette er på grunn av typen applikasjonsobjekt som er representert av denne samlingen. Identifikatoren kan være et hvilket som helst heltall. Denne typen er representert for eksempel i skjemaet tabelldel.

• Form DataStructureWithCollection er et objekt som er representert som en struktur og en samling på samme tid. Det kan behandles som alle disse enhetene. Denne typen representerer for eksempel et sett med poster i et skjema.

• Form DataTree – et objekt designet for å lagre hierarkiske data.

Et applikasjonsobjekt er representert av enten ett eller flere skjemadataelementer. I generelt syn Hierarkiet og sammensetningen av skjemadataene avhenger av kompleksiteten og sammenkoblingen av applikasjonsobjektene til det administrerte skjemaet.

For eksempel vil et dokument som inneholder en tabelldel representeres av et objekt av typen FormDataStructure (selve dokumentet), som et objekt av typen FormDataCollection (tabelldelen av dokumentet) er underordnet.

Viktig! Når du utvikler en konfigurasjon, er det viktig å huske at applikasjonsobjekter kun er tilgjengelige på serveren, mens skjemadataobjekter kan brukes både på serveren og klienten.

Sende data mellom klient- og serverdelen av et administrert skjema

Faktisk kan vi si at skjemadata er en enhetlig representasjon av data fra ulike applikasjonsobjekter som skjemaet fungerer jevnt med og som finnes både på serveren og klienten. Det vil si at skjemaet inneholder en viss "projeksjon" av applikasjonsobjektdata i form av egne datatyper og utfører konvertering mellom dem om nødvendig. Imidlertid, hvis konfigurasjonsutvikleren implementerer sin egen databehandlingsalgoritme, må han utføre datakonvertering (fra spesialiserte typer til applikasjonstyper og omvendt) uavhengig.

Når du redigerer skjemadetaljer i en spesialisert editor (for flere detaljer, se delen "Skjemadetaljer" i kapittelet "Redaktører"), er det mulig å påvirke overføringen av data mellom klienten og serveren mens skjemaet kjører. Kolonnen til detaljredaktøren brukes til dette. Bruk alltid. Effekten av denne egenskapen er forskjellig for tre typer attributter:

• For attributter som er underordnet en dynamisk liste (kolonne dynamisk liste):
  • egenskap aktivert – attributtet leses alltid fra databasen og inkluderes i skjemadataene;
  • egenskapen er deaktivert - attributtet leses fra databasen og inkluderes i skjemadataene bare når det er synlig i dette øyeblikket et formelement knyttet til et attributt eller dets underordnede attributt.

• For rekvisitter underordnet bevegelsessamlingen:
  • egenskapen er aktivert – dokumentbevegelser leses fra databasen og vil være til stede i skjemadataene;
  • egenskapen er deaktivert - dokumentbevegelser vil ikke bli lest fra databasen og vil ikke inkluderes i skjemadataene (hvis det ikke er noe skjemaelement som refererer til dokumentbevegelser).

• Andre skjemadetaljer:
  • egenskapen er aktivert – attributtet vil være til stede i skjemadataene, uavhengig av om det er minst ett skjemaelement som er knyttet til attributtet eller dets underordnede attributt;
  • egenskapen er deaktivert - attributtet vil bare være til stede i skjemadataene hvis det er et skjemaelement knyttet til attributtet eller dets underordnede attributt. I motsetning til dynamiske listeattributter, spiller ikke synligheten til elementet knyttet til attributtet noen rolle her.

Merk. Det bør huskes at egenskapen satt på overordnet attributt påvirker alle underordnede attributter. For eksempel, hvis Bruk-egenskapen alltid er ryddet for den tabellformede delen av dokumentet, vurderer systemet at denne egenskapen også er ryddet for alle underordnede detaljer (til tross for den faktiske tilstanden til eiendommen).

Metoder for å konvertere applikasjonsobjektdata til skjemadata

For å konvertere applikasjonsobjekter til skjemadata og tilbake, er det et sett med globale metoder:

• ValueInFormData(),
• FormDataInValue(),
• CopyFormData().

Viktig! Metoder som fungerer med applikasjonsobjekter er bare tilgjengelige i serverprosedyrer. Metoden for å kopiere verdier mellom skjemadata er tilgjengelig på serveren og på klienten, siden den ikke krever applikasjonsobjekter som parametere.

Når du konverterer skjemadata til et applikasjonsobjekt, må du vurdere deres kompatibilitet.

• ValueInFormData() – konverterer et applikasjonstypeobjekt til skjemadata;
• FormDataInValue() – konverterer skjemadata til et applikasjonstypeobjekt;
• CopyFormData() – kopierer skjemadata som har en kompatibel struktur. Returnerer True hvis kopieringen var vellykket, eller False hvis objektstrukturen er inkompatibel.

Merk. Når du utfører standardhandlinger (åpner et skjema, utfører en standard skrivekommando, etc.) av et skjema med hoveddetaljene, utføres konverteringen automatisk.

La oss gi et eksempel på hvordan du bruker datatransformasjon i dine egne algoritmer.

&OnServerProcedure When CreateOnServer(Failure, StandardProcessing)

ObjectProduct = Directories.Products.FindByName("Kaffekanne").GetObject(); ValueInFormData(ObjectItem, Object);

Slutt på prosedyre

&OnClient Prosedyre Write()

WriteOnServer();

Slutt på prosedyre

&OnServer-prosedyre WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

Slutt på prosedyre

ManagedForm-objektet har også metoder tilgjengelig på serveren:

• ValueВFormAttribute() – konverterer et applikasjonstypeobjekt til det angitte skjemaattributtet.
• FormAttributeVValue() – konverterer et skjemadataattributt til et objekt av en applikasjonstype.

Å bruke disse metodene er vanligvis mer praktisk, siden de for eksempel har informasjon om typen skjemadetaljer. I tillegg setter Form AttributesValue()-metoden samsvaret mellom skjemadataene og objektet, som brukes når meldinger genereres. Du kan lese mer om dette i kapitlet "Tjenestenavigasjonsfunksjoner".

La oss gi et eksempel på bruk av disse metodene.

&OnServer-prosedyre RecalculateOnServer()

// Konverterer Object-attributtet til et applikasjonsobjekt. Document = Form AttributesValue("Objekt"); // Utfører omberegning ved hjelp av metoden definert i dokumentmodulen. Document.Recalculate(); // Konverterer applikasjonsobjektet tilbake til en rekvisitt. ValueВFormAttributes(Dokument, "Objekt");

Slutt på prosedyre

Programvaregrensesnitt

FormDataTree

• FinnById
• GetItems

Beskrivelse:

Designet for å modellere et tre i administrerte skjemadata.

Dette objektet kan serialiseres til/fra XDTO. XDTO type tilsvarende dette objektet er definert i navneområdet. XDTO-typenavn:

GetItems

Syntaks:

GetItems()

Returverdi:

Type: Skjema Datasamling av treelementer.

Beskrivelse:

Får en samling treelementer på toppnivå.

Tilgjengelighet: klient, server, tynnklient, webklient.

FinnById

Syntaks:

FindById(<Идентификатор>)

Alternativer:

<Идентификатор>(obligatorisk)

Type: Antall. Treelementidentifikator.

Returverdi:

Type: FormDataTreeElement.

Beskrivelse:

Får et samlingselement etter ID.

Tilgjengelighet: klient, server, tynnklient, webklient.

FormDataTreeItem

Egenskaper:

<Имя свойства> (<Имя свойства>)

• GetId (GetId)
• GetParent
• GetItems
• Eiendom

Beskrivelse:

Skjemadatatreelement.

FormDataTreeItemCollection

Samlingselementer: DataFormTreeElement

For et objekt er det mulig å krysse samlingen ved å bruke operatoren For hver... Fra... Loop. Traverseringen velger elementene i samlingen. Det er mulig å få tilgang til et samlingselement ved å bruke [...]-operatøren. Indeksen til elementet sendes som et argument.

• Sett inn
• Legg til
• Indeks (IndexOf)
• Telle
• Klar
• Få
• Bevege seg
• Slett

Beskrivelse:

Samling av treelementer.

Tilgjengelighet: klient, server, tynnklient, webklient.

Se også:

• Skjema DataTreeElement, GetElements-metoden
• DataFormTree, metoden GetItems

Funksjoner ved å jobbe med et verditre

Treoppdatering

Det er et problem faller plattformer ved oppdatering av treet.

Hvis en node i treet har blitt utvidet og en underordnet node er valgt, så når du oppdaterer treet med funksjonen ValueInFormData plattformen faller.

Løsning: Du må tømme treet før du oppdaterer.

For eksempel:

&På serverprosedyren ClearTree(elements) For hvert element fra elementene Loop ClearTree(element.GetElements()); EndCycle; elementer.Clear(); Slutt på prosedyre

&På serverprosedyren Fyll konsepttre() dConcepts = srProperties.Byg konsepttre(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Slutt på prosedyre

&OnClient-prosedyre OnDateOnChange(Element) Fill ConceptTree(); Sluttprosedyre

Generelle detaljer i 1C 8.3 er et plattformmetadataobjekt som lar deg bruke ett attributt for mange konfigurasjonsobjekter (kataloger, dokumenter, kontoplaner, etc.). Objektet ble laget hovedsakelig for å gjøre utviklerens arbeid enklere og for å skille data.

Generelle detaljer ble opprinnelig implementert i versjon 1C 7.7, men utviklerne inkluderte det ikke umiddelbart i plattformversjon 8. Mekanismen for generelle detaljer ble introdusert av 1C-utviklere bare i utgivelse 8.2.14.

Det er veldig praktisk å legge til generelle detaljer for ikke å endre standardobjekter i konfigurasjonen. Jeg bruker dem ofte sammen med .

Etter å ha lagt til et generelt attributt, kan det brukes i spørringer og vises på objektskjemaet - Utad er det ikke forskjellig fra vanlige rekvisitter.

Den eneste begrensningen for generelle detaljer er manglende evne til å bruke dem i .

La oss se på de grunnleggende innstillingene og egenskapene til generelle detaljer som skiller seg fra andre konfigurasjonsobjekter:

Sammensatt— en liste over objekter som de generelle detaljene vil bli brukt til, minner om å sette opp en utvekslingsplan.

Få 267 videotimer på 1C gratis:

Automatisk bruk- innstillingen bestemmer om generelle rekvisitter skal brukes for de objektene som har spesifisert "Automatisk" bruksmodus.

Dataseparasjon— Vi vil vurdere denne innstillingen separat.

Separasjon av data i 1C ved hjelp av vanlige detaljer

Dataseparasjon- en mekanisme som ligner på mekanismen. Imidlertid ytelse denne mekanismen mer effektiv og enklere å konfigurere.

Mekanismen lar deg konfigurere visningen av bare elementer som brukeren kan se. Du kan for eksempel skille mellom alle objekter (dokumenter, kataloger osv.) der en bestemt organisasjon er installert.

Sette opp dataseparasjon ved hjelp av generelle 1C-detaljer

For å konfigurere de generelle detaljene, må du spesifisere dataseparasjonen - Dele opp. Umiddelbart etter å ha klikket, vil systemet tilby å opprette standard regnskapsparametere:

I dette tilfellet vil det være nødvendig å spesifisere sesjonsparametrene når du starter systemet hvordan du gjør dette ble beskrevet med et eksempel i artikkelen.

Dette fullfører oppsettet - brukeren vil kun ha tilgang til informasjonen som er spesifisert i de valgte sesjonsparametrene.

Eksempel på bruk av vanlige rekvisitter

La oss se på å sette opp generelle rekvisitter i 1C 8.3 ved å bruke eksempelet på en rammekonfigurasjon og rekvisitter Organisasjon:

Det er 3 dokumenter i systemet der det er nødvendig å angi detaljene for organisasjonen: disse er kvitteringsfakturaen, utgiftsfakturaen og lønnslisten.

Oppsettet er enkelt:

1. Vi oppretter et nytt Generelt attributt, spesifiser typen - DirectoryLink.Organization.
2. I sammensetningen ordner vi for våre dokumenter - Bruk.

Det er det, oppsettet er fullført!

La oss se resultatet:

Systemet viser generelle detaljer "som om de var dine egne": i forespørsler, i skjemadetaljer og andre steder. Dette er så magi! 🙂

Generelle krav 1C 8.3 er ikke lagt til