Форум

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

Чтобы в таймлайн добавилась запись, надо использовать пример "Полный цикл" из статьи https://dev.1c-bitrix.ru/api_d7/bitrix/documentgenerator/snippets.php

Igor, если вам для сделки надо несколько документов с одним номером, то есть два варианта. Оба потребуют наличие роботов / БП.

1. Создаем БП "Создание сопроводительных документов".
В БП первое активити - создание первого документа. В результате выполнения активити будет "Номер документа". Запишите этот номер в переменную.
После первого активити ставьте столько активити создания документов, сколько вам нужно, но в каждом активити указывается поле {DocumentNumber} из переменной.
Так у вас будет один номер во всех документах, созданных в рамках этого БП

2. Если у вас роботы. Аналогично первый робот создает первый документ, а номер пишете не в переменную, а в поле сделки.
В последующих роботах заполняете поле {DocumentNumber} из поля сделки.

G_107336047755713010335, вы можете написать php-код, в котором воспроизведете активити "Создание документа CRM", только без интерфейса (данные можно из переменных получить).

Код будет примерно следующий:
- получаем ид шаблона, тип провайдера (лид / сделка) и ид лида / сделки из переменных
- получаем данные о товарах из этого лида / сделки
- формируем два новых ArrayDataProvider как нужно
- вызываем апи создания документа, где передаем нужные данные в setFields и setValues
- записываем нужные данные в переменные и можно их использовать дальше.

G_107336047755713010335, это будет непросто.

Вместо активити можно воспользоваться тем же событием onBeforeProcessDocument, суть та же. Главное под рукой иметь объект документа.

Вот тут можно посмотреть пример кода, где на событии меняется содержимое списка товаров https://pastebin.com/dKrqmQra.
Всё никак не дойдут руки оформить нормально в документацию.

Вам надо будет сделать следующее:
1. Достать данные о товарах из документа в отдельный массив
2. Распихать данные о товарах по двум отдельным ArrayDataProvider
3. Передать описание полей для ваших новых ArrayDataProvider
4. Очистить исходный PRODUCTS (хотя если для него нет полей в шаблоне, можно и не трогать).

Задача довольно сложная, я бы рекомендовал двигаться по шагам. Будут вопросы - кидайте код, посмотрю.

Иван Рыков, во-первых, надо пометить поле, что оно является файлом.

Для этого надо в описание поля с картинкой добавить тип
не забудьте свои коды правильно подставить.

Если это было сделано и вариант со ссылкой не прокатил, то попробуйте вставить абсолютный путь к файлу, либо id из b_file (только в виде строки).
Вот в этом методе \Bitrix\DocumentGenerator\Body\Docx::getImage() из значения получается путь к файлу, можете посмотреть.

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

Вставляйте как текст, без гиперссылки на нём.

Игорь Моргачёв, я примерно понял, чего вы хотите.

Мне не удалось добиться такого поведения (ссылка на изображении) даже в редакторе (вставляю ссылку, сохраняю, открываю - ссылки нет). По крайней мере в libreoffice. Поэтому не смог проверить, как оно там храниться, чтобы подсказать.

В любом случае это вряд ли будет работать сейчас. Гиперссылки - это отдельные объекты, путь к которым хранится внутри атрибутов. А парсер сейчас перед обработкой вырезает все плейсхолдеры из атрибутов, кроме картинок (сделано специально, т.к. атрибуты гораздо чувствительней к вставляемым в них данным).


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

Феликс Ерм, для начала я бы посоветовал проверить, сможет ли генератор документов скопировать строку вложенной таблицы. Если честно, не проверял такой кейс. Может, и будет работать. Если не сможет - вам придётся переформатировать шаблон таким образом, чтобы коды и названия оквэд были в строке отдельной таблицы.

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


Правильнее было бы использовать универсальный список для хранения оквэдов. Проблема в том, что документы в CRM не умеют печатать данные из универсальных списков. Для печати данных оттуда придётся использовать rest.

Выглядеть это будет так: создаете множественное поле привязки к элементам инфоблоков. Указываете в сделке нужные оквэды. Создаете веб-хук или приложение, которое будет доставать данные из сделки и формировать на их основе данные для таблицы. Примеры есть тут https://dev.1c-bitrix.ru/rest_help/documentgenerator/example.php#generate_doc_array

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

Евгений Хазиахметов, если вкратце, то CIBlockElement - старое апи. Оно всё ещё актуально и много где используется.


Но в 19 версии iblock вышло полноценное апи для таблиц элементов и их свойств через ORM.

[URL=https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&CHAPTER_ID=012864&LESSON_PATH=3913.5062.5748.12864]https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&CHAPTER_ID=012864&LE...[/URL]

Если вы пишете новый код, то предпочтительней использовать новое апи, учитывая особенности, изложенные в курсе.




[QUOTE]Владислав Никитин написал:
ElementTable без дополнительных костылей не может вытянуть свойства элементов инфоблока - только через отдельные классы.[/QUOTE]

Отдельные классы - это не костыли. С помощью ORM сейчас можно всё достать, но для этого может потребоваться чуть больше кода, чем раньше.