1s scd värde. Använder egenskaper i SCD. Plats för fattigdom i en intelligent byggnad

Det är allt. Rapportfunktionen låter dig nu välja fält för ytterligare egenskaper i rapporten (utdatafält, urval, etc.). Men det finns ett MEN. Vi kan endast använda dessa fält i rapportinställningar i 1C:Enterprise-läge. I konfiguratorn kan vi inte se egenskapsfälten, vilket är logiskt, eftersom egenskaperna skrivs in av användaren och lagras i informationsbasen.

Men vid behov kan vi till exempel lägga till egenskapsfält till urvalet innan vi öppnar det. Låt oss titta på ett litet exempel.

Programmatiskt arbete med egenskaper

När du öppnar rapportformuläret, kör följande programkod:

CurrentSettings = ComposerSettings. Inställningar; CollectionCollection = CurrentSettings. Urval. Element; // Lägg till urval genom ytterligare. till artikelinformationen "Huvudlager". [ Huvudlager] // Lägg till urval genom ytterligare. till nomenklaturuppgifterna "Placeringsland" NovEl = CollectionSelections. Lägg till(Typ(" Val ElementData Layout" ) ); NewEl.ComparisonType = DataCompositionComparisonType. Lika med; NewEl.LeftValue = . [Inläggets land]" ) ; NewEl. Usage = False ; // Lägg till urval genom ytterligare. till artikelinformationen "Relaterad motpart" NovEl = CollectionSelections. Lägg till(Typ(" Val ElementData Layout" ) ); NewEl.ComparisonView = DataCompositionComparisonView. Lika med; NewEl.LeftValue = NewDataCompositionField("Organisation . [Relaterad motpart]" ) ; NewEl. Usage = False ;

Om vi ​​sedan tittar på rapportvalet i 1C:Enterprise-läge kommer vi att se följande bild:

Således lade vi programmässigt till ett urval baserat på ytterligare egenskaper i katalogen "Organisationer", trots att dessa fält inte var tillgängliga i ACS-designern. Notera syntaxen för att definiera ett datakompositionsfält.

nämligen texten "[Länkad motpart]". Om vi ​​skriver så här:

sedan när rapporten körs kommer ACS att upptäcka layoutfälten felaktigt. I inställningarna kommer urvalsfälten att markeras som felaktiga:

För ytterligare egenskaper och detaljer som inte är tillgängliga i ACS-designern måste du använda följande syntax när du använder programmet:

Således kan vi ställa in rapportinställningar även om fälten inte är tillgängliga i ACS-designern.

Slutsats

Att använda egenskapersinställningar i ACS kan avsevärt förenkla utvecklingen av komplexa rapporter. Trots vissa brister i arbetet, såsom bristen på förmåga att konfigurera urval av ytterligare. egenskaper hos konstruktören etc. kan egenskapsmekanismen anses vara ett viktigt steg för att förenkla utvecklingen av rapporter i 1C:Enterprise-systemet.

I artikeln övervägde vi inte alla egenskaper hos egenskaper i ACS. Utöver artikelns räckvidd finns det sådana möjligheter som: godtycklig definition av datakällor, både för egenskaper och för karakteristiska värden, samt urval av ägare för alla tillgängliga egenskaper i informationsbasen, och mycket mer. Ämnet är stort, det finns utrymme att utöka din kunskapskrets.

Ett av de viktigaste områdena inom affärsprogramvara är rapportering. Ett företags öde, vare sig det är en rapport för skattekontor eller ett diagram över efterfrågan på varors beroende av säsong och andra faktorer. Ett kraftfullt och flexibelt rapporteringssystem som gör det enkelt att extrahera nödvändiga data från systemet, presentera dem i en begriplig form, så att slutanvändaren kan konfigurera om en standardrapport för att se data i ett nytt ljus - detta är ideal för varje affärssystem bör sträva efter.

I 1C:Enterprise-plattformen är en mekanism som kallas "Data Composition System" (förkortat DCS) ansvarig för att generera rapporter. I den här artikeln kommer vi att försöka ge kort beskrivning idéer och arkitektur för ACS-mekanismen och dess kapacitet.

ACS är en mekanism baserad på en deklarativ beskrivning av rapporter. Passeringssystemet är utformat för att generera rapporter och visa information med en komplex struktur. Förresten, förutom att utveckla rapporter, används ACS-mekanismen också i 1C:Enterprise i en dynamisk lista, ett verktyg för att visa listinformation med rik funktionalitet (visa platta och hierarkiska listor, villkorlig design av rader, grupperingar, etc. ).

Lite historia

1. En eller flera frågor skrevs i frågespråket 1C (SQL-liknande språk, mer om det nedan).
2. Kod skrevs som överförde resultaten av utförda frågor till ett kalkylarksdokument eller diagram. Koden kan också göra arbete som inte kunde göras i en fråga - till exempel beräknade den värden med det inbyggda 1C-språket.

En av idéerna som låg till grund för passerkontrollsystemet var flexibiliteten och anpassningen av rapporter, vilket var tillgängligt för både utvecklaren och slutanvändaren. Helst skulle jag vilja ge slutanvändaren tillgång till samma uppsättning rapportdesignverktyg som utvecklaren. Det skulle vara logiskt att skapa en enda uppsättning verktyg tillgängliga för alla. Tja, eftersom verktygen kräver slutanvändarens deltagande, betyder det att användningen av programmering i dem bör reduceras till ett minimum (det är bäst att eliminera det helt), och visuella inställningar bör användas maximalt.

Formulering av problemet

Två språk

Frågespråk

Det är lätt att se analoger till sektionsstandarden för SQL-frågor - SELECT, FROM, GROUP BY, ORDER BY.

Samtidigt innehåller frågespråket ett betydande antal tillägg som syftar till att spegla de specifika finansiella och ekonomiska problemen och maximera minskningen av ansträngningarna för att utveckla applikationslösningar:

• Åtkomst till fält med hjälp av en prick. Om fälten i en tabell är av en referenstyp (de lagrar länkar till objekt i en annan tabell), kan utvecklaren hänvisa till dem i texten i begäran genom ".", och systemet begränsar inte antalet kapslingsnivåer av sådana länkar (till exempel Kundorder. Avtal. Organisation. Telefon).
• Multidimensionell och flernivåbildning av resultat. Summor och delsummor bildas med hänsyn till gruppering och hierarki, nivåer kan passeras i valfri ordning med summering och korrekt konstruktion av totaler enligt tidsdimensioner säkerställs.
• Stöd för virtuella tabeller. Virtuella tabeller som tillhandahålls av systemet låter dig få nästan färdiga data för de flesta applikationsuppgifter utan att behöva skapa komplexa frågor. Således kan en virtuell tabell tillhandahålla data om produktsaldon efter perioder vid en viss tidpunkt. Samtidigt utnyttjar virtuella tabeller den lagrade informationen maximalt, till exempel tidigare beräknade summor etc.
• Tillfälliga bord. Frågespråket låter dig använda tillfälliga tabeller i frågor. Med deras hjälp kan du förbättra frågeprestanda, i vissa fall minska antalet blockeringar och göra frågetexten lättare att läsa.
• Batchförfrågningar. För att göra det enklare att arbeta med tillfälliga tabeller, stöder frågespråket arbete med batch-frågor - sålunda placeras skapandet av en temporär tabell och dess användning i en fråga. En batchbegäran är en sekvens av förfrågningar separerade med semikolon (";"). Förfrågningarna i partiet exekveras en efter en. Resultatet av att exekvera en batchbegäran, beroende på vilken metod som används, kommer antingen att vara resultatet som returneras av den sista begäran i partiet, eller en uppsättning resultat från alla frågor i partiet i den sekvens som frågorna i partiet följer .
• Hämta representationer av referensfält. Varje objekttabell (i vilken en referensbok eller ett dokument lagras) har ett virtuellt fält - "Visa". Det här fältet innehåller en textrepresentation av objektet och gör rapportskaparens jobb enklare. Så för ett dokument innehåller detta fält alla nyckelinformation- namnet på dokumenttypen, dess nummer och datum (till exempel "Rea 000000003 från 07/06/2017 17:49:14"), vilket sparar utvecklaren från att skriva ett beräknat fält.
• och så vidare.

Det finns också speciella frågespråktillägg för passersystem. Expansion utförs med hjälp av speciella syntaktiska instruktioner inneslutna i lockiga hängslen och placerade direkt i förfrågan. Med hjälp av tillägg bestämmer utvecklaren vilka operationer slutanvändaren ska kunna utföra när rapporten anpassas.

Till exempel:

• VÄLJA. Denna mening beskriver de fält som användaren kommer att kunna välja för utdata. Efter detta nyckelord listas alias för fält från huvudfrågevallistan som kommer att vara tillgängliga för konfiguration, separerade med kommatecken. Exempel: (VÄLJ artikel, lager)
• VAR. Fälten där användaren kan tillämpa urval beskrivs. Detta förslag använder tabellfält. Det är inte tillåtet att använda vallistfältalias. Varje del av förbundet kan innehålla sitt eget WHERE-element. Exempel: (WHERE Item.*, Warehouse), (WHERE Document.Date >= &StartDate, Document.Date<= &ДатаКонца}
• och så vidare.

Uttrycksspråk för datasammansättning

Exempel:

Processen att skapa en rapport om passerkontrollsystemet

• begära text med instruktioner för datasammansättningssystemet;
• beskrivning av flera datamängder;
• detaljerad beskrivning av tillgängliga fält;
• beskrivning av relationer mellan flera datamängder;
• beskrivning av datainsamlingsparametrar;
• beskrivning av fältlayouter och grupperingar;
• och så vidare.

Du kan till exempel lägga till en fråga till datasammansättningsschemat som en datamängd och anropa frågekonstruktorn, som gör att du grafiskt kan skapa en fråga med godtycklig komplexitet:

Resultatet av att starta frågedesignern blir frågetexten (på frågespråket 1C:Enterprise). Denna text kan justeras manuellt vid behov:

Det kan finnas flera datamängder i ett datalayoutschema, datamängder kan länkas i layouten på vilket sätt som helst, beräknade fält kan läggas till, rapportparametrar kan anges osv. Det är värt att nämna en intressant egenskap hos frågemekanismen i 1C:Enterprise. Frågor översätts slutligen till en SQL-dialekt som är specifik för det DBMS som applikationen direkt arbetar med. I allmänhet försöker vi använda funktionerna hos DBMS-servrar maximalt (vi är begränsade av det faktum att vi bara använder de funktioner som samtidigt är tillgängliga i alla DBMS som stöds av 1C:Enterprise-plattformen - MS SQL, Oracle, IBM DB2 , PostgreSQL). På frågenivå i beräknade fält kan vi alltså bara använda de funktioner som är översatta till SQL.

Men på nivån för datasammansättningsschemat kan vi redan lägga till anpassade fält och använda funktioner i dem i det inbyggda 1C-utvecklingsspråket (inklusive de skrivna av oss), vilket avsevärt utökar rapporternas möjligheter. Tekniskt sett ser det ut så här - allt som kan översättas till SQL översätts till SQL, frågan exekveras på DBMS-nivå, frågeresultaten placeras i minnet på 1C-applikationsservern och SKD:n beräknar värdena för varje post av beräknade fält vars formler är skrivna på 1C-språket.

Lägga till anpassade fält

Du kan lägga till ett godtyckligt antal tabeller och diagram till rapporten:

Rapportdesigner

Körtidsrapport

Med SKD kan användaren lägga till komplexa val till rapporten (som kommer att läggas till förfrågan på rätt ställen), villkorlig design (så att de visade fälten kan formateras annorlunda - med typsnitt, färg etc., beroende på deras värden ) och mycket mer. .

Processen att konstruera och generera en rapport kan kort beskrivas på följande sätt:

• Utvecklaren i designtid med hjälp av en designer (eller i runtime med kod) bestämmer datalayoutschemat:
  • Text till förfrågan/förfrågningar
  • Beskrivning av beräknade fält
  • Relationer mellan förfrågningar (om det finns flera av dem)
  • Rapportalternativ
  • Standardinställningar
  • Etc.
• Ovanstående inställningar sparas i layouten
• Användaren öppnar rapporten
  • Gör eventuellt ytterligare inställningar (till exempel ändrar parametervärden)
  • Klicka på knappen "Generera".
• Användarinställningar tillämpas på datasammansättningsschemat som definierats av utvecklaren.
• En intermediär datasammansättningslayout bildas, som innehåller instruktioner om varifrån data ska tas emot. Särskilt de frågor som anges i layouten justeras. Fält som inte används i rapporten tas alltså bort från begäran (detta görs för att minimera mängden mottagen data). Alla fält som deltar i beräknade fältformler läggs till i frågan.
• Datakompositionsprocessorn kommer in i bilden. Layoutprocessorn kör frågor, länkar datamängder, beräknar värden för beräknade fält och resurser och utför gruppering. Med ett ord, den gör alla beräkningar som inte utfördes på DBMS-nivå.
• Datautgångsprocessorn startar en begäran om exekvering och visar mottagna data i ett kalkylbladsdokument, diagram, etc.

Processen att generera en rapport med hjälp av ACS-mekanismen

Vi försöker minimera mängden rapportdata som överförs från servern till klientapplikationen. När vi visar data i ett kalkylarksdokument, när vi öppnar ett kalkylarksdokument, överför vi från servern endast de rader som användaren ser i början av dokumentet. När användaren rör sig längs dokumentets linjer, laddas den saknade data ner från servern till klienten.

Anpassade inställningar

• Snabb åtkomst. Inställningen kommer att visas direkt överst i rapportfönstret.
• Vanlig. Inställningen kommer att vara tillgänglig via knappen "Inställningar".
• Inte tillgänglig. Inställningen kommer inte att vara tillgänglig för slutanvändaren.

Ställa in visningsläge i designtid

Visa inställningen i snabbåtkomstläge under körning (under knappen Generera)

Utvecklingsplaner

I frågedesignern, när den anropas från datakällans inställningsformulär, för datakompositionsschemat. Det finns en "egenskaper"-flik, vars användning inte beskrivs tydligt i dokumentationen. I den här artikeln ska jag försöka förklara hur och varför egenskaper används i ACS.

Typiska konfigurationer använder aktivt mekanismen för egenskaper och egenskapsvärden, tillgängliga för nästan alla objekt. Primitivt, i referensböcker, implementerades denna mekanism i konfigurationer 7.7. Nu implementeras denna mekanism med hjälp av en plan över egenskaperstyper och ett informationsregister, men idén förblir densamma.

När jag först stötte på behovet av att använda den här mekanismen i ett åtkomstkontrollschema, kämpade jag mycket länge, organiserade kapslade frågor, förenade dem med huvudvalet och funderade över hur jag skulle ta hänsyn till möjligheten av uppkomsten av nya typer av fastigheter som inte fanns vid rapportframtagandet. Hela mekanismen för egenskaper, som är enkel och logisk ur användarens synvinkel, lämpade sig inte för någon normal bearbetning förrän jag kom på fliken "Egenskaper".

Tabellen på fliken är väldigt nyckfull, antingen anger du hela raden korrekt eller vägrar att gå in i raden alls; systemet kommer inte att tillåta dig att lämna en ofullständigt ifylld rad "för senare."

Så låt oss gå ner till detaljerna. Första kolumnen: Typ– här väljer vi vilken typ av objekt som egenskaperna ska kopplas till, till exempel "DirectoryLink.Nomenclature"

Detta innebär att det nu kommer att vara möjligt att erhålla egenskapsvärden för alla objekt av den angivna typen.

Vidare i nästa kolumn Källa till arter vi måste ange källparametrarna för egenskapsvyn. Möjliga alternativ tabell m begäran, varför behöver vi ett alternativ? begäran Jag berättar senare, låt oss nu välja ett objekt tabell.

I en kolumn Typer av egenskaper vi måste välja infobastabellen i vilken de nödvändiga typerna av egenskaper lagras, i vårt exempel kommer det att vara "Plan of Types of Characteristics. Properties of Objects".

Därefter de värden som är tillgängliga för oss för val i kolumnerna Nyckelfält, Namnfält Och Fält för värdetyp, beror direkt på fälten i tabellen vi väljer. I Nyckelfält vi väljer Länk, V Namnfält – Prestanda(användaren kommer att se det som namnet på attributet), och in Typfält respektive TypValue.

Låt oss nu gå vidare till källan till värden. Vår värdekälla kommer att vara informationsregistret "ObjectPropertyValues", så vi väljer i kolumnen Källa till värden – tabell, och i kolumnen Attributvärden– "Informationsregister. Värden på objektegenskaper." I kolumner Ett objekt, Fast egendom, Menande, välj lämpliga registerfält Ett objekt, Fast egendom, Menande.

Det verkar som att det är allt. Vi går till schemainställningarna, lägger till en gruppering efter produkter och lägger till en underordnad gruppering, till exempel efter varumärken, vi har en sådan egenskap.

Vi utökar listan med detaljer i nomenklaturgruppen och... vi ser inga egenskaper där:

Faktum är att vi är i konfiguratorn, varifrån det inte finns någon tillgång till data. Hur gör man de nödvändiga inställningarna? Det bekvämaste sättet att göra detta är att använda datakompositionskonsolen, den på ITS-disken eller den som ingår i undersystemet "Utvecklarverktyg". Men du kan helt enkelt öppna rapportinställningarna i företagsläge.

Så låt oss öppna samma inställning, men i företagsläge:

Som du kan se har vi lagt till nya "Detaljer" och egenskapen " varumärke” utåt skiljer sig inte från de vanliga kataloguppgifterna. Och fastigheten " Produkttyp” står inom hakparentes eftersom egenskapsrepresentationen innehåller ett mellanslag.

Men vi har även fastigheten " Typ av avtal" som är länkad till katalogen " Fördrag" och har ingenting att göra med " Nomenklatur". Om den inte används i inställningen " Typ av avtal” då kommer allt att fungera korrekt, men om du väljer det, kommer det som ett resultat att visa sig vara ofyllt, eftersom inte en enda post i nomenklaturen har denna egenskap faktiskt ifylld. Men hur kan du filtrera bort onödiga egenskaper så att de inte hamnar under dina fötter?

För att göra detta måste vi ändra visningskällans inställning i frågedesignern, på fliken "Egenskaper". Kom ihåg att jag i början av artikeln lovade att berätta varför källtypen för visning behövs begäran? Nu är just ett sådant fall. Ändra visningskällans typ till begäran. I kolumnen med typer av egenskaper klickar du på knappen "[...]" och ett nytt frågedesignerfönster öppnas.

Ange följande fråga där:

VÄLJA
Objektegenskaper.Ref.
Objektegenskaper. Namn + "(egenskap)" AS-namn,
Object Properties.TypeValues
FRÅN
Plan över typer av egenskaper Egenskaper för objekt AS Egenskaper för objekt
VAR
Objektegenskaper. Ändamål med egenskaper = VÄRDE (Plan av egenskaperstyper. Ändamål med egenskaper för objektkategorier. Directory_Nomenclature)
OCH (INTE ObjectProperties.DeletionMark)
AND (INTE ObjectProperties.Category)

I kolumner Nyckelfält, Namnfält Och Fält för värdetyp, välj lämpliga urvalsfält: Länk, namn Och TypValue. Det kommer att bli så här:

Nu, när vi går vidare till att ställa in rapporten, kommer bilden i listan över nomenklaturdetaljer att ändras:

Nu har produkten bara de egenskaper som är tilldelade den, dessutom skiljer de sig nu märkbart från de vanliga detaljerna, tack vare efterskriften (fast egendom), som vi lade till i egenskapsnamnet i begäran.

Det är allt, men många kan bli förvirrade av omöjligheten att ställa in den i konfiguratorn. Det är verkligen inget fel med det. Det räcker att spara inställningen (eller hela kretsen) i en fil och återställa den i konfiguratorn.

Konfiguratorn kommer att visa detaljer som den inte förstår med röda kryss som otillgängliga:

Men detta är inte längre skrämmande, eftersom en rapport med sådana inställningar kan sparas i konfigurationen och den kommer att fungera korrekt när den öppnas av användaren.