Обущар в ботушите ", докато писахме модула за управление на финансовите ресурси за вътрешната EDMS

Не е тайна, че в Homemont ние сами използваме EDMS на THESIS. Би било странно, ако имаме в ръка модерен и надежден инструмент за съхранение и одобряване на документи, да използваме нещо друго. Не е изненадващо, че за всяка доста голяма компания понякога стандартната функционалност на EDMS не е достатъчна. В тази статия ще ви разкажем как е създаден допълнителен модул към нашата вътрешна EDMS THESIS - модул за управление на финансови ресурси или просто модул за финансови приложения, както го наричаме. И в същото време ще се възползваме от възможността и ще покажем малко как се осъществява изпълнението на проекта на системата на примера на една организация.

Начало: Предпроектно проучване за управление на финансовите ресурси

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

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

Въз основа на това автоматизацията на управлението на финансовите ресурси преследва следната цел: да автоматизира процесите на получаване на пари, договаряне на безкасови плащания и отчет за изразходване на получените средства, със 100% изключване на работния процес на хартия на всички етапи.

За тази цел беше решено да се въведе нов модул „Finzayavki“ в корпоративния EDMS TEZIS. Внедряването на модула трябваше да осигури възможно най-простия случай на употреба, изискващ минимално обучение на крайните потребители.

За постигането на тази цел са необходими следните задачи:

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

Фаза втора: функционална спецификация за управление на финансовите ресурси

На този етап нашите специалисти разработват функционална спецификация за бъдещата система за управление на документи. Той включва описание на бизнес процесите, които трябва да бъдат автоматизирани, дизайн на формуляри и системни изисквания. Функционалната спецификация се съгласува с ключовите представители на клиента (в нашия случай с търговския и изпълнителния директор). Резултатът е пълна картина на функционалността на бъдещата система.
Функционалната спецификация на новия модул за управление на финансовите ресурси, в съответствие с посочените цели, включва описание на следната нова функционалност:

Четири типа потребители работят с новия модул: инициатор, одобряващ, одобряващ и счетоводител. Ролите на инициатора, координатора и одобряващия вече са в системата (те са стандартни), но трябваше да се добави последната.

Директории.

За да работят с финансови поръчки, бяха необходими две нови директории: „Видове поръчки“ и „Дневни издръжки“. Първият съдържа, както подсказва името, видовете приложения с техните имена и задължителни прикачени файлове на сканираното приложение. Втората съдържа фиксирани дневни ставки за дневни, издавани на служители, които отиват в командировки (а ние имаме много от тях). Данните от директориите като правило се избират при създаването на карта за приложение - по този начин е по-бързо и лесно.

Карта за кандидатстване.

Всъщност го направихме на базата на обикновена карта за документи с изрязан раздел „Офис“ (не трябва да прехвърляме финансови заявления в архива). Но картите за кандидатстване бяха разделени на четири типа:
• Възстановяване на разходи: кандидатът вече разполага с всички необходими документи за потвърждение на разходите, или не се изисква потвърждение;
• За сметка на доклада: кандидатът се нуждае от пари сега, но все още няма документи, потвърждаващи разходите;
• Плащане от карта: средствата трябва да бъдат преведени на служител в непарична форма;
• Плащане от сметка: заявителят прилага фактура и се плаща;
• Предварителен доклад: всъщност докладът на кандидата до компанията за това колко и защо е похарчен.

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