No, it won't create a synthetic key, which you can see by opening up the table view in the QVW I posted. There's only one table in the final data model, no composite or synthetic key.
A synthetic key isn't always something to avoid:
Should We Stop Worrying and Love the Synthetic Key?
Though if you read that, please read the WHOLE thread, not just my initial post. I WAS shown a practical counterexample to my initial contention, I made a mistake in how I was tracking load times, synthetic keys in the wild usually ARE an indication that someone has made a mistake, even if you intend a multi-field key to link two tables you might want to build it deliberately rather than by default, and, as is true in our case here, the data model should perhaps be redone so that you need NEITHER a synthetic nor a composite key.
As you've identified, the composite "key" to the table seems to be the combination of order number, line number, and release number. But both of our tables have this same key, and no other key data. Therefore, they can and in QlikView I'd argue should be considered the same table. For whatever reason, in our database, we built multiple tables with the same key. There can be good reasons for this - we have plenty of cases like that around here. When loading into QlikView, we just join them back into one table again, but we do it in the SQL, not in QlikView script (well, except in the sense that the SQL is written in the QlikView Script).
As far as building a composite key when doing a left join, that would work but is absolutely unnecessary. QlikView will join on all common fields by name, just as SQL can join on all common fields as identified in your ON or WHERE. And there's a possibility of error as well, such as if you have order number 11, line number 1, release number 1, and order number 1, line number 11, release number 1, or any other such combination. They would all get the same key value in your script. Typically I'll separate the key fields by a character that never appears in the key fields, often a ':'. But again, unnecessary here, and an opportunity to make a mistake.
There's a problem with how you're checking for purchase type db = 'O'. This field is only in copo2, so you can't put it in a where condition when loading from pol2. One way around that is to do what I show, load 'O' as purchase_type_db, which will cause you to only join to records in copo2 that have 'O', which accomplishes what we're after.
