Hi,
I have this table with rows for an invoicereport. I'd like to sum at the last row but whenever I schedule it in Nprinting picking up the table it gives me correct Total but its like it comes on top of another row. See below the totals are correct but the following in 2 rows doesnt add up because of the total row showing above the 3rd row.
Without Totals it gives me that 3rd row as you can below...
Hi Niklas,
Does it show up this way when the total is in Qlikview or only when you schedule it in NPrinting?
Camile
Good question...
If I enable the totals it runs fine in the app so to speak. Its jsut when Nprinting schedules it somehow deleted a row...
Is MarketId = PSE something that would get filtered out when you schedule it in NPrinting?
Can you try doing the total in Excel (through NPrinting) -- namely sum().
What is the outcome if you do that? How are the totals currently being generated? Have you tried putting subtotals on bottom in Qlikview -- what result does that generate?
You might also check to see if there is a dimension limit in the qlikview set to show only.. first three MarketIds or something weird like that. Dimension limit treats other and totals bars like one of the values, so I always have to pick top 6 if I want to show top 5 + Others bar or row. Just a weird left-field thought to check for in this weird anomaly you have there.
(I was looking for a way to show only the totals row myself, and thought this subject might've been that.)
No dimension limits is being used. Any who can think of a solution?
Bumped into the same issue.
Straight table in Qlikview.
In Qlik, looks absolutely fine. Selected option for "totals at the bottom".
Without total, all the records show up in NPrinting output. But, when I enable totals(in the chart properties in the QVW), the NPrinting output has totals as the first row (though QV chart has them at the bottom) and the last row is deleted.
Similar to what Niklas has mentioned.
I have the same issue when migrating from nprinting 16.0 and QV 11.2 SR10 to nprinting 16.3 ( and 16.5 as well) and QV11.2 sr 11
although i am nog missing any lines in my straight tabel i can't get the totals at the bottom of the table, it was working fine in the old environment
I am wondering if the issue is in nprinting or in Qlikview
kind regards.
Linda Monincx
Hi Linda,
Good catch! This is an issue in QlikView 11.20 SR11 & SR12 (fixed in SR13) that affects NPrinting as well.
HTH - Daniel.
Thanks for that comment. I will re-escalate my request for us to just upgrade from 11.2 sr12 to qv 12.srwhatever12isatnow.
Hi Steve,
Just remember that NPrinting versions 16.x (that Linda is using) are not compatible with QlikView 12.x. For compatible versions see: Requirements for NPrinting 16.x.x.x versions only
HTH - Daniel.
Woah! Good to know, thanks! I'll just look for qv 11 sr13 or something then. Or leave it alone if I don't need totals on that particular object type. I hear nprinting 17 still has some issues being ironed out and friend advised me to stick to 16 for awhile if 16 is serving my current needs.
Actually, a colleague is using nprinting 16 designer and qv 12 desktop edition on another server environment, but they're using windows task scheduler and powershell to run the nprinting jobs instead of nprinting server. I'll take your word and leave qv12 alone for now. The powershell does some fancy stuff to rotate files into position for qlikviews to read, then tells nprinting to tell the qlikviews to reload themselves and grab TB01 off the front. After nprinting saves the file, the powershell moves the qlikview back out and pulls in another qlikview for the nprinting to run. So in that setup, nprintign designer's just like a little robot arm poking TB01 out of whatever qlikview powershell puts in front of it. (The powershell script is probably 20 pages long now, but it works for that purpose.:) ) My qlikviews and nprinting jobs are more complex, so I'm using nprinting server and qv server to run things.)
Hi Steve,
Interesting stuff! Possibly using the QlikView COM API?
I'm sure you could get NPrinting 16.x to work with QlikView 12.x in some instances but it is definitely not supported. What this means is that if you do have an issue and approach Qlik Support, we will ask you to reproduce the issue in a supported environment before we can help.
HTH - Daniel.
Thanks Daniel. I think we'll take a page from NASA's book and leave well enough alone if we have a bug-free configuration with the older software right now. I do suspect the compatibility issue must be the server program if there's no apparent issue when a user uses nprinting designer to run a qlikview desktop. Or it could be issues with various object or report types. My colleagues are just doing a qlikview entity report for TB01 which is probably the barebones smallest kind of task nprinting can do with a qlikview. (They're just cleaning files before importing them to our database.) I think it's a windows 8 enterprise kind of environment they're in too. Operating system environment could be a factor.
Hi Steve,
Agreed.
I just want to add one thing - NPrinting always uses QlikView Desktop to access QVW files so even when using QlikView server connections (qvp://) it goes through QlikView Desktop - similar to File > Open in Server. That is why you need a properly licensed QlikView Desktop installed on the NPrinting Designer and Server machines (v16.x - if different) or NPrinting Engine machine (v17.x if the engine is used to access QlikView connections as opposed to Qlik Sense connections). Just thought you would be interested to know that.
Best - Daniel.
Thx, as Nprinting 17 is still not having all the functionalities as version 16 at least till the summer i will stick to my current versions. I will need to migrate to version 17 if I want to use QV12 in the future but not sooner than that i hear that version 17 becomes equal on functionality as version 16 of nprinting.
Kind regards,
Linda
Changing straight table to pivot table solves the issue. It's strange - but at least works!