Many of you voted for the feature Create OrderHedSalesRep and InvcHeadSalesRep views.
We have now finished the feature for 2025.1, and have recorded a “feature Spotlight” for this… please check out the poll here: Streamlined Reporting for Sales Rep Commissions
5 Likes
Very nice solution to the problem, fast baq reporting and backward compatible.
1 Like
This is fantastic. I am more excited about the general idea of Views in a BAQ… is that concept brand new with these SalesRep views or have there been others already? I’m sure you’ll get a LOT more view suggestions now that we know this is a thing.
1 Like
@timshuwy, This was my first idea I ever added to Epicor Ideas so I was so excited to see it added in 2025.1, but it actually falls short of our needs.
For reporting we rely on the order that the sales rep is entered on the Order/Invoice for reporting proposes. (1 account manager, 2 territory sales rep, 3 dealer, etc… ) In your demo I did not see that the order from the ~ delimited list was saved into the view anywhere.
That additional column with the entry order would be critical for us to take advantage of this new feature.
1 Like
There has been a view for the XML configurator data for a few years. Not sure how many. In the classic BAQ editor, the blocks for the views are a different color
Hate to be that guy but the View solution feels like a patch. These views we’ve created ourselves for years they are generally not very performant on very large data sets. We have a couple of million invoices running queries all by rep. We ended up having to create overnight tables that mimic what we were hoping for was coming in this version.
We also have a need for more than 5 reps there’s no real need for there to be a cap if this was split into its own table, and while the initial data conversion would take a little while it would solve the problem permanently.
As far as backwards compatibility you could create a calculated column in OrderHed / InvoiceHed that would basically “pretend” for reporting sake or simply just continue also storing the old list in those fields at very little cost.
I appreciate Epicor responding to the idea, but we all voted for option one (new table), anyway I appreciate you @timshuwy and I’m sure this will work fine for most folks. But I feel like if we were spending the dollars and time to fix this it should have been fixed correctly.
6 Likes
I would second this, with a ton of respect for what you’re putting out as well, but we also have the need for more complex structure and thus more than 5 sales reps and a table would still be the best way forward for us.
I don’t see why we couldn’t go backwards with that though Jose, right? I mean you just take the view and insert it into a table?
2 Likes
I fully appreciate your comments… I also know that if we had not taken this approach, then this probably would not have fit into the schedule to get completed.
As I mentioned in the video, one major issue was the actual upgrade itself. We discussed several approaches, but in the end, we needed to have a conversion program that would populate the new table (if that were our approach). That conversion for some companies would be a long drawn out process. we also discussed that this could be something that people run after the upgrade…
Also, we were very concerned that the “table” approach would also cause lots of upgrade problems with customers who were using the tables as is… if we were to make a table that allowed more than 5 entries, it also becomes incompatible with having both approaches (old and new)…
BUT, we wanted to get something out there so that everyone could start using the new VIEW (instead of the complicated things you currently have to do)… then eventually, if it is necessary, we might make the next step to turn the view into a real table.
4 Likes
that would be cool if we could do that.
Thanks a ton for working hard on this Tim and thank the team for us too!
2 Likes
I believe that you have extended how these fields were initially intended… while I understand that you have designated each position as a specific type of sales person, it was not part of the initial design to have these in any specific order.
SINCE we have kept both versions (the stacked version in SalesRepList and the new VIEW), it should be fairly easy to still get to your sequence number. it would be a calculated field. You could get to the saleperson id in the view table, and then look to see which position that person was in in the SalesRepList, and apply your special meaning (account manager, territory sales rep, dealer, etc) to that.
While we may have expanded on the original intent, the built in BAQ functions were designed to extract specific values from the list for our reporting. The idea of the separate table is that it would be a “first class” table that would we be able to further expand with UD columns or more than 5 reps. Like @josecgomez, we have also been asked to add more than 5 reps for specific orders. Having similar Sales Rep tables for Quote, Order, & Invoice would have been great and clean up the inconsistencies between the 3 modules.
Ice.entry(3, InvcHead.SalesRepList, '~')
The new view might have limited benefit for very ad hoc reporting, but I’m unsure the benefit to updating our current BAQs to use the view. I am not trying to be rude, but this does not fulfill the needs or intent of my original idea. Should I submit another new Idea for future development, or can this be moved back in status?
2 Likes
So will there be views for all of the combined fields like this? I’m thinking of selected attributes on vendors and customer as an example.
2 Likes