Typically, a "vanity URL" is an address you use in advertisements which is redirected to your actual page, sometimes along with some tracking parameters in the query strings portion of the URL. This is usually for the purpose of shortening the URL, or making it easy to remember, for use on radio, television, print, billboards, etc. So, in this context, yes a redirect (usually 301) takes care of sending the traffic (and the search engines if any happen to discover one of the vanity URLs) to the real page.

But the phrasing of your question makes me think you are not using "vanity URLs" in this context. If they are being indexed, I assume this mean you are creating actual copies of the pages, or possibly forwarding the page request without changing the URL. If this is the case, then using canonicals (one from the secondary to the primary page, and a self-referencing one on the primary page itself) can be of help to you here. But, I would first question why you are ending up with multiple URLs for one page in the first place.

I think that might be a successful approach under some circumstances. For example, if the company is a brand, and their storefront is only one aspect of that brand but you think that they might otherwise rank for searches of non-transactional intent. An example might be a museum which also runs a gift shop. Or a manufacturer who also manages a direct-to-consumer storefront but where that is not the focus of their business. In these and similar cases, having a separate set of pages (whether on a subdomain or preferably just in a subfolder if feasible) for the commerce isn't necessarily a bad idea. I'm assuming when you wrote "proving to be highly restrictive", you meant more than just for example not being able to set the exact H1 tags you might want on a page or not being able to insert schema markup for certain types of objects. There are going to be those kinds of tactical challenges for on-page SEO in every platform, just varying degrees between the platforms, and I wouldn't take a drastic approach like separating the storefront just because of those kinds of issues. But, if the SEO challenges with the current platform are really of the highest severity and can't be addressed within that platform, then the approach of a separate storefront might make sense in the kinds of scenarios like the museum or the manufacturer mentioned above.

I would recommend to canonicalize these to a version of the page without query strings, IF you are not trying to optimize different version of the page for different keyword searches, and/or if the content doesn't change in a way which is significant for purpose of SERP targeting. From what you described, I think those are the case, and so I would canonicalize to a version without the query strings.

An example where you would NOT want to do that would be on an ecommerce site where you have a URL like www.example.com/product-detail.jsp?pid=1234. Here, the query string is highly relevant and each variation should be indexed uniquely for different keywords, assuming the values of "pid" each represent unique products. Another example would be a site of state-by-state info pages like www.example.com/locations?state=WA. Once again, this is an example where the query strings are relevant, and should be part of the canonical.

But, in any case a canonical should still be used, to remove extraneous query strings, even in the cases above. For example, in addition to the "pid" or "state" query strings, you might also find links which add tracking data like "utm_source", etc. And you want to make sure to canonicalize just to the level of the page which you want in the search engine's index.

You wrote that the query strings and page content vary based on years and quarters. If we assume that you aren't trying to target search terms with the year and quarter in them, then I would canonicalize to the URL without those strings (or to a default set). But if you are trying to target searches for different years and quarters in the user's search phrase, then not only would you include those in the canonical URL, but you would also need to vary enough page content (meta data, title, and on-page content) to avoid being flagged as duplicates.