Prosessautomatisering 1s. "1C-Bitrix24" - Bedriftsportal. Overganger mellom utgaver

Hovedemner i artikkelen- Dette:

• Veibeskrivelser for automatisering. Hva kan vi egentlig automatisere i arbeidet til 1C:Specialist? Hva bør automatiseres og hva bør ikke? Jeg vil snakke om eksempler på automatisering som allerede brukes av forskjellige mennesker.
• Jeg skal fortelle deg det om måter å skape universelle løsninger på- løsninger som vil fungere på forskjellige konfigurasjoner.
• Jeg skal fortelle deg det om verktøy, som hjelper oss med å automatisere arbeidet vårt, og hjelper oss å skrive kode som vil skrive kode for oss.
• Vel, jeg skal fortelle deg det om den generelle ordningen for tilpasning av løsninger til brukerkonfigurasjonen.

Veibeskrivelser for automatisering

Hvilke er de mest populære automasjonsveiledninger?

• Når vi snakker om automatisering, mener vi oftest automatisering av administrasjonsoppgaver(opprette sikkerhetskopier, oppdatere konfigurasjon). Denne retningen er enklest, fordi alle gjeldende standardløsninger er bygget på grunnlag av Library of Standard Subsystems (BSS), som allerede inneholder mekanismer som hjelper i automatisk modus oppdater konfigurasjonen og lag en kopi av den. Dessuten, hvis databasen din er liten og du har et aktivt abonnement på ITS, kan BSP selv legge en kopi av databasen din i 1C skylagring slik at du ikke mister data selv om noe skjer med datamaskinen din
• Den andre retningen for automatisering er teste løsninger. I 1C-verdenen er dette litt vanskeligere enn i klassisk utvikling, men i det siste har det blitt sagt mye om det faktum at konfigurasjonen bør testes med hver endring, og det er bedre å gjøre dette automatisk. Nå er det ganske mange verktøy på markedet for å lage autotester. De mest interessante av dem, etter min mening, er: "Scenariotesting" fra 1C-selskapet, og også åpen kildekode utvikling «Vanessa Behavior". De har litt forskjellig driftslogikk, men i prinsippet takler begge disse løsningene oppgaven med testautomatisering. Hvilken du skal velge er brukerens avgjørelse.
• Og det tredje området av automatisering er det jeg skal snakke om resten av presentasjonen er utviklingsautomatisering. For mange mennesker er den eneste måten å lage løsninger i 1C på å skrive kode i konfiguratoren. Men jeg vil fortelle deg det det er mange alternativer for å arbeide med kode programmatisk.

Eksempler på utviklingsautomatisering

Hva er hovedeksemplene på automatisering som allerede er implementert??

• Jeg tror et av de beste eksemplene Library of Standard Subsystems (BSS) og prosessen med implementeringen. For de som ikke har integrert med BSP, vil jeg snakke litt om prosessen med å integrere BSP med andre selvskrevne konfigurasjoner. Denne prosessen består av tre stadier.
  • I det første trinnet kombinerer vi BSP med konfigurasjonen vår. Samtidig inkluderer vår konfigurasjon moduler fra ulike delsystemer.
  • I de fleste tilfeller trenger vi bare noen delsystemer, så den andre fasen av implementeringen av en BSP er å kutte ut de objektene vi ikke trenger fra konfigurasjonen. Dette trinnet utføres automatisk. Du åpner en behandling som er en del av Standard Subsystems Library. Denne behandlingen laster ut konfigurasjonen til filer, endrer teksten til disse filene og laster dem tilbake.
  • Og det tredje trinnet av implementeringen, som ikke er nødvendig for alle undersystemer, men for noen - for eksempel hvis du implementerer mekanismen "Eksterne trykte skjemaer" i konfigurasjonen din, trenger du også, i tillegg til å kombinere den i konfigurasjonen, for å koble den til skjemaene. Dette er en enkel operasjon, du trenger bare å legge til en kodelinje i "OnCreate"-prosedyren i skjemaet, og også legge til noen små prosedyrer. For å automatisere denne operasjonen, er det også en egen behandling kalt "Arrangement av kodefragmenter". Du kjører ganske enkelt denne behandlingen, og den analyserer selv konfigurasjonen din og setter inn nødvendig tekst i skjemaene.
• Et annet eksempel på automatisering er utvikling av eksterne trykkskjemaer. Generelt, på enhver implementering flytting av innebygde trykte skjemaer til eksterne– Dette er en av de vanligste operasjonene. Denne prosessen kan også automatiseres - Infostart har til og med en liten prosessering, som kalles - "Konstruktør av eksterne trykte skjemaer". Den kjører i konfigurasjonen du overfører det trykte skjemaet fra:
  • Du velger hvilket trykt skjema du vil skrive ut,
  • Kopier teksten til ledermodulen fra dette skjemaet til denne behandlingen
  • Og selve behandlingen:
    • Den tar en mal fra seg selv og setter inn teksten som er nødvendig for å koble til mekanismen til biblioteket med standard delsystemer.
    • Legger inn data om utskriftsskjemaet (navnet) i denne teksten.
    • Angir hvilket dokument den skal koble til,
    • Og den trekker ut fra ledermodulen de prosedyrene som er nødvendige for driften av dette trykte skjemaet.

Du vil selvfølgelig ikke motta et fullt fungerende eksternt trykkskjema, men du vil motta en mal som er ganske enkel å tilpasse manuelt.

• Et annet eksempel er dette automatisk kodegenerering. Den kan for eksempel brukes til:
  • Tegning formelementer;
  • Kodeoppretting betinget registrering;
  • Og for automatisk opprettelse ACS-ordninger.

De som har jobbet i det administrerte grensesnittet i lang tid har kanskje lagt merke til at tilnærmingen til å lage betinget utseende har endret seg de siste årene. Hvis i UT11.0 den betingede designen ble skrevet i konstruktøren, er allerede i 11.2 all betinget design bygget programmatisk. Det er to årsaker til denne effekten.

• Den første er en funksjon på plattformen som forbyr samtidig tilstedeværelse av samme tilstand - fast og tilpasset.
• Men det er en annen grunn - dette er at på det nåværende utviklingsnivået av standardkonfigurasjoner er det veldig vanskelig å spesifisere alle forholdene på utviklingsstadiet. Fordi betinget styling avhenger av:
  • Avhengig av hvilke alternativer du har aktivert;
  • Fra brukerrettigheter;
  • Og fra innstillingene til informasjonsbasen.

Derfor anbefales det nå å angi betinget formatering i administrerte skjemaer programmatisk. Og hvis du legger merke til koden for å generere betinget formatering i UT11, er den den samme (samme variabelnavn, samme innrykk). Åpenbart ble denne koden generert automatisk basert på designerens data.

• Plattform 8.3.6 introduserte en så interessant funksjon som utvidelser. De lar deg endre funksjonaliteten til standardkonfigurasjoner uten å endre selve konfigurasjonene. Problemet er imidlertid at det er vanskelig å lage én universalløsning for ulike konfigurasjoner, fordi ulike objekter kan kobles til utvidelsen i ulike konfigurasjoner. I dette tilfellet er det mye mer praktisk å lage en slags generell utvidelsesmal, og legge til dokumenter/referansebøker til den programmatisk.
• Og det siste eksemplet er dette overføre endringene dine under oppdateringer. Dette kan selvfølgelig gjøres manuelt, men det er mer praktisk å utføre slike handlinger på tekstnivå, spesielt hvis du bruker Git-mekanismer (grener). I dette tilfellet slår Git sammen standardkonfigurasjonen mer korrekt med endringene dine. Hvis endringene er små, kan oppdateringen i de fleste tilfeller fullføres helt automatisk.

Måter å skape universelle løsninger

Hva er de generelle måtene å skape universelle løsninger på?

Jeg tror at hver konsulentprogrammerer som jobber med 1C har sin egen mappe med personlig behandling/rapporter som ble laget for å løse et spesifikt problem. Problemet er at i de fleste tilfeller er slike utviklinger skrevet for en veldig smal oppgave, og når en lignende oppgave dukker opp må de tilpasses. Det er mer praktisk å bruke litt tid og gjøre behandlingen i utgangspunktet mer universell.

• En måte å skape universelle løsninger på er metadataanalyse. Nesten all typisk behandling bruker denne metoden:
  • Behandling for universell dataopplasting,
  • Universell rapport,
  • Behandler for å installere detaljer.

Disse verktøyene fungerer på alle konfigurasjoner fordi de ganske enkelt analyserer metadataene til konfigurasjonen der de lanseres når de lanseres.

• I noen tilfeller fungerer ikke denne tilnærmingen fordi forskjellige konfigurasjoner krever forskjellige driftsregler. I dette tilfellet kan du bruke separate kodegrener for forskjellige konfigurasjoner:
  • Hvis konfigurasjonen er slik og slik, så kjører vi én tekst;
  • Hvis konfigurasjonen er annerledes, kjører vi annen tekst.

I de fleste tilfeller lar denne tilnærmingen deg utføre én behandling som fungerer på forskjellige brukerkonfigurasjoner.

• Men dette fungerer dessverre ikke alltid. For eksempel, for de samme utvidelsene, må du noen ganger ha forskjellige filer for forskjellige konfigurasjoner, og hver utvidelse må ha metadata for den bestemte konfigurasjonen. Dette kan også ganske enkelt automatiseres av lage en mal med påfølgende programvaretilpasning til brukerens konfigurasjon.

Verktøy for programvare fungerer med 1C-produkter. Fordeler og ulemper ved ulike tilnærminger

Hvilke verktøy finnes for programmatisk arbeid med 1C-produkter?

Spise tre hovedtilnærminger:

• Dette filparsing for små filer;
• Losser tilXML;
• OG objekttilnærming.

La oss se på hver av dem.

v8 Pakk ut

En av de mest populære måtene å jobbe med 1C-produkter på er metode basert på strukturen til 1C-filer. Faktisk spiller det ingen rolle om vi jobber med en konfigurasjon, en rapport eller en utvidelse. Teknisk sett er det bare en beholder som inneholder mange forskjellige små filer. Ethvert produkt vi kan:

• Ta den fra hverandre,
• Endre delene vi ønsker å endre,
• Og sett den sammen igjen.

For meg ser det ut til at dette er en av de mest populære måtene å jobbe med konfigurasjoner blant automatiseringsløsninger på.

Denne metoden implementeres av verktøyetv8 Pakk ut. Hva er henne proffer?

• Dette er for det første enkelhet. Dette verktøyet kjører i kommandomodus: vi forteller det hvilken fil vi analyserer, og som utdata produserer det en katalog med en haug med filer.
• Hun universell og altetende. Hun bryr seg ikke om hvilken plattform løsningen din er skrevet på (8.1, 8.2, 8.3). Teknisk sett har ikke filstrukturen til 1C-løsninger endret seg på mange år.
• Og en annen fordel med denne løsningen er dens selvforsyning. For å endre konfigurasjonen med v8Unpack trenger du ikke 1C-plattformen. Du trenger bare å starte verktøyet og vise det hvor filen er. Den samhandler ikke med verken konfiguratoren eller plattformen. Den analyserer hvilken som helst fil til filer og setter den sammen igjen.
• Og den siste fordelen er at den det eneste verktøyet som kan fungere med bytekode. Hvis behandlingen eller rapporten din inneholder moduler som leveres uten kildekode, vil v8Unpack fortsatt analysere dem til tekstfiler. Selvfølgelig får vi ikke russisk kode der, men vi får bytekode, som også kan analyseres og endres. Dessuten kan denne bytekoden konverteres til normal lesbar kode ved hjelp av verktøyene som er tilgjengelige på Infostart. Dette er selvsagt kun mulig dersom løsningen ikke er kjørt gjennom tilleggsprogramvare. Hvis den er kjørt ut er det vanligvis umulig å restaurere den fullstendig, men det er alltid mulig å delvis restaurere den.

v8Unpack-verktøyet har også ulemper.

• Dens største ulempe er det filer, som oppnås etter parsing, har ikke klare navn, og det er vanskelig å finne ut hva som må endres - du må se gjennom dem alle.
• Vel, det øyeblikket det er stille ikke en offisiell beslutning fra 1C-selskapet, men en ekstern utvikling, selv om den er gammel og fungerer stabilt.

XML-opplasting/nedlasting

Den andre måten å jobbe med 1C-utviklinger på er XML.

• Dette offisiell mekanisme, som anbefales av 1C og brukes i alle sine produkter, for eksempel i BSP og i DSS. 1C garanterer at dette verktøyet vil fungere riktig i begge retninger på plattformene det lanseres for.
• Fordelen med denne løsningen er at den laster ut konfigurasjonen til en oversiktlig struktur. Vi har:
  • Rotnivået er nivået for konfigurasjonen som helhet;
  • Egne mapper - for dokumenter, oppslagsverk, rapporter, behandling.
  • Hver mappe har en undermappe for hvert dokument, for hver oppslagsbok.

Å jobbe med denne strukturen er mye enklere enn med en struktur som er losset ved bruk av ikke-standardiserte midler.

• Nye løsninger også delvis nedlasting av data er tilgjengelig.
• Også for dette verktøyet er det en veldig mange typiske eksempler bruk i samme BSP. Basert på disse eksemplene er det veldig praktisk å forstå.

Vel, det er noen små ulemper er det:

• En konfigurasjon konfigurert på én plattform kan ikke lastes inn på en annen plattform - vi må jobbe på samme plattform på grunn av kompatibilitetsproblemer.
• I tillegg, Før versjon 8.3.7 kunne ikke dette verktøyet jobbe med eksterne rapporter og behandling. Nå er det ikke noe slikt problem, men hvis du bruker en eldre plattform, vil du ikke laste opp eksterne rapporter og bearbeiding til tekst.
• Den kan ikke fungere med bytekode - den laster ut beskyttede moduler i binær form.

Totalt sett er dette et av de mest praktiske verktøyene - enkelt og greit.

Formørkelse

Og den siste tilnærmingen jeg vil snakke om er objekttilnærming. Jeg håper dere alle vet at 1C skriver sin nye fasjonable konfigurator basert påFormørkelse. Men jeg vil påpeke at dette er litt mer enn en fancy konfigurator:

• Dette er API-tilgang som utviklere har bedt om i lang tid. Dette er det som ble implementert for mange år siden i form av Snowman, men litt mer funksjonelt, litt bedre. Hvis Snowpath bare gir oss tilgang til å lese konfigurasjonsdata, gir Graphite-prosjektet, som er implementert på Eclipce-plattformen, oss adgang allerede for å endre konfigurasjonen. For eksempel kan vi skrive vår egen lille plugin som vil endre konfigurasjonen som vi trenger uten å starte på nytt.

Algoritme for trinn-for-trinn automatisk opprettelse av 1C-utviklinger

Om hvordan du bruker alt dette for å automatisk tilpasse løsningene dine til konfigurasjoner. Dette lysbildet viser et veldig forenklet diagram som gjelder utvidelser, behandling og rapportering.

• Tanken er at hvis løsningen din skal ha forskjellige filer for forskjellige konfigurasjoner, så utvikler du en mal som inkluderer alle mekanismene som er nødvendige for drift dette løsninger i alle konfigurasjoner.
• Og i tillegg til malen er utviklet regler som tilpasser denne malen til brukerens spesifikke konfigurasjon(fortrinnsvis for enhver konfigurasjon). For eksempel, hvis du implementerer den samme mekanismen for eksterne trykte skjemaer basert på utvidelsen, så:
  • Den generelle malen vil ha følgende mekanismer:
    • Utskrifter;
    • Og nedlastinger av trykte skjemaer.
  • Og reglene vil inneholde informasjon om hvordan du kobler denne utvidelsen til kataloger og dokumenter.
• Takket være dette vil vi for hver konfigurasjon automatisk kunne generere en fil med utvidelsen vår, med tanke på funksjonene til denne konfigurasjonen.

Konklusjon

Avslutningsvis vil jeg gjenta hovedbudskapet i denne rapporten. Hovedideen er det alt vi kan gjøre manuelt, kan vi gjøre automatisk.

Selvfølgelig trenger du ikke å automatisere alt. Det er nødvendig å automatisere de oppgavene som du har gjentas(de oppgavene du gjør med hver oppdatering, med noen forbedringer).

Generelt kan alle oppgaver som kan beskrives på vanlig russisk beskrives i programmet. Samtidig, i motsetning til en person, gjør ikke programmet feil, går ikke glipp av noe, og gjør akkurat det du ba det om å gjøre.

Denne artikkelen er basert på en rapport presentert av forfatteren på Infostart-konferansen i 2016.

Automatisering av forretningsprosesser– aktiviteter rettet mot å effektivisere og regulere eksisterende forretningsprosesser i selskapet ved bruk av spesialiserte programvaremetoder. Denne definisjonen er basert på beskrivelsen av begrepet forretningsprosess:

"En forretningsprosess er et sett med arbeider bestilt i tid, designet for å oppnå ønsket resultat."

Det er mange programmer utviklet for å automatisere prosesser. Det foreslås å automatisere både individuelle forretningsprosesser, for eksempel CRM, og alle forretningsprosesser i selskapet på en helhetlig måte. Det er mulig å bruke både serviceprogrammer, uten kjøp og installasjon, og stasjonære programvareprodukter. Blant disse er relativt rimelige 1C-konfigurasjoner og de kraftigste og mest kostbare løsningene, som SAP.

Men før du bestemmer deg for hvilket system som passer deg best, bør du gjennomføre en analyse av prosessene som er foreslått for automatisering.
Til å begynne med bør du dele bedriftens prosesser inn i forretningsprosesser:

• Kontrollsystem;
• Administrert system.

For å forbedre effektivitet i det utøvende systemet , ikke bare automatisering av forretningsprosesser brukes, det er et tilstrekkelig antall rettet mot verktøy og teknologier å forbedre prosessene i det administrerte systemet. Som beviser deres effektivitet ved å bli adoptert verdensledende selskaper .

Men det er fokus på å forbedre forretningsprosesser kontrollsystem gir maksimalt bidrag til å øke virksomhetens effektivitet.

"Effektive forretningsprosesser er ditt kraftige konkurransefortrinn!"

Til forbedringsmetoder kontrollsystemprosesser kan tilskrives:

• Sosial og psykologisk støtte;
• Personalets motivasjon;
• Automatisering av forretningsprosesser.

Les mer om prosessautomatisering på 1C eller SAP

Jeg vil gjerne snakke separat om prosessautomatisering. Alle bøker om forretningsprosessledelse , som jeg noen gang har lest, rop med én stemme:

"Ved å introdusere standard forretnin1C eller SAP, frarøver du bedriften din individualitet," og til og med: "Typisk prosessautomatisering vil føre til uunngåelig kollaps."

Jeg ber om å avvike med disse konklusjonene!
Hvor kommer slike konklusjoner fra?
La oss finne ut hva som ligger bak ordene: "automatiseringssystem for forretningsprosesser" .
Og så, ethvert informasjonssystem, inkludert et automatiseringssystem for forretningsprosesser, representerer samlet:

• Database – informasjon lagres der i form av sammenkoblede tabeller, i visse seksjoner og med en viss detaljdybde;
• Brukergrensesnitt er den synlige delen av programmet, ved å manipulere som brukeren legger inn data eller genererer rapporter;
• Programvaremetoder for å jobbe med en database er en slags bro som forbinder grensesnittet og databasen.

Jeg tror at få mennesker har ideen om at databasen og programkoden for input og output av informasjon kan føre til kollaps av bedriften din, noe som betyr at det handler om brukergrensesnitt . La oss grave dypere.

Prosesser som skal automatiseres

Hva er hovedprosessene som må automatiseres først? Dette er selvfølgelig de mest rutinemessige forretningsprosessene:

• Prosessen med å registrere betalinger, både inngående og utgående;
• Prosessen med å utstede primær dokumentasjon;
• Kostnadsrefleksjonsprosess.

Brorparten av rapporteringen for beslutningstaking vil nemlig dannes fra informasjonen som registreres av disse forretningsprosessene. Og dette gir kjerneverdien av automatisering.

Hvor mye unikt har hvert selskap i beskrevne prosesser?

Hvis konkurransefortrinnet til virksomheten din ligger i det unike ved disse prosessene, vil du garantert dele denne informasjonen på en plass i "ledelse"-vitenskapen.

Selvfølgelig kan vi gi et eksempel på mer komplekse forretningsprosesser, automatiseringsprogrammer som også er vanlige på markedet, for eksempel CRM-automatisering.

Men igjen, jeg vil si til støtte for automatiseringssystemer for forretningsprosesser. Har markedsførerne eller selgerne dine funnet på noe mye bedre enn en salgstrakt eller XYZ-analyse?

Hvis ikke, er alle slike verktøy i en eller annen grad representert i programvaren som tilbys på markedet.

Ulemper med automatiseringssystemer

Imidlertid har automatiseringssystemer for forretningsprosesser også ulemper, og dette skyldes at de er utviklet som et universelt verktøy egnet for bruk i enhver virksomhet.

Disse inkluderer:

• Fraværet av noen virkelig viktige detaljer for deg. Ja, jeg innrømmer at slike detaljer er mulige.
• Grensesnittet er ikke brukervennlig nok.
• Nyanser av bruk på forskjellige enheter.
• Ytelse.

Men de fleste av disse problemene kan løses ved å velge en løsning nøye, og selvfølgelig har ethvert system muligheten tilpasning for kunden er det bare et spørsmål om pris.

Produktene som tilbys er beste praksis for automatisering av forretningsprosesser innesluttet i programvarekode – bruk den.

I tillegg, ved å bruke standard automatiseringssystemer for forretningsprosesser, vil du kunne vurdere den effektive eller ineffektive effekten av automatisering på virksomheten din. Og du vil gjøre det til relativt lave kostnader.

La oss nå diskutere de virkelige årsakene til "forretningskollapsen"

Alle disse grunnene ligger i ønsket om å gjøre intensive endringer i virksomheten, for å øke effektiviteten, men med andres hender, uten din egen intervensjon og, selvfølgelig, uten personlig ansvar.

Eller kanskje rett og slett ikke ønsket om endring, men automatiseringsprosjektet brukes som en unnskyldning: "Vi prøvde, men det gikk ikke."

Noen årsaker til prosjektautomatiseringsfeil:

1. Negativ holdning til meningene til 1C- eller SAP-implementere: "Hvem er de som skal råde oss til å endre forretningsprosessene våre..." Og dette spiller til og med i hendene på implementere, som gjør det som allerede er gjort, og til og med knytter kunden til seg selv for alltid, fordi bortsett fra en spesifikk utvikler, vil ingen kunne forstå den ikke-standardiserte koden.
2. Ikke ønsker å fordype seg i prosedyrene som tilbys av programvareproduktet. I prinsippet er det logikk her. Vi kan si at det ikke er toppledelsens jobb å forstå programvareproduktet. Men feilen er at det som regel ikke er noen prosjektleder for implementering av (formelt oppnevnt, dette er det samme). Og lokale ledere reagerer som regel på automatisering slik: «Ok, så får det være, gjør det som det er og ikke plage meg.» Dette er veien til ingensteds!
3. Tilstedeværelse av "hellige kyr" slike ansatte som er i stand til å motstå alle innovasjoner, også de som er hentet ned fra toppen. Til syvende og sist tar toppledelsen parti for «kyrne» og kansellerer automatiseringsprosjektet for forretningsprosesser.
4. Ikke noe ønske om å bare sette ting i orden og angi hvem som er ansvarlig for hva, og bryte alle unnskyldninger som: "Vi har ikke tid til å skrive."

Gjenoppta

Generelt sett er selvfølgelig automatisering av forretningsprosesser en kompleks og ansvarlig prosess, der de beste kreftene til både kundebedriften og implementeringsbedriften må involveres. Og valget av et automatiseringssystem for forretningsprosesser må tilnærmes nøye og nøye.

Men for små og mellomstore bedrifter bør prosessautomatisering være basert på standardløsninger, mens store bedrifter kan tillate seg egne skreddersydde utviklinger for å få maksimalt utbytte av implementeringen.

La oss vurdere hovedegenskapene og prosessen for å opprette og sette opp mekanismen for forretningsprosesser og oppgaver i 1C Enterprise 8.3-systemet ved å bruke eksempelet på å løse et problem fra sertifiseringen "1C Platform Specialist". Denne mekanismen brukes veldig ofte til, derfor er den viktig for enhver programmerer.

Objektene Business Processes og Tasks er svært nært knyttet til hverandre. Å fullføre en oppgave representerer bevegelse langs ruten til en forretningsprosess. La oss vurdere prosessen med å implementere forretningsprosesser i 1C mer detaljert.

Oppgavebetingelser Plattform Forretningsprosessspesialist

Stilling i ansattavdelingen
Vasina	Regnskap	Kasserer
Mishina	Regnskap	Kasserer
Mishina	Regnskap	Regnskapsfører
Krotov	Regnskap	Regnskapsfører
Ivanov	Regnskap	Ch. regnskapsfører
Onopko	Innkjøpsavdeling	Avdelingsleder
Petrenko	Innkjøpsavdeling	Stedfortreder avdelingsleder
Beldyev	Innkjøpsavdeling	Leder
Rakhimov	Innkjøpsavdeling	Leder
Mansurov	Innkjøpsavdeling	Leder
Zhupikov	Innkjøpsavdeling	Lagremann
Sidorov	Innkjøpsavdeling	Lagremann
Galkin	Salgsavdeling	Leder
Palkin	Salgsavdeling	Leder

Det første trinnet for å konfigurere forretningsprosessmotoren i vårt eksempel er å lage nye "Business Process"- og "Task"-objekter:

Oppgaven, kan man si, er "underordnet" forretningsprosessen.

Adressering av forretningsprosess 1C 8.3

I oppgaver på fanen Adressering må du angi hovedparametrene i forretningsprosessmekanismen: Adressering, Grunnleggende adresseringsdetaljer, Gjeldende utfører. Og fyll også ut adresseopplysningene.

I feltet Adressering informasjonsregisteret som adresseringen skal konfigureres med er spesifisert. I vårt eksempel er dette et register over informasjon med dimensjoner: Utøver, Divisjon, Posisjon.

Få 267 videotimer på 1C gratis:

I feltet Grunnleggende adressedetaljer det er nødvendig å indikere hovedattributtet for adressering - hovedkuttet for å fullføre oppgaven.

Nåværende artist - et felt som spesifiserer sesjonsparameteren som den gjeldende eksekveren skal bestemmes med. Du kan lese mer om dette i artikkelen om øktparametere.

For testeksemplet er det nødvendig å opprette flere forhåndsdefinerte katalogelementer: avdelinger, stillinger, enkeltpersoner.

Rutekart for forretningsprosesser

Det neste trinnet for å sette opp en forretningsprosess er å lage et forretningsprosesskart:

La oss vurdere dannelsen av en forretningsprosess basert på produktanskaffelsesprosessen:

1. innkjøpsavdelingen starter forretningsprosessen;
2. etter det går oppgaven til "Regnskap"-avdelingen, hvor, avhengig av hvordan betaling for varene vil skje, går oppgaven til enten kasserer eller regnskapsfører;
3. Etter betaling må varene mottas av en bestemt bruker - Sidorov.

"Rollene" til brukere som må utføre oppgaver er spesifisert i egenskapspaletten til hvert handlingspunkt:

Flagg Gruppe betyr at oppgaven må fullføres av alle brukere i denne gruppen.

For blokken der forgreningen skjer, må du angi en spesiell behandler i tilstandssjekk-egenskapene:

Prosedyre ConditionCheckConditions(BusinessProcessRoutePoint, Result) Resultat = Betaling i kontanter;

Slutt på prosedyre

For enkelhets skyld, la oss anta at betalingsmåten er spesifisert i oppgaven: hvis "kontantbetaling"-flagget er satt i oppgaven, vil betalingen gå gjennom kassereren.

Opprette forretningsprosessskjemaer

Det neste trinnet er å lage skjemaer for den fremtidige forretningsprosessen. For klarhet, i henhold til vilkårene for oppgaven, er det nødvendig å vise et forretningsprosesskart på et skjema. Kartet over hver forretningsprosess skal vise gjeldende stadium.

For å gjøre dette, lag et standard katalogskjema. Legg deretter til et attributt med typen "Graphic Scheme" i skjemadetaljene. Overfør denne informasjonen til skjemaet:

Og den siste tingen for skjemaet er prosedyren for å vise en forretningsprosess:

Prosedyre Oppdater kart() BP = Form AttributesValue("Objekt" ) ;

Dette skjemaet. Kort = BP. GetRouteMap() ;

Slutt på prosedyre

Det må utføres når du åpner et forretningsprosesselement og tilordnes kommandoen "Oppdater kart". Oppgavelisteskjema for forretningsprosesser Oppgavelisteskjemaet etter oppgavetilstand skal kun vise åpne oppgaver til gjeldende utfører. Det er veldig enkelt å gjøre.

Det er nok å lage et standard oppgavelisteskjema. Deretter velger du Hovedtabell - Task.Task.

Oppgaver etter utøver.

Denne innstillingen lar deg spesifisere valg etter oppgaveutfører:

I dette registeret er det nødvendig å indikere alle deltakere i forretningsprosessen og registrere medlemmer av en bestemt enhet, stilling osv.:

Det er det! Forretningsprosessoppsettet er klart!

En forretningsprosess er en stabil sekvens av handlinger utført av ansatte i en organisasjon. Automatisering av slike sekvenser effektiviserer arbeidet og fremskynder fullføringen av den endelige oppgaven betydelig.

Følgende typer forretningsprosesser er implementert i 1C: Document Flow 8-programmet:

• Betraktning: dokumentet sendes til sjefen for behandling og, med hans resolusjon, returneres til forfatteren av dokumentet. I dette tilfellet, direkte under gjennomgangsprosessen, kan tjenestemannen lage en tekstvedtak eller sende et dokument for utførelse eller vurdering.
• Henrettelse: dokumentet sendes for utførelse til alle brukere på listen, kontrolløren og inspektøren for å sikre overholdelse av ytelsesdisiplin. En av brukerne kan oppnevnes som ansvarlig utførende.
• Koordinasjon: dokumenter knyttet til en slik forretningsprosess sendes for godkjenning til de spesifiserte respondentene og returneres til forfatteren av denne forretningsprosessen for å gjennomgå resultatene eller sende for ny godkjenning. Følgende samsvarsalternativer støttes:
  • parallell;
  • sekvensiell;
  • blandet (parallell og sekvensiell), inkludert å ta hensyn til rutingforhold.
• Uttalelse: dokumentet går til den ansvarlige personen for godkjenning og går tilbake til forfatteren av prosessen for å gjøre seg kjent med resultatet av godkjenningen.
• Registrering: dokumentet går til sekretæren for å tildele et registreringsnummer, feste organisasjonens segl og sende det til korrespondenten.
• Introduksjon: Ved å bruke denne forretningsprosessen sendes det nødvendige dokumentet til alle brukere på listen for gjennomgang.
• Bestille: Ved å bruke denne forretningsprosessen kan du gi instruksjoner til ansatte og kontrollere utførelsen av dem.
• Invitasjon: Denne prosessen lar deg sende invitasjoner til møtedeltakere og motta svarene deres.
• Behandle et innkommende dokument: automatiserer hele syklusen med å behandle et innkommende dokument - gjennomgang, utførelse, avskrivning.
• Behandling av et utgående dokument: automatiserer hele syklusen med å behandle et utgående dokument - godkjenning, godkjenning, registrering.
• Behandler internt dokument: automatiserer hele syklusen med å behandle et utgående dokument - godkjenning, godkjenning, registrering, gjennomgang, utførelse, avskrivning.
• Omfattende prosess: lar deg konfigurere en tilpasset dokumentbehandlingsrute, bestående av individuelle stadier.

Hver forretningsprosess, ettersom den skrider frem gjennom stadier, skaper oppgaver rettet til spesifikke brukere. For eksempel en forretningsprosess Bestille vil først opprette en oppgave Fullfør oppgaven for utførende, og etter at utførende registrerer fullføringen av denne oppgaven, oppgaven Sjekk fremdriften for initiativtaker til forretningsprosessen.

Du kan tildele oppgaver ikke bare til bestemte utøvere, men også til roller. Så for eksempel kan et dokument sendes til rollegodkjenning Direktør, og programmet vil automatisk overføre den tilsvarende oppgaven til den som for øyeblikket utfører denne rollen - direktøren selv eller hans stedfortreder. Oppgaven kan også adresseres til brukere identifisert av følgende autosubstitusjoner:

• Alle ledere av forfatteren av forretningsprosessen
• Alle underordnede til forfatteren av forretningsprosessen
• Umiddelbar veileder for dokumentforfatteren
• Alle ledere av dokumentforfatteren

Rollesammensetningen er unik for hver virksomhet eller institusjon og kan endres og konfigureres uten å stoppe systemet. Når rolleutøveren endres, overføres oppgaver automatisk til den nye utførerens skrivebord.

Brukeren kan når som helst se listen over oppgaver som er tildelt ham i listen Mine oppgaver. Listen lastes automatisk når programmet starter.

I tillegg kan brukeren motta et varsel om å fullføre en oppgave via e-post.

For hver forretningsprosess lager programmet et kort der brukeren kan hente frem et visuelt flytskjema over forretningsprosessen. Gjennomføringen av forretningsprosessstadier vil gjenspeiles i flytskjemaet. Med dens hjelp kan skaperen av en forretningsprosess når som helst finne ut hvilket stadium implementeringen er på og hvilke ansatte som allerede har fullført oppgaven og hvem som ikke har gjort det. Nedenfor er et kort og et typisk flytskjema for forretningsprosesser Koordinasjon.

En ny forretningsprosess knyttet til et spesifikt dokument kan opprettes basert på dette dokumentet. For hver type forretningsprosess gir programmet en egen liste, for eksempel en liste over godkjenninger:

For hver type forretningsprosess kan du konfigurere en mal som skal brukes når du oppretter nye forretningsprosesser. En forretningsprosessmal inneholder informasjon som:

• ruting
• frister
• betydning
• Navn
• beskrivelse og andre

For eksempel mal for forretningsprosess Avtalegodkjenning kan se slik ut:

På dokumenttypekortet kan du spesifisere en liste over forretningsprosessmaler knyttet til det. Denne listen vil automatisk bli brukt når du oppretter nye forretningsprosesser basert på dokumenter av denne typen. I eksemplet som er gitt, er typen innkommende dokument Avtale relatert til malen ovenfor Avtalegodkjenning og to andre maler - Avtalegodkjenning (enkel) Og Registrering av avtalen.