В любой компании в ходе хозяйственной деятельности формируется ряд документов: договора, акты, накладные, счета фактуру и пр., наличие оригиналов которых важно при проведении аудиторских и налоговых проверок.
Типичная проблема при работе с договорами/накладными/актами и пр. — отсутствие оригинала подписанного контрагентом. Нередко он отправляется контрагенту, но обратно не возвращается. Отслеживать ведение бумажного документооборота вручную — довольно затруднительно. Кроме того при ручном отслеживании отсутствует взаимозаменяемость, поскольку записи понятны только тому, кто их ведет. Как только человек уходит в отпуск, передать дела заместителю непросто.
Второй момент — при проведении аудита аудиторам необходимо предодставлять копии документов, для чего их приходится сканировать. Это отнимает немало времени, когда нужно подготовить большой объем «макулатуры» единовременно.
Пока бумажный документооборот не отмер, необходимо обеспечить грамотное ведение бумажного документооборота, чтобы минимизировать риски отсутствия заверенных контрагентом копий. Из-за этого могут возникнуть проблемы с налоговой.
Если в компании используется Redmine для постановки задач, то для организации учета документов и проведения согласования внутри компании нет смысла внедрять какое-то дополнительное программное обеспечение.
Зоопарк систем огорчает, усложняя стоимость сопровождения. Да и лицензии стоят для некоторых систем немало, приличная стоимость внедрения. Если система масштабная, то потребуется обучение персонала. В общем, затраты могут бытьсущественными и «овчинка не стоит выделки».
Redmine бесплатная система с легкой настройкой в большинстве случаев не требующей программирования. Для небольших компаний человек до 100 более чем достаточно. Хотя количество людей, несомненно, не основной критерий.
Роли
Если в организации есть офис-менеджер, то он первый получает корреспонденцию и задачу по сканированию документов и заполнению карточки документа логично поручить ему.
Если компания распределенная и корреспонденцию получают в разных офисах, а затем направляют в центральный для обработки, то целесообразно сканировать документы в каждом офисе перед отправкой бумажных копий, чтобы исключить риск потери. В комментариях (статусах) системы указывается, что документ отправлен в центральный офис.
В Redmine для обеспечения безопасности настраивается отдельная роль для тех сотрудников, которые будут иметь доступ к документам. Например, роль может быть названа: «Работа по документам ООО…»
Безопасность
Поскольку документы конфиденциальны, к обеспечению настроек безопасности нужно подойти с максимальной тщательностью.
- Заводится проект, доступ к которому будет выдан узкой группе участников. Например, «Документы ООО …»
- Создается группа объединяющая участников работающих над определенным типом документа в данной организации. Например, группа «Работа с документами ООО…».
- В группу добавляются участники и сопоставляются с ролью «Работа по документам ООО…» и проектом «Документы ООО …». В дальнейшем достаточно будет добавить сотрудника в эту группу, чтобы он получил необходимые доступы.
- Если доступ к определенным типам документов должен быть только у некоторых сотрудников — необходимо создать несколько групп.
- При создании настраиваемых полей (custom fields) доступ к этим полям дается для определенной роли. Это дополнительно обеспечивает безопасность данных, хотя и выглядит как чрезмерное ограничение, поскольку доступ к проекту уже ограничен определенным кругом участников.
Трекер
Для прохождения процесса согласования договора создаем трекер «Работа по докам ООО…». В трекере управляем доступностью полей для выбранного трекера. Если процесс обработки разных типов документов отличается, например, разные поля и пр. — создаем трекеры под каждый уникальный процесс обработки документа.
Статусы
Для удобства работы сотрудника обрабатываеющего документы, чтобы он не забывал, что сейчас с ним просходит, а также для обеспечения взаимозаменяемости сотрудников каждый этап работы должен размечаться соответствующими статусами.Нужно избегать избыточных статусов, поскольку это усложняет работу сотрудников. LTG — название компании. Естественно, можно задать название статусов более обще, например, вместо «Согласование в LTG» -> «Согласование в компании», однако в этом случае статус выглядит уже не так однозначно понятным и может приводить к замешательству, например, новых сотрудников. Система же должна быть максимально самодокументируемой, чтобы не нужно было лезть в толмуды документации, чтобы понять зачем нужен тот или иной параметр. В крайнем случае описание полей дается на hint к соответствующему полю. Примерные статусы:
- Новый.
- Согласование у нас.
- Согласование у контрагента.
- Подписание у нас.
- Скан отправлен контрагенту.
- Оригинал отправлен контрагенту.
- Скан получен нами.
- Оригинал отправленнам
- Оригинал получен нами.
- Закрыта.
- Отклонена.
В данном примере я задал максимально гибкое движение по статусам. Это не самый хороший вариант, поскольку добавляет вероятность ошибки. Однако в данном случае позволяет упростить процесс для различных стартовых точек.
Например, документ может быть формальным, либо не предполагающим изменений (с очень долгми согласованиями). Изначально подписан контрагентам и оригинал отправлен нам, но ещё не получен. В этом случае работа начинается со статуса «Оригинал отправлен нам». Офис-менеджер отслеживает подобные статусы по документам, поскольку: почта может не доставить документ, либо контрагент подумал, что отправил, а на самом деле документ завалялся у офис-менеджера и т.п.
Если оргинал был подготовлен у нас и направлен контрагенту без отправки скана, то процесс может начинаться со статуса «Оригинал отправлен контрагенту». Если же предварительно было согласование у нас, то статус будет «Согласование у нас» и меняются ответственные, при переходе на следующий этап. Естетственно, если нужно прописать перемещение по согласовантам, то количество статусов будет больше. например, «Согласование в юротделе», «Согласование в бухгалтерии» и т.п. Если согласование в юротделе только после согласования бухгалтерами, то переход со статусов будет жесткий, не допускающий перехода на «Согласование в юротделе» со статусов отличных от «Согласования в бухгалтерии», например.
Настраиваемые поля
Примерный список кастомных полей для работы с договорами в Redmine приведен ниже:
Остановлюсь на пояснении некоторых моментов. Важный момент логическое поле «Оригинал получен». По нему удобно будет фильтровать финальное состояние, когда от контрагента получены все документы. Если флаг снят, то нужно продолжать работу с контрагентом. Флаг можно автоматом проставлять скриптом при перемещении в статус «Оригинал получен от контрагента» и/или закрыто, но поскольку допускается мягкая работа по статусам, то здесь для подстраховки есть возможность вручную выставить флаг, когда работа завершена и мне лень было писать скрипт. 🙂
Что касается описания контрагента и адресов. В данном случае не правильно реализовано, поскольку, карточка контрагента должна быть отдельным справочником. В штатной конфигурации Redmine такого типа поля нет. Это только при установке плагина CRM: RedmineUP или EasyRedmine. У RedmineUp есть бесплатная версия плагина.
Однако, для того, чтобы хоть как-то упорядочить документооборот даже такого варианта будет более чем достаточно. Ctrl-C — Ctrl-V реквизитов из текста договора не займут много времени у офис-менеджера.
Поле «Организация» — это известное наименование юрлица. Например, у сети магазинов «Ситилинк» в каждом городе свое юрлицо. Но для упрощения поиска документа в «Организацию можно прописать, напрмиер, «Ситилинк НН».
Полагаю, остальные поля не требуют пояснения.
Присоединение документов
При готовности документов сканы присоединяют к карточке документа. Если с контрагентом есть договор и идут регулярные оплаты, для простоты нет смысла каждый раз заводить карточку на каждый вид документа (счет-фактуру, акут и накладную). Да, это нарушение классической парадигмы, когда на каждый документ создается отдельная карточка, заносится номер, дата и заполняются другие реквииты. С другой стороны при поиске достаточно ввести организацию, чтобы зайти в договор и увидеть все сканы документов, которые были с контрагентом.
Если нужно придерживаться классического подхода, тогда на каждый тип документа создается карточка, и к ней присоединяются только сканы относящиеся к ней, а в поле родительского документа прописывается ссылка на основной договор.
