1c dokumentumfolyamat, a jóváhagyó személy nincs megadva. Üzleti folyamatok automatizálása. Az üzleti folyamatok figyelése és optimalizálása az 1C: Document Flow segítségével

Ezen termékek kiadásával/frissítésével, valamint a webszolgáltatási technológia fejlesztésével kapcsolatban az 1C szakemberei zökkenőmentes integrációt, 1C ERP és 1C Document Management (a továbbiakban: „DO”) valósítottak meg.

Ez a cikk nemcsak az integráció sémáját és konfigurációját írja le, bár ez teljes terjedelmében foglalkozik, hanem az integráció több lehetséges típusát is figyelembe veszik.

A két program közötti interakció megvalósításához szükségünk van:

• 1C "DO" 2.0 (CORP-verziók)

  Webszerver Apache.

Nem szükséges leírni ezeknek a szoftvertermékeknek a telepítését és konfigurálását, menjünk közvetlenül a konfigurációra.

Így. Az üzleti folyamat a következő: meg kell állapodnunk az értékesítési szerződésekről. A koordinációs séma a következő lesz:

Egy ilyen séma megvalósításához felhasználókat adunk hozzá az 1C ERP-hez és az 1C DO-hoz.

- Biztonság

- Jogász

- Közgazdász

- Jegyző

Most menjünk tovább a beállításhoz

Lépjünk az 1C DO-hoz „Configurator” módban, és tegyük közzé adatbázisunkat a webszerveren.

Név - erőforrás címe, pl. http://localhost/DocCorp/

Címtár – A webszolgáltatás helye.

Ellenőrizzük a munkát.

Most végezzük el a beállításokat az 1C DO-ban.

1) Hozzon létre egy új dokumentumtípust: „Eladási szerződés”

Lépjen az „NSI és adminisztráció” - „Dokumentumok típusai” menüpontra.

Hozzunk létre egy dokumentumcsoportot „Megállapodások”

Új nézet létrehozása

Lépjünk a "Dokumentum sablonok" - "Dokumentum részletei" fülre.

Hozzon létre egy mappát az összes adásvételi szerződés egy helyen történő tárolására.

Lépjen a „Feldolgozási sablonok” elemre, és hozzon létre egy új sablont.

Megnyílik a „Jóváhagyás” sablon kiválasztási űrlap, létrehozza a „Nem szabványos folyamatok” mappát, majd az „Értékesítési szerződés jóváhagyása” folyamatot.

Rögzítsük a folyamatot.

Térjünk át a folyamat tárgyaira, mert Van feltételes routingunk, ami a szerződés összegétől függ, kell egy elemzési objektum, hozzuk létre.

Térjünk vissza a „Folyamatbeállítások” lapra, és adjunk hozzá jóváhagyókat.

Ezután megváltoztatjuk az útvonal irányát és beállítjuk a koordinációs sorrendet:

Most állítsuk be a fogási címzést, kattintson a „Használati feltételek” gombra *(Csak CORP verzióban).

Hozzon létre egy új útválasztási feltételt: Szerződés összege > 100 000 rubel.

Rendeljük hozzá a „Dokumentum típushoz” - „Eladási szerződés”.

Az 1C "TO" beállítása befejeződött. Térjünk át az 1C: ERP beállítására.

Adjunk hozzá felhasználókat, ugyanúgy, mint az 1C "DO"-ban

Az URL mezőbe írja be a szolgáltatás webcímét, jelölje be a szükséges négyzeteket, és folytassa az integráció beállításával.

Jelöljük a beállításoknál, hogy melyik dokumentumhoz szeretnénk kapcsolni a folyamatot.

Ez egy „szerződés a szerződő féllel”, az 1C „DO” tárgya - „Belső dokumentum”

A kapcsolatok kiválasztása után megtörténik a kapcsolódó objektumok alapbeállítása.

Számos mezőt be kell állítani.

A dokumentum típusa az 1-ben „ELŐTT” - „Adásvételi szerződés”

Amikor beír egy dokumentumtípust, az 1C ERP az 1C „DO”-ban keresi.

„Mappa” - „Eladási szerződések” (a dokumentumok tárolási helye)

"Regisztrációs szám"

Az alapértelmezett rendszer azt mondja, hogy ez a „Kód”, ez hibás, változtassuk meg az értéket.

Ez a szerződésünk száma.

Állítsuk be a fennmaradó mezőket

Ez minden – Mentse el a beállítást.

Hozzon létre egy értékesítési szerződést az 1C ERP-ben, azt a „Clerk” felhasználó alatt hozzuk létre.

Most hozzuk létre az 1C „DO” folyamatot ezen a megállapodáson alapulva. Kattintson a „Tovább” gombra a lista űrlapon

Az 1C DO-ban létrejön egy „Eladási szerződés” belső dokumentum

A „név” megfelel az 1C ERP adatainak. A rendszer azonnal felszólít bennünket, hogy válasszuk ki a folyamatsablont. Válassza az „Értékesítési szerződés” lehetőséget, majd kattintson a „Folyamat létrehozása” gombra. Az „Azonnali indítás” jelölőnégyzetet egyelőre nem telepítjük.

A szerződésünk összege > 100 000 rubel, ezért az útválasztási szabályunk működött, az „Economist” hozzáadásra került.

Kezdjük a folyamatot.

Most jelentkezzünk be az 1C ERP-be különböző felhasználók alatt, és nézzük meg az eredményt. Amikor a felhasználó először jelentkezik be az 1C ERP-be, ha az 1C „DO”-val való integráció konfigurálva van, a felhasználónak meg kell adnia egy bejelentkezési nevet és jelszót a „DO”-hoz való csatlakozáshoz.

Aztán megyünk a The Economisthoz

Nincs feladata, mert... jóváhagyása a „Jogász” után jön, egyeztetünk az „Jogász” megállapodásáról, aktualizáljuk a „Közgazdász” feladatait.

Megállapodásunk „Érvényes” állapotba került.

Egy kis kitérő. Ez egy példa az 1C ERP és az 1C DO integrációjára. De véleményem szerint számos hiányosság van nem magában az integrációban, hanem az üzleti folyamat megszervezésében. Tegyük fel, hogy nagy mennyiségű adásvételi szerződésünk van a partnerekkel, minden megállapodás átesik a jóváhagyási eljáráson. Ezért minden alkalommal, amikor a szerződést meg kell kötni az 1C: ERP-vel. De lehet, hogy nem hagyják jóvá a szerződést, akkor a „szemét” marad az adatbázisban, nem mondanám, hogy ez nagyban befolyásolja a rendszer működését, de akkor is.

De van lehetőség a kapcsolat bővítésére. A „Clerk Clerk” létrehoz egy „Eladási szerződés” belső dokumentumot az 1C „DO”-ban, a dokumentum átmegy a jóváhagyási szakaszokon, majd amikor jóváhagyásra kerül, a „Clerk Clerk” beviszi a már jóváhagyott adatokat az 1C ERP-be, és beállítja. az 1C ERP-ben lévő objektum és az 1C „DO” közötti kapcsolat.

Az 1C DO-ban létrehozunk egy belső dokumentumot „Eladási szerződés”

Regisztráljuk a szerződést és elküldjük az általunk készített jóváhagyási sablon segítségével.

Egy kis pontatlanság a képernyőképen a szerződés összegét később 1500 rubelben tüntették fel.

A szerződés összegét 1500 rubelben határoztam meg, ezért az Economistnak nincs szüksége jóváhagyásra.

Térjünk át az 1C ERP-re.

Amint láthatja, még az 1C ERP-ben, zökkenőmentes integrációval rendelkező dokumentum létrehozása nélkül is, az 1C „BEFORE” összes felhasználói folyamata megjelenik az 1C ERP-ben.

Az összes jóváhagyási eljárás befejezése és a szerződés megkötése után csak be kell írnia azt az 1C ERP adatbázisba, és be kell állítania a kapcsolatot.

Megállapodásunkat az 1C ERP-be kötjük, és kapcsolatot létesítünk az 1C „DO” megállapodás szerinti objektummal

Lépjen a dokumentum „Dokumentumfolyamat” részéhez, és válassza a „belső dokumentum” 1C DO lehetőséget.

A keresés a kiválasztott kritériumok szerint történik az 1C "DO" oldalon.

Most konfiguráltunk egy kapcsolatot két objektum között.

Ugyanakkor nem hoztunk létre felesleges dokumentumokat az 1C ERP-ben, a teljes jóváhagyási folyamat az ERP oldalon zajlott (1C DO eszközökkel). És kapcsolat érkezett 2 objektum között különböző bázisokról.

Ennyi az egész. Hogy melyik módszert választja, az az Ön igényeitől függ, döntse el Ön.

PS. Az 1C ERP-vel való integráció során azt javaslom, hogy készítsen terveket a vállalati struktúra, a partnerek, a felhasználók és a DDS cikkek cseréjére. Ez csökkenti az interferenciát az 1C DO rendszerben, és naprakész információkkal rendelkezik a szerződéses elszámoláshoz.

3 Működési tervezés és tény. DS mozgalom.

3.1 A költségvetések lefoglalása

Amint korábban említettük, a DDS költségkeret szerint korlátozza (DDS üzleti tervek)gyakran megadható (például egy tétel összegét részletezhetik a szerződő felek, további elemzők, például események stb.).

A DS határértékek beállítását a működési kontúrban a „Költségvetési foglalás” dokumentum végzi.Az ilyen dokumentumokat kényelmes a DDS üzleti tervek alapján megadni. Ugyanakkor a limitek beállítása és ellenőrzése egy előre meghatározott forgatókönyv – „tartalék” – keretében történik.

Továbbá a DS kiadások operatív tervezése során (a kifizetési kérelem benyújtásakor) a program a keretek szerint ellenőrzi az aktuális működési egyenlegeket. A limit túllépése esetén pedig a program nem engedélyez ilyen alkalmazást, és megfelelő figyelmeztetést kap.

A limit túllépése esetén a bizonylatok feladásának tiltásához lépjen az „Általános könyvtárak és beállítások/Paraméterek beállítása/Kincstár” részhez.

Beállítjuk továbbá a „Tiltjuk a fizetési megbízások közvetlen létrehozását kérvényen, a fizetési nyilvántartás megkerülésével” jelzőt.Erre a funkcióra szükség lesz, mivel feladatunk szükségszerűen magában foglalja a fizetési nyilvántartást (a nyilvántartást szükségszerűen a főkönyvelő hozza létre és hagyja jóvá).

Tehát vegyük be a Költségvetések lefoglalása a 2017. szeptemberi időszakra vonatkozó dokumentumokat.

Figyeljünk a következő pontokra:

• 
  Nem hozunk létre jóváhagyási útvonalat a „Költségvetési foglalás” dokumentumhoz. Állítsa be az „Útvonalon kívül” táblát és a „Jóváhagyva” állapotot.

• 
  A szervezetet „MSK UK (Management Functions)” néven jelöljük meg, míg a pénzügyi igazgató az üzleti tervben feltüntetett értéket hagyja meg.

3.2. A szállítónak benyújtott fizetési kérelem jóváhagyásának módjai

Az általunk megoldandó feladat részeként a jóváhagyási útvonalon biztosítjuk a beszállító felé benyújtott fizetési kérelem jóváhagyását.Így a fizetési kérelem automatikusan elküldésre kerül „a megállapodások láncán keresztül”, amelyek mindegyikének jóvá kell hagynia (vagy a saját szakaszában el kell utasítania) a kérelmet.

Minden szerződő „a maga részéről” ellenőrzi a kérelem jóváhagyásának szükségességét. Például a vásárlásért felelős személy -ellenőrzi a szerződési feltételek helyességét, a pénztáros megbizonyosodik arról, hogy nincs-e készpénzhiány (és ha szükséges, a fizetési naptárban kiegyenlítést végez), pénzügyi. az igazgató véglegesíti a pályázatot stb.

Ezzel egyidejűleg a rendszer automatikusan megállapítja, hogy szükség van-e az alkalmazás elküldésére bizonyos szerződő feleknek (példánkban a feltételek az alkalmazásban szereplő DDS cikktől függően lesznek konfigurálva). Is, a feltételek beállítása nagyon rugalmasan elvégezhető, és az alkalmazásból származó egyéb adatok is ellenőrizhetők.

Lépjünk a „Folyamatok és jóváhagyások/Feldolgozási sablonok” részhez.

Hozzon létre egy új sablont - „A fizetési kérelmek jóváhagyásának folyamata”. A folyamat céljaként a „Jóváhagyási útvonalat” jelöljük meg. típusjóváhagyás tárgya – „Üzemeltetési kérelem”.

Hozzuk létre a következő jóváhagyási útvonalat:

Az útvonalválasztás feltételeit egy speciális konstruktorban konfigurálják.Azok. Mindig beállíthatja, hogy mikor milyen feltételek (vagy feltételcsoportok) teljesülnek, milyen műveleteket kell végrehajtani, és mely jóváhagyási szakaszokban haladjon tovább a program.

Az útvonal-ellenőrzésben a „Megjelenítés” funkció segítségével ellenőrizheti, hogyan működnek az útválasztási feltételek a kérés paramétereitől függően.

Az „Értesítés” szakasz működhet külön szakaszként (a folyamat hálózati diagramja).

Azaz, amikor ebbe a szakaszba lép, a rendszer képes lesz külön riasztást generálni a felhasználó számára.

Ennek megfelelően az „Értesítés” szakasz beépíthető a folyamathálózati diagramba.

A riasztási tartalom konfigurálásához konfigurálnia kell a riasztási sablont:

Ezenkívül a rendszer biztosítja automatikus riasztások generálása különféle események bekövetkezésével kapcsolatban. Itt található a megadott eseménykategóriák listája:

Ilyen módon például konfigurálhatja a riasztások generálását, amikor az egyes jóváhagyási szakaszokra való áttéréskor a rendszer automatikusan generálja a figyelmeztetéseket.

Azok. a jóváhagyó mindig kap értesítést, megtekintheti, hogy jelenleg mely szakaszokban kell megegyeznie, és közvetlenül a „Feladataim és riasztásaim” naplóból tudja elvégezni a jóváhagyást.

Az eseményriasztások generálásáhozlépjen a „Folyamatok és jóváhagyások/Riasztási beállítások” szakaszba. és add hozzá ezt a bejegyzést:

És végül A jóváhagyási folyamatsablon teljes konfigurálása után meg kell adnia ezt a sablont a jelentési szabályzatban. A mi példánkban A „DDS limitek megállapítása és ellenőrzése” rendelet előírja a jelentésmásolatok jóváhagyására szolgáló hatósági mátrix felállítását - a jóváhagyási folyamat sablonjának feltüntetését.

Az Üzemeltetési kérelem dokumentumhoz adja meg a „Fizetési kérelmek jóváhagyásának folyamata” folyamatsablont.

3.3 Az útvonalra vonatkozó kérések koordinálása

Az általunk megoldott feladat részeként fizetési felszólítást készítünk és jóváhagyásra elküldjük.

Töltsük ki a „BDDS (költség) elszámolások partnerekkel” típusú működési kérelem dokumentumot.

A limitek ellenőrzése érdekében a kérelemben a limitekben előírtnál nagyobb összeget tüntetünk fel.

Amikor megpróbálunk feladni egy dokumentumot, üzenetet kapunk a limit túllépéséről.

Korrigáljuk ezt a helyzetet az alkalmazás helyes formázásával.Jelöljük a keretek forrását (költségvetési foglalási dokumentum) és feltüntetjük a rendelkezésre álló összeget.

Töltse ki a partnert és a megállapodást;Lépjünk a „Limit Control” fülre.

Meglátjuk, hogy mennyi az aktuális limit egyenleg (az aktuális működést figyelembe véve), és milyen limitet terveztek.

Tekintsük át a dokumentumot, és nézzük meg, hogy a dokumentum „Jóváhagyás alatt” állapotot kap-e

Kattintson a „Jóváhagyás folyamata” gombra az útvonal megnyitásához, és megtekintheti, hogy az alkalmazás jelenleg melyik szakaszban van.

Az aktuális szakasz kék színnel van kiemelve.

Most nézzük meg, hogyan valósítja meg a program a riasztások generálásának mechanizmusát, és milyen lehetőségeket biztosít a beleegyezőnek.

Lépjünk a „Folyamatok és jóváhagyások/Saját feladatok és figyelmeztetések” részre.

Látjuk, hogy riasztások generálódnak a rendszerben.A riasztások mind az eseménykategóriák szerint, mind az egyes folyamatszakaszokra való átállással generálódnak.

Az értesítési napló elhagyása nélkül a jóváhagyó jóváhagyhatja a szakaszt, átadhatja a szakaszt a helyettesnek, és további jóváhagyókat rendelhet hozzá.

Az alkalmazások további vezérléséhez a program lehetővé teszi a fizetések tiltásának/engedélyezésének konfigurálását a speciálisan meghatározott elemzők számára.

A „Tervezés és ellenőrzés/Fizetések engedélyezése és tilalma” részben (például) a következő bejegyzést fogjuk tenni.

Amikor ilyen kérelmet próbálunk benyújtani jóváhagyásra, a következő üzenetet kapjuk

Ez azt jelenti, hogy bár az alkalmazás átmegy a limitellenőrzésen, a fizetés-ellenőrzési irányelvet nem.

Tiltsuk le a korábban bevitt direktívát, és küldjük el a kérelmet jóváhagyásra.

Kattintson a „Dokumentum jóváhagyása” gombra az aktuális szakasz jóváhagyásához.

Beírjuk a vízumot (magyarázat), és rákattintunk az „Elfogadom” gombra.

Tegyük fel, hogy a jóváhagyás következő szakaszában a pénztáros látta, hogy a fizetési cél nincs kitöltve a kérelemben, és szükségesnek tartotta visszaküldeni a kérelmet a vállalkozónak (hogy az összes mezőt kitöltse, ahogy lennie kell). Erre a célra egy „Elutasítás” gomb található.

A program a következő hasznos szolgáltatásokat is nyújtja a jóváhagyási útvonal követése szempontjából:

• 
  elutasítja a kérelmet az előző jóváhagyási lépésre;
• 
  Nyújtsa be a kérelmet jóváhagyásra további jóváhagyóknak (azaz ha szükséges, jóváhagyókat adhat hozzá az aktuális útvonalhoz, és átirányíthatja hozzájuk a kérelmet).

3.4 A fizetési naptár használata.

Jelenleg tehát 2 fizetési felszólítás van a pénztárossal „egyeztetés” szakaszában.

A pénztáros fő feladata a fizetés lehetőségének ellenőrzése.Azaz azért, hogy például ne keletkezzen készpénzhiány (meg kell becsülni, hogy fizetéskor mekkora összeg van a folyószámlákon betervezve). Benne is Ebben a 2 alkalmazásban a folyószámlák (amelyekről a fizetés történik) nincsenek meghatározva.

Összességében a pénztárosnak ki kell egyensúlyoznia a fizetési pozíciót (meg kell határoznia a fizetési számlát, és figyelemmel kell kísérnie a fizetési dátumot a készpénzhiányokra).És ha kiderül, hogy a tervezett pillanatra a befizetés nem elegendő, akkor a pénztárosnak vagy el kell tolnia a tervezett kifizetés időpontját, vagy figyelembe kell vennie (ráadásul meg kell terveznie) a kifizetést c a belépéshez, vagy fizetési lehetetlenség miatt elhalasztja a jelentkezést (áthelyezése a stoplistára). Mindezek a funkciók, valamint az elválasztás funkció egy alkalmazás többre (egy összeg több részre osztása érdekében) és a készpénz számlák közötti mozgatásának funkciója - mindezt figyelembe veszik a későbbi fizetési naptárral való munka során.

Fontos megemlíteni még egy funkciót a fizetési naptárral való munkavégzéshez, nevezetesen a különböző „események fejlesztésére szolgáló opciók” mentésének lehetőségét.

Vagyis a pénztáros modellezheti például a készpénz várható beérkezésének „további tervezésének” 1. számú helyzetét.az ügyféltől, és elemezze és mentse el az események ezen „forgatókönyvét” (a fizetési naptár ezen verzióját). Ezután szimulálja a 2. számú helyzetet, amikor a várt d/s beérkezés nem történt meg, de a d/s hiányt megszüntetni kell c mozgáson keresztül d/ c másik folyószámláról, és részben eltolja a fizetési dátumokat. Összességében lehetőség lesz mindkét forgatókönyv összehasonlítására, és kiválasztani az előnyösebbet.

A fizetési naptár funkcionalitása az irányítási rendszerben gazdag lehetőségeket biztosít a pénztárosnak, nézzük meg mindezt példákkal.

Mielőtt azonban elkezdene dolgozni a fizetési naptárral, el kell végeznie a következő lépéseket.

Konfiguráljon számos paramétert a fizetési naptárhoz:

• 
  A naptárképzés horizontjai (napok száma);
• 
  A fizetési naptár kialakításakor figyelembe kell venni vagy sem (1 vagy 0, vagy például - 0,5 - akkor „a felét figyelembe vesszük”) a pályázati dokumentumokat (beleértve azokat is, amelyeket nem hagytak jóvá, amelyek jóváhagyás alatt állnak) .
  • 
    Azok. Ha a nem jóváhagyott pályázatoknál mindenhol „1”-et állítunk be, akkor az összes nem jóváhagyott (de jóváhagyás alatt álló) kérelmet maradéktalanul figyelembe veszi a program a fizetési naptár generálásakor.

    Vagyis ez azt jelenti, hogy a program megvizsgálja ezeknél a pályázatoknál a tervezett kifizetési időpontokat és összegeket, és ennek megfelelően ezeket az adatokat a naptárba beépíti, és kiszámítja a folyószámlák tervezett pénzmaradványait, figyelembe véve az ilyen pályázatok várható kifizetéseit.

Regisztrációaktuális nyitó egyenlegek:

A programban a fizetési naptár kiszámításához regisztrálnia kell a kezdeti d/c egyenlegeket. Kívánt hogy a kezdeti egyenlegek a „Pénzpénz” felhalmozási nyilvántartásba kerüljenek. Ugyanakkor a tényleges mozgás (érkezés/indulás) d/ c ennek a nyilvántartásnak is tükröződnie kell.

Kezdő egyenlegek nyilvántartásaA nyitó egyenlegek kiigazítása című dokumentum végrehajtásával történik. ahol, Ez a bizonylat természetesen automatikusan, a számviteli adatok szerint kitölthető. könyvelés ( m .e folyószámla szerint 51).

Tehát regisztráljuk 2 jogi személy kezdeti egyenlegét. magánszemélyek és bankszámláik.

A d/s tényleges bevételei/eladásai a „Tényleges költségvetési adatok tükrözése” dokumentumokon keresztül jelennek meg a programban.Az ilyen dokumentumok automatikusan generálásra kerülnek a programban a tény tükrözésének pillanatában. számviteli bizonylatok mozgása d/c (bevételek/leírások d/ c fiók szerint). A rendszer viselkedését a következő beállítások határozzák meg:

Menjünk a "Tervezés és ellenőrzés/Fizetési naptár" részhez.

Állítsuk be a következő kulcsparamétereket:

• Csoportosításokat hozunk létre: szervezetenként és bankszámlánként;
• Az időszakot beállítjuk: az aktuális dátumtól az aktuális hónap végéig;

Szervezetenkénti kiválasztás: az MSC Energy + csoport konszolidálásával hozzuk létre

Fizetési naptárt generálunk (a naptár az aktuális dátumtól a hónap végéig készül).

Látni fogjuk, hogy a naptár két folyószámla kezdeti egyenlegét tartalmazza,d/c kiadások tervezett mozgásai (két fizetési kérelem befizetése, holnap esedékes).

A piros szín azt jelenti, hogy készpénzhiány van a „Bankszámla nincs megadva” számlán. Ez azért merült fel, mert a fizetési számla nem volt meghatározva a kérelmekben.

• Változtassuk meg a kiválasztott rendelések számát. Állítsuk be a fiókot – VTB 24.

• 
  Ennek eredményeként azt kapjuk, hogy a „bankszámla nincs megadva” ki van zárva a naptárból, azonban 05/09-től 4000 összegű készpénzhiány van. A lényeg az, hogy a tervezett kiadások (34 ezer rubel ben) összesen 2 pályázat) meghaladja a számla d/ c egyenlegét.

• A „halasztás/elhalasztott” funkció használatával egy jelentkezést egy időre elhalaszthat (áthelyezheti a stoplistára). Ezután küldje vissza a halasztottból.

• A naptár így létrejött változata elmenthető. Utána pedig nyisson meg, hasonlítson össze és válasszon kedvezőbb forgatókönyveket a helyzet alakulására a d/s mozgását illetően.

• A jelentkezések fizetési dátumát áthelyezheti egy megadott határidőre

A készpénzhiányokat is bezárhatja, például csoporton belüli készpénzátutalással(egy szervezet számlájáról egy másik szervezet számlájára). Ebből a célból belső mozgásra vonatkozó alkalmazást biztosítanak.

Gyorsan megtervezheti a kiadásokat és a várható bevételeket is. Ezek lehetnek tranzakciók, például ügyfelektől származó bevételek és más tranzakciók várható bevételei.

3.5 Fizetési nyilvántartás kialakítása.

A kérelmek jóváhagyása után azok bekerülhetnek a fizetési nyilvántartásba.

Példánkban a főkönyvelő hozza létre és tartja a nyilvántartást „Jóváhagyva” státuszban.

A fizetési megbízások generálása a „Fizetési megbízások generálása” gombbal történik.

3.6 A tények tükrözése, nyilatkozatok terjesztése a költségvetés-elemzőknek.

Az ügyfélbankból történő letöltést követően folyószámla terheléskor a dokumentumok betöltődnek a programba"A folyószámláról történő terhelések."

Felhívjuk figyelmét, hogy a folyószámláról történő terheléskor a program automatikusan generálja a „Tényleges adatok tükrözése” bizonylatokat.

A „Tényszerű adatok tükrözése” dokumentumok célja, hogy a kiadás tényét tükrözzék a költségvetési és pénzforgalmi nyilvántartásokban. Tényleges fogyasztás d/c a fizetési naptárban is figyelembe veszik az aktuális egyenlegek meghatározásához c.

A bankszámlakivonat betöltése után a program segítségével szétosztható a tervezési elemzők között.

Ilyen algoritmus konfigurálható a „Számlakivonatok elosztása a tervezési elemzők között” feldolgozásban.A kitöltés az analitikai sablonok alapján történik. A program számos kitöltősablont tud készíteni.

Íme egy példa egy sablonra, amely beállítja a „Project” analitikai értéket. A sablon (szabály) minden szervezetnél és vállalkozónál működik. Ezzel egyidejűleg a fizetési cél tartalmát is ellenőrizzük.Vagyis ha a „fizetési cél” mező a „Fő megállapodás” szavak kombinációját tartalmazza, akkor ebben az esetben a „Projekt fő” elemzése a projekt mezőbe kerül.

Ily módon más algoritmusokat is rendszerezhet a fizetés céljának felismerésére és ennek megfelelően a mezők kitöltésére tsfo , DDS cikk, elemző stb.

Az alrendszer alkalmas azoknak, akik

• Elegem van abból, hogy az emberek időnként csak az aláírások kedvéért rohangálnak az irodákban;
• látni kell: ki, mikor és hogyan hagyta jóvá ezt vagy azt az objektumot az 1C adatbázisban;
• csökkenteni kell a jóváhagyási időt (megállapodás, kiadási kérelem vagy bármi más esetében).

A program lehetővé teszi bármely dokumentum és referenciakönyv összehangolását az 1C adatbázisban. A koordináció szekvenciálisan történik, azaz. Először az első értékelő vállalja, ha egyetért, akkor a következő, és így tovább.

A következő állapotok léteznek:

• "Nem engedélyezett"
• „Jóváhagyás folyamatban”,
• "Jóváhagyott"
• "Törölve"
• "Visszaküldve felülvizsgálatra."

A lektorok feladatainak létrehozásakor nincs megadva konkrét felhasználó, hanem csak a Címzési szerepkör + Címzési osztály kerül kitöltésre. Tételezzük fel, hogy egyet kell értenünk

Ezután létrejön a feladat a Könyvelő számára a Könyvelésből. A „Címjegyzék” regiszterben pedig konkrét felhasználókat kell megadni

Így a jóváhagyásra váró feladatot egyszerre két felhasználó fogja látni, és bármelyikük elvégezheti a feladatot. Ez különösen akkor hasznos, ha egy alkalmazott szabadságra megy, és meg kell adnia egy felhasználót, aki helyettesíti őt. Ebben az esetben elegendő egy új bejegyzést hozzáadni a címzési nyilvántartáshoz, és minden régi és minden új feladat azonnal látható lesz az új felhasználó számára.

Előnyök

• teljesen nyílt forráskódú;
• független konfiguráció;
• független a BSP-től (nem szabványos konfigurációknál ez fontos);
• bármilyen konfigurációba beépíthető (lásd alább a tesztelt konfigurációk listáját);
• vékony kliensben működik (normál alkalmazásban is működik);
• Új koordináció beállításához nincs szükség programozásra, minden futásidejű módban történik;
• nagyon egyszerű új szerződés beállítása, mindössze 4 lépést kell végrehajtania, és a megállapodás használható;
• beállíthat jóváhagyásokat az 1c adatbázisban lévő bármely címtárhoz és dokumentumhoz;
• értesítések küldése e-mailben;
• a jóváhagyási idő jelentős csökkenése, és gyakran a jóváhagyási idő is jelentősen csökken;
• mindig világos, hogy kinek kell jóváhagynia, valamint azt, hogy ki és mikor hagyta jóvá;
• egy dokumentum végrehajtásának megtiltása addig, amíg megállapodás meg nem születik;
• egy adatbázis-objektum használatának megtiltása mindaddig, amíg megállapodás nem születik róla;
• könnyen integrálható más üzleti folyamatokba az 1C-ben;
• nincs szükség külön adatbázisra, amiben a koordináció történik, minden egy adatbázisban történik.

Videó

• Új megállapodás létrehozása

• a megfelelő alrendszer felülvizsgálata

• hogyan lehet egy alrendszert szabványos konfigurációba integrálni

• Fiók beállítása értesítések küldéséhez:

Az alrendszer teljes mértékben felügyelt formában van megvalósítva, és vékony kliensben fut.

Példák az alrendszer használatára

1. példa

A pénzeszközök kiadására irányuló kérelmet annak teljesítése előtt jóvá kell hagyni. Ebben az esetben a következő koordinációs útvonalra van szükség:

• mindig egyeztetni a „Beszerzési vezetővel”;
• ha a pályázati összeg meghaladja a 10 000-et, akkor állapodjon meg a kereskedelmi igazgatóval;
• ha a pályázati összeg meghaladja az 50 000-et, akkor egyezzen meg a pénzügyi igazgatóval;
• ha a pályázati összeg meghaladja a 100 000-et, akkor egyeztessen a főigazgatóval.

2. példa

Bármely felhasználó létrehozhat szerződéseket a rendszerben, a szerződés jóváhagyását a következő útvonalon kell beállítani:

• ha a szerződő fél/partner a szállítók körébe tartozik, akkor a „Szállító könyvelővel” egyeztetni kell;
• ha az ügyfél/partner a vevők körébe tartozik, akkor a „Vásárlók könyvelőjével” egyeztetni kell;
• mindig forduljon ügyvédhez;
• ha a szerződés hagyományos egységekben történik, akkor állapodjon meg a kereskedelmi igazgatóval;

Gyakran ismételt kérdések (GYIK)

Kérdés: Lehetséges-e egy alrendszert nem szabványos konfigurációba integrálni?

Válasz: Igen, megteheti, ehhez szükséges, hogy a végső konfiguráció tartalmazza a következőket:

• Directory.Users;
• "CurrentUser" munkamenet paraméter;
• A konfigurációnak rendelkeznie kell a „Felügyelt alkalmazás” vagy a „Felügyelt és normál alkalmazások” tulajdonsággal, mert minden forma ellenőrzött.

Kérdés: Meg lehet hívni a „Jóváhagyási állapotok” űrlapot közvetlenül egy címtárelemből vagy dokumentumból?

Válasz: igen tudsz. Ha kezelt űrlapokat használ, akkor a következőket kell tennie:

• lépjen a konfigurátorba;
• keresse meg a „bpsStatusConcordance” általános parancsot;
• kattintson a jobb gombbal, és válasszon ki egy tulajdonságot;
• a „Command Parameter Type” tulajdonságban adja meg az összetett adattípust, és válassza ki a kívánt objektumot.

Ha normál űrlapokat és szabványos konfigurációt használ, akkor a következőket kell tennie:

• vegye át a szállításból a „bpsStatusCoordination.epf” feldolgozást;
• Kattintson a "Szolgáltatás - További nyomtatási űrlapok és feldolgozás - Nyomtatási űrlapok" elemre.
• kattintson a Hozzáadás gombra, majd adja meg a feldolgozást;
• adja hozzá a táblázat részhez azokat az objektumokat, amelyekhez ezt a feldolgozást meg kell hívni;
• Most a nyomtatás gomb meg tudja hívni ezt a feldolgozást.

Ha normál űrlapokat használ, és a konfiguráció nem szabványos, akkor manuálisan kell beillesztenie a kódot egy könyvtár/dokumentumelem minden egyes formájába, a kódra egy példa található a „Példakód gomb hozzáadásához normálhoz Form.epf” (a készletből).

Kérdés: Megadható egy dokumentum státusza, mondjuk „Fizetett”?

Válasz: Igen, megteheti, ehhez szüksége van:

• lépjen az „Object statuses” könyvtárba, és adjon hozzá egy „Fizetett” nevű elemet, írja le és zárja be;
• majd nyissa meg a „Jóváhagyási állapotok” feldolgozást, kattintson az „Állapot beállítása” gombra, és válassza ki a „Fizetett” állapotot.

Szerepek

• (BPS) Felhasználó- minden felhasználónál meg kell adni;
• (BPS) Címzésregiszter szerkesztése- a „Címjegyzék” nyilvántartás szerkesztési joga szükséges;
• (BPS) Dokumentum szerkesztés, objektum állapot regisztráció- a jog szükséges ahhoz, hogy manuálisan megadhassa egy 1c objektum állapotát;
• (BPS) Teljes jogok- hozzáférés a koordinációs alrendszer összes objektumához, és szükséges a koordináció felállításához is.

Ami automatikusan történik

• az értesítéseket ütemezetten küldik el (percenként egyszer);

Mit terveznek hozzáadni a jövőben, ha az alrendszer sikeres lesz

• a jóváhagyási feladat másik lektorhoz való átirányításának képessége;
• a magyarázat szövegének generálására szolgáló sablon testreszabásának lehetősége, amelyet a jóváhagyás megkezdésekor és az értesítések e-mailben történő elküldésekor jeleznek (például: a magyarázatban szerepeljen a dokumentum pénzneme, kezelője, összege stb.);
• válaszlevél útján történő megegyezés képessége az 1C-be való bejelentkezés nélkül;
• hogy a címzési egység automatikusan a dokumentum/könyvtár fejlécéből kerüljön kiválasztásra, és ne legyen „mereven” feltüntetve a jóváhagyás tárgyában;
• a „Koordináció” alrendszer olyan konfigurációkban való használatának képessége, ahol a rekordszintű hozzáférési korlátozás engedélyezett;
• címtárelem használatának tilalma, amíg meg nem állapodnak.

A fejlesztés Bitbucket-en (egyelőre zárt tároló) zajlik, az alrendszer fő funkcióit az xUnitFor1c() segítségével végzett tesztek fedik le.

A szabványos konfigurációkra való átvitel tesztelése

A tesztelést a 8.3.8.1652 platformon végezték el

Konfiguráció

Vizsgálati eredmények

Az üzleti folyamat egy szervezet alkalmazottainak stabil cselekvési sorozata. Az ilyen szekvenciák automatizálása leegyszerűsíti a munkát, és jelentősen felgyorsítja a végső feladat elvégzését.

A következő típusú üzleti folyamatok valósulnak meg az 1C: Document Flow 8 programban:

• Megfontolás: a dokumentumot megfontolásra benyújtják a vezetőnek, és határozatával visszaküldik a dokumentum készítőjének.
• Végrehajtás: a dokumentum végrehajtásra átkerül a listán szereplő összes felhasználóhoz és a kontrollerhez a végrehajtási fegyelem fenntartása érdekében. Az egyik felhasználó kijelölhető felelős végrehajtónak.
• Koordináció: az ilyen üzleti folyamatokhoz csatolt dokumentumokat jóváhagyásra benyújtják a megadott válaszadóknak, majd visszaküldik az üzleti folyamat szerzőjének, hogy áttekintsék a jóváhagyás eredményeit vagy elküldjék újbóli jóváhagyásra.
• Nyilatkozat: a dokumentum a felelős személyhez kerül jóváhagyásra, és visszaküldi a dokumentum készítőjének, hogy ellenőrizze a jóváhagyás eredményét.
• Bejegyzés: a dokumentum a titkárhoz kerül, hogy adjon neki regisztrációs számot, amelyet a szervezet pecsétjével hitelesítenek, és elküldik a levelezőnek.
• Bevezetés: Ezzel az üzleti folyamattal a szükséges dokumentumot elküldi a listán szereplő összes felhasználónak áttekintésre.
• Rendelés: Ezzel az üzleti folyamattal utasításokat adhat ki az alkalmazottaknak, és ellenőrizheti azok végrehajtását.

Minden egyes üzleti folyamat, ahogy halad a szakaszokon, feladatokat hoz létre meghatározott felhasználók számára. Például egy üzleti folyamat Rendelés először létrehoz egy feladatot Végezze el a feladatot a végrehajtó számára, és miután a végrehajtó rögzíti e feladat elvégzését, a feladat Ellenőrizze a folyamatot az üzleti folyamat kezdeményezője számára.

Nemcsak konkrét előadókhoz, hanem szerepekhez is rendelhet feladatokat. Így például el lehet küldeni egy dokumentumot szerepkör jóváhagyásra Rendező, és a program automatikusan átadja a megfelelő feladatot annak, aki éppen ezt a szerepet tölti be - magának az igazgatónak vagy helyettesének. A feladat a következő automatikus helyettesítések által azonosított felhasználóknak is címezhető:

• Az üzleti folyamat szerzőjének minden menedzsere,
• Az üzleti folyamat szerzőjének minden beosztottja,
• A dokumentum készítőjének közvetlen felettese,
• A dokumentum szerzőjének összes menedzsere.

A szerepkörök összetétele minden vállalatnál vagy intézménynél egyedi, és a rendszer leállítása nélkül módosítható és konfigurálható. Amikor a szerepkör végrehajtója megváltozik, a feladatok automatikusan átkerülnek az új végrehajtó asztalára.

A felhasználó a listában bármikor megtekintheti a hozzá rendelt feladatok listáját Az én feladataim. A lista automatikusan betöltődik a program indításakor.

Ezenkívül a felhasználó e-mailben értesítést kaphat a feladat elvégzéséről.

A program minden üzleti folyamathoz létrehoz egy kártyát, amelyről a felhasználó előhívhatja az üzleti folyamat vizuális folyamatábráját. Az üzleti folyamat szakaszainak végrehajtását a folyamatábra tükrözi. Segítségével egy üzleti folyamat megalkotója bármikor megtudhatja, hogy megvalósítása melyik szakaszban van, és mely munkatársak végezték már el feladatukat és kik nem. Az alábbiakban egy kártya és egy tipikus üzleti folyamat folyamatábra látható Koordináció.

Egy adott dokumentumhoz társított új üzleti folyamat hozható létre e dokumentum alapján. A program minden üzleti folyamattípushoz külön listát biztosít, például a jóváhagyások listáját:

Minden üzleti folyamattípushoz beállíthat egy sablont, amelyet az új üzleti folyamatok létrehozásakor fog használni. Az üzleti folyamatsablon olyan információkat tartalmaz, mint például:

• útvonalválasztás,
• határidők,
• fontossága,
• Név,
• leírás és mások.

Például üzleti folyamatsablon Szerződés harmonizálásaígy nézhet ki:

A dokumentumtípus kártyán megadhatja a hozzá tartozó üzleti folyamatsablonok listáját. Ez a lista automatikusan felhasználásra kerül az ilyen típusú dokumentumokon alapuló új üzleti folyamatok létrehozásakor. A megadott példában a bejövő dokumentum típusa a Megegyezés a fenti sablonhoz kapcsolódik Szerződés harmonizálásaés két másik sablon - Szerződés jóváhagyása (egyszerű)És A megállapodás regisztrációja:

Amikor üzleti folyamatot hoz létre bármely típusú bejövő dokumentum alapján Megegyezés a felhasználó kiválaszthatja a megfelelő sablont ebből a listából.

Megkérjük Önt, hogy gondoljon egy példát. Az áruk árait a cég marketingese vagy tervezési osztályának szakembere határozza meg. Ennél a cégnél az árpolitikát a menedzsment hagyja jóvá, és az árelfogadás folyamata számos, egymással összefüggő tevékenységből áll. Hogyan alakítsuk ki az árképzési folyamatot egy szabványos programban?

Az 1C: Trade Management 8 szabványos megoldásában már beszéltünk az üzleti folyamatokról, mint olyan funkcionalitásról, amely segít számos műveletet egy szigorúan meghatározott műveletsorba kombinálni. Ennek eredményeként a vállalati alkalmazottak munkája egyértelműen meghatározott algoritmuson alapul.

Az ártárgyalás folyamatának előzetes konfigurálása

• Az áregyeztetés folyamatának kialakítása a programban 1C: Kereskedelmi menedzsment 8 a megfelelő opció engedélyezésével kezdődik.
• Ezután ellenőriznie kell az árképzésben részt vevő összes felhasználó „Hozzáférési profilját”. Példánkban az árakat egy marketingszakember állítja be, ezt követően a menedzsment hagyja jóvá, ezért ellenőrizzük: profiljában le kell tiltani a „Cikkár-beállítás jóváhagyás nélkül” szerepet.
• Végül hozzá kell adnia a végső árakat jóváhagyó felhasználókat. Ehhez be kell lépnie az „Üzleti folyamatok szerepei és végrehajtói” címtárba, és hozzá kell rendelnie a felelős vezetőhöz a „Cikkár-meghatározás koordinátora” szerepet.

Hogyan működik az ártárgyalás üzleti folyamata?

Az üzleti folyamatokat alkalmazó ártárgyalási mechanizmus működési elve a következő. Marketingesünk az értékesítési piac helyzetét áttanulmányozva arra a következtetésre jut, hogy a termékpaletta egyes tételeinél árat lehet emelni. Standard oldatban 1C: Kereskedelmi menedzsment 8 az árak rögzítése a „Cikkárak beállítása” dokumentum segítségével történik. Az árváltozások hatálybalépéséhez azonban ennek a dokumentumnak „Jóváhagyva” állapotúnak kell lennie. Marketingesünknek nincs joga a bizonylat státuszának megváltoztatására, így az árak módosításához az „Árjóváhagyás” üzleti folyamatot kell használnia.

Tegyük fel, hogy a menedzser úgy gondolja, hogy az árakat még tovább lehet emelni.

• Ebben az esetben ki kell töltenie a „Feladat elvégzésének eredménye” mezőt, javaslatot tenni, és rá kell kattintani a „Nem egyeztetett” gombra.
• Ebben az esetben a marketinges értesítést kap a meghozott döntéséről, amelyben megismerheti a menedzser kívánságait.
• Ezután a marketingszakember rákattint az „Ismerem” gombra, és befejezi az üzleti folyamatot. Most a marketingszakembernek felül kell vizsgálnia az árakat a menedzser javaslatainak megfelelően, és új üzleti folyamatot kell létrehoznia.
• A menedzser még egyszer megismerkedik a megváltozott árakkal és megegyezik azokban. Ebben az esetben a marketingszakember által készített „Cikkárak beállítása” dokumentum „Egyetért” státuszt kap, és felkerül a programba.

A menedzser mindent kézben tart

A „Jóváhagyás” lapon a menedzser nyomon követheti egy adott árváltozási dokumentum jóváhagyásának teljes folyamatát.

Az egyes ilyen dokumentumokkal kapcsolatos összes munkát a program egy helyen tárolja, ami lehetővé teszi a marketingszakember munkájának hatékonyságának értékelését.

Végezetül szeretném megjegyezni, hogy az „Ármegállapodás” üzleti folyamat használata lehetővé teszi az árképzési folyamat egyszerűsítését, javítva a személyzeti menedzsment minőségét és ellenőrzésüket.