To perform a JOIN you have to have one or more fields that have the same name across the two tables. If you don't you will get a cartesian join which means that you get all the combinations of all rows from each table. It is a multiplication. As far as I can tell from the log above you will get 3.855.140*31.081.765 which is 119.824.555.522.100 rows as a result. Clearly Qlik will run out of memory long before it can produce these rows...
Make sure that the fields that need to match have the same name in both tables - then the resulting number of rows will be within hopefully a manageable limit.
You can just to test put FIRST 10 in front of both LOAD statements - this gives you an idea:
FIRST 10 LOAD
FIRST 10 LOAD
Try to run and you will see that the resulting table will have 10*10 rows or 100 rows... which shows that you got a cartesian join.
Maybe the fields %KeyBillingAccountMonthName and CellphoneQty should be matching fields but then they will have to have the same name. Furthermore they have to be calculated the same way too.
We came across the same issue a while ago - and this had nothing to do with the structure of our join etc, as at the end of it error was returned in various parts of the code. Surprisingly - it never appeared when we ran a limited load.
We started from setting the error mode to 0 : set ErrorMode=0; and running the code this way.
This helped us for a while, but then it started coming back, error -129. I came across this: Re: Hi. Has anyone come across a -129 error when loading data. and it helped us too. Error started coming back, nothing from Qlik which helped us resolve this problem. Meanwhile we upgraded to Sep 2017 and we were hoping this will help, unfortunately it didn't.
At the end of the day the issue rectified itself - we recreated the app, renamed it and it's been ok ever since, error never appeared again.
It took us a good couple of weeks to stabilize the situation, hopefully it will not be the case for you, good luck!