1в документооборот, одобряващият не е посочен. Автоматизация на бизнес процеси. Мониторинг на бизнес процеси и тяхното оптимизиране с помощта на 1C: Документооборот

Във връзка с пускането/актуализацията на тези продукти, както и с развитието на технологията за уеб услуги, специалистите на 1C внедриха безпроблемна интеграция, 1C ERP и 1C Управление на документи (наричани по-долу „DO“).

Тази статия ще опише не само схемата и конфигурацията на интеграцията, въпреки че това ще бъде разгледано изцяло, но също така ще бъдат разгледани няколко възможни типа интеграция.

За да реализираме това взаимодействие между двете програми ще ни трябва:

• 1C "DO" 2.0 (версии на CORP)

  Уеб сървър Apache.

Няма нужда да описваме инсталирането и конфигурацията на тези софтуерни продукти; нека преминем директно към конфигурацията.

Така. Бизнес процесът е следният: трябва да договорим споразумения за продажба. Схемата за координация ще бъде следната:

За да приложим такава схема, ще добавим потребители към 1C ERP и 1C DO.

- Безопасност

- Адвокат

- икономист

- Чиновник

Сега да преминем към настройката

Нека да отидем в 1C DO в режим "Конфигуратор" и да публикуваме нашата база данни на уеб сървъра.

Име - адрес на ресурс, т.е. http://localhost/DocCorp/

Директория - местоположението на уеб услугата.

Проверяваме работата.

Сега нека направим настройките в 1C DO.

1) Създайте нов тип документ: „Договор за продажба“

Отидете на „НСИ и администрация” – „Видове документи”

Да създадем група документи „Споразумения“

Създаване на нов изглед

Нека отидем в раздела "Шаблони на документи" - "Подробности за документа".

Нека създадем папка за съхраняване на всички договори за продажба на едно място.

Отидете на „Шаблони за процеси“ и създайте нов шаблон.

Ще се отвори формулярът за избор на шаблон „Одобрение“, създайте папката „Нестандартни процеси“, след което създайте процеса „Одобрение на споразумение за продажба“.

Нека запишем процеса.

Да преминем към субектите на процеса, т.к Имаме условно маршрутизиране, което зависи от сумата на договора, имаме нужда от обект на анализ, нека го създадем.

Нека се върнем към раздела „Настройки на процеса“ и да добавим одобряващи.

След това променяме посоката на маршрутизиране и задаваме реда на координиране:

Сега нека настроим catch адресиране, щракнете върху бутона „Условия за използване“. *(Само във версия CORP).

Нека създадем ново условие за маршрутизиране: Сума на договора > 100 000 rub.

Нека го присвоим на „Тип документ“ - „Договор за продажба“.

Настройката на 1C "TO" е завършена. Нека да преминем към настройката на 1C: ERP.

Нека добавим потребители, същите като в 1C "DO"

В полето URL въведете уеб адреса на услугата, поставете отметки в необходимите квадратчета и продължете с настройката на интеграцията.

Нека посочим в настройките към кой документ искаме да свържем процеса.

Това ще бъде „споразумение с контрагент“, обект от 1C „DO“ - „Вътрешен документ“

След като изберете връзки, ще бъде извършена основна настройка на свързаните обекти.

Трябва да се конфигурират редица полета.

Тип документ в 1 “ПРЕДИ” - “Договор за продажба”

Когато се въведе тип документ, 1C ERP го търси в 1C “DO”.

„Папка“ - „Договори за продажба“ (място за съхранение на документи)

"Регистрационен номер"

Системата по подразбиране казва, че това е „Код“, това е неправилно, нека променим стойността.

Това е номерът на нашия договор.

Нека да конфигурираме останалите полета

Това е всичко - Запазете настройката.

Нека създадем споразумение за продажба в 1C ERP, ще го създадем под потребителя „Clerk“

Сега нека създадем процеса 1C „DO“ въз основа на това споразумение. Щракнете върху „Още“ във формата за списък

В 1C DO се създава вътрешен документ „Споразумение за продажба“.

„Името“ на което съответства на данните от 1C ERP. Системата веднага ни подканва да изберем шаблон за процес. Изберете „Споразумение за договор за продажба“ и щракнете върху „Създаване на процес“. Засега няма да инсталираме квадратчето за отметка „Стартирай веднага“.

Сумата на нашия договор е > 100 000 рубли, следователно правилото ни за маршрутизиране работи, добави „Икономист“.

Да започнем процеса.

Сега нека влезем в 1C ERP под различни потребители и да видим резултата. Първият път, когато потребител влезе в 1C ERP, ако е конфигурирана интеграция с 1C „DO“, потребителят ще бъде подканен да въведе потребителско име и парола, за да се свърже с „DO“.

След това ще отидем в The Economist

Той няма задачи, защото... неговото одобрение идва след „Юриста“, ще съгласуваме споразумението от „Юриста“ и ще актуализираме задачите на „Икономист“

Нашето споразумение е преминало в състояние „Валидно“.

Малко отклонение. Това е пример за интеграция от 1C ERP към 1C DO. Но според мен има редица недостатъци не в самата интеграция, а в организацията на бизнес процеса. Да речем, че имаме голям документооборот от споразумения за продажба с контрагенти, всички споразумения преминават през процедурата за одобрение. Следователно, всеки път, когато договорът трябва да бъде въведен в 1C: ERP. Но договорът може да не бъде одобрен, тогава „боклукът“ ще остане в базата данни, да не кажа, че това ще повлияе значително на работата на системата, но все пак.

Но има възможност за разширяване на връзката. „Служителката” създава вътрешен документ „Споразумение за продажба” в 1C „DO”, документът преминава през етапите на одобрение, след което, когато стане одобрен, „Служителката” въвежда вече одобрените данни в 1C ERP и настройва връзката между обекта в 1C ERP и 1C “DO” .

В 1C DO ще създадем вътрешен документ „Договор за продажба“

Ние регистрираме договора и го изпращаме, като използваме създадения от нас шаблон за одобрение.

Малка неточност в снимката на екрана по-късно е посочена като 1500 рубли.

Зададох сумата на договора на 1500 рубли, следователно икономистът не трябва да прави одобрения.

Да преминем към 1C ERP.

Както можете да видите, дори без създаване на документ в 1C ERP с безпроблемна интеграция, всички потребителски процеси в 1C „ПРЕДИ“ се показват в 1C ERP.

След като всички процедури за одобрение са завършени и договорът е съгласуван, трябва само да го въведете в базата данни на 1C ERP и да настроите връзката.

Въвеждаме нашето споразумение в 1C ERP и установяваме връзка с договорения обект от 1C „DO“

Отидете на „Поток на документи“ на този документ и изберете „вътрешен документ“ 1C DO.

Търсенето се извършва според избраните критерии от страна на 1C "DO".

Сега сме конфигурирали връзка между два обекта.

В същото време не създадохме ненужни документи в 1C ERP; целият процес на одобрение се проведе от страна на ERP (с помощта на 1C DO инструменти). И се получи връзка между 2 обекта от различни бази.

Това е всичко за това. Кои методи да изберете зависи от вашите нужди, решете сами.

PS. Когато се интегрирате с 1C ERP, бих препоръчал да създадете планове за обмен на корпоративна структура, изпълнители, потребители и DDS статии. Това ще намали намесата в системата 1C DO и ще има актуална информация за договорно счетоводство.

3 Оперативно планиране и факт. ДС движение.

3.1 Бюджетна резервация

Както бе споменато по-рано, DDS ограничения по бюджет (DDS бизнес планове)често може да бъде специфицирана (например сумата за дадена позиция може да бъде детайлизирана по контрагенти, по допълнителни анализатори, например събития и т.н.).

Задаването на лимитите на DS в оперативния контур ще се извършва от документа „Бюджетна резервация“.Удобно е да въвеждате такива документи на базата на DDS бизнес планове. В същото време настройката и контролът на лимити ще се извършва в контекста на предварително зададен сценарий - „резерв“.

Освен това, по време на оперативно планиране на разходите на DS (в момента на подаване на заявление за плащане), програмата ще провери текущите оперативни салда според лимитите. И ако лимитът бъде превишен, програмата няма да позволи такова приложение и ще бъде издадено подходящо предупреждение.

За да активирате забраната за публикуване на документи, когато лимитът е надвишен, отидете в раздела „Общи директории и настройки/Параметри за настройка/Съкровище“.

Също така ще поставим флага „Забранете директното създаване на платежни нареждания въз основа на приложения, заобикаляйки регистъра на плащанията.“Тази функционалност ще е необходима, тъй като нашата задача задължително ще включва регистър на плащанията (регистърът задължително ще бъде формиран и одобрен от главния счетоводител).

И така, нека въведем документите Резервация на бюджети за периода – септември 2017 г.

Нека обърнем внимание на следните точки:

• 
  Няма да създаваме маршрут за одобрение за документа „Бюджетна резервация“. Задайте знака „Извън маршрута“ и статуса „Одобрен“

• 
  Ще посочим организацията като „MSK UK (Управленски функции)“, докато финансовият директор ще остави стойността, посочена в бизнес плана.

3.2 Начини за одобрение на заявление за плащане към доставчик

Като част от задачата, която решаваме, ще осигурим одобрение на заявката за плащане към доставчика по пътя на одобрение.По този начин заявлението за плащане ще бъдат изпратени автоматично „през веригата от споразумения“, всеки от които ще трябва да одобри (или да отхвърли на свой собствен етап) заявлението.

Всеки съгласен ще провери „от своя страна“ необходимостта от одобрение на заявлението. Например лицето, отговорно за закупуването -ще провери правилността на условията на договора, касиерът ще се увери, че няма парична разлика (и, ако е необходимо, ще извърши балансиране в платежния календар), финансови. директорът ще одобри окончателно заявлението и др.

В същото време системата автоматично ще определи необходимостта от изпращане на приложението до определени съгласни (в нашия пример условията ще бъдат конфигурирани в зависимост от DDS статията в приложението).Също, настройването на условия може да се направи много гъвкаво и всички други данни от приложението могат да бъдат проверени.

Да отидем в раздела „Процеси и одобрения/Шаблони на процеси“.

Нека създадем нов шаблон - „Процес на одобрение на заявки за плащане“. Ще посочим „маршрут на одобрение“ като цел на процеса. Типобект на одобрение – „Заявление за експлоатация”.

Нека създадем следния маршрут за одобрение:

Условията за избор на маршрут се конфигурират в специален конструктор.Тези. Винаги можете да конфигурирате - кога кои условия (или групи от условия) са изпълнени, какви действия трябва да бъдат извършени и към кои етапи на одобрение да премине програмата.

За да проверите как ще работят условията за маршрутизиране в зависимост от параметрите на заявката, в проверката на маршрута е предоставена функционалността „Показване“.

Етапът „Уведомяване“ може да действа като отделен етап (мрежова диаграма на процеса).

Тоест, когато преминете към този етап, системата ще може да генерира отделно предупреждение за потребителя.

Съответно, етапът „Уведомяване“ може да бъде включен в диаграмата на мрежата на процеса.

За да конфигурирате съдържанието на предупреждението, трябва да конфигурирате шаблона за предупреждение:

Освен това системата осигуряваавтоматичен генериране на сигнали във връзка с настъпване на различни събития. Ето списък на предоставените категории събития:

По този начин, например, можете да конфигурирате генерирането на предупреждения, когато при преминаване към всеки от етапите на одобрение автоматично ще се генерират предупреждения за това.

Тези. одобряващият винаги ще получава известия, ще вижда кои етапи трябва да съгласува в момента и ще може да завърши одобрението директно от дневника „Моите задачи и сигнали“.

За да активирате генерирането на предупреждения за събития,трябва да отидете в раздела „Процеси и одобрения/Настройки за предупреждения“ и добавете този запис:

И накрая След като шаблонът за процеса на одобрение е напълно конфигуриран, трябва да посочите този шаблон в правилата за отчитане.В нашия пример, В наредбата „Определяне и контролиране на DDS граници“ се изисква да се създаде матрица от органи за одобряване на копия на отчети - като се посочи шаблон за процеса на одобрение в нея.

За документа Искане за операция посочете шаблона на процеса „Процес на одобрение на заявки за плащане“.

3.3 Съгласуване на заявките за маршрута

Като част от задачата, която решаваме, ще създадем заявка за плащане и ще я изпратим за одобрение.

Нека попълним документа Заявление за операция с типа „Разплащания на BDDS (разходи) с контрагенти“.

За да проверим контрола на лимитите, ще посочим в заявлението сума, по-голяма от предвидената в лимитите.

Когато се опитаме да публикуваме документ, ще получим съобщение за превишаване на лимита.

Нека коригираме тази ситуация, като формираме правилно приложението.Ще посочим източника на лимитите (документ за бюджетна резервация) и ще посочим наличната сума.

Да попълним контрагента и договора;Нека отидем в раздела „Контрол на ограниченията“.

Ще видим какво е текущото лимитно салдо (като се вземе предвид текущата операция) и какъв лимит е бил планиран.

Нека да прегледаме документа и да видим, че документът получава статус „В процес на одобрение“

Щракнете върху бутона „Прогрес на одобрението“, за да отворите маршрута и да видите етапа, на който се намира приложението в момента.

Текущият етап е маркиран в синьо.

Сега нека да видим как програмата прилага механизма за генериране на предупреждения и какви възможности предоставя на съгласуващия.

Да отидем в раздела „Процеси и одобрения/Моите задачи и предупреждения“.

Виждаме, че в системата се генерират предупреждения.Сигналите се генерират както по категории събития, така и по преход към отделни етапи на процеса.

Без да напуска регистъра на известията, одобряващият може да одобри етапа, да прехвърли етапа на заместника и да назначи допълнителни одобряващи.

За допълнителен контрол върху приложенията програмата предоставя възможност за конфигуриране на забрана/разрешение на плащания за специално определени анализатори.

В секцията „Планиране и контрол/Разрешения и забрани за плащания“ ще направим (например) следния запис.

Когато се опитаме да подадем такова заявление за одобрение, получаваме следното съобщение

Това означава, че въпреки че приложението преминава контрола на ограниченията, то не преминава директивата за контрол на плащанията.

Нека деактивираме въведената преди това директива и да изпратим приложението за одобрение.

Щракнете върху бутона „Одобряване на документа“, за да продължите към одобрението на текущия етап.

Нека въведем визата (обяснение) и щракнете върху „Съгласен съм“.

Да предположим, че на следващия етап на одобрение касиерът е видял, че целта на плащането не е попълнена в заявлението и е сметнал за необходимо да върне заявлението на изпълнителя (така че той да попълни всички полета,както би трябвало да бъде). За тези цели е предвиден бутон „Отхвърляне“.

Програмата предоставя и следните полезни функции по отношение на преминаването на маршрута за одобрение:

• 
  Отхвърлете заявлението за предишната стъпка на одобрение;
• 
  Изпратете заявлението за одобрение на допълнителни одобряващи (т.е., ако е необходимо, можете да добавите одобряващи към текущия маршрут и да пренасочите приложението към тях).

3.4 Работа с платежния календар.

Така че в момента 2 искания за плащане са на етап „координиране“ с касиера.

Основната задача на касиера е да контролира възможността за плащане.Тоест, за да не възникне например парична разлика (трябва да прецените каква сума е планирана в текущите сметки към момента на плащането).Също така в В тези 2 приложения не са дефинирани разплащателните сметки (от които ще се плаща).

Като цяло касиерът трябва да балансира платежната позиция (да определи платежната сметка и да следи датата на плащане за парични пропуски).И ако се окаже, че плащането за планирания момент не е достатъчно, тогава касиерът трябва или да измести датата на планираното плащане, или да вземе предвид (допълнително да планира) плащането c за прием, или отложи кандидатстването поради невъзможност за плащане (премести го в стоп списъка). Всички тези функции, както и функцията за разделяне едно приложение на няколко (за да се раздели една сума на няколко) и функцията за преместване на пари в брой между сметки - всичко това ще бъде взето предвид при работа с платежния календар по-късно.

Важно е да споменем и още една функционалност за работа с платежния календар, а именно възможността за запазване на различни „опции за развитие на събитията“.

Тоест касиерът може да моделира например ситуация № 1 на „допълнително планиране“ на очакваното постъпване на парични средстваот клиента и анализирайте и запазете този „сценарий“ от събития (тази версия на платежния календар). След това симулирайте ситуация № 2, когато очакваното получаване на d/s не се случи, но е необходимо да се затвори недостигът на d/s° С чрез движение d/° С от друга разплащателна сметка и частично изместване на датите за плащане. Като цяло ще бъде възможно да се сравнят двата сценария и да се избере по-изгодният.

Функционалността на платежния календар в UH предоставя богати възможности за касиера; нека разгледаме всичко това с примери.

Въпреки това, преди да започнете да работите с платежния календар, трябва да изпълните следните стъпки.

Конфигурирайте редица параметри за платежния календар:

• 
  Хоризонти на формиране на календара (брой дни);
• 
  Да се ​​вземат под внимание или не (1 или 0, или например - 0,5 - тогава „вземаме предвид половината“) документи за кандидатстване (включително неодобрени, такива, които са в процес на одобрение) при формиране на платежния календар .
  • 
    Тези. Ако зададете „1“ навсякъде за неодобрени приложения, тогава всички неодобрени (но в процес на одобрение) приложения ще бъдат взети предвид изцяло от програмата при генериране на платежния календар.

    С други думи, това означава, че програмата ще разгледа планираните дати за плащане и суми за тези приложения и съответно ще включи тези данни в календара и ще изчисли планираните парични наличности по разплащателни сметки, като вземе предвид очакваните плащания за такива заявления.

Регистрирамтекущи начални салда:

За да изчислите платежния календар в програмата, трябва да регистрирате първоначалните салда на д/к. Задължително така че началните салда да се регистрират в набирателен регистър “Каса”. В същото време реалното движение (пристигане/заминаване) г/° С също трябва да бъдат отразени в този регистър.

Регистрация на начални салдасе осъществява чрез съставянето на документ „Коригиране на начални салда”.при което, Този документ, разбира се, може да се попълва автоматично, според счетоводните данни. счетоводство (м .е по разплащателна сметка 51).

И така, нека регистрираме първоначалните салда на 2 юридически лица. лица и техните банкови сметки.

Реалните постъпления/разписки на д/с ще бъдат отразени в програмата чрез документите „Отразяване на действителни бюджетни данни”.Такива документи ще бъдат генерирани в програмата автоматично в момента на отразяване на факта. документи за отчитане на движението d/c (постъпления/отписвания г/ c по сметка). Това поведение на системата се определя от тези настройки:

Да преминем към раздела "Планиране и контрол/Плащателен календар".

Нека зададем следните ключови параметри:

• Ще създадем групи: по организация и банкова сметка;
• Ще зададем периода: от текущата дата до края на текущия месец;

Избор по организация: ние ще създадем чрез консолидиране на група MSC Energy +

Ние ще генерираме платежен календар (календарът ще се генерира от текущата дата до края на месеца).

Ще видим, че календарът включва първоначалните салда за две текущи сметки,планирани движения за d/c разходи (плащане на две молби за плащане, дължими утре).

Червеният цвят означава, че имаме парична разлика в сметката „Банкова сметка не е дефинирана“. Това се случи, защото платежната сметка не беше дефинирана в приложенията.

• Нека променим броя на избраните поръчки. Да настроим сметката - VTB 24.

• 
  В резултат на това получаваме, че „Банковата сметка не е дефинирана“ е изключена от календара, но към 05/09 има парична разлика в размер на 4000. Въпросът е, че планираните разходи (34 хиляди рубли в общо за 2 приложения) надвишават баланса d/c по сметката.

• Използвайки функцията „отлагане/отложено“, можете да отложите приложение за известно време (да го преместите в стоп списъка). След това го върнете от отложено.

• Получената версия на календара може да бъде запазена. И след това отворете, сравнете и изберете по-благоприятни сценарии за развитие на ситуацията по отношение на трафика.

• Можете да изместите датата на плащане за заявления до определена крайна дата

Можете също така да покриете паричните пропуски, например чрез парични преводи в рамките на групата(от акаунт на една организация към акаунт на друга организация). За целта е предвидено приложение за вътрешно движение.

Можете бързо да планирате както разходите, така и очакваните приходи. Това могат да бъдат транзакции като постъпления от клиенти и очаквани постъпления от други транзакции.

3.5 Формиране на регистър на плащанията.

След приключване на одобрението на заявленията, те могат да бъдат включени в регистъра на плащанията.

В нашия пример главният счетоводител създава и поддържа регистъра в статус „Одобрен“.

Платежните нареждания се генерират чрез бутона „Генериране на платежни нареждания“.

3.6 Отразяване на фактите, разпространение на изявления на бюджетиращите анализатори.

След изтегляне от клиентската банка при дебитиране на разплащателната сметка, документите ще бъдат заредени в програмата"Дебити от разплащателна сметка."

Моля, имайте предвид, че при дебитиране от текущата сметка, програмата автоматично генерира документи „Отразяване на действителни данни“.

Целта на документите „Отразяване на фактически данни“ е да отразят факта на разходите в регистрите за бюджетиране и касов поток.Действително потребление d/c също се взема предвид в платежния календар за определяне на текущите салда° С.

След зареждане на банково извлечение, програмата може да се използва за разпространението му между планиращите анализатори.

Такъв алгоритъм може да бъде конфигуриран в обработката на „Разпределение на банкови извлечения между планиращи анализатори“.Попълването ще се извършва въз основа на аналитични шаблони. Програмата може да създава много шаблони за попълване.

Ето пример за шаблон, който задава аналитична стойност „Проект“. Шаблонът (правилото) работи за всякакви организации и изпълнители. В същото време се проверява съдържанието на целта на плащането.Тоест, ако полето „Цел на плащането“ съдържа комбинация от думите „Основно споразумение“, тогава в този случай анализът „Основен проект“ е инсталиран в полето на проекта.

По този начин можете да организирате други алгоритми за разпознаване на целта на плащане и съответно попълване на полетата tsfo , DDS статия, анализатори т.н.

Подсистемата е подходяща за тези, които

• Уморен съм от хора, които тичат из офисите от време на време, само в името на подписите;
• необходимо е да видите: кой, кога и как е одобрил този или онзи обект в базата данни 1C;
• необходимо е да се намали времето за одобрение (на споразумение, заявление за харчене на пари или нещо друго).

Програмата ви позволява да координирате всякакви документи и справочници в базата данни 1C. Координацията става последователно, т.е. Първо се съгласява първият рецензент, ако е съгласен, след това следващият и т.н.

Съществуват следните състояния:

• "Неодобрен"
• „В процес на одобрение“,
• "Одобрен"
• "Отменен"
• „Върнато за преразглеждане.“

При създаване на задачи за рецензенти не се посочва конкретен потребител, а се попълва само Адресираща роля + Адресиращ отдел. Да приемем, че трябва да се съгласим

След това ще се създаде задачата за Счетоводителя от Счетоводството. И конкретните потребители трябва да бъдат посочени в регистъра „Адресен регистър“.

Така задачата за одобрение ще се вижда от двама потребители наведнъж и всеки от тях може да изпълни задачата. Това е особено полезно, когато един служител излезе на почивка и трябва да посочите потребител, който да го замести. В този случай е достатъчно да добавите нов запис към адресния регистър и всички стари и всички нови задачи веднага ще бъдат видими за новия потребител.

Предимства

• напълно отворен код;
• независима конфигурация;
• независимо от BSP (за нестандартни конфигурации това е важно);
• може да се вгради във всяка конфигурация (вижте списъка с тествани конфигурации по-долу);
• работи в тънък клиент (работи и в обикновено приложение);
• За да настроите нова координация, не е необходимо програмиране, всичко се извършва в режим на изпълнение;
• много проста настройка на ново споразумение, трябва да преминете само през 4 стъпки и споразумението може да се използва;
• можете да настроите одобрения за всяка директория и всеки документ в базата данни 1c;
• изпращане на известия по имейл;
• значително намаляване на времето за одобрение, а често времето за одобрение се намалява значително;
• винаги е ясно кой трябва да одобри, както и кой и кога го е одобрил;
• възможността да се забрани изпълнението на документ, докато не бъде договорено;
• възможността да се забрани използването на обект от база данни, докато не бъде договорено;
• лесен за интегриране в други бизнес процеси в 1C;
• няма нужда от отделна база данни, в която да става координацията, всичко се случва в една база данни.

Видео

• Създаване на ново споразумение

• преглед на съответстващата подсистема

• как да интегрирате подсистема в стандартна конфигурация

• Как да настроите акаунт за изпращане на известия:

Подсистемата е изцяло внедрена в управлявани форми и работи в тънък клиент.

Примери за използване на подсистемата

Пример 1

Заявлението за разход на средства трябва да бъде одобрено, преди да може да бъде изпълнено. В този случай е необходим следният координационен маршрут:

• винаги координирайте с „Мениджър покупки“;
• ако сумата на заявлението е повече от 10 000, тогава се съгласувайте с търговския директор;
• ако сумата на заявлението е повече от 50 000, тогава се съгласувайте с финансовия директор;
• ако сумата на заявлението е повече от 100 000, тогава се съгласете с генералния директор.

Пример 2

Всеки потребител може да създава договори в системата; необходимо е да настроите одобрение на договора по следния маршрут:

• ако контрагентът/партньорът принадлежи към групата доставчици, тогава е необходимо да се съгласува със „Счетоводителя на доставчика“;
• ако контрагентът/партньорът принадлежи към групата на купувачите, тогава е необходимо да се съгласува с „Счетоводителя на купувачите“;
• винаги се консултирайте с адвокат;
• ако договорът е в конвенционални единици, тогава съгласувайте с търговския директор;

Често задавани въпроси (FAQ)

Въпрос:Възможно ли е вграждане на подсистема в нестандартна конфигурация?

Отговор:Да, можете, за това е необходимо крайната конфигурация да съдържа следното:

• Directory.Users;
• Параметър на сесията "CurrentUser";
• Конфигурацията трябва да има или свойството „Управлявано приложение“, или свойството „Управлявани и редовни приложения“, тъй като всички форми се контролират.

Въпрос:Възможно ли е да извикате формуляра „Статуси на одобрение“ директно от елемент на директория или документ?

Отговор:да, можеш. Ако използвате управлявани формуляри, трябва да:

• отидете на конфигуратора;
• намерете общата команда „bpsStatusConcordance“;
• щракнете с десния бутон и изберете свойство;
• в свойството „Тип параметър на командата“ посочете съставния тип данни и изберете желания обект.

Ако използвате обикновени формуляри и стандартна конфигурация, трябва да:

• вземете от доставката обработката „bpsStatusCoordination.epf“;
• Кликнете върху „Услуга - Допълнителни печатни форми и обработка - Печатни форми“
• щракнете върху добавяне, след това посочете обработка;
• добавете към раздела на таблицата онези обекти, за които трябва да се извика тази обработка;
• Сега бутонът за печат ще може да извика тази обработка.

Ако използвате обикновени форми и конфигурацията не е стандартна, тогава трябва ръчно да вмъкнете код във всяка форма на елемент на директория/документ; Form.epf” (от доставката).

Въпрос:Възможно ли е да се посочи статуса, да кажем „Платено“, за документ?

Отговор:Да, можете, за целта са ви необходими:

• отидете в директорията „Статуси на обекти“ и добавете елемент с името „Платено“, запишете го и го затворете;
• след това отворете обработката на „Статуси на одобрение“, щракнете върху бутона „Задаване на статус“ и изберете статуса „Платено“.

Роли

• (BPS) Потребител- трябва да се посочи за всички потребители;
• (BPS) Редактиране на адресния регистър- необходимо е право за редактиране на регистър „Адресен регистър”;
• (BPS) Редактиране на документи, регистрация на статус на обект- правото е необходимо, за да можете ръчно да посочите състоянието на 1c обект;
• (BPS) Пълни права- достъп до всички обекти на подсистемата за координация, а също така е необходим за настройка на координацията.

Какво се случва автоматично

• известията се изпращат по график (веднъж на минута);

Какво се планира да се добави в бъдеще, ако подсистемата е успешна

• възможност за пренасочване на задачата за одобрение към друг рецензент;
• възможност за персонализиране на шаблон за генериране на текста на обяснение, което се посочва при стартиране на одобрение и изпращане на известия по имейл (например: включете валутата на документа, ръководителя, сумата и т.н. в обяснението);
• възможност за съгласие чрез писмо за отговор, без да влизате в 1C;
• така че адресната единица да се избира автоматично от хедъра на документа/указателя, а не да е „твърдо” посочена в предмета на одобрение;
• възможността за използване на подсистемата „Координация“ в конфигурации, където е разрешено ограничаване на достъпа на ниво запис;
• забрана за използване на елемент от указател до съгласуване.

Разработката се извършва на Bitbucket (засега затворено хранилище), основната функционалност на подсистемата се покрива от тестове с помощта на xUnitFor1c().

Тестване на прехвърлянето към стандартни конфигурации

Тестването е извършено на платформата: 8.3.8.1652

Конфигурация

Резултати от тестовете

Бизнес процесът е стабилна последователност от действия на служителите на една организация. Автоматизирането на такива последователности рационализира работата и значително ускорява изпълнението на крайната задача.

В програмата 1C: Документен поток 8 са внедрени следните видове бизнес процеси:

• Съображение:документът се предава на ръководителя за преглед и с негова резолюция се връща на автора на документа.
• Екзекуция:документът се предава за изпълнение на всички потребители в списъка и на контрольора за спазване на изпълнителната дисциплина. Един от ползвателите може да бъде определен за отговорен изпълнител.
• Координация:документите, приложени към такъв бизнес процес, се изпращат за одобрение на посочените респонденти и след това се връщат на автора на бизнес процеса за преглед на резултатите от одобрението или изпращане за повторно одобрение.
• Изявление:документът отива при отговорното лице за одобрение и се връща на автора на документа за преглед на резултата от одобрението.
• Регистрация:документът отива при секретаря, за да му бъде присвоен регистрационен номер, заверен с печата на организацията и изпратен до кореспондента.
• Въведение:Използвайки този бизнес процес, необходимият документ се изпраща до всички потребители в списъка за преглед.
• Поръчка:Използвайки този бизнес процес, можете да издавате инструкции на служителите и да проверявате тяхното изпълнение.

Всеки бизнес процес, докато преминава през етапи, създава задачи, адресирани до конкретни потребители. Например бизнес процес Поръчкапърво ще създаде задача Изпълнете заданиетоза изпълнителя и след като изпълнителят запише изпълнението на тази задача, задачата Проверете напредъказа инициатора на бизнес процеса.

Можете да възлагате задачи не само на конкретни изпълнители, но и на роли. Така например може да бъде изпратен документ за одобрение на ролята Директор, а програмата автоматично ще прехвърли съответната задача на този, който в момента изпълнява тази роля - самият директор или неговият заместник. Задачата може да бъде адресирана и до потребители, идентифицирани чрез следните автозамествания:

• Всички мениджъри на автора на бизнес процеса,
• Всички подчинени на автора на бизнес процеса,
• Непосредственият ръководител на автора на документа,
• Всички мениджъри на автора на документа.

Съставът на ролите е уникален за всяко предприятие или институция и може да се променя и конфигурира без спиране на системата. Когато изпълнителят на ролята се промени, задачите се прехвърлят автоматично към работния плот на новия изпълнител.

Потребителят може по всяко време да види списъка с възложените му задачи в списъка Моите задачи. Списъкът се зарежда автоматично при стартиране на програмата.

Освен това потребителят може да получи известие за изпълнение на задача по имейл.

За всеки бизнес процес програмата създава карта, от която потребителят може да извика визуална блок-схема на бизнес процеса. Изпълнението на етапите на бизнес процеса ще бъде отразено в блок-схемата. С негова помощ създателят на бизнес процес може по всяко време да разбере на какъв етап е неговото изпълнение и кои служители вече са изпълнили задачата си и кои не. По-долу има карта и блок-схема на типичен бизнес процес Координация.

Въз основа на този документ може да бъде създаден нов бизнес процес, свързан с конкретен документ. За всеки тип бизнес процес програмата предоставя отделен списък, например списък с одобрения:

За всеки тип бизнес процес можете да конфигурирате шаблон, който ще се използва при създаване на нови бизнес процеси. Шаблон за бизнес процес съдържа информация като:

• маршрутизиране,
• срокове,
• важност,
• Име,
• описание и други.

Например шаблон за бизнес процес Хармонизиране на договораможе да изглежда така:

В картата на типа документ можете да посочите списък с шаблони за бизнес процеси, свързани с него. Този списък ще се използва автоматично при създаване на нови бизнес процеси, базирани на документи от този тип. В дадения пример видът на входящия документ е споразумениесвързани с шаблона по-горе Хармонизиране на договораи два други шаблона - Одобрение на споразумението (просто)И Регистрация на споразумението:

При създаване на бизнес процес въз основа на всеки входящ документ от вида споразумениепотребителят ще може да избере подходящ шаблон от този списък.

Каним ви да разгледате един пример. Специалистът по маркетинг или планиране на компанията определя цените на стоките. В тази компания ценовата политика се одобрява от ръководството, а процесът на приемане на цените включва редица взаимосвързани действия. Как да установя процеса на ценообразуване в стандартна програма?

Вече говорихме за бизнес процесите в стандартно решение 1C: Управление на търговията 8, като функционалност, която помага да се комбинират редица операции в строго определена последователност от действия. В резултат на това работата на служителите на компанията се основава на ясно дефиниран алгоритъм.

Предварително конфигуриране на процеса на договаряне на цената

• Установяване на процеса на договаряне на цените в програмата 1C: Управление на търговията 8започва с активиране на съответната опция.
• След това трябва да проверите „Профилите за достъп“ на всички потребители, които участват в ценообразуването. В нашия пример цените се определят от маркетолог, след което се одобряват от ръководството, така че проверяваме: в неговия профил ролята „Задаване на цени на артикули без одобрение“ трябва да бъде деактивирана.
• Накрая трябва да добавите потребители, които одобряват крайните цени. За да направите това, трябва да отидете в директорията „Роли и изпълнители на бизнес процеси“ и да зададете на отговорния мениджър ролята „Координиране на определянето на цените на артикулите“.

Как работи бизнес процесът за договаряне на цена?

Принципът на действие на механизма за договаряне на цените с използване на бизнес процеси е следният. Нашият маркетолог, след като проучи ситуацията на пазара на продажби, стига до извода, че цените могат да бъдат повишени за някои артикули от продуктовата гама. В стандартен разтвор 1C: Управление на търговията 8цените се определят с помощта на документа „Определяне на цени на артикули“. Въпреки това, за да влязат в сила ценовите промени, този документ трябва да има статус „Одобрен“. Нашият маркетолог няма право да променя статуса на документа, така че за да промени цените, той ще трябва да използва бизнес процеса „Одобрение на цената“.

Да приемем, че управителят вярва, че цените могат да бъдат повишени още повече.

• В този случай той трябва да попълни полето „Резултат от изпълнение на задачата“, като направи своите предложения и щракнете върху бутона „Не е съгласен“.
• В този случай търговецът получава известие за взетото решение, в което може да се запознае с желанията на мениджъра.
• След това маркетологът кликва върху бутона „Запознат“ и завършва бизнес процеса. Сега маркетологът трябва да преразгледа цените в съответствие с предложенията на мениджъра и да създаде нов бизнес процес.
• Управителят още веднъж се запознава с променените цени и ги съгласува. В този случай документът „Определяне на цени на артикули“, създаден от маркетинг специалиста, получава статус „Съгласувано“ и се публикува в програмата.

Управителят държи всичко под контрол

В раздела „Одобрение“ мениджърът може да проследи целия процес на одобрение на конкретен документ за промени в цената.

Цялата работа по всеки такъв документ се съхранява в програмата на едно място, което дава възможност да се оцени ефективността на работата на маркетолога.

В заключение бих искал да отбележа, че използването на бизнес процеса „Споразумение за цените“ ви позволява да рационализирате процеса на ценообразуване, като подобрите качеството на управление на персонала и контрола върху него.