Your comments

Добавлены ещё диаграммы ER_Продажи.pdfER_Комм.Предл.pdfER_Договоры.pdf.


Ждём Ваших замечаний о том, чего не хватает.

Клонирование записей производится только для атрибутов самой карточки. Т.е. связанные объекты при этом не копируются.

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

Далее откроется диалог выбора - искать или просмотреть все 
Например быстро найти то, что требуется:

Далее отразится перечень найденных объектов (соответствующих условию поиска):
Необходимо выбрать тот, который требовалось.



К сожалению в настоящий момент массовое копирование списка не доступно, т.е. копирование возможно только для одной выделенной записи. Но для трудоемких по заполнению операций (где необходимо указывать боле 10-ти параметров) такой метод будет экономить время оператора ввода.

В ближайшее время мы рассмотрим возможные варианты по массовому копированию списков операций и сообщим здесь о резльтатах.

Начали структурировать мысли в архитектуру

ER_Контрагенты.pdf 


Зеленым цветом отмечены объекты в которых присутствуют/считаются деньги

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


Процедуру легко представить: Ведем сделку -> формируем КП -> модифицируем КП и ещё несколько раз формируем -> Выставляем счет на предоплату -> Планируем поступления по счету -> Выставляем счет на остаток или как там по согласованному графику.


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

Ещё возник вопрос: нужная ли спецификация продуктов в Договоре?

Ведь по существу ключевым объектом является Продажа - в ней и продукты и задачи и статусы и пр... А Договор - это сервисный объект. Если для него вводить работу с поступлениями, продуктами - логика станет ветвиться и заметно усложнится.


Предлагаем оставить в Договоре: Задачи, Файлы, Комментарии и Напоминания. Всё остальное концентрировать в Продажах - так и понятнее пользователям будет, и аналитики разные проще строить.

Согласен. Такое разделение - важно и в целом статусом Продукта в продаже эта задача вполне решается.

Таблица - супер!!! 

Я вот сперва хотел собрать планируемый функционал, а потом уже сравнивать с Комплексной конфигурацией... Но оказалось, что это полезно уже на этом этапе. 

Спасибо!


Теперь по сути:

  1. Несколько юр.лиц по одному контрагенту считаю объективной необходимостью, которая просто диктуется суровыми реалиями бизнеса. И тут "подкрученные гайки" в вид таких ограничений нечего хорошего не принесут...
  2. Напоминания по всем объектам системы - штука полезная и нужная. На основной функционал она не влияет, являясь лишь сервисным дополнением. Считаю, что не имеет смысла её исключать. Равно как и e-mail уведомления участников задач - зачем их в этом ограничивать?
  3. Коммерческие предложения, как самостоятельный объект - все же крайне полезен и удобен. Тем более, что универсального объекта "Документы" тут не будет.
  4. Списание (отгрузка товара) вообще-то не планировалась, т.к. нет склада и нет никакого движения ТМЦ. Давайте обсуждать в каком виде это требуется и каким объектом реализовывать?
  5. Касса-счет сама по себе все же должна быть, просто остатки по ней считать смысла нет, но видеть куда (какой р/с, кому в карман) оплатил клиент - пользователям желательно.
  6. Про мультивалютность - отсутствует уверенность: нужна она или нет... Полезно это ещё и для последующего "апгрейда" до комплексной конфы. Давайте обсуждать...
  7. Инструмент настройки интеграции с 1С - т.к. Конфигуратор убираем, то его не будет включено в поставку. Тут - согласен.
  8. Редактор VBS я бы оставил. Во-первых хоть какая-то гибкость должна присутствовать, во-вторых без архитектурных изменений (без Конфигуратора) за счет VBS можно только эргономику допиливать и слегка логику вычислений менять. Что с одной стороны не принципиально, а с другой - бывает крайне важно и полезно.
  9. CR - однозначно надо оставлять доступным для пользователей. СR+Word+Excel - это тот минимум, который позволит относительно жёсткую структуру адаптировать под реальность бизнеса и документооборота во внедряющей компании.
Ещё есть вопрос с логированием изменений (которое настраивается в Конфгураторе), получается, что его не будет? Останутся только системные события и всё?

Добавили в планируемую архитектуру "Коммерческие предложения" самостоятельным объектом в рамках Продажи. Это позволит формировать несколько КП (по разным условиям) в одной сделке, контролировать статусы каждого КП, выбирать принятое клиентом и на его основе уже формировать счета на оплату и планировать поступления.

Запланировали импорт из банк-клиентов в формате 1С, а так же преднастроенные шаблоны импорта из Excel для основных объектов системы.


Будет два типа воронок продаж (по вошедшим за период и по всем изменениям в периоде). Это принципиально разные виды анализа, но важные и очень показательные. 

Просто сохраните нужную Вам картинку (из представленных ниже) с именем splash.jpg и скопируйте себе в папку, куда установлен КлиК (обычно это: "c:\Program Files\Клиент-Коммуникатор 7.0" ).


"КлиК: Комплексная конфигурация"


"КлиК: Полиграфия и сувенирный бизнес"


"КлиК: BTL-агентство"