+5
Завершен

Нужна ли "первичка" в "КлиК-CRM: Продажи" ?

Отдел внедрений (бизнес-аналитик) 9 лет назад обновлен 9 лет назад 14
Уважаемые члены сообщества просьба высказать Ваше мнение по вопросу - нужны ли в конфигурации "КлиК-CRM: Продажи" такие первичные документы, как Акт, Накладная, Счет-фактура?

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

Если Вы за это расширение функционала - голосуйте "вверх", если против - соответственно "вниз". Спасибо.

Ответ

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

При этом фиксируем ограничения:
1. Расчет сальдо "дебиторки" в базовой конфигурации на основании актов и накладных не будет.
2. Никакого движения по складам - не будет.
3. Анализ продаж останется по "счетам на оплату".

Предложения ещё рассматриваются - ждём от вас конструктивных идей.
Бланки первички безусловный плюс. В MS NAV весь пакет первички формируется из одного документа - заявка на продажу. У них нет заморочек на отдельные реестры счетов, накладных, актов, счетов-фактур. Я за бланки, но не за усложнение структуры данных. Можно вполне обойтись статусом счета и по нему включить нумератор накладных и счетов-фактур. В ситуации: на 1 счет 2 пакета документов: дублируйте в системе счет. Дешево и сердито. Или внедряемый проект)))
Галина, спасибо за комментарий.


Мы изначально были ориентированы на такой подход. Т.е. сущность одна, но бланков на ней несколько (акты уже и сейчас можно печатать). Тут же вопрос стоит в том - нужны ли именно реестры?


Но в целом идею Вашу понял. Учли.

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

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

Про "создать прошлым годом" задумаемся - если есть потребность, то должно быть и решение.
считаю, что нужны, это будет плюсом.

тем более если интеграция с 1С есть

И в идеале возможность отключить этот функционал для тех, кому не нужно, чтобы не было загромождения интенфейса
Такой подход подходит (извините за калабур) только для простых продаж: Один счет, один акт или накладная, одна счет-фактура. В реальности вплошь я рядом случаи кода по одному счету несколько актов или накладных.
Предствьте себе случай продажа товаров когда отгрузка происходит не одним документом а несколькими накладными.
Или случай когда работы закрываются актами по этапам. Техподдержка, внедрение, например.
Мариель, я должен признать, что не совсем корректно сформулировал свой вопрос. В его текущей постановке - все предлагаемые функции будут нужны. Мы прекрасно осознаем варианты бизнес-процессов, когда кол-во документов как счетов, так и закрывающих не равны друг другу в обе стороны. Это было учтено ещё в самых ранних версиях УМБ. 

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

Compare_Complex&Sales.xlsx - это ссылка на сравнение УБ и УП, где мы постарались выдержать баланс. но первые контакты с партнерами и клиентами показали, что закрывающие документы востребованы по причине того, что менеджера необходимо оставлять работать в одной программе на полном цикле взаимодействия с клиентом. От того и возник данный опрос - только нам такое попадается или это повсеместная практика, требующая доработки в решении?
В целом, если рассматривать процесс продаж, как завершенный, то CRM должна давать возможность, как начать сделку, так ее и завершить, тем более, что все остальные функции достаточно серьезно проработаны. В основном в  коробках данные функции реализованы именно как реестры. По поводу нумерации, не во всех компаниях нумерация формируется с начала года, есть такие у которых нумерация непрерывная, поэтому возможно нужен выбор. Также разделение по типам документов "акт", "накладная", "счет-фактура" даст возможность работать в CRM как с товарами, так и услугами при различных системах налогообложения.
Для этого продукта, именно как для "коробки" мы готовы рассматривать только вариант реализации как простых реестров без дополнительных расчетов на их основе. Т.е. сальдо по клиенту в классической бухшалтерском смысле в базовой конфигурации "КлиК-CRM: Продажи" мы делать не планируем. Для таких развернутых аналитик и показателей есть "Клик: Комлексная конфигурация" (Управление бизнесом).

Что касается нумерации - то совершенно понятно, что она должна быть настраиваемая и более того, сейчас и в "Продажах" и в "Комплексной" есть вынесенные на уровень пользователя возможности настраивать нумерацию по разным правилам. Это уже работающий мощный и гибкий инструмент.
Если предприятие уже ведет учет в 1С, реестры придется синхронизировать? кто будет первично вносить информацию и куда: в КлиК или в 1С?
А вот "это" можно назвать основной причиной, почему мы хотели избежать реализации первички в "КлиК-CRM: Продажи" - при внедрении возникает масса сопутствующих задач по интеграции, которые простой для освоения продукт заметно усложняют.
С другой стороны если структуры данных "КлиК-CRM: Продажи" и "КлиК-CRM: УБ" будут сильно отличаться, то на реализацию задачи по переходу из УП на УБ можно поставить крест.
Возмите пример когда в УБ, для расчета каких то данных использовались скрипты и хранимые вычисления или тд.  Если УБ не передать все данные нелбходимые для расчета, то бог знает, что там получится.
1. Определение "сильно отличаться" для структур данных разных продуктов не совсем корректно. Они в любом случае сильно отличаются и любой переход с УП на Комплексную - это непростая скриптовая задача. Она может быть решена за счет того, что УП (на Prof версия) является жесткой архитектурной конструкцией и потому все правила переноса могут быть детерминированы.


2. В наших планах развивать линейку "новых" решений на базе УП. Это будут не перегруженные функционалом продукты для  определенных видов деятельности: Услуги, Проекты, Товары и т.п. Мы не будем больше делать глобальных нагромождений вида "всё-в-одном", а пойдем по пути максимального приближения к упрощенной реальности, но с быстрым и простым внедрением и без необходимости отрезать "лишнее". Есть уверенность, что такая кастомизация позволит стать в разы клиентоориентированнее и предлагать уже не просто возможности платформы, а значительно более подходящие и узнаваемые клиентами решения. Правда работы для этого предстоит оч-чень и оч-чень много, но - это есть наша стратегическая задача на 2012-й год. 

На рассмотрении
В настоящее время склоняемся к тому, что бы сделать Акты, Счета-фактуры и Накладные в виде простых реестров с типовым набором функция (файлы, напоминания, задачи, комментарии, копирование, создание на основании и т.п.). Ну и естественно печатные формы для этих документов по требованиям ФЗ РФ.

При этом фиксируем ограничения:
1. Расчет сальдо "дебиторки" в базовой конфигурации на основании актов и накладных не будет.
2. Никакого движения по складам - не будет.
3. Анализ продаж останется по "счетам на оплату".

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

При этом фиксируем ограничения:
1. Расчет сальдо "дебиторки" в базовой конфигурации на основании актов и накладных не будет.
2. Никакого движения по складам - не будет.
3. Анализ продаж останется по "счетам на оплату".

Предложения ещё рассматриваются - ждём от вас конструктивных идей.
Ответ
Завершен
В настоящее время склоняемся к тому, что бы сделать Акты, Счета-фактуры и Накладные в виде простых реестров с типовым набором функция (файлы, напоминания, задачи, комментарии, копирование, создание на основании и т.п.). Ну и естественно печатные формы для этих документов по требованиям ФЗ РФ.

При этом фиксируем ограничения:
1. Расчет сальдо "дебиторки" в базовой конфигурации на основании актов и накладных не будет.
2. Никакого движения по складам - не будет.
3. Анализ продаж останется по "счетам на оплату".

Предложения ещё рассматриваются - ждём от вас конструктивных идей.

Сервис поддержки клиентов работает на платформе UserEcho