Могу ли я установить переменную на основе записей сведений в отчете Acumatica и использовать ее, чтобы определить, следует ли печатать поле сведений?
У меня есть отчет Acumatica, который создает этикетки для сборок комплектов. Отчет включает в себя заголовок, а также записи сведений о настраиваемых объектах, прикрепленные к элементу комплекта. Подробные записи для данного элемента могут иметь один и тот же идентификатор или разные.
Я пытаюсь отобразить или не отобразить поле из моих подробных записей в зависимости от того, имеют ли все подробные записи для этого элемента набора asm одинаковый идентификатор.
Я думаю, что мне нужно рассчитать это, сохранить его в заголовке комплекта asm и использовать его, чтобы определить, отображать ли мое поле, но есть ли способ выполнить этот расчет полностью в отчете без дополнительного кода?
Ответы 1
I'm attempting to display or not display a field from my detail records depending on whether all the detail records for this kit asm item have the same ID.
Если я правильно понимаю, дизайнер отчетов не сможет этого сделать. Ограничение заключается в том, что дизайнеры отчетов обрабатывают каждую детальную запись отдельно и не могут просматривать следующие записи. Вы можете просматривать предыдущие записи, кэшируя их значения в переменных по мере продвижения, но не можете знать значение следующих подробных записей, которые необходимо обработать. Также вы не можете установить значение для предыдущих записей в конце, потому что они обрабатываются индивидуально.
I'm thinking I need to calculate this, store it on the kit asm header and use it to determine whether to display my field, but is there a way to do this calculation entirely within the report without additional code?
Чтобы вычислить условие, вам нужно будет каким-то образом выполнить выбор SQL. Поэтому это нужно сделать в коде или через схему таблицы редактора отчетов. Кажется сложным впихнуть такое условие в схему таблицы. Я думаю, что самым простым способом было бы использовать Пользовательская функция отчетов (UDF), но их нелегко поддерживать. Наличие настраиваемого поля, как вы предлагаете, вполне может быть лучшим решением. Этот отвечать на той же странице рекомендует вместо UDF для лучшей ремонтопригодности.