Артём Колисниченко: Сегодня в рубрике «Рассказ от первого лица» вновь Алексей Дёмин. Он занимается веб-разработкой, интернет-маркетингом, а так же проработкой бизнес-процессов и интеграцией ПланФикса для малого бизнеса. В этой публикации Алексей расскажет о способах автоматизации ведения договоров на абонентское обслуживание. Передаю ему слово.
Алексей Дёмин:
Скорее всего я не ошибусь, если предположу, что многие из пользователей ПланФикса занимаются оказанием услуг, и среди них зачастую встречаются периодические: заказчик платит с определенной периодичностью за работу, которая выполняется тоже с некоторой периодичностью. При этом могут быть сложные варианты. Например, периодичность выставления счетов и периодичность выполнения работ могут не совпадать.
Наверняка все, кто пользуется ПланФиксом, уже нашли своё решение этой задачи, я расскажу свой опыт.
Всё перечисленное ниже может пригодиться для автоматизации разного рода биллингов, учёта аутсорсинговых услуг (обслуживание компьютеров, оказание бухгалтерских или юридических услуг), а также для компаний, предоставляющих товары и услуги по подписке.
У нас тоже было своё решение, и о нем я расскажу чуть позже, хотя оно настолько простое и очевидное, что не стоит отдельного упоминания. Хотя у нас немного клиентов и нам этого решения хватает, наверное, я переделаю часть договоров.
Однажды фирма, которая ведет нашу бухгалтерию, тоже решила усовершенствовать учет договоров и занялась поиском более удобного инструмента, чем Excel. Я предложил ПланФикс. Думал, что мне не составит труда всё настроить, ведь у нас уже что-то подобное работает. Но оказалось, что в их случае вариативность гораздо выше в виду того, что:
- они обслуживают гораздо больше клиентов,
- оказывают больше видов услуг,
- применяют больше разных вариантов периодичности оказания услуг.
Но отступать было уже поздно, и я стал искать решения.
Поиск решений – процесс, несомненно, увлекательный и напоминает мне эволюционное развитие. Решения развиваются от простого к сложному. Иногда вырастает что-то гигантское, которое не приживается и вымирает, а что-то простое и примитивное, наоборот чувствует себя прекрасно и перетекает из реализации в реализацию.
В случае с учетом периодических договоров, мне приходит на ум аналогия с развитием приматов. Появившиеся в голове идеи могли жить параллельно, как разные виды HOMO, некоторые перестали существовать, так же как вымерли денисовцы. Некоторые влились в другие решения, как неандертальцы растворились в сапиенсах. Некоторые мысли (в основном пришедшие ночью, перед засыпанием) забылись, как несомненно существовавшие, но не оставившие следов, и пока неизвестные нам виды приматов.
Поэтому я решил построить изложение от простого к сложному, и сначала рассказать про самый первый, приходящий на ум, способ организации учёта повторяющихся услуг в ПланФиксе.
Периодические задачи или кто бы мог подумать?
Это как раз тот метод, который применяли мы в своей работе. Он очень незамысловатый, и всё, что вам надо знать, уже есть в документации. Идея простая и работающая, как автомат Калашникова: для каждого клиента и договора создается шаблон повторяющейся задачи, в которой указываются контрагент, необходимые аналитики (например, Услуги), добавляются шаблоны документов для счетов и актов, ну и параметры повторения.
Плюсы этого способа в том, что можно указывать пользовательские условия для каждого договора, например, вы можете прописать различные услуги в каждой задаче, поставить различных исполнителей для каждого клиента.
Однако, я вижу проблему в избыточном дублировании: если у вас много договоров, то поддержка их в актуальном состоянии сильно усложняется. А если вы выставляете счета раз в год, а услуги оказываете раз в месяц, то шаблонов повторяющихся задач для договора надо сделать два.
Больше об этом способе мне сказать нечего, всё есть в документации. Если всё же остались вопросы – пишите в комментариях.
Способы, основанные на шаблонах задач и сценариях
Дальше пойдёт целый подвид способов. В их основе лежит шаблон задачи, в который добавлено поле Дата следующего срабатывания и сценарий. Он создаёт новую задачу при наступлении даты из этого поля и устанавливает в новой задаче дату следующего срабатывания. Способы этого вида похожи друг на друга, но каждый имеет свою специфику.
Отмечу основные моменты для всех вариаций данного типа.
Для реализации нескольких периодов нужно создать несколько сценариев и каждому из них как-то дать понять, на сколько увеличивать следующую дату. Для проверки разных периодов в сценарии можно использовать, например, поле типа список и в это поле добавить значения «Ежемесячно», «Ежеквартально», «Ежегодно».
По клику картинка отроется в большем размере и новом окне.
Так же можно создать отдельный шаблон задачи для каждого периода, но этот способ мне не понравился.
Ещё важный момент в том, что при создании задачи по определенному шаблону можно не просто выбрать шаблон из списка, а создавать новую задачу на основании текущей, и даже с подзадачами.
Это даёт возможность кастомизировать каждый счёт или работы по клиенту. Например, если у вас все услуги и условия договора для разных клиентов не очень отличаются, то вы можете прописать их в шаблоне задачи и использовать конкретный шаблон при создании задачи сценарием.
Однако, может случиться, что вы оказываете различные услуги и по разной цене, тогда вы можете прописать их не в шаблоне, а в задаче (вплоть до пунктов чек-листа), и сказать сценарию, чтобы он создавал задачу, используя в качестве шаблона текущую задачу.
Приведу пару вариантов, как можно использовать связку шаблон/сценарий.
Шаблон задачи, повторяемый сценарием
Общий алгоритм таков: вы создаете первую задачу по шаблону вручную, прописываете дату следующего срабатывания. В зависимости от ваших процессов отрабатываете её, выполняете или завершаете (главное не удалять, т.к. цепочка прервётся). А при наступлении даты следующего выполнения запустится сценарий, который создаст новую задачу по этому шаблону и проставит в Дату следующего выполнения +1 месяц, например.
Это идеальный способ, если у вас много клиентов, небольшая вариативность оказываемых услуг и периодичности их оказания.
При выполнении текущей задачи, создавать задачу на следующий период
Суть в заголовке: когда сотрудник выполняет текущую задачу, срабатывает сценарий, который создает новую задачу.
который создает новую задачу.
Этот вариант отличается тем, что задача будет создана заранее и в ней можно не указывать дату следующего срабатывания, а указать, например, даты планируемого начала или откладывать созданную задачу на 1 месяц от Даты активации текущей задачи.
Подход немного противоречит концепции периодичности создания задач, да и если ваши сотрудники не выполняют задачи, то новая создаваться не будет. Однако, это решение может пригодиться, если вы оказываете услуги периодично, но не каждый месяц.
Например, у бухгалтерской фирмы бывает так, что клиент иногда сдаёт налоговые отчёты самостоятельно, а иногда обращается к ним. В этом случае выставление счетов каждый квартал не совсем оправдано. Лучше, если клиент отказался от услуг в этом периоде, переместить задачу в статус Отложенная до следующего периода. Это позволит не забыть про него и напомнить о себе в следующий отчёт. И если он подтвердит подготовку отчёта, выполнить задачу, инициировав при этом создание задачи на новый период.
Способ с действиями, без дублирования задачи
Суть этого способа – вести учёт работ в одной задаче и сценарием создавать вместо задач действия к определенной задаче. Такой способ тоже можно обыграть, но я не придумал, чем он лучше способов с отдельной задачей, да и к тому же если выставлять счета, то аналитика с услугами будет суммироваться.
Если фантазировать, то наверное его можно использовать при выставлении счетов ежегодно, но при проведении работ, например, ежемесячно. Т.е. создавать задачу на выставление счёта, используя один из способов, описанных выше, а другим сценарием ежемесячно добавлять комментарий и/или чек-лист в эту задачу, уведомляя об этом исполнителей.
Примечание: Я думал, что этот способ – аналог денисовского человека. Я его придумал, когда писал этот текст. Никак не реализовывал и не проверял. Думал, что он мне не пригодится. Но теперь, всё же я дам ему шанс и переделаю повторяющиеся задачи для клиентов на хостинг оплатой за год.
Заключение
Уверен, это не все способы реализации договоров абонентского обслуживания, однако их можно использовать сами по себе или как строительные блоки для решения более сложных прикладных задач. Рад, если кому-то пригодится.
По старой инфлюенсерской традиции: ставьте лайки (ПланФиксу), подписывайтесь на канал (ПланФикса), заходите в инстаграм (у ПланФикса его нет, приходите ко мне).
Алексей Дёмин
Артём Колисниченко: Спасибо Алексей за предложенные варианты автоматизации. Думаю, эта информация будет кому-то обязательна полезна, особенно новичкам ПланФикса. И в завершение мне остаётся только напомнить: подписывайтесь на наши социальные сети (Facebook, ВКонтакте, Telegram, Twitter и YouTube-канал), чтобы не пропустить актуальные новости и новинки.
Алексей, спасибо. Отличная статья.
На одном проекте используем “надзадачу-договор”. И подзадачи – счета.
Первую подзадачу-счет делает сотрудник вручную и заполняет аналитику-задачи. После первой оплаты в задаче выставляется оплаченный период от него считается дата следующей оплаты.
При этом счет с признаком оплаты остается в статусе Выполненная.
В зависимости от периодичности оплаты (месяц, 2, квартал и т.п.) за несколько дней до даты очередной оплаты срабатывает сценарий который:
– создает копию подзадачи-счет (копия для того чтобы скопировались аналитики задачи, увы другого способа взять в новую задачи аналитики – нет);
– очищает новой задаче-счет те поля которые должны иметь другие значения для этого счета (период оплаты, дата следующей оплаты и т.п.);
– заполняет поля периода на основе данных полей периода из счета-основания;
– в новой задаче-счет ставит надзадачу задачу-договор (надзадача текущего счета) договор;
– завершает текущую задачу-счет
При создании новой задачи-счет сценариями:
– вычисляется дата следующей оплаты;
– в зависимости от режима установленного в задаче выполняется либо только формирование файла счета в поле либо и формирование и автоотправка контактам Клиента (спец поле для указания списка контактов).
Таким образом в самом договоре можно сделать поле типа сумма подзадач, в котором считать все оплаченные счета или настроит отчет по задаче-договор, который покажет все оплаченные подчиненные задачи-счета.
Илья, интересное решение. Я что-то подобное делаю сейчас для нашей бухгалтерии, но на базе проектов, а не головной задачи.
И да, к сожалению немного не хватает возможностей для действий с аналитикой в сценариях и отчётах.
“— завершает текущую задачу-счет”
А зачем держать задачу-счет в статусе “Выполненная” всё это время?
Есть версия от авторитетного товарища, что для задач в неактивном статусе в частности в статусе “завершенная” не сработает сценарий по дате задачи. Я правда не тестировал.
Также поддержание задачи в активном статусе может соответствовать жизненному циклу, акт выставляется в дату завершения (хотя некоторые компании предпочитают выставлять акт в дату оплаты, но не все бухгалтеры такие акты принимают: “мы оплатили месяц, вот когда он кончится тогда и пришлете акт”. А вдруг ваш сервис не будет работать, тога мы потребуем уменьшение стоимости работ/оказанных услуг.
Точно, точно. Тогда аргументированно.
Во всей этой истории есть два громадных минуса.
1. Отсутствие интеграции с 1С и/или с ЭДО.
2. Предоплата за услуги, которые могут меняться в течении месяца (при этом информация об изменениях может поступать по иным каналам).
Например. Есть услуга аренды бубликов с подневной тарификацией.
В начале месяца было 5 бубликов. Счёт выставили на предоплату на 5 бубликов. В середине месяца добавили еще бублик. Итого, закрывающие документы нужно выставить на 5,5 бублика, а счёт выставить на 6,5 бубликов (в следующем периоде ожидается 6 бубликов, так как 5+1=6, плюс доплатить за 0,5 бублика за уже прошедший период).
И вот как это сделать … пожалуй никак.
А в чем проблема по п.. 1? интегрировать ПФ и 1С, выставление счета автоматически передавать в 1С и там будет сформирован документ “счет на оплату”. При отражении в 1С поступления денег по документу-счету, через API или просто на адрес задачи-счет отправить статус “оплачено”.
На стороне “1С” трудозатрат не более 3 часов (если квалифицированный программист.
По п. 2. А можете привести пример системы где это как то автоматически делается без участия человека. Как система сама “завангует” цифры факта? Обычно логику абонентки используют, когда есть фикс, по схеме “плати и бери”, не успел выбрать оговоренную сумму, то какое нам дело до этого. Ваша тема уже немного о другом, но думаю что и для вашего примера можно проработать логику и по ней настроить, например фиксировать факт и корректировать счет с учетом переноса, части суммы.
Интеграция с 1с возможна, но это отдельная история.
По второму пункту, я только описал принципы и дал пару примеров. Под реальный бизнес процесс можно придумывать конкретную реализацию. Возможно, что-то не получится. Как я и говорил: при высокой вариативности нужно придумывать разные способы. При описанном вами кейсе нельзя обойтись без человеческого фактора, поэтому можно автоматизировать создание задач, а заполнение аналитик оставить людям.