CRM 2.0.7.1 - замечания и ошибки
Внимание! Данный форум является модерируемым.
Для получения к нему доступа необходимо зарегистрироваться или авторизоваться на сайте.
Доступ к форуму партнерам «1C-Рарус» по дистрибуции предоставляется на сайте
rarus-soft.ru
Читают тему
2. при попытке сохранить харакретистику номенклатуры получаем ошибку - неоднозначное имя характеристики
Прикрепленные файлы
1 - проверила на релизе, вся информация об адресе отображается в списке. Можно скрин с карточкой Клиента и списком клиентов, где не отображаются адреса.
2- спасибо за сообщение, поставила разработчикам задачу на исправление.
Прикрепленные файлы
Действительно, не заметил, что был изменен порядок вкладок, а КИ у партнера и контактного лица оказалась одинаковой.
P.S. Как по мне, то как-то нелогично вышло. Понятно, что можно поменять местами вкладки за счет настройки формы...
Прикрепленные файлы
Тем более что появилась панель с большими кнопками и список КИ самого клиента не так уже нужен. пользователю проще и удобнее нажать по большой кнопке и сразу выполнить конкретное действие (позвонить, создать письмо и т.п.) чем всматриваться в список КИ, вставить на строку и потом жать кнопочку.
При необходимости уточнить конкретный вид КИ для выбранного действия будет выведено спец. дерево, в которое попадут сразу же и Контакты контактных лиц. А также, что очень удобно для писем/sms, можно будет в этом дереве выбрать сразу нескольких получателей/адресов.
Еще одна проблема - при создании задачи из бизнес-процесса не заполняется клиент, что неудобно, т.к. при просмотре списка задач быстрый предпросмотр не позволяет увидеть клиента и нужно заходить в саму задачу, чтобы увидеть с кем предстоит общаться.
Если же нажимать кнопку "К исполнению", тогда клиент заполняется.
При этом, в случае "БП-шной" задачи форма оличается от "ручной".
Прикрепленные файлы
Спасибо за сообщение. Поставила задачу разработчикам-изменения будут внесены в след. релиз.
Спасибо. Если будет возможность внести небольшие корректировки в конфиуграцию, прошу сообщить где и что нужно поменять чтобы мы могли обновить на нашей рабочей CRM.
Еще обнаружена проблема
при создании исходящего электронного письма и заполнении его из шаблона писем с вложениями (т.е. повторный выбор шаблона) происходит дополнение списка вложений без вопросов и контроля их наличия в письме.
Не критично, но при ручной работе пользователь может ошибочно выбрать не тот шаблон и будут отправлены лишние вложения .
Прикрепленные файлы
при создании исходящего электронного письма и заполнении его из шаблона писем с вложениями (т.е. повторный выбор шаблона) происходит дополнение списка вложений без вопросов и контроля их наличия в письме.
Прикрепленные файлы
Это уже исправлено, изменения будут в релизе 2.0.7.2
2. В предыдущем релизе в персональных настройках пользователе при указании в поле основная организационно правовая форма ООО, при заполнении новой карточки клиента, после заполнения поля наименование, поле полное наименование заполнялось автоматически, теперь только в ручную.
3. Реализована функция "Передача дел другому ответственному"?
2. В предыдущем релизе в персональных настройках пользователе при указании в поле основная организационно правовая форма ООО, при заполнении новой карточки клиента, после заполнения поля наименование, поле полное наименование заполнялось автоматически, теперь только в ручную.
Спасибо за сообщение - это ошибка. Она уже исправлена. Для самостоятельного исправления нужно сделать следующее:
- Открыть модуль формы "CRM_ФормаЭлемента" справочника "Партнеры.
- перейти в процедуру "НаименованиеПриИзменении"
Вынести указанный код из условия в самый конец процедуры, (перед "КонецПроцедуры")
3. Реализована функция "Передача дел другому ответственному"?
Прикрепленные файлы
1. Ограничение к доступу клиентов по уровню доступа, 2а клиента например Иванов Иван Иванович и компания юридическое лицо с лицом указанным карточке клиента с той же Фамилией Именем и Отчеством, уровень доступа у клиента разный, ни как не пересекаются, и если сотрудник с одним из уровней доступа в поисковой строке вводи запрос Иванов, то ему выходит сообщение что у него не достаточно прав, это актуальная проблема, потому что среди большого количества клиентов с не рабочей полосой прокрутки искать клиента не удобно, время трудо затрат увеличивается!!! Об этом уже писали.
У меня все отрабатывает правильно -без ошибки. Рассказываю как проверяла. Дала администратору Уровень доступа-Москва, менеджеру по продажам-Санкт-Петербург. Создала юр. лицо с уровнем доступа Москва, и абсолютно идентичное по наименованию физ. лицо с уровнем доступа Санкт-Петербург. Захожу в Предприятие под менеджером, открываю список клиентов, в поисковую строку ввожу наименование, находится клиент физ.лицо(какое и нужно было по уровню доступа) -ошибки никакой нет. Прилагаю ниже права менеджера по продажам.
Прикрепленные файлы
Ошибка при исполнении запроса набора данных
по причине:
{(57, 2)}: Таблица не найдена "КурсКратностьВалютыУУ"
<<?>>КурсКратностьВалютыУУ КАК КурсКратностьВалютыУУ
Прикрепленные файлы
Передала ошибку разработчикам-будут разбираться, а пока вариант один-не использовать отчет с такой настройкой, а пользоваться стандартной.
CRM при получении почты не контролирует идентификаторы сообщений.
С другими конфигурациями - нетиповая УТ 10.3, ИТИЛ - таких проблем не было, сработал контроль по идентификаторам сообщений.
Прикрепленные файлы
В настройках Проекта указано: «Редактировать дату выполнения»
Но в задаче не дает менять Дату начала. Причем при сохранении изменения ошибка не выдается, но при повторном открытии дата возвращается какая была.
Задача не принята к исполнению.
Прикрепленные файлы
CRM при получении почты не контролирует идентификаторы сообщений.
Я не совсем понял, какого рода сбой произошел...
Правильно ли я понимаю, что все эти письма пришли с ту же учетную запись, куда они уже приходили? Это не новая учетка с теми параметрами почтового ящика?
Поясните табличку, которую вы приложили - из какой базы и вообще откуда эти данные?
По поводу того что в CRM письма пришли заново после сбоя на сервере, а в 10.3 не пришли - сейчас поясню почему такое разное поведение:
В механизмах контроля идентификаторов в продуктах типа УТ 10.3 (УПП, КА, CRM 1.4 и т.д) и в продуктах на основе БСП - библиотеке стандартных подсистем (УТ11, УНФ, CRM 2.0) используются разные данные. В объекте "ИнтернетПочтовоеСообщение" (при помощи которого вот всех конфигурациях производится получение почты) есть 2 свойства: Идентификатор (Тип: Массив.
Содержит строку, идентифицирующую сообщение. Данный идентификатор сообщения уникален в пределах почтового ящика и остается неизменным на протяжении всего времени существования этого сообщения в почтовом ящике на сервере.) и ИдентификаторСообщения (Тип: Строка.
Уникальный идентификатор письма.)
И те и другие идентификаторы уникальны и не должны меняться со временем (подразумевается что они не меняются).
В УТ10.3 идентификаторы хранятся в разрезе данных поля "ИдентификаторСообщения", а в БСП/CRM2/УТ11 - в разрезе данных поля "Идентификатор".
Насколько я понимаю, в результате сбоя на почтовом сервере у всех писем почему то изменился "Идентификатор". но при этом остался неизменным "ИдентификаторСообщения". Почему - не могу конечно сказать, как будто бы все письма поднялись из некого бекапа, но при этом создались заново с генерацией данных поля "Идентификатор" и не измененным полем "ИдентификаторСообщения".
В результате в УТ 10.3 все ОК, потому что контроль отработал, а в CRM 2 система не смогла сопоставить данные измененных идентификаторов и загрузила все письма заново.
Почему разработчики БСП фирмы 1С приняли решение изменить схему хранения идентификаторов по сравнению с механизмами УТ10.3 - я конечно не могу сказать. мы не сами пишем этот механизм, а используем готовый из БСП, которым пользуются и все остальные разработчики типовых решений.
Мне кажется новый механизм более правильный, но сбой на почтовом сервере не возможно предугадать и обойти...
Это первая подобная ситуация, по другим продуктам (в том числе типовым от 1С) я тоже не видел упоминаний...
С другой стороны мы недавно анализировали обратную ситуацию - у одного клиента было все похожее, но как раз на 10.3. То есть там приходили от сервера дубли поля "ИдентификаторСообщения", а поля "Идентификатор" были уникальными.
Я отпишусь в 1С с описанием проблемы и попрошу комментариев. Может стоит сделать двойную проверку, по обоим идентификаторам...
Понять причину не смогли - ошибка была, "насобирала" множество документов .
Ощущение, что 9-го сентября начались проблемы, почта не очищалась на сервере, 11-го что-то "исправилось" и почта перестала дублироваться.
Похоже на то, что сервер не очищал почту, а CRM постоянно получал одни и те же письма без контроля идентификаторов.
По скриншоту видно - совпадают оба идентификатора писем и дата их создания (и тема, и текст письма и прочие параметры).
Прикрепленные файлы
Пока не видно дубликатов. Ждем...
Опять пошли дубли. Убрал настройку "Оставлять почту на сервере". Пока не видно дубликатов. Ждем...
Как я понял, задача у вас оставлять письма на сервере...
Или вам и не нужно оставлять письма и вы их ранее и не оставляли??
То есть вы хотите сказать, что тех 100т писем в принципе не было на сервере, а потом они вдруг откуда то опять появились?
Механизм хранит идентификаторы полученной почты только тогда, когда включен режим "Сохранять письма на сервере". Если он выключен - письма с сервера удаляются и считается что нет смысла хранить эти идентификаторы и засорять базу. И конечно в этом случае, если письма вдруг "волшебным" образом откуда то возникают, они считаются новыми.
Если ситуация была такая, то тоже понятно, почему в 10.3 письма не продублировались. В 10.3 идентификаторы хранятся не в регистре (как в БСП/УТ11/CRM 2), а в самом документе Электронное письмо. И поскольку они хранятся в письмах, то они есть в базе независимо от настройки "Сохранять письма на сервере". А поскольку вы не удаляли письма из базы, то идентификаторы были сопоставлены и почта повторно не загрузилась.
Но в этом подходе 10.3 есть большой минус - если вы удалите письмо, а оно осталось на сервере - то оно опять загрузится. Чтобы не возникало такой ситуации, и был сделал в БСП отдельный регистр, не зависящий от самого письмо - письмо можно удалить, но его идентификатор останется и дублей не будет. Эта ситуация более жизненна и распространена, чем сбой, который произошел у вашего провайдера почты....
Похоже на то, что сервер не очищал почту, а CRM постоянно получал одни и те же письма без контроля идентификаторов.
вот код работы с письмами, там все очень просто:
вот описание метода УдалитьСообщения()
УдалитьСообщения (DeleteMessages)
Синтаксис:
УдалитьСообщения(<МассивУдаляемыхДанных>)
Параметры:
<МассивУдаляемыхДанных> (обязательный)
Тип: Массив.
Массив, содержащий либо заголовки сообщений, либо серверные идентификаторы сообщений, которые необходимо удалить с сервера.
Для варианта работы с IMAP протоколом также допускается передать массив порядковых номеров сообщений (целые числа) в текущем почтовом ящике (ТекущийПочтовыйЯщик).
Описание:
Удаляет с сервера все сообщения, указанные либо объектами ИнтернетПочтовоеСообщение, либо идентификаторами, находящиеся в массиве, принимаемом в качестве параметра.