I realize that many factors exist when being tasked with restructuring (or re-writing) an out-of-the-box Epicor report… however… typically, how long does it take you, from start to finish, to re-write, test, and release an average report solution in your environment?
I am asking merely to compare my level of “production speed” against others who are doing similar reporting tasks for their company.
It took me 14 days to add a sub-report to the Job Traveler, because I had to tinker with the gazillion keep-together with group type of settings or I got scattered unreadable pages.
We dont re-do anything from scratch because when we upgrade, we can easily merge Epicor fixes.
But it depends on the report. Some are simple and some just take a long time to get right!
I’m with @hasokeric here, it really does depend on the complexity of the exiting report and the requirement, for example having to turn a report to landscape, or grouping with for some unusual request, but I think my favourite is picking up a prior version that someone else tinkered with, that can be a whole new world of pain.
Typically… and again, depending upon the complexity of the restructuring of existing RDL objects (i.e. - creating an Excel version of a PDF report), or the addition of fields to a supporting dataset, or the complete production of a new BAQReport… it takes me anywhere between 2 to 8 weeks (sweet spot is 4 to 6 weeks).
This level of development “speed” appears to be unsatisfactory in my company, so I wanted to get a good idea of how everyone else is doing. Thanks for sharing your experience.
… and I forgot to mention - this is in addition to other tasks unrelated to SSRS report projects, such as day-to-day Epicor administration and problem resolution, consistent preparation and readiness for scheduled Epicor upgrades, maintenance and problem resolution for our legacy crap-tier, home-grown MS Access database applications, etc. So, it’s not as if I start a project and sit in that progress chamber uninterrupted only to be released when the project has been completed. There are many things going on during the evolution of a typical SSRS report project (or any project for that matter, as I’m sure most of you can attest) that will run the completion time either long, or short.
I find one of the things that adds time, but seldom does the requestor realize it, is all the back and forth to really define what they want. Even the better users don’t expect the number of my questions they’ll have to answer.
Most are because the user generalizes many concepts and doesn’t consider all the odd conditions.
Requestor: “When was the last time we used this part?”
Me: “Define ‘used’. It was on an order, was shipped to a customer, purchased, received, had any qty changes, etc… ?”
Requestor: “Uhhh…”
Exactly… and only speaking for myself, that discussion can span several days depending upon how I correctly/incorrectly interpret those answers. I may go back into development thinking I understood everything the requestor asked for, then on the next review cycle, I realize that the answers provided by the requestor actually meant something else.
Not only that, but there are always “can you also add…” adjustments with almost every subsequent contact during the lifecycle of the project. At least, that’s been my experience.
Sometimes I’m my own worst enemy, and solve problems they didn’t realize they had. Like way too much time spent making the report “Excel friendly” (removing all the blank rows and columns you’ll get if fields don’t line up just right)
I also skimp on documenting things. Better documentation would add multiple days.
We just worked on a BPM that was about 30 lines of code for about 5 weeks… because no Analyst understood what Epicor was truly doing, yet they somehow knew “We need this BPM”. After 5-weeks of meetings trial/error they realized half of the BPM is not needed and the “Problem they thought they had” was not understanding Epicor.
I understand that completely, @ckrusen.
I just finished converting the “Shop Load” report into an Excel-friendly report style. I’m sure everyone knows how many fields are on that report (not a terrible amount, but enough to confuse the hell out of most people) and the original alignment of each field paled in comparison to the subsequent realignment of those exact same fields with every “no-that-sucks-let-me-try-it-this-way” layout decision I made.
Still haven’t mastered the art of avoiding the phantom columns in the Excel output when you align two header textboxes together at a spacing of “0 points” in the report header region. You’d want the header text in the header region so that it can be output as a “frozen row” when you scroll through the spreadsheet vertically. If you, instead, put the header text into a “row outside of the group” (that really becomes nothing more than part of the tablix data), then you’ve solved the phantom columns issue - but - the “header” scrolls with the rest of the output and doesn’t behave like an actual header (because it technically isn’t). So, yeah… that’s fun.
If you have slayed the phantom column issue (while maintaining header textboxes in the report’s header region), let me know - would love to know the secret. 
I use Table, it seems to slay absolutely every phantom for me 
I dont try to align rectangles anymore.
I thought that was what I was using, but I certainly could be wrong about that. I’ll have to go back and check. Does “Table” ensure that your header fields are output into Excel as “frozen rows”, perhaps?
The table columns need to line up with fields in the page header and footer. Sometimes you have to merge table cells so that rows can have different numbers of columns
Being an SSRS dev before getting into Epicor. Working with SSRS in the Epicor world is horrible. It has its fair share of challenges. Either with formatting issues or data issues when you have to make joins to “blackbox” RDDs. Where you can’t really see behind the curtain of what makes up that data set. If there aim is to make these reports customizable there should definitely be more documentation on what makes up the RDD.
I also find Epicor documentation lacking as whole, either in find-ability or in content. But that is another thread.
This is humbling.
Oh no… I thought it only took me a long time because I was unfamiliar with SSRS 
Disheartening to learn it will still take a long time even after I get the hang of it.
As many have pointed out it depends on the complexity of the SSRS report to begin with and then what modifications need to be done to it. I’ve seen replies mention the Job Traveler report, which I agree is a complex one to modify. I would also state that the AR invoice is also one that can get you in trouble as well as Epicor has all sorts of expressions in shrunk down textboxes that can cause you issues if you start deleting stuff and not realize they are there.
On average, I found for most report modifications, it can take me a few hours do one, which includes creating a new style, possibly creating a new report definition, and modification of the report.
The worst one to modify I have found is the check report. Why Epicor believes all companies use the same check format is beyond me. Even the one report they provide needs modification to ensure the address properly displays in the envelope window. When you have to modify this to make a complex check form such as stub-check-stub or stub-stub-check, then things can get a little interesting. It would be nice if Epicor provided basic report files for each of these check formats to save a bit of time. Other ERP companies do such as Sage. Most of the time spent on this report is ensuring that the report prints properly on the check and the stub(s) properly print all the information they are suppose to and overflow properly if space runs out.
In my opinion the mess is only because they outsourced the conversion of the Crystal Reports to SSRS instead of just rewriting for SSRS.
Does anyone know how these are going to work with E11 in a browser though? I can’t wait 15 minutes for a report to generate on a mobile device 
Unless things have changed (I’m using Report Builder for SQL 2014), you cannot add a table matrix object to an RDL header region (the software won’t allow it).
If you use the table object in the RDL body region, then sure, the phantom row issue is solved because you have a “table header row” that you can associate outside of your group details - but - you lose the “locked/frozen rows” functionality of a true Excel header when the data is output directly to Excel. This is maddening (for me, anyway) because only objects placed in the RDL header region can be output as locked/frozen rows in Excel.