1.Ingress.
Det fanns ett behov av att organisera redovisningen för två organisationer i ett informationssäkerhetssystem. Situationen är inte unik, men det hände att vår mycket icke-standardiserade 250 gigabyte USB-enhet fungerade ganska långsamt, så istället för RLS bestämde vi oss för att prova dataseparation. Vad det är beskrivs till exempel, eller. Kort sagt, om RLS kompletterar med villkor SQL-frågor, då är dataseparatorn en extra kolumn i tabeller på DBMS-nivå, på grund av vilken separationsmekanismen bör fungera snabbare än RLS.
Så till databasen där register hölls för LLC nr 1 är det nödvändigt att överföra information från den separata databasen för LLC nr 2 och organisera gemensamt arbete. Precis som på bilden:
Bara dödliga arbetar bara med sin egen LLC, och chefsrevisorn tittar ibland på data för två juridiska personer. I åtkomstläget till båda LLCs kan du bara läsa data, så chefsrevisorn bör interaktivt kunna växla mellan lägena "läs alla"/"skriv endast för en organisation" och välj LLC (dvs. ställ in värdet av de gemensamma detaljerna) för att till exempel utföra kostnadsberäkningar.
2. Genomförande
Plattform 8.2.19.90, utan kompatibilitetsläge. DBMS - MSSQL Server 2008 R2 Standard.
Vi skapade det allmänna attributet OrganisationSeparator av typen "nummer", gick med på förslaget att skapa sessionsparametrar, fyllde i sammansättningen av detaljerna (inkluderade flera kataloger, alla dokument, ackumulerings-, redovisnings- och beräkningsregister). Dataseparation - "Oberoende och gemensam". Sessionsparametervärdet ställs in från standardinställningar användare i proceduren SettingSessionParameters i sessionsmodulen:
Organization = UserManagement.GetDefaultValue(chCurrentUser,"PrimaryOrganization");
SessionParameters.OrganizationSeparatorValue = Organization.SeparatorValue;
I ekonomichefens gränssnitt skapade de ett formulär med möjlighet att växla mellan organisationer och slå på/av separationsläget:
När separation är inaktiverad, när SessionParameters.OrganizationSeparatorUsage = False, vägrar plattformen att skriva dokument, kraschar med fel som "SDBL-fel: uttryck förväntat (pos=12)", så du kan inte tillåta användaren att skriva dokument i det här alternativet. För att vara på den säkra sidan skapade vi prenumerationer på händelsen "Före inspelning" för objekt som är en del av det allmänna attributet:
IfSessionParameters.OrganizationSeparatorUsage = False Då
#Om klient då
Varning("Kan inte skriva eftersom datadelning är inaktiverat!");
#EndIf
Vägra = Sant;
endIf;
Vår handlingsplan var följande: förbered mottagarkonfigurationen för IS nr 1, ställ in värdena för det allmänna attributet = 1, ladda data från IS nr 2, efter laddning, för alla objekt med en tom (lika med 0) ) separatorvärde, ställ in OrganisationSeparator = 2.
Konfigurationen har förberetts, frågan uppstod: hur man ställer in värdet på de allmänna detaljerna för dokument och deras rörelser under stängda perioder, snabbt och utan risk att siffrorna i balansräkningen flyger? Det är omöjligt att skriva en separator separat från objektet genom 1C-objektmodellen, så jag var tvungen att bryta licensavtal gå ut och skriv en fråga för MS SQL. Eftersom det finns många objekt i det allmänna attributet, och det finns ännu fler tabeller i tabellen för dessa objekt, skrev vi en bearbetning som genererar en fråga för SQL (för varje metadataobjekt som ingår i separatorn skrev vi "update" + DB_Name + ".dbo._" + Tabellnamn + "set _" + FieldGeneralAttributes + "= 1";)
Vi angav värdet, överförde en del av data från IS nr 2 och började testa.
Resultatet var en besvikelse. För det första problem med redovisningsregistret. När separation är aktiverad är analytikern inte synlig:
Detta beror på att redovisningsregistret på DBMS-nivå är lagrat som flera tabeller, och inte alla tabeller hade värdet på det allmänna attributet inmatat (bearbetning användes för att se strukturen).
Okej, låt oss ange separatorvärdet med MS SQL, så ser vi analysen. Rapporter fungerar inte längre. Det visar sig att det finns problem med frågor till de virtuella tabellerna i redovisningsregistret "Turnover" och "TurnoverDtKt":
(Fld27033 är bara ett allmänt attribut i redovisningsregistertabellen)
Separatorn är installerad i alla tabeller, detta syns på DBMS-nivå, det är inte klart vad felet kan vara. Vi distribuerar en vanlig tom SCP, gör konfigurationsändringarna som beskrivs ovan, anger ett par dokument (i detta alternativ anger plattformen själv separatorvärdet i alla redovisningsregistertabeller), men felen återskapas. Det är dåligt, men vi utesluter redovisningsregister från de allmänna detaljerna och fortsätter att testa.
Vidare visar det sig att förskjutningsmekanismen för beräkningsregistren har slutat fungera. Vi separerade inte planerna för beräkningstyper vi försöker leta efter problemet i beräkningsregistrets tabeller och i omräkningar. Vi kontrollerar, anger värdet på huvuddetaljerna, gör T&I - utan resultat.
Längs vägen diagnostiserar vi problemet när vi skriver information från listformuläret till fristående register. I det här fallet registreras data och kan ses efter en omstart. Problemet återges också på testbasen:
Det var inte möjligt att "fixa" informationsregistren genom att manipulera med SQL (separatorvärdet i alla tabeller är satt), så vi uteslöt dem helt enkelt från de allmänna attributen. Efter flera dagars experimenterande visar sig även försök att återställa preemptionens funktion vara misslyckade.
Vid det här laget bestämmer vi oss för att stänga av dataseparering och använda RLS. När vi ställer in partitionen till "använd inte" stöter vi på felen "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX avslutades eftersom en dubblettnyckel hittades för index...". Det vill säga att det inte är så lätt att återvända till staten innan delningen. Problem med index över konverteringstabeller, inställningar för lagring av totaler och annat. Faktum är att tabellerna lagrar identiska rader, som endast skiljer sig åt i värdet av det allmänna attributet. När du tar bort ett gemensamt attribut visas icke-unika poster. Du måste ta bort onödiga poster direkt i MS SQL, ungefär så här (för konverteringstabellen):
Använd bas;
ALTER TABLE_CRgRecalc1399
ADD id INT IDENTITY(1,1);
GÅ
DELETE FROM_CRgRecalc1399
VAR ID< (SELECT MAX(id)
FRÅN _CRgRecalc1399 AS T1
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef och
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] och
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] och
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] och
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] och
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
GÅ
ALTER TABLE_CRgRecalc1399
DROP COLUMN id;
Och först efter att ha rengjort flera dussin tabeller är det möjligt att stänga av dataseparation. Efter att ha stängt av separationen är det inga problem.
3. Slutsatser.
Det fanns en gnutta hopp om att problemen var lösta i 8.3. Vi var inte för lata, vi kontrollerade det på 8.3.4.482 (med kompatibilitetsläget inaktiverat). Vi tittade på en nästan standardstyrenhet, med ändringar i konfigurationen endast för allmänna detaljer. På denna testbas aktiverades separation innan information matades in, d.v.s. plattformen var tvungen att korrekt skriva separatorvärdet i alla tabeller de skrev inte något direkt i MS SQL själva.
Resultat:
Problemet med frågor till de virtuella tabellerna "Turnover" och "TurnoverDtKt" återges.
Problemet med förtryck reproduceras.
Problemet med att skriva till oberoende informationsregister återges.
Problemet med att stänga av separationen är att du inte kan bli av med den med ett klick på en knapp!
Därför kunde vi inte ersätta RLS med en ny mekanism. Denna mekanism var tydligen tänkt för molntjänster, och i alternativet att använda delad data "oberoende", kanske uppdelningen fungerar, men vi behöver en gemensam stamdata. Vi måste bara vänta på att 1C ska rätta till felen, eller ännu bättre, för att implementera en standardmekanism för att separera efter organisation i standardkonfigurationer.
En gång diskuterade vi mekanismer för att begränsa användaråtkomst i 1C och i synnerhet.
Det tillåter användaren att inte arbeta med alla dokument, utan bara med de som indikerar en specifik organisation eller lager. Valen görs dynamiskt och lägger därför en viss belastning på driften av databasen.
Egenskapen för det allmänna separatorattributet – 1C användarseparation – låter dig ställa in tillgängligheten för listan över användare beroende på användningen av separatorer.
Om separatorn är aktiverad för en användare kommer den att synas i listan över användare i 1C Enterprise-läge - annars kommer den inte att synas.
På så sätt kan du organisera olika listor med användare för olika delar av databasen.
Egenskapen för det allmänna separatorattributet – 1C-autentiseringsseparation – låter dig skapa användare med samma användarnamn för olika delar av databasen.
Villkorlig division 1C
Villkorlig separation 1C låter dig aktivera eller inaktivera separatorn baserat på databasdata. På så sätt kan du skapa kedjor av separatorer som är beroende av varandra och agerar dynamiskt i ett visst fall.
För att aktivera villkorlig division 1C - måste du ange i egenskapen för det allmänna separatorattributet - Villkorlig division 1C - som kommer att ansvara för att fastställa faktumet att aktivera division 1C.
Det är möjligt att använda en konstant med en boolesk typ eller ett katalogattribut med en boolesk typ.
Viktigt - du måste inaktivera användningen av denna konstant/denna referensbok (välj Använd inte) som en del av avgränsare, först då kan den väljas.
Allmänna detaljer i 1C 8.3 är ett plattformsmetadataobjekt som låter dig använda ett attribut för många konfigurationsobjekt (kataloger, dokument, kontoplaner, etc.). Objektet skapades främst för att underlätta utvecklarens arbete och för att separera data.
Allmänna detaljer implementerades initialt i version 1C 7.7, men utvecklarna inkluderade det inte omedelbart i version 8-plattformen. Mekanismen för allmänna detaljer introducerades av 1C-utvecklare endast i release 8.2.14.
Det är väldigt bekvämt att lägga till allmänna detaljer för att inte ändra standardobjekt i konfigurationen. Jag använder dem ofta tillsammans med .
Efter att ha lagt till ett allmänt attribut kan det användas i frågor och visas på objektformuläret - Utåt sett skiljer det sig inte från vanlig rekvisita.
Den enda begränsningen för allmänna detaljer är oförmågan att använda dem i .
Låt oss titta på de grundläggande inställningarna och egenskaperna för allmänna detaljer som skiljer sig från andra konfigurationsobjekt:
Förening— En lista över objekt för vilka de allmänna detaljerna kommer att användas påminner om att upprätta en utbytesplan.
Få 267 videolektioner på 1C gratis:
Automatisk användning— inställningen avgör om allmänna rekvisita kommer att användas för de objekt som har angett "Automatisk" användningsläge.
Dataseparation— Vi kommer att överväga denna inställning separat.
Separering av data i 1C med hjälp av vanliga detaljer
Dataseparation- en mekanism som liknar mekanismen. Men prestandan för denna mekanism är mer effektiv och den är lättare att konfigurera.
Mekanismen låter dig konfigurera visningen av endast element som användaren kan se. Du kan till exempel skilja på alla objekt (dokument, kataloger etc.) där en viss organisation är installerad.
Ställa in dataseparation med hjälp av allmänna 1C-detaljer
För att konfigurera de allmänna detaljerna måste du ange dataseparationen - Dela. Omedelbart efter att ha klickat, kommer systemet att erbjuda att skapa standardredovisningsparametrar:
I det här fallet kommer det att vara nödvändigt att specificera sessionsparametrarna när du startar systemet hur man gör detta beskrevs med ett exempel i artikeln.
Detta slutför installationen - användaren kommer endast att ha tillgång till informationen som anges i de valda sessionsparametrarna.
Exempel på användning av vanliga rekvisita
Låt oss titta på att ställa in allmänna rekvisita i 1C 8.3 med hjälp av exemplet på en ramkonfiguration och rekvisita Organisation:
Systemet har 3 dokument där det är nödvändigt att ange organisationens detaljer: dessa är kvittofakturan, utgiftsfakturan och lönelistan.
Inställningen är enkel:
- Vi skapar ett nytt Allmänt attribut, ange typen - DirectoryLink.Organization.
- I sammansättningen ordnar vi våra dokument - Använda.
Det var allt, installationen är klar!
Låt oss se resultatet:
Systemet visar allmänna detaljer "som om de vore dina egna": i förfrågningar, i formulärdetaljer och på andra ställen. Det här är så magi! 🙂
Allmänna krav 1C 8.3 är inte tillagda
Ett gemensamt attribut är ett attribut som läggs till flera konfigurationsobjekt och kan även användas som komponent speciell datasepareringsmekanism:
- Gemensam rekvisita för flera föremål. Ett attribut som finns i flera konfigurationsobjekt där detta attribut behåller sin betydelse och typ. Ett exempel på sådan användning: Attributet "Organisation" i reglerade redovisningsdokument i en applikationslösning
- Allmänna attribut som en integrerad del av en speciell datasepareringsmekanism. Denna mekanism låter dig dela upp arbetet i separata delar applikationslösning och all lagrad data. I det här fallet är dataseparation aktiverad för det allmänna attributet.
Exempel på sådan användning: I en fysisk informationsbas Olika "ägare" av data arbetar oberoende, och varje användare av en sådan applikationslösning kommer bara att ha tillgång till sina data
Egenskapen "Data separation" för det allmänna attributet
Om den här egenskapen är inställd på "Använd inte" kommer det skapade konfigurationsobjektet endast att användas som ett attribut som ingår i flera konfigurationsobjekt.Om egenskapen är inställd på "Separate" kommer det gemensamma attributet att användas som dataseparator
Sammansättning av föremål
Egenskapen "Composition" för ett allmänt attribut bestämmer listan över konfigurationsobjekt som inkluderar detta allmänna attribut.Om egenskapen "Auto-Use" är inställd på "Använd inte" kommer det automatiska tillägget av rekvisita inte att ske, och för att välja objekt som du vill inkludera vanliga rekvisita i bör du använda egenskapen "Composition".
Egenskapen "Composition" ska också användas om det finns objekt i vilka det gemensamma attributet inte ska finnas när det gemensamma attributet används automatiskt.
Använder vanliga rekvisita
För varje konfigurationsobjekt kan kolumnen Användning ha ett av tre värden:- Automatiskt – betyder att tilldelningen av ett konfigurationsobjekt till ett allmänt attribut beror på värdet på egenskapen "Auto-Use"
- Använd - betyder att konfigurationsobjektet är en del av det allmänna attributet
- Används inte - betyder att konfigurationsobjektet inte är en del av det allmänna attributet
Konfigurationsobjekt
Det allmänna attributet (inte i datadelningsläge) kan inkludera följande konfigurationsobjekt:- Kataloger
- Dokument
- Dokumentloggar
- Karakteristiska typplaner
- Beräkningstypsplaner
- Affärsprocesser
- Uppgifter
- Informationsregister
- Ackumuleringsregister
- Bokföringsregister
- Utbytesplaner
- Externa datakällor
Egenheter
Vid registrering av ett dokument tilldelas det allmänna journalattributet värdet av det allmänna dokumentattributet eller värdet NULL om dokumentet inte är en del av det allmänna attributetAllmänna attribut kan användas i dataåtkomstbegränsningar. Det är vettigt att inkludera externa datakällor som en del av ett gemensamt attribut när det gemensamma attributet är en separator.
RÅD! Du bör inte använda allmänna attribut för att beskriva data som är en del av affärslogiken för specifika objekt.
