Форум сервиса Планфикс

Доброго времени суток.
Есть задача:

1. Освободить руководителя производства от рутинных задач по составлению смет, выставлению счетов и актов.
2. Создать менеджерский отдел, который мог бы в режиме телефонного разговора просчитать заказ и предоставить хотя бы примерную стоимость изделия.
3. После согласования менеджером с клиентом цен\количества\ и прочих вопросов перенаправить согласованную заявку на производство.
4. На производстве печатник должен увидеть тех карту по новому заказу с необходимыми ему данными (Файл макета\размеры\количество\ постпечатные работы)

Я лично понимаю что система очень гибкая. Так же я понимаю что с помощью планфикса можно будет реализовать практически все "хотелки". Ткните пожалуйста в меня инструкцией, или типовым решением. Оно с одной стороны всё просто, а с другой не понятно что и где применять.
Типовые CRM системы не подходят из-за сложнейшего просчёта изделия. около сотни видов материала на котором печатаем, всегда разные размеры изделия, если изделие шириной больше 3,2метра то включается пост печатная обработка в виде проклейки, есть еще такие штуки как монтаж и многое другое.

Други, не оставьте в неведении. Я юноша смышлёный, вы просто покажите куда копать.
В приложении примерная схема взаимодействий.

Здравствуйте, Сергей!
Схема понятна, но сразу хочу расстроить одной штукой - делать именно расчеты на лету пока не получится, ждем функционала расчетных полей, который должен появиться в обозримом будущем (до конца года). Но если представить, что этот функционал уже есть (для простоты), то общий подход к настройке должен быть таким:

1. Определяем жизненный цикл заказа, от обращения клиента до последней стадии монтажа и расчетов и настраиваем его в виде набора статусов в соответствующем Процессе. Если есть несколько типов заказов, то делаем отдельные процессы для каждого типа.

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

2. Делаем шаблон задачи-заказа:
- добавляем нужные поля для исходных данных (для некоторых понадобится предварительное создание справочников, из которых будут выбираться данные)
- добавляем расчетные поля, которые оперируют данными, введенными в обычные поля, и выдают результаты по формулам (вот это как раз то, чего прямо сейчас пока нет)
- указываем в шаблоне Процесс, по которому живет эта задача-заказ

Повторяем все это для каждого типа задачи-заказа (если их несколько)

3. Думаем по поводу учета взаимоотношений с заказчиком по оплате и документам - возможно, стоит сразу настроить его в ПланФиксе при помощи Аналитик и Отчетов:
- делаем аналитики для внесения суммы, выставленной клиенту по заказу
- делаем аналитику для внесения прихода денег от клиента
- делаем отчет, который будет собирать данные из этих аналитик и выводить их в разбивке по заказам и в общем

В общем целом, на этом этапе уже можно запускать в пробную обкатку. Она выявит неудобства и нехватку каких-то моментов в настроенном процессе, их нужно будет по ходу донастраивать и добавлять. Сам по себе процесс выглядит так:
- звонит клиент и хочет получить просчет заказа
- менеджер создает задачу по нашему шаблону и вбивает в нее данные в ходе разговора
- система на лету выдает результат расчетов
- если клиент согласен, задача сохраняется и заказ начинает жить настроенной для него нами жизнью.

Пока нет расчетных полей и не получится в режиме телефонного разговора на лету вбивать данные в ПФ и сразу получать итоговый расчет - но настраивать саму систему для работы можно и сейчас, просто вынести сам момент расчета временно на Эксель, а в заказ вбивать не только исходные данные, но и итоговую сумму заказа, которая рассчитана за пределами ПФ. Работы по тому, чтобы настроить и приучить людей работать в системе все равно много, а сам расчет это не основное в этом процессе и может быть добавлено позже (ну это по моему мнению, конечно).

P.S. Я, конечно, рекомендую всем по возможности разбираться в настройках самостоятельно - там не так все сложно потом, только начать страшно, зато поддерживать и развивать систему можно будет самостоятельно. Но если появится необходимость, можем найти партнера, который настроит ПланФикс под ваши нужды за отдельные деньги, так что если что, ставьте задачу на Службу поддержки, организуем.



 

Спасибо огромное за ответ. Сейчас вдумчиво изучаю документацию по ПланФиксу, надеюсь настроить скелет самостоятельно.
Дело в том что мы уже год выбираем систему рассчёта, учёта и взаимодействия с клиентом. Попробовали много чего, на одну из систем даже лицензию приобрели. Но из-за того что практически все системы "не гибкие" и как правило заточены под простые продажи (есть коробка магнитофонов по цене такой-то, продаем клиенту одну штуку по такой-то цене) очень сложно их адаптировать под наши нужды. В итоге вернулись к ПланФиксу. Дмитрий, если помните вы мне в "Тостере" рекоммендовали ПФ.
Буду изучать, буду настраивать. Спасибо за развёрнутый ответ.

Всегда рад помочь, Сергей - если будут возникать вопросы по ходу настройки, пишите, продолжим тут или в Службе поддержки.

Пока нет расчетных полей

Мысль по-ходу.
Тут бы к Планфиксу прикрутить исходящий push-API (вроде Webhook в Telegram), чтобы система могла в нужный ей момент обращаться к внешнему серверу пользователя, предоставляя туда данные и забирая в ответ результат (в отличие от существующего входящего pull-API). Тогда специфическую математику любой сложности клиент мог бы реализовать у себя, удобным ему способом (благо, сейчас поднять какой-нибудь Python-серверочек это совсем не проблема), а с Планфиксом происходил бы только обмен данными полей. И никакой мороки со скриптами-плагинами (самый простой путь), которым нужно обеспечить соответствующую "песочницу", чтобы они системе не навредили. И овцы сыты, и волки целы.

Мысль интересная, но боюсь, что для обычного пользователя, который больше предприниматель, чем айтишник, этот инструмент оказался бы слишком сложным. А мы все же стараемся, чтобы система была доступна именно таким пользователям (хотя иногда нас и срывает в явно гиковские штуки :)).

Вторая мысль по-ходу

прикрутить исходящий push-API

есть POST в сценариях

чтобы система могла в нужный ей момент обращаться к внешнему серверу пользователя, предоставляя туда данные и забирая в ответ результат (в отличие от существующего входящего pull-API)

зачем плодить сервера, эту работу (по расчету) прекрасно выполнит Telegram Bot, проведя опрос клиента по всем пунктам и перипетиям заказа, а в ПФ придут структурированные данные в кастомных полях. Далее:
1. Запускается сценарий (на основе полученных данных из Telegram Bot) 
2. Коммерческое предложение уходит клиенту (с расчетами полученными из Telegram Bot)
3. При положительном решении клиента - создаются задачи подразделениям и службам (на основе данных из Telegram Bot)
4. Контроль выполнения задач (это уж выполнять Вам)

P.S. В данное время - выражение " Программирование функций и запуск сервера Telegram Bot  "  потеряло свою актуальность. Рабочего и продуктивного бота можно запустить за сутки без строчки кода, бесплатно* 

Добавлено спустя 1 час 2 минуты 55 секунд:
Посмотрите конструктор ботов http://flowxo.com Экспериментировал с пятью конструкторами ботов, по соотношению цена-эффективность-возможности, ему нет равных.

ЁКЛМН!!!
Я очень-очень-очень сильно извиняюсь за нижеследующий суровейший эмоциональный офтоп, но я только что написал длиннющий ответ к трём постам в этом обсуждении, а потом кликнул ссылку http://flowxo.com (давно здесь не писал, расслабился, понимаешь). И ПАРА ДЕСЯТКОВ СТРОК НАБРАННОГО ТЕКСТА ПОШЛА В ОДНО МЕСТО. Инструменты сохранения содержимого форм, которые работают везде, на этом форуме бессильны. Я об этом писал уже пару раз и в предложениях по форуму. Досадно и дико бесит. Нельзя так.

Добавлено спустя 36 минут 10 секунд:
Так-с... Соответствующий тикет в поддержку написал, теперь попробую восстановить мысли. =)

боюсь, что для обычного пользователя, который больше предприниматель, чем айтишник, этот инструмент оказался бы слишком сложным

Само собой для простых случаев хватит какого-то построителя выражений (вспомнился таковой из Access) и движка вычисления формул. Но для них нужно создавать объектное окружение и сами средства вычисления. И конца-края этой теме нет, в аспекте неограниченности хотелок клиентов. И это нормально. Потому очень уместен был бы путь масштабирования средств через интеграцию с внешними средствами.
В случая Сергея, как я понимаю, всё более чем серьёзно и вопрос выделения ресурсов на организацию мини-сервера для произвольной обработки внутренних данных (на любой удобной платформе) не является препятствием. Насколько живой отклик может дать предоставление именно исходящего push-API мы все можем видеть на примере ботов Telegram. При этом, заранее грамотно расставленные ограничения позволяют избежать нездоровой нагрузки на сервера системы (тот же bot-API Telegram в этом плане по-самурайски чёток и суров). И это даёт людям ту самую "удочку", а не вынуждает вас таскать им готовую "рыбу", ломая голову над её поголовьем, ассортиментом и весовыми характеристиками. =)

зачем плодить сервера, эту работу (по расчету) прекрасно выполнит Telegram Bot

Я говорю о сервере обработки данных (поучает XML/JSON, обрабатывает произвольным образом, возвращает XML/JSON). Хотя, буквальной обработкой данных тут не ограничится, конечно. Но самое главное — push-подход, в дополнение к pull-подходу в существующем API.
  

Простенького бота для расчетов наваял в конструкторе за 40 минут http://telegram.me/polygraphistbot

есть POST в сценариях

Да, можно сказать, что половина работы уже сделана. Ну, или треть, или четверть. :-) 
Но существующая реализация POST предназначена только для отправки данных. А тут нужен ещё соответствующий разбор возвращённых в ответ данных.
Конечно, можно это дело завернуть назад в Планфикс через API:
1) в POST сообщаем внешнему серверу, кроме прочего, идентификационные данные (к примеру, id задачи), чтобы было ясно, куда надо положить ответ;
2) внешний сервер обрабатывает данные, как ему удобно;
3) внешний сервер возвращает результат через обычный API (к примеру, через task.update). 
Так получается самопальное подобие push-API c внешней обработкой данных. На костылях, сложновато и неизящно, но вроде бы, вполне работоспособно. Главное отличие от полноценного push-API — полная асинхронность. Иногда это может быть и хорошо, но в случае сценария скорее будет неуместно — сценарий придётся разрывать, и запускать продолжение по триггеру, как я понимаю.

Как я решил бы подобную задачу в ПЛАНФИКС + Telegram Bot. 
1. Бот должен сделать (КАЧЕСТВЕННЫЙ, СТРУКТУРИРОВАННЫЙ) опрос http://telegram.me/polygraphistbot   (надо добавить регистрацию, полнофункционального бота за 40 минут не напишешь - не пинать, это набросок)
2. Данные из бота с расчетами ушли в ПФ  кастомными полями при условии согласия Заказчика с расчетом
3. Запускается сценарий №1 - Заказчику уходит отредактированное  коммерческое предложение или счет (задача №345)
4. При оплате счета (статус задачи № 345 изменился на оплачено)  запускается сценарий №2 - назначаются исполнитель -дизайнер (должен прикрепить макеты верстки)
5. Дизайнер отработал (статус задачи № 345 изменился на отдизайнерено) запускается сценарий №4 - уходит в производство - печатнику  - к нему пришли данные: 
- вид печати 
- материал печати
- размеры печати
- количество печати
- макет дизайн печати (вложенными файлами)
(Что- то мог пропустить из специфического)
6. Печатник отработал перевел статус в отпечатано. Опять при изменении статуса на отпечатано запускается сценарий №5 создающий при необходимости 2-3 подзадачи (или переводит в статус выполнено если все ниже выполнять не требуется):
- письмо заказчику о выполнении заказа
- новыя подзадача - монтажники (если они есть в кастомном поле от бота)
- доставка заказчику

Итоговый бот на этой платформе умеет отправлять email в структурированном виде на внешние адреса?

Добавлено спустя 1 час 57 минут 19 секунд:
Проверил - да отлично отправляет, ПланФикс умеет распознавать такие данные  и раскладывать по полям.

Теперь у меня есть Ваш ID Michael Goshka :-)
Да, по SMTP бот отправляет письмо с заданного ящика, в аккаунт ПФ в текстовом формате (Значение А: ххххххх, Значение Б: ххххххх, Значение С: хххххххх и т.д) только остается настроить "Правила для задач по почте". Хорошим моментом является неизменяемая структура письма - тем самым исключаются ошибки в кастомных полях (Телефон: Иван Петрович).
 

Сергей, добрый день.

Удалось настроить? У нас почти такое же производство, хотелось бы совет от Вас получить.

И тишина.
Есть какие-то подвижки? Очень интересно (сходное производство)
 

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

Не появился ещё?

Нет, пока не появился.

А я реализовал это все с помощью собственной аналитики "Продукт"
То есть сам заказ - это контейнер, а вот позиция в заказе - это прикрепленная аналитика. Ведь в одном заказе может быть несколько позиций, верно и каждая со своими параметрами.

Сначала я пошел по пути добавления полей к типу задач "Заказ", но уперся в то, что не могу добавить более одного изделия, скажем, для двух позиций в рамках одного заказа я должен создавать 2 задачи. С аналитиками это легко решается.

Дмитрий, правильно ли я сделал или можно было все-таки решить это описаннымвами способом.

Смогу ли я пользоваться вычисляемыми полями в задаче на основе прикрепленной аналитики определенного типа?

Александр, да, я считаю что использование аналитик в этом случае это самый правильный вариант.
Когда появятся вычисляемые поля, Вы сможете использовать суммарные данные из аналитик на уровне задачи при помощи полей типа "Итоги аналитик"