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

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

Галина, спасибо за комментарий.

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

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

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

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

Роман, спасибо.

Проблема такая есть

считаю, что нужны, это будет плюсом.

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

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

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

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

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

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

Если предприятие уже ведет учет в 1С, реестры придется синхронизировать? кто будет первично вносить информацию и куда: в КлиК или в 1С?

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

С другой стороны если структуры данных "КлиК-CRM: Продажи" и "КлиК-CRM: УБ" будут сильно отличаться, то на реализацию задачи по переходу из УП на УБ можно поставить крест.
Возмите пример когда в УБ, для расчета каких то данных использовались скрипты и хранимые вычисления или тд.  Если УБ не передать все данные нелбходимые для расчета, то бог знает, что там получится.

1. Определение "сильно отличаться" для структур данных разных продуктов не совсем корректно. Они в любом случае сильно отличаются и любой переход с УП на Комплексную - это непростая скриптовая задача. Она может быть решена за счет того, что УП (на Prof версия) является жесткой архитектурной конструкцией и потому все правила переноса могут быть детерминированы.

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

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

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