1c dokumentflöde, den godkännande personen anges inte. Automatisering av affärsprocesser. Övervaka affärsprocesser och optimera dem med 1C: Document Flow

I samband med lanseringen/uppdateringen av dessa produkter, samt utvecklingen av webbtjänstteknik, implementerade 1C-specialister sömlös integration, 1C ERP och 1C Document Management (nedan kallat "DO").

Den här artikeln kommer att beskriva inte bara schemat och konfigurationen av integration, även om detta kommer att täckas i sin helhet, utan också flera möjliga typer av integration kommer att övervägas.

För att implementera denna interaktion mellan de två programmen behöver vi:

• 1C "DO" 2.0 (CORP-versioner)

  Webbserver Apache.

Det finns inget behov av att beskriva installationen och konfigurationen av dessa mjukvaruprodukter; låt oss gå direkt till konfigurationen.

Så. Affärsprocessen är som följer: vi måste komma överens om försäljningsavtal. Samordningsschemat kommer att se ut som följer:

För att implementera ett sådant schema kommer vi att lägga till användare till 1C ERP och 1C DO.

- Säkerhet

- Advokat

- Ekonom

- Kontorist

Låt oss nu gå vidare till inställningen

Låt oss gå till 1C DO i "Konfigurator"-läget och publicera vår databas på webbservern.

Namn - resursadress, d.v.s. http://localhost/DocCorp/

Katalog - Platsen för webbtjänsten.

Vi kontrollerar arbetet.

Låt oss nu göra inställningarna i 1C DO.

1) Skapa en ny dokumenttyp: "Försäljningsavtal"

Gå till "NSI och administration" - "Typer av dokument"

Låt oss skapa en grupp av dokument "Avtal"

Skapa en ny vy

Låt oss gå till fliken "Dokumentmallar" - "Dokumentinformation".

Låt oss skapa en mapp för att lagra alla försäljningskontrakt på ett ställe.

Gå till "Bearbeta mallar" och skapa en ny mall.

Mallvalsformuläret "Godkännande" öppnas, skapa mappen "Icke-standardiserade processer" och skapa sedan processen "Godkännande av försäljningsavtal"

Låt oss spela in processen.

Låt oss gå vidare till ämnena i processen, eftersom Vi har villkorlig routing, som beror på kontraktsbeloppet, vi behöver ett analysobjekt, låt oss skapa det.

Låt oss gå tillbaka till fliken "Processinställningar" och lägga till godkännare.

Sedan ändrar vi färdriktningen och ställer in koordinationsordningen:

Låt oss nu ställa in fångstadressering, klicka på knappen "Användningsvillkor". *(Endast i CORP-version).

Låt oss skapa ett nytt routingvillkor: Kontraktsbelopp > 100 000 rub.

Låt oss tilldela det till "Dokumenttyp" - "Säljavtal".

Inställningen av 1C "TO" är klar. Låt oss gå vidare till att ställa in 1C: ERP.

Låt oss lägga till användare, samma som i 1C "DO"

I URL-fältet anger du tjänstens webbadress, kryssar i de nödvändiga rutorna och fortsätter med att ställa in integrationen.

Låt oss ange i inställningarna vilket dokument vi vill länka processen till.

Detta kommer att vara ett "avtal med en motpart", ett objekt från 1C "DO" - "Internt dokument"

Efter att ha valt relationer kommer grundläggande inställningar av relaterade objekt att utföras.

Ett antal fält måste konfigureras.

Typ av dokument i 1 "FÖRE" - "Försäljningsavtal"

När en dokumenttyp skrivs in letar 1C ERP efter den i 1C "DO".

"Mapp" - "Försäljningsavtal" (plats för lagring av dokument)

"Registreringsnummer"

Standardsystemet säger att detta är "Kod", detta är felaktigt, låt oss ändra värdet.

Detta är vårt kontraktsnummer.

Låt oss konfigurera de återstående fälten

Det är allt - Spara inställningen.

Låt oss skapa ett försäljningsavtal i 1C ERP, vi skapar det under användaren "Cerk"

Låt oss nu skapa 1C "DO"-processen baserat på detta avtal. Klicka på "Mer" i listformuläret

I 1C DO skapas ett internt dokument "Säljavtal".

Vars "namn" motsvarar data från 1C ERP. Systemet uppmanar oss omedelbart att välja en processmall. Välj "Avtal om försäljningsavtal" och klicka på "Skapa process". Vi kommer inte att installera kryssrutan "Starta omedelbart" för närvarande.

Beloppet för vårt kontrakt är > 100 000 rubel, därför fungerade vår routingregel, "Economist" lades till.

Låt oss börja processen.

Låt oss nu logga in på 1C ERP under olika användare och se resultatet. Första gången en användare loggar in på 1C ERP, om integration med 1C "DO" är konfigurerad, kommer användaren att uppmanas att ange en inloggning och lösenord för att ansluta till "DO".

Sedan går vi till The Economist

Han har inga uppgifter, eftersom... dess godkännande kommer efter "Advokaten", vi kommer att komma överens om avtalet av "Advokaten", och uppdatera uppgifterna för "Ekonomen"

Vårt avtal har flyttats till statusen "Giltigt".

En liten utvikning. Detta är ett exempel på integration från 1C ERP till 1C DO. Men enligt min mening finns det ett antal brister, inte i själva integrationen, utan i organisationen av affärsprocessen. Låt oss säga att vi har ett stort dokumentflöde av försäljningsavtal med motparter, alla avtal går igenom godkännandeförfarandet. Därför måste varje gång kontraktet ingås 1C: ERP. Men kontraktet kanske inte godkänns, då kommer "skräp" att finnas kvar i databasen, för att inte säga att detta i hög grad kommer att påverka driften av systemet, men ändå.

Men det finns en möjlighet att utöka relationen. "Clerk Clerk" skapar ett internt dokument "Sales Agreement" i 1C "DO", dokumentet går igenom godkännandestadierna, sedan, när det blir godkänt, anger "Clerk Clerk" den redan godkända informationen i 1C ERP och ställer in förhållandet mellan objektet i 1C ERP och 1C "DO" .

I 1C DO kommer vi att skapa ett internt dokument "Säljavtal"

Vi registrerar kontraktet och skickar det med den godkännandemall vi skapat.

En liten felaktighet i skärmdumpen angavs senare till 1 500 rubel.

Jag satte kontraktsbeloppet till 1 500 rubel, därför behöver Economist inte göra godkännanden.

Låt oss gå vidare till 1C ERP.

Som du kan se, även utan att skapa ett dokument i 1C ERP med sömlös integration, visas alla användarprocesser i 1C "BEFORE" i 1C ERP.

Efter att alla godkännandeprocedurer har slutförts och kontraktet har kommit överens om, behöver du bara skriva in det i 1C ERP-databasen och konfigurera anslutningen.

Vi ingår vårt avtal i 1C ERP och upprättar en förbindelse med det överenskomna objektet från 1C “DO”

Gå till "Dokumentflöde" i detta dokument och välj "internt dokument" 1C DO.

Sökningen sker enligt de valda kriterierna på 1C "DO"-sidan.

Nu har vi konfigurerat en anslutning mellan två objekt.

Samtidigt skapade vi inte onödiga dokument i 1C ERP hela godkännandeprocessen skedde på ERP-sidan (med hjälp av 1C DO-verktyg). Och en koppling togs emot mellan 2 objekt från olika baser.

Det var allt för detta. Vilka metoder du ska välja beror på dina behov, bestäm själv.

PS. När du integrerar med 1C ERP rekommenderar jag att du skapar planer för utbyte av företagsstruktur, entreprenörer, användare och DDS-artiklar. Detta kommer att minska störningar i 1C DO-systemet och ha uppdaterad information för avtalsredovisning.

3 Verksamhetsplanering och fakta. DS rörelse.

3.1 Budgetreservation

Som nämnts tidigare, DDS-gränser per budget (DDS Business Plans)kan ofta specificeras (till exempel kan beloppet för en post specificeras av motparter, av ytterligare analytiker, till exempel händelser, etc.).

Inställningen av DS-gränser i operationskonturen kommer att utföras av dokumentet "Budgetreservation".Det är bekvämt att ange sådana dokument på grundval av DDS affärsplaner. Samtidigt kommer inställningen och kontrollen av gränser att utföras inom ramen för ett fördefinierat scenario - "reserv".

Och vidare, under den operativa planeringen av DS-utgifter (vid tidpunkten för inlämnande av en ansökan om betalning), kommer programmet att kontrollera de aktuella driftsbalanserna enligt gränserna. Och om gränsen överskrids kommer programmet inte att tillåta en sådan ansökan, och en lämplig varning kommer att utfärdas.

För att möjliggöra förbud mot att posta dokument när gränsen överskrids, gå till avsnittet "Allmänna kataloger och inställningar/Ställa in parametrar/Skassa".

Vi kommer också att sätta flaggan "Förbjud direkt skapande av betalningsorder baserat på ansökningar, förbi betalningsregistret."Denna funktion kommer att behövas, eftersom vår uppgift nödvändigtvis kommer att involvera ett betalningsregister (registret kommer nödvändigtvis att bildas och godkännas av chefsrevisorn).

Så låt oss ange dokumenten Reservation av budgetar för perioden – september 2017.

Låt oss vara uppmärksamma på följande punkter:

• 
  Vi kommer inte att skapa en godkännanderutt för dokumentet "Budgetreservation". Ställ in skylten "Out of route" och statusen "Godkänd"

• 
  Vi kommer att ange organisationen som "MSK UK (Management functions)", medan CFO lämnar det värde som angavs i affärsplanen.

3.2 Vägar för godkännande av en ansökan om betalning till en leverantör

Som en del av den uppgift vi löser kommer vi att säkerställa godkännandet av ansökan om betalning till leverantören längs godkännandevägen.Således ansökan om betalning kommer automatiskt att skickas "genom kedjan av avtal", var och en måste godkänna (eller avslå i sitt eget skede) ansökan.

Varje avtalspart kommer "för sin del" att kontrollera behovet av godkännande av ansökan. Till exempel den person som är ansvarig för inköp -kommer att kontrollera riktigheten av villkoren i kontraktet, kommer kassören att se till att det inte finns något kassagap (och vid behov utföra balansering i betalningskalendern), ekonomisk. direktören kommer att göra slutligt godkännande av ansökan m.m.

Samtidigt kommer systemet automatiskt att avgöra behovet av att skicka ansökan till vissa avtalsparter (i vårt exempel kommer villkoren att konfigureras beroende på DDS-artikeln i applikationen). Också, att ställa in villkor kan göras mycket flexibelt och all annan data från applikationen kan kontrolleras.

Låt oss gå till avsnittet "Processer och godkännanden/Processmallar".

Låt oss skapa en ny mall - "Process för godkännande av betalningsförfrågningar". Vi kommer att ange "Godkännandeväg" som syftet med processen. Typobjekt för godkännande – ”Ansökan om drift”.

Låt oss skapa följande godkännanderutt:

Vägvalsvillkoren konfigureras i en speciell konstruktör.De där. Du kan alltid konfigurera - när vilka villkor (eller grupper av villkor) är uppfyllda, vilka åtgärder som ska utföras och vilka godkännandestadier programmet ska gå vidare till.

För att kontrollera hur ruttvillkoren kommer att fungera beroende på förfrågningsparametrarna, tillhandahålls "Display"-funktionen i ruttkontrollen.

Steget "Meddelande" kan fungera som ett separat steg (nätverksdiagram över processen).

Det vill säga när man går till detta stadium kommer systemet att kunna generera en separat varning för användaren.

Följaktligen kan "Meddelande"-steget inkluderas i processnätverkets diagram.

För att konfigurera varningsinnehållet måste du konfigurera varningsmallen:

Dessutom ger systemet automatisk generering av larm i samband med att olika händelser inträffar. Här är en lista över de angivna kategorierna av evenemang:

På detta sätt kan du till exempel konfigurera genereringen av varningar när, när du flyttar till vart och ett av godkännandestadierna, varningar om detta genereras automatiskt.

De där. godkännaren kommer alltid att få aviseringar, se vilka steg han för närvarande behöver komma överens om, och han kommer att kunna slutföra godkännandet direkt från loggen "Mina uppgifter och varningar".

För att möjliggöra generering av händelsevarningar,du bör gå till avsnittet "Processer och godkännanden/Larminställningar" och lägg till denna post:

Och slutligen Efter att godkännandeprocessmallen är helt konfigurerad måste du ange denna mall i rapporteringsreglerna. I vårt exempel, Det krävs i förordningen "Sätta och kontrollera DDS-gränser" att upprätta en matris av myndigheter för att godkänna kopior av rapporter - att i den ange en mall för godkännandeprocessen.

För dokumentet Request for Operation, ange processmallen "Process för godkännande av begäran om betalning".

3.3 Samordning av förfrågningar för rutten

Som en del av uppgiften vi löser kommer vi att generera en betalningsförfrågan och skicka den för godkännande.

Låt oss fylla i dokumentet Ansökan om drift med typen "BDDS (kostnadsavräkningar) med motparter."

För att kontrollera kontrollen av gränser kommer vi att ange i ansökan ett belopp som är större än vad som anges i gränserna.

När vi försöker lägga upp ett dokument får vi ett meddelande om att gränsen överskrids.

Låt oss rätta till den här situationen genom att skapa applikationen korrekt.Vi kommer att ange källan till gränserna (budgetreservationsdokument) och ange det tillgängliga beloppet.

Låt oss fylla i motpart och avtal;Låt oss gå till fliken "Limit Control".

Vi kommer att se vad den nuvarande gränsbalansen är (med hänsyn till den aktuella verksamheten) och vilken gräns som var planerad.

Låt oss granska dokumentet och se att dokumentet får statusen "Under godkännande"

Klicka på knappen "Godkännandeförlopp" för att öppna rutten och se på vilket stadium applikationen för närvarande befinner sig.

Det aktuella steget är markerat i blått.

Låt oss nu se hur programmet implementerar mekanismen för att generera varningar och vilka möjligheter det ger konsentanten.

Låt oss gå till avsnittet "Processer och godkännanden/Mina uppgifter och varningar".

Vi ser att varningar genereras i systemet.Varningar genereras både av händelsekategorier och genom övergång till enskilda processsteg.

Utan att lämna aviseringsloggen kan godkännaren godkänna scenen, överföra scenen till ställföreträdaren och tilldela ytterligare godkännare.

För ytterligare kontroll över applikationer ger programmet möjlighet att konfigurera förbud/tillåtelse av betalningar för speciellt specificerade analytiker.

I avsnittet "Planering och kontroll/Tillstånd och betalningsförbud" gör vi (till exempel) följande post.

När vi försöker lämna in en sådan ansökan för godkännande får vi följande meddelande

Detta innebär att även om applikationen klarar gränskontrollen så klarar den inte betalningskontrolldirektivet.

Låt oss inaktivera det tidigare angivna direktivet och skicka ansökan för godkännande.

Klicka på knappen "Godkänn dokument" för att fortsätta till godkännandet av det aktuella steget.

Låt oss ange visumet (förklaring) och klicka på "Godkänn."

Antag att kassören i nästa godkännandesteg såg att syftet med betalningen inte var ifyllt i ansökan och ansåg att det var nödvändigt att returnera ansökan till entreprenören (så att han skulle fylla i alla fält, som det ska vara). För dessa ändamål finns en "Avvisa"-knapp.

Programmet ger också följande användbara funktioner när det gäller att följa godkännandevägen:

• 
  Avslå ansökan för det tidigare godkännandesteget;
• 
  Skicka in ansökan för godkännande till ytterligare godkännare (dvs. om det behövs kan du lägga till godkännare till den aktuella rutten och omdirigera ansökan till dem).

3.4 Arbeta med betalningskalendern.

Så för tillfället är 2 förfrågningar om betalning på "samordning"-stadiet med kassören.

Kassörens huvuduppgift är att kontrollera möjligheten till betalning.Det vill säga för att t ex inte ett kassagap ska uppstå (du bör uppskatta vilket belopp som planeras i löpande konton vid betalningstillfället). Också i I dessa 2 ansökningar är de löpande kontona (från vilka betalning kommer att göras) inte definierade.

Totalt ska kassören balansera betalningspositionen (bestäm betalningskontot och övervaka betalningsdatum för kassaluckor).Och om det visar sig att betalningen för det planerade ögonblicket inte räcker, måste kassören antingen flytta datumet för den planerade betalningen eller ta hänsyn (dettare planera) betalningen c för antagning, eller skjuta upp ansökan på grund av omöjlighet att betala (flytta den till stopplistan). Alla dessa funktioner, såväl som separationsfunktionen en applikation i flera (för att dela upp ett belopp i flera) och funktionen att flytta kontanter mellan konton - allt detta kommer att beaktas när du arbetar med betalningskalendern senare.

Det är också viktigt att nämna ytterligare en funktionalitet för att arbeta med betalningskalendern, nämligen möjligheten att spara olika "alternativ för utveckling av evenemang."

Det vill säga, kassören kan till exempel modellera situation nr 1 av "tilläggsplanering" av det förväntade mottagandet av kontanterfrån klienten och analysera och spara detta "scenario" av händelser (denna version av betalningskalendern). Simulera sedan situation nr 2, när det förväntade mottagandet av d/s inte inträffade, men det är nödvändigt att stänga bristen på d/s c genom rörelse d/ c från ett annat löpande konto och delvis flytta betalningsdatumen. Totalt kommer det att vara möjligt att jämföra båda scenarierna och välja det mer fördelaktiga.

Funktionaliteten i betalningskalendern i UH ger rika möjligheter för kassören, låt oss titta på allt detta med exempel.

Innan du börjar arbeta med betalningskalendern måste du dock genomföra följande steg.

Konfigurera ett antal parametrar för betalningskalendern:

• 
  Horisonter för kalenderbildning (antal dagar);
• 
  Att ta hänsyn eller inte (1 eller 0, eller till exempel - 0,5 - då "vi tar hänsyn till hälften") ansökningshandlingar (inklusive de som inte är godkända, de som är under godkännande) när betalningskalendern bildas .
  • 
    De där. Om du ställer in "1" överallt för ogodkända ansökningar, kommer alla ej godkända (men håller på att godkännas) ansökningar att beaktas fullt ut av programmet när betalningskalendern genereras.

    Med andra ord innebär detta att programmet kommer att titta på de planerade betalningsdatumen och beloppen för dessa ansökningar, och följaktligen inkludera dessa uppgifter i kalendern och beräkna de planerade kassabalanserna på löpande konton, med hänsyn till de förväntade betalningarna för sådana ansökningar.

Registreranuvarande ingående saldon:

För att beräkna betalningskalendern i programmet måste du registrera de initiala d/c-saldona. Nödvändig så att initiala saldon registreras i ackumuleringsregistret ”Kassa”. Samtidigt, själva förflyttningen (ankomst/avgång) d/ c bör också återspeglas i detta register.

Registrering av initiala saldonutförs genom exekvering av dokumentet "Justering av ingående balanser". Vart i, Detta dokument kan naturligtvis fyllas i automatiskt, enligt bokföringsdata. bokföring ( m .e enligt löpande räkning 51).

Så, låt oss registrera initiala saldon för 2 juridiska personer. individer och deras bankkonton.

Faktiska intäkter/avyttringar av d/s kommer att återspeglas i programmet genom dokumenten "Reflektion av faktiska budgeteringsdata".Sådana dokument kommer att genereras i programmet automatiskt i det ögonblick som faktumet återspeglas. bokföringshandlingar rörlighet d/c (kvitton/avskrivningar d/ c per konto). Detta systembeteende bestäms av dessa inställningar:

Låt oss gå till avsnittet "Planering och kontroll/betalningskalender".

Låt oss ställa in följande nyckelparametrar:

• Vi kommer att upprätta grupperingar: efter organisation och bankkonto;
• Vi kommer att ställa in perioden: från aktuellt datum till slutet av innevarande månad;

Urval efter organisation: vi kommer att etablera genom att konsolidera gruppen MSC Energy +

Vi kommer att generera en betalningskalender (kalendern kommer att genereras från det aktuella datumet till slutet av månaden).

Vi kommer att se att kalendern inkluderar de initiala saldona för två löpande konton,planerade rörelser för d/c-kostnader (betalning av två ansökningar om betalning, förfaller i morgon).

Den röda färgen betyder att vi har ett kassagap på kontot "Bankkonto ej definierat." Detta berodde på att betalkontot inte var definierat i ansökningarna.

• Låt oss ändra antalet valda beställningar. Låt oss ställa in kontot – VTB 24.

• 
  Som ett resultat får vi att "Bankkonto är inte definierat" är uteslutet från kalendern, men från och med 05/09 finns det ett kassagap på 4000. Poängen är att de planerade kostnaderna (34 tusen rubel i totalt för 2 ansökningar) överstiger saldot d/c på kontot.

• Med hjälp av funktionen "skjut upp/skjut upp" kan du skjuta upp en ansökan ett tag (flytta den till stopplistan). Skicka sedan tillbaka den från uppskjuten.

• Den resulterande versionen av kalendern kan sparas. Och sedan öppna, jämför och välj gynnsammare scenarier för utvecklingen av situationen gällande trafikflödet.

• Du kan flytta betalningsdatum för ansökningar till ett angivet sista datum

Du kan också täppa till kassaluckor, till exempel genom koncerninterna kontantöverföringar(från en organisations konto till en annan organisations konto). För dessa ändamål tillhandahålls en ansökan om intern förflyttning.

Du kan snabbt planera både utgifter och förväntade intäkter. Det kan vara transaktioner som kvitton från kunder och förväntade kvitton från andra transaktioner.

3.5 Bildande av ett betalningsregister.

Efter att godkännande är klart för ansökningar kan de tas upp i betalningsregistret.

I vårt exempel skapar och underhåller redovisningschefen registret i statusen "Godkänd".

Betalningsorder genereras med knappen "Generera betalningsorder".

3.6 Reflektion av fakta, distribution av uttalanden till budgetanalytiker.

Efter nedladdning från klientbanken vid debitering från byteskontot kommer dokument att laddas in i programmet"Debiteringar från löpande konto."

Observera att vid debitering från det aktuella kontot kommer programmet automatiskt att generera dokument "Reflektion av faktiska data".

Syftet med dokumenten "Reflektion av faktauppgifter" är att återspegla kostnadsfaktumet i budget- och kassaflödesregistren. Faktisk förbrukning d/c beaktas även i betalningskalendern för att fastställa löpande saldon c.

Efter att ha laddat ett kontoutdrag kan programmet användas för att distribuera det bland planeringsanalytiker.

En sådan algoritm kan konfigureras i bearbetningen "Fördelning av kontoutdrag bland planeringsanalytiker".Fyllning kommer att utföras baserat på analysmallar. Programmet kan skapa många fyllningsmallar.

Här är ett exempel på en mall som anger analysvärdet "Projekt". Mallen (regeln) fungerar för alla organisationer och entreprenörer. Samtidigt kontrolleras innehållet i betalningssyftet.Det vill säga, om fältet "betalningssyfte" innehåller en kombination av orden "Huvudavtal", så installeras i detta fall analysen "Projektets huvud" i projektfältet.

På detta sätt kan du organisera andra algoritmer för att känna igen syftet med betalningen och följaktligen fylla i fälten tsfo , DDS-artikel, analytiker etc.

Delsystemet passar de som

• Jag är trött på att folk springer runt på kontor då och då bara för underskrifternas skull;
• det är nödvändigt att se: vem, när och hur godkände detta eller det objektet i 1C-databasen;
• det är nödvändigt att minska godkännandetiden (av ett avtal, en ansökan om att spendera pengar eller något annat).

Programmet låter dig koordinera alla dokument och referensböcker i 1C-databasen. Samordning sker sekventiellt, d.v.s. Först håller den första granskaren med, om han håller med, sedan nästa osv.

Följande statusar finns:

• "Ej godkänd"
• "I processen för godkännande",
• "Godkänd"
• "Inställt"
• "Återlämnas för revision."

När man skapar uppgifter för granskare anges inte en specifik användare utan endast Adresseringsrollen + Adresseringsavdelningen fylls i. Låt oss anta att vi måste komma överens

Därefter skapas uppgiften för Bokföraren från Bokföring. Och specifika användare måste anges i registret "Adresseringsregistret".

Således kommer uppgiften för godkännande att ses av två användare samtidigt och vilken som helst av dem kan slutföra uppgiften. Detta är särskilt användbart när en anställd går på semester och du behöver ange en användare som ersätter honom. I det här fallet räcker det att lägga till en ny post i adressregistret och alla gamla och alla nya uppgifter kommer omedelbart att vara synliga för den nya användaren.

Fördelar

• helt öppen källkod;
• oberoende konfiguration;
• oberoende av BSP (för icke-standardkonfigurationer är detta viktigt);
• kan byggas in i valfri konfiguration (se listan över testade konfigurationer nedan);
• fungerar i en tunn klient (det fungerar också i en vanlig applikation);
• För att sätta upp en ny koordination krävs ingen programmering, allt görs i runtime-läge;
• mycket enkel uppsättning av ett nytt avtal, du behöver bara gå igenom 4 steg och avtalet kan användas;
• du kan ställa in godkännanden för vilken katalog och vilket dokument som helst i 1c-databasen;
• skicka meddelanden via e-post;
• betydande minskning av godkännandetiden, och ofta minskas godkännandetiden avsevärt;
• det är alltid tydligt vem som ska godkänna, samt vem som godkänt det och när;
• möjligheten att förbjuda utförande av ett dokument tills det är överenskommet;
• möjligheten att förbjuda användningen av ett databasobjekt tills det är överenskommet;
• lätt att integrera i andra affärsprocesser i 1C;
• det behövs ingen separat databas där samordningen sker, allt sker i en databas.

Video

• Skapar ett nytt avtal

• granskning av det matchande delsystemet

• hur man integrerar ett delsystem i en standardkonfiguration

• Så här ställer du in ett konto för att skicka aviseringar:

Delsystemet är helt implementerat i hanterade former och körs i en tunn klient.

Exempel på användning av delsystemet

Exempel 1

Det är nödvändigt att en begäran om utgifter för medel godkänns innan den kan genomföras. I det här fallet krävs följande samordningsväg:

• alltid samordna med "Inköpschefen";
• om ansökningsbeloppet är mer än 10 000, kom överens med den kommersiella direktören;
• om ansökningsbeloppet är mer än 50 000, kom överens med ekonomidirektören;
• om ansökningsbeloppet är mer än 100 000, kom överens med generaldirektören.

Exempel 2

Alla användare kan skapa kontrakt i systemet, det är nödvändigt att ställa in kontraktsgodkännande på följande väg:

• om motparten/partnern tillhör gruppen av leverantörer är det nödvändigt att komma överens med "Leverantörsrevisorn";
• om motparten/partnern tillhör gruppen av köpare är det nödvändigt att komma överens med "Köparens revisor";
• kontrollera alltid med en advokat;
• om kontraktet är i konventionella enheter, kom överens med den kommersiella direktören;

Vanliga frågor (FAQ)

Fråga:Är det möjligt att bädda in ett delsystem i en icke-standardkonfiguration?

Svar: Ja, du kan, för detta är det nödvändigt att den slutliga konfigurationen innehåller följande:

• Directory.Users;
• Sessionsparameter "CurrentUser";
• Konfigurationen måste ha antingen egenskapen "Managed application" eller egenskapen "Managed and regular applications", eftersom alla former är kontrollerade.

Fråga:Är det möjligt att anropa formuläret "Godkännandestatus" direkt från ett katalogelement eller dokument?

Svar: Jo det kan du. Om du använder hanterade formulär måste du:

• gå till konfiguratorn;
• hitta det allmänna kommandot "bpsStatusConcordance";
• högerklicka och välj en egenskap;
• i egenskapen "Kommandoparametertyp", ange den sammansatta datatypen och välj önskat objekt.

Om du använder vanliga formulär och en standardkonfiguration måste du:

• ta från leveransen bearbetningen "bpsStatusCoordination.epf";
• Klicka på "Service - Ytterligare utskriftsformulär och bearbetning - Utskrift av blanketter"
• klicka på lägg till, ange sedan bearbetning;
• lägg till de objekt för vilka denna bearbetning ska anropas i tabellsektionen;
• Nu kommer utskriftsknappen att kunna anropa denna bearbetning.

Om du använder vanliga formulär och konfigurationen inte är standard, måste du manuellt infoga kod i varje form av ett katalog-/dokumentelement Form.epf” (från leveransen).

Fråga:Är det möjligt att ange status, låt oss säga "Betalt" för ett dokument?

Svar: Ja, du kan, för detta behöver du:

• gå till katalogen "Object statuses" och lägg till ett element med namnet "Paid", skriv ner det och stäng det;
• öppna sedan bearbetningen "Godkännandestatus", klicka på knappen "Ange status" och välj "Betalad"-status.

Roller

• (BPS) Användare- måste anges för alla användare;
• (BPS) Redigera adresseringsregistret- rätten är nödvändig för att redigera "Adresseringsregistret"-registret;
• (BPS) Dokumentredigering, objektstatusregistrering- rätten är nödvändig så att du manuellt kan ange status för ett 1c-objekt;
• (BPS) Fullständiga rättigheter- Tillgång till alla objekt i delsystemet samordning och är också nödvändig för att upprätta samordning.

Vad händer automatiskt

• aviseringar skickas med hjälp av ett schema (en gång per minut);

Vad planeras läggas till i framtiden om delsystemet lyckas

• förmågan att omdirigera godkännandeuppgiften till en annan granskare;
• möjligheten att anpassa en mall för att generera texten i en förklaring, vilket indikeras när du startar godkännande och skickar meddelanden via e-post (till exempel: inkludera dokumentets valuta, chef, belopp etc. i förklaringen);
• möjligheten att komma överens via ett svarsbrev, utan att logga in på 1C;
• så att adresseringsenheten automatiskt väljs från dokumentets/katalogens rubrik och inte är "stelt" angivet i godkännandeföremålet;
• förmågan att använda delsystemet "Koordinering" i konfigurationer där åtkomstbegränsning på postnivå är aktiverad;
• förbud att använda ett katalogelement tills det är överenskommet.

Utvecklingen utförs på Bitbucket (ett slutet arkiv för tillfället), huvudfunktionaliteten i delsystemet täcks av tester med xUnitFor1c().

Testar överföringen till standardkonfigurationer

Testning utfördes på plattformen: 8.3.8.1652

Konfiguration

Testresultat

En affärsprocess är en stabil sekvens av handlingar av anställda i en organisation. Att automatisera sådana sekvenser effektiviserar arbetet och påskyndar avsevärt slutförandet av den sista uppgiften.

Följande typer av affärsprocesser är implementerade i 1C: Document Flow 8-programmet:

• Hänsyn: handlingen överlämnas till chefen för övervägande och, med hans beslut, återlämnas till dokumentets författare.
• Avrättning: dokumentet överförs för exekvering till alla användare på listan och till kontrollanten för att upprätthålla exekveringsdisciplin. En av brukarna kan utses till ansvarig utförare.
• Samordning: Dokument som är kopplade till en sådan affärsprocess skickas in för godkännande till de angivna respondenterna och returneras sedan till författaren av affärsprocessen för att granska resultatet av godkännandet eller skicka för nytt godkännande.
• Påstående: dokumentet går till den ansvariga personen för godkännande och går tillbaka till författaren av dokumentet för att granska resultatet av godkännandet.
• Registrering: dokumentet går till sekreteraren för att tilldelas ett registreringsnummer, certifierat med organisationens sigill och skickat till korrespondenten.
• Introduktion: Med denna affärsprocess skickas det nödvändiga dokumentet till alla användare på listan för granskning.
• Beställa: Med hjälp av denna affärsprocess kan du ge instruktioner till anställda och kontrollera deras utförande.

Varje affärsprocess, allt eftersom den fortskrider genom stadier, skapar uppgifter riktade till specifika användare. Till exempel en affärsprocess Beställa kommer först att skapa en uppgift Slutför uppgiften för utföraren, och efter att utföraren registrerat slutförandet av denna uppgift, uppgiften Kontrollera framstegen för initiativtagaren till affärsprocessen.

Du kan tilldela uppgifter inte bara till specifika utförare, utan även till roller. Så till exempel kan ett dokument skickas för rollgodkännande Direktör, och programmet kommer automatiskt att överföra motsvarande uppgift till den som för närvarande utför denna roll - direktören själv eller hans ställföreträdare. Uppgiften kan också riktas till användare som identifieras av följande autosubstitutioner:

• Alla chefer för författaren till affärsprocessen,
• Alla underordnade till författaren till affärsprocessen,
• Den närmaste handledaren för författaren av dokumentet,
• Alla chefer för författaren av dokumentet.

Rollernas sammansättning är unik för varje företag eller institution och kan ändras och konfigureras utan att systemet stoppas. När rollexekutorn ändras överförs uppgifter automatiskt till den nya executorns skrivbord.

Användaren kan när som helst se listan över uppgifter som tilldelats honom i listan Mina uppgifter. Listan laddas automatiskt när programmet startar.

Dessutom kan användaren få ett meddelande om att slutföra en uppgift via e-post.

För varje affärsprocess skapar programmet ett kort från vilket användaren kan ta fram ett visuellt flödesschema över affärsprocessen. Utförandet av stadier i affärsprocesserna kommer att återspeglas i flödesschemat. Med dess hjälp kan skaparen av en affärsprocess när som helst ta reda på vilket stadium dess implementering är i och vilka anställda som redan har slutfört sin uppgift och vilka som inte har gjort det. Nedan finns ett kort och ett typiskt flödesschema för affärsprocesser Samordning.

En ny affärsprocess kopplad till ett specifikt dokument kan skapas baserat på detta dokument. För varje typ av affärsprocess tillhandahåller programmet en separat lista, till exempel en lista över godkännanden:

För varje typ av affärsprocess kan du konfigurera en mall som kommer att användas när du skapar nya affärsprocesser. En affärsprocessmall innehåller information som:

• routing,
• deadlines,
• betydelse,
• Namn,
• beskrivning och andra.

Till exempel affärsprocessmall Harmonisering av kontrakt kan se ut så här:

På dokumenttypkortet kan du ange en lista över affärsprocessmallar som är kopplade till det. Denna lista kommer att användas automatiskt när man skapar nya affärsprocesser baserade på dokument av denna typ. I det angivna exemplet är typen av inkommande dokument Avtal relaterad till mallen ovan Harmonisering av kontrakt och två andra mallar - Avtalsgodkännande (enkelt) Och Registrering av avtalet:

När du skapar en affärsprocess baserat på alla inkommande dokument av denna typ Avtal användaren kommer att kunna välja en lämplig mall från denna lista.

Vi inbjuder dig att överväga ett exempel. Företagets marknadsförare eller planeringsavdelningsspecialist sätter priser på varor. I detta företag godkänns prispolicyn av ledningen, och processen för prisantagande innefattar ett antal inbördes relaterade åtgärder. Hur etablerar man prissättningsprocessen i ett standardprogram?

Vi har redan pratat om affärsprocesser i en standardlösning 1C: Trade Management 8, som en funktion som hjälper till att kombinera ett antal operationer till en strikt definierad sekvens av åtgärder. Som ett resultat är företagets anställdas arbete baserat på en tydligt definierad algoritm.

Förkonfigurering av prisförhandlingsprocessen

• Fastställande av processen för att komma överens om priser i programmet 1C: Handelshantering 8 börjar med att aktivera motsvarande alternativ.
• Sedan måste du kontrollera "Åtkomstprofiler" för alla användare som är involverade i prissättning. I vårt exempel sätts priserna av en marknadsförare, varefter de godkänns av ledningen, så vi kontrollerar: i hans profil måste rollen "Sätta artikelpriser utan godkännande" vara inaktiverad.
• Slutligen måste du lägga till användare som godkänner de slutliga priserna. För att göra detta måste du gå till katalogen "Roller och utförare av affärsprocesser" och tilldela den ansvariga chefen rollen "Koordinera inställningen av artikelpriser".

Hur fungerar affärsprocessen för prisförhandling?

Principen för driften av prisförhandlingsmekanismen med hjälp av affärsprocesser är som följer. Vår marknadsförare, efter att ha studerat situationen på försäljningsmarknaden, kommer till slutsatsen att priserna kan höjas för vissa varor i produktsortimentet. I en standardlösning 1C: Handelshantering 8 Priserna fastställs med hjälp av dokumentet "Sätta artikelpriser". Men för att prisändringar ska träda i kraft måste detta dokument ha statusen "Godkänd". Vår marknadsförare har inte rätt att ändra dokumentets status, så för att ändra priser måste han använda affärsprocessen "Prisgodkännande".

Låt oss säga att chefen tror att priserna kan höjas ännu mer.

• I det här fallet bör han fylla i fältet "Resultat av att slutföra uppgiften", lämna sina förslag och klicka på knappen "Ej överens om".
• I det här fallet får marknadsföraren ett meddelande om det fattade beslutet, där han kan bekanta sig med chefens önskemål.
• Sedan klickar marknadsföraren på knappen "Bekanta" och slutför affärsprocessen. Nu måste marknadsföraren revidera priser i enlighet med chefens förslag och skapa en ny affärsprocess.
• Chefen sätter sig återigen in i de ändrade priserna och kommer överens om dem. I det här fallet får dokumentet "Ställa in artikelpriser" som skapats av marknadsföringsspecialisten statusen "Agreed" och läggs upp i programmet.

Chefen har allt under kontroll

På fliken "Godkännande" kan chefen spåra hela processen för att godkänna ett visst dokument om prisändringar.

Allt arbete på varje sådant dokument lagras i programmet på ett ställe, vilket gör det möjligt att utvärdera effektiviteten av marknadsförarens arbete.

Avslutningsvis vill jag notera att användningen av affärsprocessen "Prisavtal" gör att du kan effektivisera prissättningsprocessen, förbättra kvaliteten på personalhanteringen och kontrollen över dem.