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

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

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

Видимо я выразился неточно. Имел ввиду что настроенные фильтры и методы для справочника на странице редактирования не применяются в детали, хотя методы расчетов по числовым полям, настроенные на странице, работают в детали.

Страница карточки (например, AccountPageV2) и детали (например, AccountRelationshipDetailV2) задаются в разных схемах со своей логикой и связаны с разными объектами и их таблицами в базе.

Александр, в моем случае это OpportunityProductPageV2 и OpportunityProductDetailV2. 

Это не меняет сути.

Подскажите, пожалуйста, Александр, где прописана логика расчета стоимости продукта для детали OpportunityProductDetailV2. Я в схеме детали не вижу методов расчета суммы. Они есть в схеме страницы детали OpportunityProductPageV2. Я считал что метод расчета колонок берется из страницы детали.

Вероятно, во встроенном БП объекта OpportunityProductInterest в скрипте CalckOpportunityAmountAfterSevedScriptTask и вызываемой им функции CalckOpportunityAmount.

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

recalculateAmount: function() {
	var price = this.get("Price");
	var quantity = this.get("Quantity");
	if (price && quantity) {
		this.set("Amount", price * quantity);
	}
}

К тому же бизнес-правила на странице добавления продукта работают и для детали. Почему же тогда на справочные поля (при редактировании детали в реестре) не накладываются фильтры, которые указаны в OpportunityProductPageV2? 

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

Подскажите, пожалуйста, Александр, как настроить фильтр для справочного поля в детали редактируемой в реестре. 

См. тут.

Добрый день!

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

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

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

Зверев Александр,

Предлагаете его переопределить?

Когда Вы меняете в мастере, оно и так переопределяется, в пакете Custom создаётся CasePageV2 с новым порядком полей. Но, видимо, в одном из пакетов выше по иерархии описано иначе и конфликтует.

Здравствуйте! На Маркетплейс есть решение которое определяет запущенные процессы по объекту - https://marketplace.terrasoft.ru/app/processes-log-view-bpmonline

Добрый день!

Публикацию нужно делать каждого объекта.

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

Сидоров Александр В.,

Спасибо!

CallPageV2 — это не метод, а страница карточки звонка. Если Вы собираетесь открывать её в БП и знаете Id записи об этом звонке, то для этого предусмотрен элемент процесса «Открыть страницу редактирования» с возможностью передать туда параметры. С его же помощью можно и открыть карточку новой записи с нужными значениями в полях.

Элемент «Открыть страницу редактирования» содержит список возможных для редактирования страниц, среди которых нет карточки звонка. Это происходит потому, что страница звонка является системным объектом, и в результате не проходит фильтрацию данного элемента. То есть, на уровне БД в таблице SysModule у объекта с Code = «Call» колонка IsSystem = true. Если убрать признак IsSystem, то страница звонка начнет отображаться в списке страниц элемента, однако не рекомендуется этого делать, так как это может быть чревато другими непредсказуемыми последствиями в системе.

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

На конференции TechPoint рассказывали о мобильной программе для спортивных ставок, которая плохо работала на демонстрации у заказчика, как оказалось, из-за плохой связи в его офисе. В Вашем случае может тоже быть что угодно. Больше подробностей можно узнать из отчёта по кнопке «Отправить лог». Если подозреваете, что дело в обновлении, попробуйте и на старом, и на новом.

Зверев Александр,

Спасибо, Александр.

Со связью проблем нет - тестировалось на офисном wifi в том числе.

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

Как выяснилось, проблемы возникают не на всех устройствах.

Есть подозрение, что проблема в количестве контрагентов, которое в последние дни подскочило при подключении новых филиалов к системе.

Смотрите логи на стороне мобильного и на стороне сайта (не IIS).

Поля расширяют через CSS, если оно оказывается шире экрана, включается прокрутка. Возможно, и с контейнером реестра так получится.

А вообще, горизонтальная прокрутка — зло и не нужна.

Эта логика реализована в схеме «Список обращений пользователя портала» (UserCasesListModule) в функции initConfig: function(). Вероятно, проще действительно не трогать базовый, а скопировать, сделать в отдельной схеме свой аналог с нужным фильтром, а затем в дизайнере  панели итогов «Главная страница портала» указать его в свойствах блока.

Зверев Александр,

благодарю за ответ

Либо старое значение сохранилось в кэше и поможет перезапуск и чистка Redis, либо оно всё же есть в настройках и нужно найти и изменить. Сам по себе планировщик не работает с почтой, он всего лишь запускает определённый БП SyncImapMail.

Возможно, ранее настраивали под другим пользователем, у кого прописан старый адрес; как удалить его триггер, см. тут.

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