Varje 1C: Enterprise -administratör vet att uppgiften att separera användarrättigheter och motsvarande ändringar i arbetsgränssnittet är en av huvuduppgifterna vid införandet av ett bokföringssystem eller nya användares utseende i det. Arbetets effektivitet och datasäkerhet beror på hur väl denna uppgift utförs. Därför kommer vi idag att prata om detaljerna i att anpassa användarrättigheter och gränssnitt i en hanterad applikation.

Först och främst vill jag notera de viktigaste aspekterna av denna typ av inställningar. Många närmar sig denna fråga ensidigt och betraktar dem enbart som ett skydd mot obehörig åtkomst till data eller deras okvalificerade ändringar. Samtidigt glömmer de bort den andra sidan av myntet: skapar en enkel och bekväm arbetsmiljö... I de fall användargränssnittet är överbelastat med onödiga objekt, vars betydelse dessutom inte är helt klart för honom, uppstår en falsk uppfattning om programmets alltför komplexa komplexitet och det finns en rädsla för att göra ett misstag. Det är klart att detta inte på något sätt bidrar till en ökning av de anställdas produktivitet.

Helst ska varje anställd bara se de gränssnittselement som han behöver för att utföra sina omedelbara uppgifter. Då blir det lättare att arbeta, och frestelserna att klättra där det inte är nödvändigt kommer inte att uppstå. Dessutom är det vettigt att utföra sådana inställningar även när vissa delsystem helt enkelt inte används eller åtkomstbegränsning till dem inte krävs. Detta kommer att göra gränssnittet enklare och mer begripligt, och därför blir användaren lättare och bekvämare att arbeta med.

Om vi ​​går tillbaka lite till det förflutna kan vi komma ihåg det i normala konfigurationer Roller och Gränssnitt var en del av konfigurationen och för dem finjustering det var nödvändigt för att möjliggöra möjligheten att göra ändringar, och in grundläggande versioner var omöjligt alls.

Nackdelarna med detta tillvägagångssätt är uppenbara: det är både komplikationen av infobasunderhåll och möjliga konflikter under efterföljande uppdateringar, när ändrade konfigurationsobjekt kräver ändrade åtkomsträttigheter.

I en hanterad applikation har rättigheter och gränssnittsinställningar äntligen flyttats till användarläge och konfigureras direkt från programgränssnittet. Användarrättigheter tilldelas baserat på deras åtkomstgruppsmedlemskap. Låt oss gå till Administration - Användar- och rättighetsinställningar - Åtkomstgrupper - Åtkomstgruppsprofiler, där vi kommer att se redan förinställda profiler för de viktigaste åtkomstgrupperna.

En användare kan vara medlem i flera åtkomstgrupper samtidigt, i detta fall summeras de totala rättigheterna. I allmänhet är allt ganska klart och bekant, såvida inte inställningarna nu utförs i användarläget och inte i konfiguratorn.

Men om vi försöker hitta gränssnittsinställningarna misslyckas vi. I ett hanterat program genereras arbetsytans gränssnitt automatiskt baserat på åtkomsträttigheter. Låt oss till exempel jämföra gränssnitten i sektionspanelen Administratör och försäljningschef:

I allmänhet är tanken sund, det finns åtkomsträttigheter till objektet - vi visar det i gränssnittet, nej - vi döljer det. Detta är mycket bättre än meddelanden som dyker upp i en vanlig applikation om åtkomstöverträdelser när de senare inte matchar det tilldelade gränssnittet. Om du lägger till rättigheter till en åtkomstgrupp eller omvänt tar bort dem, visas eller försvinner gränssnittselementen som är associerade med dem. Bekväm? Ja.

Användaren kan också självständigt anpassa sin arbetsyta inom gränserna för sina åtkomsträttigheter. Vid första anblicken ser allt bra ut, men det var inte utan en fluga i salvan. Det finns ingen mekanism för att centralt konfigurera och tilldela ett standardgränssnitt till användare i en hanterad applikation.

Om vi ​​tittar på Administration - Användar- och rättighetsinställningar - Personliga användarinställningar - Användarinställningar, kommer vi att se en lista över alla objekt vars inställningar har ändrats av användaren, men vi kan inte ändra dem på något sätt.

De där. Vi erbjuds att gå direkt under användaren och konfigurera arbetsgränssnittet för hans räkning. Ett kontroversiellt beslut, särskilt om det inte finns två eller tre användare. Lyckligtvis har utvecklarna gett möjlighet att kopiera användarinställningar, vilket gör det möjligt att anpassa gränssnittet för en av användarna på det sätt som vi behöver för att snabbt tillämpa inställningarna för alla andra.

För att inte vara ogrundad, låt oss analysera ett praktiskt exempel. Som förberedelse för övergången till onlinekassor beslutades det att automatisera kontanterna i ett litet nätverk av tandkliniker. Grunden för automatisering av kliniker var branschprogramvaran som inte var baserad på 1C och som inte gav möjlighet att ansluta en skatteregistrator, därför beslutades att använda Enterprise Accounting 3.0 -konfigurationen för att automatisera utcheckningspunkterna, som innehåller alla nödvändiga funktioner.

Här står vi inför två svårigheter, men om du tittar närmare kommer du att upptäcka att det här är två sidor av samma mynt. Kort sagt: personalen hade aldrig arbetat med 1C tidigare, och därför var det nödvändigt att skapa den mest lättlästa arbetsmiljön, samtidigt som informationsbasen skyddades från eventuell okvalificerad personalexponering. Hanterad applikation låter dig helt enkelt kombinera affärer med nöje, vilket gör det så att användaren är begränsad och samtidigt låter honom arbeta bekvämt utan att märka begränsningarna.

Låt oss börja. Först och främst måste du skapa en användargruppsprofil. Om vi ​​öppnar standardprofilerna ser vi att det inte finns någon möjlighet att ändra dem. Detta, enligt vår mening, är korrekt, historien känner till många exempel när standardrättigheter i en ansträngning av serviceivrar skottades till ett sådant tillstånd att de måste återställas från referenskonfigurationen. Det kan också vilseleda andra användare eller administratörer av denna databas, som förväntar sig att se standarduppsättningar av rättigheter under standardprofiler.

Därför hittar vi den profil som passar bäst för våra uppgifter, i vårt fall är det försäljningschefen och gör en kopia av den, som vi kommer att ge namnet Kassör. Nu kan vi anpassa rättigheterna efter eget gottfinnande. Standard plattlista är dock inte särskilt bekvämt att arbeta med, om du inte snabbt behöver hitta ett alternativ som du redan vet, är det i de flesta fall mycket mer bekvämt att arbeta med listan genom att aktivera gruppering efter delsystem.

Vi kommer inte att fördjupa oss i denna fråga på samma sätt, eftersom tilldelningen av rättigheter beror på de specifika uppgifter som användaren står inför, vi kan bara råda dig att vara försiktig och inte gå till ytterligheter. Kom ihåg att ditt jobb är att skapa en bekväm och säker arbetsmiljö, inte direkt förbjuda allt.

Efter att ha skapat en profil, tilldela en åtkomstgrupp till nödvändiga användare och kör programmet under en av dem. Beroende på tilldelade rättigheter ser du ett automatiskt genererat gränssnitt.

I princip är det redan ganska bra, men i vårt fall börjar allt bara. Till vår förvåning har många användare och administratörer fortfarande ingen aning om hur "Taxi" -gränssnittet är konfigurerat och fortsätter att klaga på dess "olägenheter".

Låt oss gå till Huvudmeny - Visa, där vi kommer att se ett antal inställningar relaterade till gränssnittet.

Låt oss börja med sektionspanelinställningar, i vårt fall var sortimentet begränsat till en kort lista med tjänster, så lagersektionen visade sig vara överflödig, för att inte komplicera och belasta gränssnittet tar vi helt enkelt bort det.

Sedan, i varje avsnitt, genom att klicka på kugghjulet i det övre högra hörnet, kommer vi i följd att konfigurera navigering och åtgärder. Här kommer vi också att ta bort allt som inte är nödvändigt i det dagliga arbetet, men tvärtom kommer vi att lyfta fram det nödvändiga.

Du kan till och med jämföra hur det var och hur det blev:

Slutligen, låt oss konfigurera panelerna. Eftersom vi har få sektioner är det vettigt att flytta sektionspanelen uppåt och den öppna panelen nedåt och därigenom utöka arbetsytan horisontellt, vilket är viktigt för bildskärmar med en liten diagonal eller 4: 3 -format.

Efter avslutad bör du kontrollera alla inställningar igen, det är bäst att göra detta genom att imitera verklig handling kassör, ​​vilket omedelbart hjälper till att bedöma bekvämligheten med att arbeta med gränssnittet. I vårt fall visade det sig vara enkelt och bekvämt arbetsplats kassören, i alla fall, det fanns inga problem med dess utveckling av personalen:

Nu kommer vi in ​​i programmet igen som administratör och går till Administration - Användar- och rättighetsinställningar - Personliga användarinställningar - Kopieringsinställningar. Vår uppgift är att distribuera de ändringar vi gjort till de återstående användarna av kassörgruppen. Operationen i sig är ganska enkel: vi väljer den användare vars inställningar vi kopierar, anger vem och väljer vilken.

Och slutligen kan du hindra användaren från att konfigurera gränssnittet på egen hand, för att göra detta, gå tillbaka till gruppprofilen och avmarkera åtgärden Sparar användardata.

Som du kan se är konfigurering av gränssnitt och användarrättigheter i en hanterad applikation ganska enkel och, trots vissa nackdelar, ger administratörer mycket mer flexibilitet och bekvämlighet, så att de snabbt kan skapa en bekväm och säker arbetsmiljö.

• Taggar:

Aktivera JavaScript för att se

"1C: Enterprise 8. Managed Application". Nya möjligheter

Nikita Zaitsev

Vi fortsätter att granska möjligheterna och arkitektoniska koncept för den nya generationens tekniska plattform - "1C: Enterprise 8. Managed Application". Artikeln kommer att behandla olika typer av klientapplikationer, en ny princip för att använda konfigurationsundersystem, mekanismer för funktionella alternativ och hanterade rapporter och några andra innovationer i "Managed Application".

Klientapplikationstyper

I tidigare versioner av 1C: Enterprise 8 fanns det inga alternativ för att starta klientprogrammet. För att alla användare skulle kunna arbeta med infobaser användes endast en typ av klientprogram, som kallades "klient". För att organisera distansarbete för användare med en infobas har olika tekniker använts (och används nu), som var och en har sina egna fördelar och nackdelar. Fjärranslutning kan organiseras med standardmedel "1C: Enterprise 8":

Bygga en distribuerad informationsbas... Varje grupp av fjärranvändare arbetar med sin egen lokala infobas; data synkroniseras regelbundet mellan huvudinfobasen och fjärrdatabaserna. Fördelen med denna teknik är att fjärranvändare inte alls behöver direktåtkomst till den "huvudsakliga" informationsbasen. Men det finns också en nackdel - dataändringar som görs i en av noderna i den distribuerade infobasen överförs inte omedelbart till angränsande noder, men efter en tid.

Arbeta via webbgränssnittet (baserat på 1C: Enterprise 8.Web -tilläggsplattformen). Fördelar - möjligheten att arbeta på kommunikationskanaler med låg hastighet, det finns ingen anledning att installera "1C: Enterprise 8" på användarens dator. Nackdelar - betydande funktionell utarmning användargränssnitt jämfört med den tjocka klienten, behovet av att involvera ASP.NET -programmerare för att utveckla en webbapplikation.

Fjärråtkomst till infobasen kan också organiseras med hjälp av icke-systemverktyg:

Arbeta genom en terminaltjänst. Fördelar - möjligheten att arbeta över kommunikationskanaler med låg hastighet, det finns inget behov av att ändra något i konfigurationen. Men å andra sidan krävs ytterligare licenser för serverprogramvara och ytterligare hårdvaruresurser (helst en dedikerad server för "terminal" -användare).

Arbeta via en VPN -anslutning. Fördel - användaren arbetar med fjärrinfobasen som vanligt, som om den befinner sig i hans lokal lokalt nätverk... Nackdel - en pålitlig höghastighetskommunikationskanal krävs, stora trafikmängder förbrukas.

Klient-server-interaktion

"Hanterad applikation" är utformad för att förenkla och minimera kostnaderna för att organisera distansarbete för användare med infobaser - nu kan användare arbeta med infobaser online både inom företagets lokala nätverk och via Internet.

Det finns tre olika typer av klientprogram som du kan använda i en "Hanterad applikation".

"Fat client". Det liknar klientapplikationen för tidigare versioner av 1C: Enterprise 8, men är kompatibel med två driftsätt - normalt och hanterat. Den största skillnaden mellan dem är principen om att bygga en global kommandogränssnitt(mer information om den nya gränssnittsmodellen för "Managed Application" beskrivs i föregående artikel i vår serie). "Fettklienten" förbrukar fler systemresurser på användarens dator, men det innebär inga funktionsrestriktioner för att arbeta med konfigurationen.

"Tunn klient". En helt ny applikation som ingår i 1C: Enterprise. Det fungerar bara i ett kontrollerat läge, det är avsett för användare att arbeta med infobaser via Internet (det kan naturligtvis också fungera på företagets lokala nätverk). För en "tunn klient" finns det en "låg anslutningshastighet" -läge; när du arbetar i den optimerar plattformen interaktionsprocesserna mellan klientprogrammet och servern för kommunikationskanaler med låg hastighet. Den "tunna klienten" kräver betydligt mindre systemresurser än den "tjocka klienten", men är funktionellt begränsad - den fungerar bara med hanterade konfigurationsformer, konfiguratorläget är inte tillgängligt.

Webbklient. I det här fallet behöver du inte installera 1C: Enterprise 8 eller någon ytterligare programvara på användarens dator. Arbete med informationsbaser "1C: Enterprise 8" utförs via en vanlig webbläsare (MS Internet Explorer eller Mozilla FireFox). Webbklientens funktionsbegränsningar är desamma som för den "tunna klienten". Konfiguratorläget stöds inte endast om man arbetar med hanterade formulär. Nästan fullständig (med undantag för några mindre begränsningar) deklareras identitet utseende och systembeteende när du arbetar med en tunn och webbklient. Tyvärr, när denna artikel skrevs, hade webbklienttekniken ännu inte publicerats av 1C, så informationen som tillhandahålls om denna teknik är endast baserad på medföljande dokumentation för den hanterade applikationen.

Delsystembaserat kommandogränssnitt

För att inte bli förvirrad och tydligt förstå vilka metoder för anslutning till infobaser och vilka gränssnittsmodeller som stöds olika typer klientapplikationen "1C: Enterprise 8", presenteras informationen bäst i form av en tabell (se tabellerna 1 och 2).

När du arbetar med "Hanterad applikation" går organisationen av onlineåtkomst till "1C: Enterprise 8" infobasen i princip ner till att skapa en webbserver. För varje infobas behöver du dessutom:

Skapa en infobas -beskrivningsfil (två rader XML);

Konfigurera ett program (virtuell katalog) som motsvarar infobasen på sidan av webbservern (MS IIS eller Apache).

Dessa operationer utförs en gång för varje infobas som fjärrarbete förväntas. Naturligtvis, för att fjärranvändare ska kunna arbeta med infobasen i "tunn klient" eller webbklientläge måste konfigurationen utvecklas och (eller) modifieras för den nya gränssnittsmodellen för "Hanterad applikation" och måste innehålla den hanterade former av de objekt som de kommer att arbeta fjärranvändare med.

Observera att med tillkomsten av webbklientteknik får "1C: Enterprise 8" fullfjädrad funktionalitet på flera plattformar. Nu alla element informationssystem kan köras under både Windows och Linux (se tabell 3).

Den enda arbetsplats där Windows måste installeras är informationssystemadministratörens arbetsplats, där du måste köra 1C: Enterprise 8 i konfiguratorläget.

Ange kommandosynlighet som standard

Det bör också noteras förändringarna i klient-serverarkitekturen för "1C: Enterprise 8" som gjorts i samband med uppkomsten av nya typer av klientapplikationer. I tidigare versioner av plattformen var den enda formen av interaktion mellan klienten och servern en anslutning, det vill säga en hård anslutning mellan klientprogrammet och en av arbetarprocesserna i serverklustret. Denna anslutning upprättas när klienten ansluter till infobasen och kvarstår tills klientprogrammet stängs.

Anpassning av användargränssnitt

I en "Managed Application" när du arbetar med " tunn klient"Eller så använder webbklienten ett mer flexibelt system för klient-server-interaktion: en användarsession. Varje samtal från klientprogrammet till servern är separat och behandlas av serverklusterna oberoende av de föregående samtalen. Detta schema tillåter:

Öka systemets "överlevnadsförmåga". Om en serverklusterarbetarprocess av någon anledning blir otillgänglig, byter klientprogram till andra tillgängliga arbetsprocesser (i tidigare versioner innebar en "krasch" av arbetsflödet att alla anslutningar bryts och "kraschar" alla klientapplikationer som betjänas av processen).

Förbättra systemprestanda genom att dynamiskt balansera arbetsbelastningar. I tidigare versioner distribuerades belastningen endast vid den första klientåtkomsten till servern. I "Managed Application" övervakar klusterhanteraren ständigt arbetsbelastningen för arbetarprocesser och fördelar belastningen mellan dem. Om arbetarprocessen eller arbetarservern som betjänade klientprogrammet plötsligt blir överbelastad, byts klienten nästa gång till servern till en mindre laddad process eller server.

Konfigurationsundersystem

I tidigare versioner av 1C: Enterprise 8 hade konfigurationsundersystemen ingen funktionell belastning. Naturligtvis kan det inte sägas att före "Managed Application" visade sig delsystemmekanismen vara rent dekorativ - konfigurationsutvecklare och specialister som var involverade i att underhålla informationsbaser använde den för att lösa en mängd olika tekniska problem. Men delsystemen hade absolut inget inflytande på konfigurationens beteende i användarläge. Dessutom kunde inte ett enda delsystem ha definierats alls i konfigurationen, och detta påverkade inte dess funktion på något sätt.

I en "Managed Application" är situationen helt annorlunda: den hierarkiska strukturen för delsystem är det viktigaste konfigurationselementet som det globala kommandogränssnittet är baserat på. Användargränssnittet är utformat enligt följande principer:

Kommandogränssnittsdelar skapas på grundval av rotkonfigurationsundersystemen (ligger på den första nivån i hierarkin).

Baserat på tillhörande till motsvarande rotsubsystem och underordnade delsystem för vissa konfigurationsobjekt skapas en uppsättning kommandon för motsvarande avsnitt.

För varje kommando från uppsättningen avgörs om det är tillgängligt för den aktuella användaren i princip. Beslutet fattas i två steg: först, de kommandon som användaren inte har åtkomsträttigheter tas bort från uppsättningen och sedan kommandon som inaktiveras med hjälp av funktionella alternativ.

För var och en av de kommandon som är tillgängliga för användaren bestäms synlighetsläget: visa kommandot i motsvarande gränssnittspanel eller dölj kommandot. Plattformen kontrollerar inställningarna som anges av konfigurationsutvecklaren och infobasanvändaren. Konfigurationsutvecklaren kan ställa in olika synlighetslägen för ett kommando för olika roller, och användaren kan, om så önskas, åsidosätta synligheten för var och en av de kommandon som är tillgängliga för hans arbetsplats.

När man byter till en "Hanterad applikation" blir konfigurationsundersystem från ett "tjänst" -objekt till ett nyckelobjekt, och uppgiften att kompetent utforma strukturen för delsystem och distribuera konfigurationsobjekt mellan dem blir av yttersta vikt för utvecklaren.

Funktionsalternativsmekanism

Med hjälp av mekanismen för funktionella alternativ kan implementatorn dynamiskt inkludera eller utesluta vissa funktioner från användarens applikation och dess motsvarande gränssnittselement, och inga ändringar av den faktiska konfigurationen krävs. De funktionella alternativen är baserade på applikationsdata för infobasen och kan kopplas på direkt under systemdriften.

Påverkan av funktionella alternativ på ett gränssnitt

Det bästa sättet att förklara hur funktionella alternativ fungerar är att specifikt exempel... Låt oss säga att vi skapar en konfiguration för att automatisera ett litet butik. När vi utformar vår konfiguration markerar vi serien funktionalitet som är "pass-through" till konfiguration, med behovet av dessa funktioner bestäms av kontexten för en viss implementering eller till och med en viss process.

På företaget kan olika handelsutrustningar (till exempel streckkodsskannrar) användas för att automatisera redovisning.

Flera lager kan vara organiserade på ett företag; följaktligen kan det vara nödvändigt att föra register i samband med lager.

Redovisning kan upprätthållas på olika sätt för lokala och exportprodukter, för lokala och utländska leverantörer.

Beroende på specifikationerna för en viss implementering bör samma konfigurationsobjekt se ut och agera annorlunda, till exempel:

Om streckkodsläsare används måste ett kommando för att styra skannern finnas i form av vissa typer av dokument.

Om bokföringen hålls inom ramen för lager bör detaljer och kommandon som är associerade med lagret visas i lämpliga formulär (säljdokument, rapporter).

Om företaget arbetar med utländska leverantörer bör lämpliga formulär (avräkningsdokument, rapporter) visa detaljer och kommandon som är relaterade till valutaräkenskaper (valuta, växelkurs, "beräkna om till nuvarande kurs", etc.).

Mekanismen för funktionella alternativ gör det möjligt för applikationsutvecklaren att anpassa utseendet och beteendet hos konfigurationsobjekt till kraven för en specifik implementering och specifika för ett visst företag utan otroligt tråkig kodning av funktioner som styr gränssnittets synlighet och tillgänglighet element. Utvecklaren definierar deklarativt en uppsättning funktioner (objekt och konfigurationskommandon) och anger regler enligt vilka plattformen ska aktivera eller inaktivera den angivna uppsättningen. Användaren, å andra sidan, får ett applikationsgränssnitt som inte är belastat med "onödiga detaljer" och inte slösar tid på förfarandena, "i vilket fall detta område är viktigt och när det är vettigt att klicka på den här knappen" - allt som är framför hans ögon är betydelsefullt.

Det bör noteras viktig poäng: tillståndet för funktionella alternativ och deras parametrar påverkar inte sammansättningen av konfigurationsobjekt eller sammansättningen av tabeller och databasfält. Metadataobjekt och deras attribut, som styrs av funktionella alternativ, försvinner endast från användargränssnittet, men inte från infobasen. Funktionella alternativ används inte för att begränsa möjligheterna till applikationskonfiguration, utan för att inaktivera och dölja för användaren de funktioner som är redundanta och / eller irrelevanta i det nuvarande användarsammanhanget.

Hanterade rapporter Hanterat rapportformulär

Rapporteringsmekanismen "Managed Application" har behållit "familjefunktionerna" i rapporteringsmekanismen för den tidigare versionen av "1C: Enterprise 8":

Rapporten bygger på schemat för datakomposition. I allmänhet är det tillräckligt för att skapa en ny rapport i konfigurationen för att utveckla ett layoutschema - rapportformuläret (inklusive olika servicefunktioner - dekryptering, urval, villkorlig design etc.) genereras automatiskt av plattformen.

I anpassat läge kan varje användare om så önskas ändra några av layoutschemainställningarna, skapa och spara sina egna personliga "rapportvarianter".

Konfigurera en rapportvariant

Hanterade rapporter (de så kallade rapporterna som implementeras med "Managed application" -tekniken) har ett antal viktiga skillnader från sina föregångare.

Rapporten genereras endast på serversidan, endast de färdiga resultaten skickas till klientprogrammet. I tidigare versioner av 1C: Enterprise 8 kan rapporten genereras både på serversidan och på klientsidan.

Mekanismen för att hantera rapportinställningar har designats avsevärt. Denna process är nu hierarkisk och består av rapportvarianter, rapportvariantinställningar och anpassade rapportinställningar.

Rapportinställningarna sparas i systemdatabastabellen eller (om de tillhandahålls av konfigurationsutvecklaren) i ett speciellt objekt i infobasen "Inställningar lagring". I tidigare versioner av 1C: Enterprise 8 var du tvungen att antingen spara rapportinställningarna som en fil eller utveckla din egen lagring av inställningar baserat på informationsregister.

Anpassa rapporten

Låt oss stanna mer i detalj om mekanismen för att hantera rapportinställningar. Vid första anblicken kan det verka alltför komplicerat, men i själva verket är allt väldigt enkelt och bekvämt. Rapportinställningar hanteras på flera nivåer:

Konfiguratornivå. Konfigurationsdesignern skapar ett schema för datasammansättning och definierar rapportvarianter (en rapportvariant är en samling av schemainställningar för datasammansättning). Till exempel för rapporten "Analys av försäljning" kan alternativen "Efter perioder" (analys av försäljningsvolymen i samband med perioder) och "Efter grupper" (analys av försäljningsvolymen i samband med varugrupper) definieras. Konfigurationsdesignern bestämmer också vilka inställningsobjekt som ska vara tillgängliga för användaren att ändra när han arbetar med rapporten.

Implementation Specialist Level. Utför "omjustering" av rapporten för kraven i ett visst företag. Implementeringsspecialisten har tillgång till samma funktioner som konfigurationsutvecklaren, men en viktig nyans bör noteras: du kan ändra de befintliga rapportalternativen och lägga till nya i användarläget 1C: Enterprise 8 utan att göra några ändringar i konfigurationen.

Informationsbasanvändare. Användaren styr de rapportanpassningsobjekt som har gjorts tillgängliga av konfigurationsutvecklaren och implementeringsspecialisten.

Utveckling av rapportalternativ

Bekvämligheten med den nya strukturen för rapportinställningarna i jämförelse med de tidigare versionerna av "1C: Enterprise 8" är att:

Delar av anpassade inställningar redigeras antingen direkt på rapportformuläret (om tecknet " snabb åtkomst"), Eller i en separat enkel form. Detta formulär innehåller bara de mest nödvändiga kontrollerna, är inte överbelastad med funktionalitet och chockar inte oförberedda användare (jämför bara utseendet på detta formulär med formuläret för hantering av rapportalternativet).

Uppsättningen av rapportalternativ och användarinställningar kan redigeras i klientprogrammet, systemadministratören eller avancerad användare kan ändra rapporten direkt, förenkla eller komplicera dess anpassning.

På grund av det faktum att alla inställningar lagras i infobasen kan processen för utbyte av inställningar mellan användare förenklas till gränsen - för detta måste konfigurationsläget konfigureras för att lagra rapportinställningar i ett speciellt konfigurationsobjekt "Inställningar lagring ". Systemadministratören konfigurerar de nödvändiga alternativen för rapporten, användaren behöver bara öppna rapportformuläret, välja ett alternativ, ställa in värdena för "snabba" användarinställningar och klicka på "Generera" -knappen.

Anpassning av flera nivåer

Om vi ​​försöker formulera fördelarna med hanterade rapporter jämfört med "vanliga" rapporter om "1C: Enterprise 8" i tre ord, kommer dessa ord att vara: produktivitet, flexibilitet, bekvämlighet. Hanterade rapporter är snabbare - alla rapportgenereringsoperationer utförs på serversidan. De ger en mycket mer flexibel konfigurationsmekanism genom att dela upp inställningarna i två nivåer. Slutligen är hanterade rapporter bara lättare att arbeta med. Men rapporterna, närmare bestämt den information som presenteras i rapporterna, är slutprodukten av informationssystemets arbete, det är resultatet som systemet tillhandahåller konsumenten.

Detta avslutar vår granskning av innovationen "Managed Application". Kanske återkommer vi till detta ämne efter den första utgåvan. Naturligtvis kan du få en fullständig bild av möjligheterna i den nya generationen av plattformen bara genom att hålla den i dina händer och noggrant läsa dokumentationen - partner till 1C och registrerade användare av 1C: Enterprise 8 har redan denna möjlighet.

Nyheter. 15 till 15

Datorer

ASUS (http://asus.com.ru) tillkännagav lanseringen av personlig dator Eee Box. Produkten är monterad i en ultrakompakt kaross, Eee Box kan monteras på ett VESA-fäste. Systemet implementerar medel för höghastighetsnedladdning och internetanslutning (ASUS Express Gate), det finns en trådlös WiFi -adapter 802.11n.

Hej.

I det förra inlägget skrev jag om vanliga och hanterade applikationer, vanliga och hanterade formulär ah "1C: Enterprise", artikeln finns här.
Framtiden tillhör den hanterade applikationen, nu byggs många typiska konfigurationer utifrån den hanterade applikationen, dessa inkluderar:
1. "1C: Trade Management 11";
2. "1C: Ledning av ett litet företag 8";
3. "1C: Dokumentflöde 8";
4. "1C: Enterprise Accounting 3.0";
5. "1C: Manufacturing Enterprise Management 2.0" (kommer att släppas inom en snar framtid);

Dessa applikationer är baserade på hanterade formulär och öppnas automatiskt i den tunna klienten.

Många externa behandlingar och rapporter har inte hanterade formulär och när de öppnas i en hanterad applikation öppnas de men kommer att vara tomma, d.v.s. inte som arbetare arbetar de i vanliga applikationer.

Ett exempel på att öppna behandlingen beskrivs i inlägget: ""

De flesta generika och annan behandling kan bara köras i en vanlig applikation.

Tänk nu på följande fråga: Hur kan jag starta ett vanligt program om programmet startas i en tunn klient som standard?

Konfiguratorparametern måste ställas in Hanterad applikation och vanlig applikation, och sedan enligt prioriteten när du väljer att starta programmet.

Prioriteten när du väljer att starta programmet är följande:
1. Det första att analysera är registreringsegenskapen för infobasen.
2. Den andra är att analysera om användaren är tvungen att konfigurera en vanlig eller hanterad applikation. Om värdet är Auto utförs övergången till nästa nivå.
3. Och den sista analyseras huvudläget för konfigurationsstart.

För att fånga det ögonblick som programmet startas och det ögonblick som arbetet stängs av, tjänar det.

Låt oss överväga var och en av punkterna mer detaljerat.

Skapa vanliga och hanterade formulär blir tillgängliga om parametern är inställd i konfiguratorläget Service - Allmänt - Hanterad applikation och vanlig applikation

Programlanseringsprioritet

Den första när du väljer en klient att starta, analyseras egenskapen för infobasregistrering för den här datorn... För att göra detta, klicka på knappen Ändra i infobasregistreringsfönstret, gå till den tredje fliken i infobasredigeringsformuläret och i gruppen Grundläggande startläge välj vilken typ av klient som ska startas.

Andra applikationsstartläget för en specifik användare analyseras. Det finns i listan över användare. Administration - Användare väljer en användare och på fliken Annat i markeringsfältet Startläge välj värdet Managed application eller Regelbunden ansökan.
För roller som är markerade i listan Tillgängliga roller måste du ange rätten att köra den tjocka klienten.

Jag publicerar det andra kapitlet i min bok "Development Basics in 1C: Taxi"

Kapitel 2: Vanlig och hanterad 1C -applikation

I det här kapitlet ska vi titta på vad en vanlig applikation och en hanterad applikation är och hur de skiljer sig från varandra, men innan det, låt oss titta på begreppet ett "gränssnitt".

Vad är egentligen ett "gränssnitt"? I själva verket är detta en gemensam gräns mellan två interagerande system (mycket ofta är en person ett system). Ta en bil, till exempel. Har den ett gränssnitt? Åh visst. Men vad är den gemensamma gränsen mellan en bil och en person? För det första är det en arbetsplats, d.v.s. direkt förarsätet och kontroller (ratt, gaspedal, bromspedal, etc.). För det andra är detta principerna för interaktion mellan människor och bilar, som är någon form av regler. Till exempel, för att accelerera bilen, måste du trycka på gaspedalen, för att sakta ner - bromspedalen, för att svänga åt höger måste du skruva av ratten till höger, etc. Tack vare dessa två enheter kan en person köra bil. Ta bort en sak och du kommer inte att kunna köra.

I världen programvara allt är exakt detsamma. Ett system är en person - en operatör, en användare. Och det andra systemet är en applikation som skapats för att automatisera en viss typ av mänsklig aktivitet (vi överväger tillämpad programmering).

Till exempel måste vi självständigt underhålla lagerbokföring: att genomföra varornas ankomst till lagret, skriva av den här produkten och övervaka saldona. Vad kommer att vara den gemensamma gränsen mellan applikationen, oavsett hur och var den är skriven, och användaren? För det första är dessa organ för inmatning av information - annars, hur kan du överföra till programmet att 5 delar av någon produkt har kommit till lagret. I vårt fall är det dator tangentbord och PC -mus... För det andra är det ett interaktionssystem mellan en dator och en person. Det kan till exempel vara ett kommandoradsgränssnitt: du kommer att ange olika textsträngar (kommandon) med hjälp av tangentbordet och använda dem för att utföra nödvändiga åtgärder (registrera ankomst av varor, konsumtion av varor, etc.). Ett sådant gränssnitt ser ut ungefär så här: se fig. 1.2.1.

Ris. 1.2.1 Exempel på kommandorad

Denna figur visar kommandorad operativ system Windows, med hjälp av det kan du utföra nästan alla operationer som du gör i Explorer: kopiera filer, ta bort filer, skapa kataloger etc.

Denna typ av gränssnitt har länge varit föråldrad och har ersatts av ett grafiskt användargränssnitt (eng. grafiskt användargränssnitt GUI). I detta gränssnitt sker interaktionen mellan användaren och applikationen genom olika grafiska element ritade på displayen (knappar, ikoner, switchar, etc.). I det grafiska gränssnittet har operatören slumpmässig åtkomst via kontrollerna till alla grafiska element. I vårt fall, när vi automatiserar lagerbokföring, kan interaktionen se ut så här: operatören klickar på "Ankomst" -knappen, produktvalsformuläret öppnas, där operatören väljer önskad produkt från listan och anger dess mängd. Om du behöver göra en kostnad klickar operatören på knappen "Förbrukning", valformuläret öppnas också, där operatören också väljer önskad produkt och anger dess mängd. När det är nödvändigt att stämma av saldona klickar operatören på knappen ”Saldon” och programmet visar varans saldo på lagret. Således kan du med hjälp av detta grafiska gränssnitt ganska framgångsrikt hålla reda på varor på lagret.

Låt oss avsluta med den teoretiska delen och gå direkt till ämnet i detta kapitel. Nämligen till de typer av applikationsgränssnitt i 1C -programmet, som alla är grafiska användargränssnitt. 1C: Enterprise 8 -programmet har två globala typer av grafiska applikationsgränssnitt. Dessa är normalt applikationsläge och applikationsläge under Managed Forms (eller Managed Application).

Plattformar av version 8.0 och 8.1. arbetade bara under normalt läge, högre versioner av plattformen (8.2, 8.3, etc.) kan fungera i både normalt applikationsläge och hanterat applikationsläge.

Normalt applikationsläge

Nästan alla moderna konfigurationer körs redan i hanterat läge, men det finns fortfarande organisationer som använder äldre konfigurationer som körs i vanligt applikationsläge. Därför måste du veta hur en typisk applikation fungerar. Detta beskrivs i detalj i min bok (kapitel 3 och 4). Här kommer vi bara att beröra de mest allmänna punkterna.

Normalt applikationsläge använder gränssnittet och formulär som användes i plattformar 8.0 och 8.1. Tidigare har detta läge inte namngetts på något sätt, men nu kallas det "normalt applikationsläge", och de formulär som används i det här läget kallas "normala former".

Låt oss ta en snabb titt på hur det här läget ser ut. Det kommer redan att vara bekant för många, men vissa, särskilt de som inte har hittat arbete under plattformarna 8.0 och 8.1, kommer att se det för första gången.

Efter att ha laddat programmet ser användaren ett gränssnitt med en meny högst upp (se bild 1.2.2).

Fig 1.2.2 Gränssnittsvy för en vanlig applikation

Genom att navigera genom menyalternativen kan användaren öppna olika formulär. I grund och botten är det här former av listor över referensböcker och dokument (se fig. 1.2.3), men det kan också finnas rapporter, bearbetning, kontoplaner etc.

Fig. 1.2.3. Formen för dokumentlistan

Från listformuläret kan användaren öppna ett dokument eller en referensbok (se bild 1.2.4).

Ris. 1.2.4. Dokumentformulär

Utvecklaren kan använda automatiskt genererade formulär eller självständigt designa dem.

Utvecklaren måste konstruera de vanliga formerna med musen: placera de nödvändiga elementen (knapp, fält, tabell) på formuläret, flytta dem till en lämplig plats och bestäm storleken (se bild 1.2.5).

Fig 1.2.5. Konstruera vanliga former

Mycket ofta, när man utvecklade komplexa former, var det nödvändigt att ta hänsyn till interaktionen mellan formelement med varandra. För detta upprättades bindningar. Ibland gick de vilse, och formen tog inte riktigt vacker utsikt... Vi kommer inte att gå för djupt in i denna mekanism och konsekvenserna av dess missbruk, eftersom den för kontrollerade former har tappat sin relevans.

Slutligen noterar jag att, till skillnad från en hanterad applikation, kan en vanlig applikation bara fungera under en "tjock klient". I stort sett är detta den viktigaste, mest kardinala skillnaden mellan konventionella och kontrollerade former. Eftersom det hanterade applikationsläget var särskilt utformat för att köras under en "tunn klient".

Hanterat applikationsläge

Så vad är den särart och grundläggande skillnaden mellan det hanterade applikationsläget och det vanliga? Den största skillnaden är användningen av ett hanterat kommandogränssnitt och hanterade formulär. Låt oss analysera var och en av dessa enheter separat. Vad är ett hanterat kommandogränssnitt? För att besvara denna fråga är det nödvändigt att gå djupt in i det förflutna igen.

Låt oss i sin enklaste form överväga hur utvecklingen av konfigurationen utfördes i en vanlig applikation. Först utformade vi affärslogik: dokument, kataloger, rapporter, bearbetning och deras interaktion med varandra. Sedan satte vi upp rollerna, till exempel hade en användare med rollen "Leverantör" tillgång till dokumentet "Ankomst av varor", men inte till "Varukonsumtion" -dokumentet. Och tvärtom, en användare med rollen "Säljare" hade tillgång till dokumentet "Förbrukning av varor", men till dokumentet "Ankomst av varor" - nej. Nästa steg var att utveckla gränssnitt för varje typ av användare. De som har praktiserat utveckling under en vanlig applikation kommer ihåg att det fanns ett konfigurationsobjekt som "Interface", där det var möjligt att konfigurera varje meny som menyn i figur 1.2.2. Och i vårt fall var utvecklaren tvungen att arbeta hårt för att göra två gränssnitt: ett för leverantören och det andra för säljaren. För om han utvecklade ett gemensamt gränssnitt där du kan öppna både dokumentet "Varukvitto" och dokumentet "Varukonsumtion", skulle det inte vara helt korrekt om leverantören, när han försöker öppna listan över dokument "Varukonsumtion", fått ett meddelandesystem att han inte har rätt att göra det. För att undvika detta var det nödvändigt att skapa två gränssnitt och ange för varje användare vilket gränssnitt han skulle arbeta under.

I hanterat applikationsläge är allt mycket enklare. Vi kommer att utforska det hanterade kommandogränssnittet mer detaljerat i nästa del. I denna del kommer vi att bryta ner det i de mest allmänna termerna. När det gäller taxi -gränssnittet ser det hanterade kommandogränssnittet ut så här:

Ris. 1.2.6. Kontrollerat kommandogränssnitt

När en hanterad applikation utvecklas måste programmeraren ta en lite annan väg. Innan vi utvecklar affärslogiken måste vi definiera delsystemen som kommer att inkludera våra objekt (i en normal applikation finns de också, men de är mer av deklarativ natur). Till exempel kommer dokumentet "Ankomst av varor" att ingå i delsystemet "Leverans", och dokumentet "Förbrukning av varor" kommer att inkluderas i delsystemet "Försäljning". Samtidigt kan vissa objekt placeras i flera delsystem samtidigt: "Produkter" -katalogen kommer att ingå i delsystemet "Försäljning", delsystemet "Tillförsel" och delsystemet "Marknadsföring". I det här fallet behöver utvecklaren inte skapa ett "gränssnitt" -objekt, systemet bygger automatiskt önskad gränssnittstyp baserat på inställningarna för användarrättigheter och funktionella alternativ.

Om någon användare har en roll som inte har rättigheter att se delsystemet, till exempel "Supply", så kommer 1C -applikationen helt enkelt inte att se detta menyalternativ. Dessutom kommer han inte att se ett dokument i menylistan, som han inte har rätt att åtminstone visa.

I figur 1.2.6 har du sett användargränssnittet med fullständiga rättigheter, och till exempel kommer säljarens gränssnitt att se ut så här:

Ris. 1.2.7. Begränsat användargränssnitt

En annan skillnad från det vanliga gränssnittet är att användaren självständigt kan bestämma utseendet på sitt gränssnitt med hjälp av navigeringsinställningar, åtgärder, sektioner etc. Från gränssnittet i figur 1.2.7 kan vi till exempel ta bort objekt "Lager" från funktionerna i det aktuella avsnittet (toppmeny) och "Produkt". Det kommer att se ut så här:

Ris. 1.2.8. Användargränssnitt med avskalade funktioner i den aktuella sektionen

Vi kommer att diskutera mer detaljerat om anpassningen av användargränssnittet i nästa kapitel i denna del, och vi kommer att studera förhållandet mellan roller och gränssnittets utseende i nästa del av denna kurs. Låt oss samtidigt notera de viktigaste skillnaderna mellan det hanterade kommandogränssnittet och det vanliga.

• Typen av det hanterade kommandogränssnittet konfigureras automatiskt med hjälp av plattformsmekanismerna, beroende på inställningarna för användarrättigheter och funktionella alternativ.
• Användaren kan självständigt anpassa utseendet på gränssnittet efter behag.

Låt oss nu ta en titt på vad hanterade former är.

Lär dig programmering i 1C med hjälp av min bok "Program i 1C i 11 steg"

1. Inga komplicerade tekniska termer.
2. Över 700 sidor praktiskt material.
3. Varje uppgift åtföljs av en bild (skärmdump).
4. Insamling av uppgifter för läxor.
5. Boken är skrivet förståeligt och enkelt språk- för en nybörjare.
6. Boken skickas till e-post v PDF -format... Kan öppnas på vilken enhet som helst!

Om den här lektionen hjälpte dig att lösa något problem, du gillade det eller visade sig vara användbar, kan du stödja mitt projekt genom att överföra valfritt belopp:

du kan betala manuellt:

Yandex.Money - 410012882996301
Webpengar - R955262494655

Gå med i mina grupper.

Uppmärksamhet! Nu hålls kursen också på kvällen från 18:30 till 21:30 i ett nedsänkt format.

Kursen är en integrerad del av den omfattande kursen "Effektivt arbete i systemet" 1C: Enterprise 8 ".

Syftet med utbildningen: för att bekanta eleverna med det kontrollerade driftsläget för den tekniska plattformen 1C: Enterprise 8, för att visa specialister tillvägagångssätt för att bygga ett system för att använda denna version av systemet.

Kursen omfattar en ny modell för att bygga applikationsgränssnittet, en ny implementering av klient-serverarkitekturen, formmekanismen. Under kursen kommer studenterna att förvärva praktiska färdigheter i att konfigurera, administrera, programmera i det studerade mjukvarupaketet. Dessa färdigheter kommer att förvärvas när inlärningsproblemet är löst. Kärnan i denna uppgift: att konfigurera den tillhandahållna konfigurationen för att säkerställa möjligheten att arbeta i "tunn klient" -läge.

Kursen är avsedd: för specialister med erfarenhet av att konfigurera applikationslösningar på 1C: Enterprise -plattformen (version 7.7, 8.0, 8.1, 8.2 - en vanlig applikation).

Mekanismer som omfattas av kursen:

• Principer för att bygga ett hanterat gränssnitt
• Nya moduler, modulkörningskontext, interaktionsmekanism
• Gränssnittsegenskaper för konfigurationsobjekt
• Formanpassning (i konfiguratorläge, i körningsläge)
• Direktiv, klient / serverprogrammering, hur det hanterade formuläret fungerar
• Funktionella alternativ mekanism, form funktionella alternativ
• Listformulär, dynamiska listor
• Mekanismen för att forma tryckplåtar
• Ändringar i datasammansättningsmotorn (särdrag i att arbeta i en hanterad applikation)
• Privilegierade / säkra lägen
• Tillfällig förvaring, ny teknologi arbeta med filer, bilder
• Mekanism för interaktion av former, organisation av urval
• Arbetar med systeminställningar, åsidosätter mekanismen för lagring av inställningar
• Externa källor
• Datadelningsmekanism
• Automatiserad testning
• Mobil plattform

Kostnaden för en heltidskurs inkluderar:

• 2 dagar från 10:00 till 17:00
• metodiska material
• luncher, fika
• certifikat från företaget "1C"

Kostnaden för WEB-kursen inkluderar:

• 5 veckors kurs, 5 webinarier med en lärare
• certifikat från 1C-Training Center nr 3 (förutsatt övning)

Kostnaden för heltidskursen inkluderar:

• 5 dagar från 10:00 till 17:00 eller 9 kvällar från 18:30 till 21:30
• abstrakt, hörlurar
• luncher, fika
• tillgång i 2 år till uppdaterade videor efter kursens slut
• certifikat från 1C-Training Center nr 3

Inlärningsformat

Heltid dagtid

Vem är detta format för:För dig som kan gå deltidsträning och föredrar klassisk heltidsträning.

Varaktighet:16 akademiska timmar

WEB -utbildning

Vad är det här formatet:Det föreslagna formatet kombinerar många av fördelarna med distansutbildning med en komponent ansikte mot ansikte, presenterad av videomaterial och onlinekonsultationer.
WEB-kursen består av videor, praktiska uppgifter och webinarier med lärare. Allt kursmaterial är tillgängligt 24/7 via Internet - du kan studera vid en lämplig tidpunkt. Kursen är indelad i klasser. Under lektionen studeras material om det aktuella ämnet, workshops genomförs, frågor ställs till läraren. I slutet av varje lektion hålls ett webbseminarium där läraren analyserar alla mottagna frågor, typiska fel, förklarar rätt lösning. Inspelning av webinarier finns i portalen. På så sätt sker flera klasser efter varandra. I slutet genomförs ett sista oberoende arbete och ett sista webinar.

Varaktighet: 5 veckor

Vad är det här formatet:

Varaktighet:40 akademiska timmar

Vad är det här formatet:En heltidskurs är ett format som kombinerar alla fördelar med heltidsutbildning, distansteknik och individuell utbildning. Klasserna hålls i ett utrustat klassrum, du studerar självständigt kursmaterialet (steg-för-steg-videor) och utför workshops. Samtidigt finns det en lärare i klassrummet som är redo att när som helst svara på en fråga och hjälpa till med att lösa praktiska problem, samt kontrollera att deras genomförande är korrekt.
Fördelar - individuella samråd med läraren om dina frågor, takten för att skicka det material som passar dig personligen.
Allt detta ger en djupare studie av kursmaterialet.
Det är möjligt att ta denna kurs från din arbetsplats med full effekt av lärarens närvaro där eleven är! Om du är intresserad av denna möjlighet - ring oss!

Varaktighet:40 akademiska timmar

Kursprogram

KURSENS MÅL OCH MÅL

INTRODUKTION

1. DRIFTSALTERNATIV

2. TEKNISK STRUKTUR FÖR INTERAKTION

• Alternativ för klient-server:
• Filalternativ:
• Protokoll som används
• Serverklusterstruktur
• Sessioner
• Typer av moduler, gemensamma funktioner

3. KOMMANDO GRÄNSSNIT

• Delsystem
• Kommandon
• Förinställning
• Förbättra gränssnittet

4. GRÄNSSNITTEGENSKAPER

• Anpassad representation av objekt
• Standardkrav
• Kontroll av att fylla i föremål för objekt
• Ange standardvärdet
• Använda underordning

5. FUNKTIONELLA ALTERNATIV

6. KONTROLLERAD FORM

• Dialoginställning
• Definiera händelsehanterare
• Beräkning av dokumentets belopp
• Validering av fyllning, meddelanden
• Fyllhantering
• Med vippomkopplaren
• Privilegierad lägeshantering
• Säkert läge
• Ny metod för att genomföra genom register
• Händelse-driven hanterad form modell
• Form funktionella alternativ
• Visa registerrörelser

7. SKAPA EN UTSKRIFTSFORM

• Enkel dekryptering

8. LISTENS FORMER

• Formen för listan över dokumentet "Försäljning av varor"
• Formulär för val av referensbok "Nomenklatur"
• Använda "OnFetchingDataOnServer" -hanteraren
• Hämtar data som visas av en dynamisk lista

9. AVSNITT FRÅN MODAL SAMTAL.

10. TILLFÄLLIG FÖRVARING

• Arbeta med filer (bilder)
• Organisation av urval

11. HANTERADE RAPPORTER

• Återstående rapport
• Rapporteringsalternativ
• Anpassade inställningar
• Hämtar dekrypteringsvärdet

12. DATAHISTORIK

13. MEKANISM AV ENHETER

14. FÖRVARINGSINTERVALLETS GRÄNSER

15. DEFINERADE TYPER

16. ARBETSBORD

17. LAGRING AV INSTÄLLNINGAR

• Sparar rapportinställningar

18. ALLMÄNNA UPPGIFTER

• Definition allmänna detaljer nära föremål
• Datadelningsmekanism

19. KONFIGURATIONSFÖRLÄNGNINGAR

20. PLANERARE

21. EXTERNA DATAKÄLLOR

• Åtkomst till databasanslutning

22. AUTOMATISK TESTERING

23. MOBILPLATTFORM

• Introduktion (utdrag från "http://v8.1c.ru/overview/Term_000000818.htm")
• Databasutveckling
• Förinställning
• Bygga en mobilapplikation
• Testar applikationen

Tekniska krav:

• tillgång till Internet(du kan kontrollera din kommunikationskanal genom att ansluta till "test" -åtkomst),
• tillgänglighet för 1C: Enterprise 8.3 -plattform för att öva kursens praktiska uppgifter.

Du kan använda versionen "1C: Enterprise 8.3" för att lära ut programmering.