Het hele idee om programmatisch te werken met voorgedefinieerde elementen is naar mijn mening zeer correct. Er zijn slechts enkele nuances waarmee u rekening moet houden bij het werken.
Eerst moet u voor uzelf duidelijk begrijpen dat er voorgedefinieerde elementen in de configuratie zijn en dat er voorgedefinieerde elementen in de infobase (IB) zijn. Technisch vooraf gedefinieerde informatiebeveiligingselementen zijn de meest voorkomende elementen van woordenboeken, waarin het kenmerk "PredefinedDataName" aangeeft met welk vooraf gedefinieerd configuratie-element ze overeenkomen. Ze verschillen niet meer van gewone elementen. Dienovereenkomstig kan elk gewoon IB-element voorgedefinieerd worden gemaakt, elk voorgedefinieerd gewoon. Om dit te doen, voert u gewoon de gewenste waarde in de rekwisieten in. "Vooraf gedefinieerde gegevensnaam".
Periodiek blijkt deze eigenschap niet de waarde te zijn die de ontwikkelaar heeft verstrekt. Hierdoor ontstaan er fouten in het werk van 1C. Van kritisch, waarbij werken in principe onmogelijk is, naar niet-kritisch, waarbij de logica van de algoritmen wordt geschonden.
Het kan voorwaardelijk worden onderscheiden drie soorten fouten:
1. "Er ontbreekt een vooraf gedefinieerd item in de gegevens";
3. Ongeldige aanduiding van een vooraf gedefinieerd element;
1. "Er ontbreekt een vooraf gedefinieerd item in de gegevens" - o De afwezigheid van een vooraf gedefinieerd element beschreven in de configuratie in de IB-gegevens.
Dit is het gemakkelijkste type fout om te debuggen en op te lossen. De eenvoud is dat het platform correct genoeg rapporteert over deze situatie "Er ontbreekt een vooraf gedefinieerd element in de gegevens" en het is vrij duidelijk hoe dit op te lossen.
Bij verwijzing naar het ontbrekende element in de code "Directories.Types of ContactInformation.EmailContactPerson" wordt het bericht weergegeven
Bij toegang tot een item in het verzoek "VALUE (Directory.Types of ContactInformation.EmailContactPerson)", wordt het volgende bericht weergegeven:
Deze fout treedt op als een element wordt beschreven in de configuratie, maar het element is er niet aan gekoppeld in de database.
Laten we om te beginnen duidelijk maken dat deze situatie niet altijd verkeerd is. Het is heel goed mogelijk om vooraf gedefinieerde gegevens te gebruiken in een soort programmalogica, die voor de meeste gebruikers misschien niet worden gebruikt. Om het naslagwerk niet voor alle gebruikers van de configuratie onoverzichtelijk te maken, is het in dit geval logisch om vooraf gedefinieerde elementen in de configuratie te definiëren, maar niet om ze in alle informatiebeveiligingssystemen te creëren, maar alleen voor die informatiebeveiligingssystemen in waarin de vereiste configuratielogica wordt gebruikt. In dit geval kan de programmeur de eigenschap "Vooraf gedefinieerde gegevens niet bijwerken" specificeren voor het naslagwerk en programmatisch elementen creëren bij toegang tot de functionaliteit van de module. Of om de gebruiker in staat te stellen de vooraf gedefinieerde elementen van de module zelfstandig te binden aan de gebruikelijke elementen die hij heeft.
Ook wordt het automatisch aanmaken van voorgedefinieerde elementen niet gebruikt bij het werken in de RIB-modus. Omdat nieuwe elementen vanuit de centrale basis moeten worden overgedragen en niet moeten worden gemaakt in knooppunten met verschillende UID's.
Die. soms is het een vergissing om naar een ongeëvenaard item te verwijzen in plaats van naar de aanwezigheid van een dergelijk item.
U moet analyseren waarom het item niet is gemaakt. Misschien moet het worden gemaakt wanneer een bepaalde modus van het programma wordt uitgevoerd. Bijvoorbeeld na het uitvoeren van een uitwisseling in RIB. Of misschien is het gewoon per ongeluk verwijderd.
Als de logica voorziet in het niet automatisch invullen van vooraf gedefinieerde elementen, maar in een aparte modus, dan vóór gebruik van de oproep op naam " Directories.Soorten contactInformation.EmailContactPerson"Om een uitzondering te voorkomen, is het raadzaam om te controleren of het element al in de database staat. Als het element afwezig is, informeer dan de gebruiker hierover en leg uit welke modus hij moet uitvoeren om het element te vullen. Voor een dergelijke controle, u kunt een query uitvoeren op de gegevens.
Verzoek = Nieuw Verzoek; Request.Text = "SELECTEER | Soorten contactinformatie.Link | FROM | Directory.Typen contactinformatie AS Soorten contactinformatie | WHERE | Soorten contactinformatie. PredefinedData Name =" " E-mailContactPersoon"" "; ElementNoNo.VD = Request.Run (). Leeg ();
Als dit nog steeds een fout is in de databasegegevens, dan is het noodzakelijk om te binden aan een vooraf gedefinieerd element van het IB-element. Die. het is noodzakelijk om aan het systeem uit te leggen naar welk element van informatiebeveiliging de programmacode met deze naam moet verwijzen. Technisch gezien is binding gewoon het specificeren van de naam van een vooraf gedefinieerd element in een eigenschap "Vooraf gedefinieerde gegevensnaam"IB-element. Om het te installeren, voert u gewoon de code uit:
2. "Het vooraf gedefinieerde element is niet uniek" - h advoi voorgedefinieerde elementen:
Deze situatie bestaat uit het feit dat meerdere IB-elementen aan één vooraf gedefinieerd element zijn gebonden. In dit geval wordt bij verwijzing naar een vooraf gedefinieerde naam het element willekeurig geselecteerd. Deze situatie is altijd verkeerd. De moeilijkheid is dat het platform er op geen enkele manier over communiceert. Alleen beginnen de algoritmen verkeerd te werken.
Het framework rapporteert de fout "Vooraf gedefinieerd item is niet uniek" alleen wanneer u probeert een gedupliceerd item te bewerken.
Totdat niemand het element hoeft te bewerken, weet niemand van de fout.
Dergelijke duplicaten kunnen bijvoorbeeld worden gemaakt als de RIB wordt gebruikt voor het naslagwerk en de modus "Automatisch bijwerken" is opgegeven in de eigenschappen voor vooraf gedefinieerde gegevens. In dit geval, wanneer de uitwisseling wordt uitgevoerd, wordt één exemplaar van de vooraf gedefinieerde gegevens gemaakt wanneer de configuratie wordt bijgewerkt. Tijdens de uitwisseling wordt een tweede exemplaar van voorgedefinieerde items met dezelfde naam uit de centrale database overgedragen.
Deze duplicaten zullen ook optreden bij het gebruik van uitwisselingsverwerking tussen configuraties in het geval dat verschillende informatiebeveiligingselementen overeenkomen met vooraf gedefinieerde elementen in verschillende databases. In dit geval bestaat één kopie van de vooraf gedefinieerde gegevens al in de database, de tweede komt bij het laden van gegevens met een andere UID. Als u gegevensoverdrachten uitvoert, moet u beslissen welke database-elementen als primair worden beschouwd en deze in de ondergeschikte database gebruiken. In de ondergeschikte basis is het noodzakelijk om het gebruik van oude elementen te vervangen door elementen van de hoofdbasis.
Dergelijke fouten in de database kunnen worden gedetecteerd door een query van het formulier:
SELECTEER Soorten Contactinformatie .PredefinedData Name, QUANTITY (VERSCHILLENDE SOORTEN CONTACTINFORMATION.Link) ALS een nummerPredefined from the Directory.Types of Contact Information AS Soorten Contact Information.
Deze query retourneert een lijst met vooraf gedefinieerde elementen waaraan meer dan één IB-element is gekoppeld.
Als er dergelijke elementen zijn, is het noodzakelijk om de verbinding met de vooraf gedefinieerde voor een van hen te verwijderen. Die. het is noodzakelijk om voor het systeem eenduidig vast te stellen naar welk IS-element de programmacode moet verwijzen bij het gebruik van deze naam. Om dit te doen, hoeft u alleen de code uit te voeren.
3. Ongeldige aanduiding van een vooraf gedefinieerd element.
De fout ligt in het feit dat het vooraf gedefinieerde element overeenkomt met het verkeerde element, dat wordt geleverd door de programmalogica. Dergelijke fouten zijn het moeilijkst te diagnosticeren. In tegenstelling tot de eerste twee typen, kunt u de configuratie niet automatisch controleren op deze fouten. Ze kunnen alleen worden geïdentificeerd door de logica van het werk te analyseren. Bij twijfel kun je controleren of het juiste artikel wordt gebruikt.
Om dit te doen, voert u gewoon een van de opdrachten uit.
// Een IB-element definiëren dat is gekoppeld aan het vereiste vooraf gedefinieerde rapport (Directories.Types of ContactInformation.EmailContactPerson) // Een vooraf gedefinieerd element definiëren waaraan het geselecteerde rapport is gebonden (ElementRef.Name of PredefinedData)
Als dergelijke fouten worden gevonden, is het noodzakelijk om de onjuiste link met het oude element te verwijderen en een link met het nieuwe element toe te voegen. De opcode is vergelijkbaar met de correctiecode voor de eerste twee soorten fouten.
Welnu, kort over fouten tijdens de werking van het programma of in de configuratormodus:
"Het vooraf gedefinieerde item behoort niet tot<Имя справочника>" - er treedt een fout op bij het schrijven van een vooraf gedefinieerd element met een naam die niet overeenkomt met de naam in de co-configurator.
"Niet-vooraf gedefinieerde objecten kunnen geen vooraf gedefinieerde subconto-type-items hebben" - er treedt een fout op wanneer u probeert een vooraf gedefinieerd rekeningschema-element ongedefinieerd te maken. Om fouten te elimineren, is het noodzakelijk om de "Voorgedefinieerde" vlag uit te schakelen voor elke regel van het onderaannemingscontract van het element.
"Niet-vooraf gedefinieerde objecten kunnen geen vooraf gedefinieerde records van leidende typen berekeningen hebben"- er treedt een fout op wanneer u probeert een vooraf gedefinieerd element van een tabel met berekeningstypen ongedefinieerd te maken. Om fouten te elimineren, is het noodzakelijk om de "Vooraf gedefinieerde" vlag te wissen voor elke regel van het leidende type elementberekening.
"Vooraf gedefinieerde items zijn niet uniek"- er wordt een fout weergegeven in de configurator bij het bijwerken van de infobase naar een configuratieversie zonder de 8.3.4-compatibiliteitsmodus. Het is noodzakelijk om duplicaten te controleren en te verwijderen voordat u bijwerkt.
"De naam van het voorgedefinieerde element is niet uniek" - de fout treedt op als er meerdere vooraf gedefinieerde elementen met dezelfde naam in de configuratie zijn bij het updaten naar het platform8.3.6.2332 en hoger. Het is noodzakelijk om duplicaten in de configuratie te elimineren.
Voor het werken met voorgedefinieerde gegevens raad ik verwerking aan. Ze weet met voorgedefinieerde gegevens alle handelingen uit te voeren en kan ook de configuratie als geheel controleren op de aanwezigheid van fouten van de eerste twee typen (dubbele en ontbrekende elementen) in alle informatiebeveiligingsobjecten (referentieboeken, rekeningschema's, PVC , PVR).
Iedereen kent het verschil tussen voorgedefinieerde elementen en gewone: "Vooraf gedefinieerde elementen worden gemaakt in de "Configurator"-modus en kunnen niet worden verwijderd in de 1C: Enterprise-modus." In de gebruikersmodus kunt u een voorgedefinieerd element onderscheiden van de elementen die door gebruikers zijn toegevoegd door een speciaal pictogram (zie de volgende schermafbeelding).
In principe worden vooraf gedefinieerde elementen door ontwikkelaars gemaakt om de algoritmen eraan te koppelen in verschillende configuratieobjecten. In de configuratie "Manufacturing Enterprise Management" in de referentie "Kwaliteit" hebben de ontwikkelaars bijvoorbeeld een vooraf gedefinieerd item "Nieuw" toegevoegd.
Dit element wordt in veel configuratiemodules gebruikt. Dus in het document "Ontvangst van goederen en diensten", bij boeking in alle registers waar sprake is van een dimensie "Kwaliteit", wordt de waarde van een vooraf gedefinieerd element vervangen. Hieronder ziet u hoe u de tabel met transacties in het register "Organisaties Goederen" kunt invullen:
// GOEDEREN IN HET REGISTER GoederenOrganisaties. Set bewegingen = bewegingen. ProductenOrganisaties; Als Ontvangsttype = Overboekingen. Soorten inkomstengoederen. Op voorraad dan // Krijg een tabel met waarden die overeenkomt met de structuur van de recordset van het register. Tabel verplaatsen = Set verplaatsen. Uitladen (); // Vul de bewegingstabel in. Algemeen doel. LoadInTableValues (TableBy Products, TableMotions); // Ontbrekende velden. Tabel met bewegingen. FillValues (Organisatie, "Organisatie"); Tabel met bewegingen. FillValues (niet gedefinieerd, "commissaris"); Tabel met bewegingen. FillValues (Referenties. Kwaliteit. Nieuw, "Kwaliteit"); // Vulkwaliteit van een vooraf gedefinieerd elementDe kenmerken van de vooraf gedefinieerde elementen en hun doel zijn dus vrij eenvoudig. Laten we eens kijken naar hoe ze worden opgeslagen in databasetabellen en hoe het verschilt van gewone items.
Verschillen
De directory "Producten" is aangemaakt in de testconfiguratie. Daarin is de groep "Testitems" aangemaakt. Je zou de inhoud van de groep kunnen zien in de schermafbeelding aan het begin van het artikel. Voor de verwijzing "Producten" in de SQL-database is er een bijbehorende tabel "_Reference37" met de volgende structuur:
Maar hoe bepaal je de overeenstemming van de attributen met de configuratieboom en de velden in de SQL-tabel?
Laten we de standaardmethode van de globale context "GetDatabaseStorageStructure ()" gebruiken, die ons een tabel met waarden zal retourneren met een beschrijving van de structuur van de tabellen.
In de waardetabel "Velden" zien we de overeenkomst tussen de SQL-tabelvelden en de objectattributen in de metadataboom. In ons voorbeeld houden we rekening met de structuur van de directory "Producten". Alle mappen hebben een standaard "Voorgedefinieerd" booleaans type attribuut, dat is ingesteld op TRUE voor vooraf gedefinieerde elementen:
Volgens de tabel met de structuur van het opslaan van het referentieboek in de database, kunnen we zeker zeggen dat het veld "Vooraf gedefinieerd" overeenkomt met het veld "IsMetadata". Als we naar de inhoud van de tabel "_Reference37" in de SQL-database kijken, zien we het volgende:
In de invoer voor een vooraf gedefinieerd element wordt de waarde van het veld "IsMetadata" ingesteld op "0x01", wat overeenkomt met de TRUE-vlag. Voor reguliere artikelen is de waarde ingesteld op "0x00". Dit is het belangrijkste verschil tussen vooraf gedefinieerde elementen en gewone. Alle andere velden worden op dezelfde manier in de database opgeslagen als voor gewone door de gebruiker toegevoegde items.
De voorgedefinieerde elementen blijken zeer interessante toepassingen te hebben. Met hun hulp kunt u het verwijderen / markeren voor verwijdering van een groep elementen in het naslagwerk en andere objecten waar ze kunnen worden toegevoegd, verbieden. Als we de groep "Testitems" proberen te verwijderen of markeren voor verwijdering. dan krijgen we de volgende fouten:
Zo maken voorgedefinieerde elementen de groep waarin ze zijn geplaatst ook "voorgedefinieerd".
Voltooiing
Vooraf gedefinieerde items vormen een integraal onderdeel van de meeste configuraties. Het gebruik ervan vereenvoudigt de ontwikkeling en maakt de constructie van functionaliteit logischerwijs "harmoniever" en coherenter.
Bij het werken op het 1C: Enterprise 8.x platform is het vaak nodig om in de programmacode te binden aan de gebruikelijke (niet voorgedefinieerde) elementen van directory's. Een organisatie kan bijvoorbeeld vijf soorten prijzen hebben die in bijna alle mechanismen worden gebruikt. In dit geval wordt een programmatische verwijzing naar een specifieke prijs in het beste geval uitgevoerd door te piepen bij een code in een naslagwerk, in het slechtste geval door de naam van een element.
Ik heb gezien hoe in de rapporten om de vereiste prijs te verkrijgen, selectie op type prijs werd gebruikt in een verzoek op naam (zie de volgende schermafbeelding).
Als u zich bovendien bindt aan de naam of code van de directory-elementen, wordt er altijd een zoekopdracht uitgevoerd in de directory-tabel wanneer u een link naar het element ontvangt. Ondanks het feit dat de standaard systeemattributen door het DBMS worden geïndexeerd, kan het zoeken door hen in sommige gevallen aanzienlijke middelen in beslag nemen. Bovendien zou het rationeler zijn om geen zoekopdracht uit te voeren op de opzoektabel als, laten we zeggen, de link naar het element al "vooraf bekend" is.
Als uitweg kunt u een verwijzing naar elk veelgebruikt item in de zoekopdracht "Artikelprijstypes" in afzonderlijke constanten opslaan en er waarden uit halen in de query. In dit geval zal de ontwikkelaar echter voor elk dergelijk element een afzonderlijke constante moeten toevoegen. De situatie wordt veel gecompliceerder als dergelijke elementen niet alleen in de map "Artikelprijstypes" staan, maar ook in andere mappen ("Objectcategorieën", "Kwaliteit", "Nomenclatuur" en andere). Dan kan het aantal constanten in het systeem meerdere malen toenemen!
Natuurlijk zou men voorgedefinieerde elementen aan elk van de mappen kunnen toevoegen en het zou veel gemakkelijker zijn om ze te openen. Het wijzigen van de generieke objecten zou het proces van het bijwerken van de configuratie van leverancierspakketten echter bemoeilijken.
Er is een meer optimale benadering, zowel vanuit het oogpunt van het ontwikkelen van de configuratie metadatastructuur, als vanuit het oogpunt van systeemprestaties. Vandaag gaan we het over hem hebben.
One-stop-oplossing:
De essentie van een universele oplossing is als volgt: er wordt een referentie gemaakt waaraan de ontwikkelaar vooraf gedefinieerde elementen zal toevoegen. De variabele "Waarde" is toegevoegd aan het woordenboek, waarvan het type afhangt van de waarden waarvoor de correspondentie "Vooraf gedefinieerd woordenboekelement -> Geassocieerde waarde" zal worden gemaakt. De directory-metadatastructuur ziet er als volgt uit (zie de volgende schermafbeelding).
Om een vooraf gedefinieerd element te krijgen, is de beste optie om de globale methode te gebruiken "Vooraf gedefinieerde waarde (<Имя>)" ... Het volledige pad naar het vooraf gedefinieerde element wordt als parameter aan de methode doorgegeven. De syntaxis is vergelijkbaar met de "VALUE ()"-querytaalfunctie.
Om de ontwikkeling te vergemakkelijken, raad ik aan om de functie te verplaatsen om de waarde die is gekoppeld aan een vooraf gedefinieerd element in een gemeenschappelijke module te krijgen. In de testconfiguratie, beschikbaar om te downloaden via de link aan het einde van het artikel, is een algemene module "PredefinedElement Values" met een exportfunctie gemaakt "GetValuePredefinedElement (<ИмяПредопределенногоЭлемента>)" ... De programmacode van de functie ontvangt een link naar een vooraf gedefinieerd element en ontvangt vervolgens op verzoek de waarden van het kenmerk "Waarde". De volgende schermafbeelding toont de volledige lijst van de functie.
Zoals we kunnen zien, genereert de functie een verzoek naar het kenmerk "Waarde" van het vooraf gedefinieerde element dat als parameter is doorgegeven. De functieparameter is een string met de naam van een vooraf gedefinieerd element.
Om het gecreëerde mechanisme correct te laten werken, moet u een voorgedefinieerd element verbinden met een regulier cataloguselement in de gebruikersmodus door het corresponderende element te selecteren in het "Waarde" attribuut. Laten we verder gaan met de kwestie van de impact op de prestaties.
Impact op prestaties
Snelheidstest uitgevoerd voor beide zoekmogelijkheden: op naam en op referentie vanuit een vooraf gedefinieerd element. De zoekopdracht ging door de directory "Producten" met 20.000 records. Bij het uitvoeren van tests op een bestandsdatabase werden de volgende resultaten verkregen:
De resultaten toonden aan dat voor de bestandsversie van werk, het gebruik van vooraf gedefinieerde elementen om veelgebruikte elementen van andere mappen te krijgen bijna 4 keer langzamer werkt!
In de client-server-modus laten de testresultaten een heel ander beeld zien. De snelheid van het verkrijgen van een link naar het gewenste element nam niet significant af (een van de tests toonde 0,002 sec. voor zoeken op naam en 0,0008 sec. bij het werken via een vooraf gedefinieerd element), maar de betrouwbaarheid van het programma is aanzienlijk toegenomen!
conclusies
In gevallen waar het vaak nodig is om te binden aan gewone directory-elementen, raad ik aan om geen binding op code of naam te gebruiken. Deze aanpak vermindert de betrouwbaarheid en prestaties van het systeem.
Tijdens mijn werk met het platform ben ik herhaaldelijk situaties tegengekomen waarin, na het wijzigen van de naam van bijvoorbeeld een element van het naslagwerk "Prijsnomenclatuurtypes", de meeste niet-standaard rapporten crashten.
Hoe meer algoritmen zijn gekoppeld aan gewone directory-elementen via een code of naam, hoe minder stabiel het systeem is.
Bovendien stelt deze aanpak u in staat om typische configuratieobjecten niet te wijzigen als u er een vooraf gedefinieerd element aan moet toevoegen. In de toekomst zal dit het proces van het bijwerken van de configuratie iets eenvoudiger maken.
Bestanden om te downloaden:
- De testbank uitladen met voorbeelden uit het artikel.
Goedendag.
Vandaag zullen we het hebben over een innovatie in het 8.3-platform met betrekking tot vooraf gedefinieerde elementen.
Invoering
Laat me je eraan herinneren dat ik vroeger, in de praktijk, heel vaak naar een element uit een naslagwerk wilde kijken om de vooraf gedefinieerde naam te achterhalen. U hebt bijvoorbeeld twee vooraf gedefinieerde aannemers gemaakt en deze IPSidorov en OOOMeteor genoemd. En ze naaiden er een soort logica op.
Toen alles was gedebugd en werkte, bleek de taak andersom te zijn ingesteld en was de logica voor de eenmanszaak nodig voor de LLC en de logica van de LLC voor de eenmanszaak. "Geen probleem", zeggen we, en in Enterprise Mode hernoemen we de items. Het is veel moeilijker om in de code te komen. Een jaar gaat voorbij en je krijgt een nieuwe taak: wat meer logica opzetten voor IP Sidorov. Je gaat naar de configurator, schrijft de logica, begint te controleren en niets werkt, want in de IPSidorov-configurator en in de onderneming - Meteor LLC. De hersenen zijn gebroken en ik wil deze hark vernietigen. De eenvoudigste en meest intuïtieve is om de naam van een vooraf gedefinieerd element uit te voeren in de vorm van een lijst. Hier is een hinderlaag, je kunt de naam van de voorgedefinieerde in 8.2 alleen door de methode krijgen. En de methode heeft zijn eigen ongemak, het kan niet worden verkregen in het verzoek. Die. het eerste ongemak is om de naam van de vooraf gedefinieerde te krijgen door te verwijzen naar de map.
Het tweede ongemak is wanneer we al een directory-element hebben en we het vooraf moeten definiëren. We maken een vooraf gedefinieerd item en krijgen twee items in de directory. Een voorgedefinieerd, een ander werkend, waarnaar wordt verwezen in al onze documenten. Het vervangen van links helpt zeker, maar als de database groot is, dan is het moeilijk.
Nu op de zaak
De eerste is dat de referentie nu de eigenschap "Voorgedefinieerde gegevens bijwerken" heeft.
Wat levert dit veld ons op? Als het is ingesteld op "Niet automatisch bijwerken", zullen we het niet onmiddellijk in de referentie zien door een vooraf gedefinieerd element toe te voegen. Die. metadata heeft niets met data te maken. En als het niet in de directory is gemaakt, zal het verwijzen naar de naam via de directorymanager een syntaxisfout veroorzaken.
Heel interessant, maar waarom? Hoe maken we een item in de referentie aan? En zoals u wilt, kunt u deze maken, of u kunt deze koppelen aan een bestaande. Nu heeft de zoekopdracht het kenmerk "PredefinedDataName". We maken zoals gebruikelijk een catalogusitem programmatisch via "References.Contractors.CreateElement ()" en vullen het "PredefinedDataName" -attribuut gelijk aan de naam van het vooraf gedefinieerde item. Of, als het element al bestaat, halen we het object op en vullen we opnieuw de "PredefinedDataName" erin. Alles.
En als laatste een beetje siroop
Deze nieuwe rekwisieten zijn niet alleen lezen/schrijven, maar ook beschikbaar in verzoeken. Zo kun je er voorwaarden aan stellen in queries, bepalen of het voorgedefinieerd is of niet.
Bedankt voor de aandacht.
In de vierde les van onze we blijven ons vertrouwd maken met het programma. Vandaag maken we kennis met enhiërarchische mappen, en leer hoe u vooraf gedefinieerde elementen kunt maken.
Tijdstip van 4 lessen van de cursus:
00:19
Wijzigingen in de medewerkersgids na het maken van huiswerk voor de 3e les van de cursus
00:35
De volgorde van attributen in mappen bewerken
02:54
Het naslagwerk Nomenclatuur maken
03:40
Een hiërarchische directory maken en configureren
05:10
Groepen Services en Producten maken in de directory Nomenclatuur
06:05
Het naslagwerk Nomenclatuur invullen
07:14
3 manieren om een directory-item naar een andere groep te verplaatsen
08:21
Aanmaken van de Magazijnen-directory
09:19
Vooraf gedefinieerde catalogusitems maken
11:25
De Magazijnen-directory invullen
12:20
Neem Materiële Test Les 4
Hiërarchische directory- een naslagwerk met de mogelijkheid van hiërarchische rangschikking van de elementen. In de directory Nomenclatuur kunnen bijvoorbeeld groepen worden aangemaakt: Goederen, Diensten, enz., waarin de elementen die bij deze groepen horen zich bevinden. Bovendien kunnen directorygroepen andere groepen bevatten, waardoor een hiërarchische structuur met meerdere niveaus ontstaat.
Daarnaast ondersteunen woordenboeken ook een ander type hiërarchie, waarbij de elementen van de woordenboeken niet tot groepen behoren, maar tot andere elementen van dezelfde woordenboeken. Dit soort hiërarchie ( element hiërarchie) kan bijvoorbeeld worden gebruikt bij het maken van de map Onderverdelingen, waarbij een onderverdeling (in dit geval onderverdeling een element van de map, geen groep) meerdere andere onderverdelingen kan bevatten. Dit soort hiërarchie wordt zelden gebruikt.
Directoryformulieren- visuele presentatie van het naslagwerk. Afhankelijk van welke acties we precies willen uitvoeren met onze directory, moeten we de directory in "verschillende weergaven" weergeven. Dus in de 4e les van de cursus hebben we de volgorde van de benodigdheden aangepast in de vorm van een lijst en in de vorm van een referentie-element.
Het systeem maakt (genereert) automatisch formulieren, maar indien nodig kan de ontwikkelaar de formulieren zelf "tekenen".
Er zijn 5 formulieren (soorten formulieren) voor naslagwerken:
- element vorm- om een directory-item aan te maken of te bewerken;
- groepsvorm- om een directorygroep aan te maken of te bewerken;
- lijstvorm- om een lijst met directory-items weer te geven;
- selectie formulier- wordt gebruikt om een van de elementen van deze directory te selecteren in een veld van een bepaalde vorm. Om bijvoorbeeld een specifiek magazijn te selecteren uit de directory Magazijnen in het document Goederenontvangst in het veld magazijn;
- groepsselectieformulier- wordt gebruikt om een van de groepen van deze directory te selecteren in het veld van een bepaald formulier.
Vooraf gedefinieerde directory-items- directory-elementen die door de ontwikkelaar in de Configurator-modus zijn gemaakt en die op naam toegankelijk zijn vanuit de ingebouwde 1c-taal.
Er is een fundamenteel verschil tussen reguliere en vooraf gedefinieerde directory-elementen. Reguliere items zijn inconsistent in configuratie. Tijdens het werk van de gebruiker kunnen ze worden gemaakt, bewerkt en verwijderd en daarom mag er niet op worden vertrouwd bij het uitvoeren van algoritmen (de code en naam van het element kunnen door de gebruiker worden gewijzigd).Vooraf gedefinieerde items zijn daarentegen permanent. In het proces, zelfs als de gebruiker een dergelijk element hernoemt, zal het mogelijk zijn om het te openen vanuit de ingebouwde 1c-taal. Dit wordt bereikt door het feit dat het vooraf gedefinieerde element een props heeft Naam die niet beschikbaar is voor de gebruiker. Gewone elementen van de directory hebben zo'n attribuut niet.
Belangrijk! Technisch gezien heeft de gebruiker de mogelijkheid om een vooraf gedefinieerd woordenboekelement te verwijderen, maar in de regel worden gebruikers uitgeschakeld van de rechten om vooraf gedefinieerde woordenboekelementen te verwijderen.
Huiswerk voor de 4e les van de cursus
Huiswerk voor de vierde les van de cursus is direct na het succesvol afronden van het theorie-examen voor u beschikbaar.
