The general rule is that if you are referring to the value contained by the field, you don’t use quotes.
If the field name contains punctuation, then you need to use chevrons.
It’s ok to use chevrons even if there is no punctuation in the field name, but they are simply ignored.
If you are referring to the name of the field, rather than the value then you do use quotes. You should not use chevrons, even if the name contains punctuation.
By the way, it’s not so much that you are using quotes, it’s rather that a formula is being used to calculate the name of the field. So it could be a more complicated formula, for example:
Or you could even put the field name into a variable, and use that, in which case there would be no quotes.
Your specific question is about the lineitemarray( function. The first parameter of that function is the name of the field, not the contents of the field. So the field name should be in quotes. And in fact, both the Panorama 6 documentation and the Panorama X documentation clearly state that the field name must be in quotes.
So according to the Panorama 6 documentation, your code is incorrect. However, in some cases, Panorama is able to figure out what is going on anyway, and allow the field name without quotes even though normally they should be required according to the rules. I did some testing, and it appears that the Panorama 6 version of the lineitemarray( does accept the field name without quotes, even though this is not documented.
Now that I’m aware of this, I did some preliminary investigation, and getting this to work exactly the same as Panorama 6 is not a one line fix. However, even though this isn’t how it is documented to work, I’ve filed a bug report and hopefully in the future Panorama X can have the same documented behavior that Panorama 6 had.
As a final note, this sort of thing is a symptom of the fact that the code in Panorama X is entirely brand new. It was written from scratch, not using any of the existing Panorama 6 code. That’s not for the sake of being new, it’s simply because the old Panorama code is written using an ancient programming language that is not compatible with modern developer tools. So the new code is written from scratch to match the Panorama documentation. In this case, the documentation didn’t exactly match the old program. This isn’t the first time that has happened, and in many cases I’ve done testing of the old version to make sure the new version matches the behavior of the old version. But it’s impossible to catch every single undocumented behavior.
P.S. The previous statement about the code being entirely brand new isn’t actually 100% true. Much of Panorama is written in Panorama itself, using custom statements and functions. A lot of that code has been reused with little or no documentation. After all, the goal is for you to be able to reuse most or all of your code, so I can take advantage of that reuse as well. But the low level code is all new.