В следующем обновлении не будет final у классов. Но если кто-то каким-то образом унаследовался от классов с final, то после установки обновления могут быть проблемы, т.к. я поменял сигнатуру методов (добавил строгую типизацию, местами отрефакторил). Изменения больше косметические, но всё же.
Кроме этого, я добавил возможность указать своего наследника вместо стандартного класса для Document, Template, DataProviderManager, UserPermissions через событие. Переопределив Template, можно будет указать свой тип парсера (вынес в отдельный метод). Т.к. классов для парсера два, то у Docx я добавил метод
getXmlClassName, где можно будет указать своего наследника вместо DocxXml.
Некоторые просили дать возможность добавлять свои поля в стандартные провайдеры в crm. Теперь такая возможность появилась - с помощью события можно будет подсунуть своего наследника вместо стандартного провайдера. И он будет использован во всех местах, без внесения изменений в интерфейс. Ну и всегда есть вариант наследовать DataProviderManager и там делать что угодно с провайдерами и полями.
Для ArrayDataProvider и HashDataProvider добавил геттеры и сеттеры, больше не надо будет использовать рефлексию в onBeforeProcessDocument.
Ещё будет добавлена возможность использовать повторяющиеся блоки внутри ячеек таблицы, и в маркере повторяющегося блока можно будет вставить модификатор index, чтобы он размножился только один раз для определенного элемента списка (эти способы можно комбинировать).
В одном из следующих обновлений crm выйдет выбор моей компании и реквизитов в роботе создания документа, печать свойств заказа.
Документацию написал.
По срокам - вряд ли скоро, не раньше мая.
А планируется ли добавить парсер условий в сам шаблон документа? Чтобы можно было выбрать одно поле, либо другое в зависимости от значения третьего?
Хотелось бы отдельно отметить
Это великолепно
Однако жаль, что не используется простая дот-нотация и массивы, вместо адаптеров.
Грубо говоря не хватает php функции ucwords(), в б24 по дефолту все реквизиты при заполнении по ИНН грузятся из базы налоговой большими буквами. Соответсвенно везде в договорах контакты ИВАНОВ ИВАН ИВАНОВИЧ и адреса, тоже, как будто орешь на заказчика)
Хотелось бы хотя бы ФИО приводить к человеко-читаемому деловому виду. В дизайнере БП тоже сейчас такой функции нет. Есть ли надежда на генератор?
Числовые переменные в текст тоже не хватает, приходится дублировать все в отдельные поля с типом деньги.
Все числа как деньги, мне кажется, избыточно.
Услуга оказывается на 10 (десяти) рабочих местах. Это в принципе юридическая норма для однозначного толкования, ну плюс защита что никто нолик не подрисует.
Сейчас в текст можно только поле "деньги" переводить, поэтому во внедрениях приходится на каждое числовое поле создавать его денежный дубль (скрытый от юзера), заполнять его через бизнес процесс, а потом уже подставлять в генератор.
Ну в общем, если вдруг это получиться реализовать просто числа в текст переводить - скажем спасибо)
А то уже проект сдан с рефлексией.
Свойства ТП заказа - это довольно длинная цепочка (заказ - товар - ТП - свойства), сейчас так не работает.
Напишите в техподдержку, запрос зафиксируют и может когда-нибудь добавим.
Непонятно, как отправлять счета клиентам, если они сделали заказ например на партию обуви или одежды, где у каждой позиции свой размер. Функционал отправки и генерации документа вроде как и есть, но получается что он сценарии работы с размерными товарами не предусматривает. Хотя сама 1с тут же формирует счета с учетом доп. реквизитов и поддержки размеров. Приходится формировать счет там и потом отправлять его из заказа в б24, прикрепляя файл. Немного странно выглядит.
Хотя возможно можно и у ТП генерировать название и добавлять к нему размер, но тоже не самый удобный вариант.
Возможно, с выходном нового товарного каталога (и нового апи к нему) действительно получится "на лету" прокинуть поля из торгового предложения в товар в корзине
Ниже пример
/bitrix/modules/documentgenerator/lib/template.php
Если мы через событие onDataProviderManagerFillSubstitutionProviders переопределим \Bitrix\Crm\Integration\DocumentGenerator\DataProvider\Deal
То в функции public function setSourceType($sourceType): Template
вот эта проверка не заменит на нужный класс sourceType
if(DataProviderManager::checkProviderName($sourceType, $this->MODULE_ID))
Жуткий костыль
Напишите конкретный кейс, в котором вам мешает текущее поведение метода, посмотрю, что можно сделать
В БД попадает как Bitrix\Crm\Integration\DocumentGenerator\DataProvider\Deal
И теперь в списке документов не выводится, тк в БД стоит Bitrix\Crm\Integration\DocumentGenerator\DataProvider\Deal, а фильтрует по Shef\DocumentGenerator\Integration\DataProvider\Deal
/bitrix/modules/crm/lib/integration/documentgeneratormanager.php
public static function onDeleteDocument(Event $event)
Document::loadById - число ждет
Проблема проявляется когда из TimeLine удалять документ