1

I'm experimenting with Sharepoint 2013. I'd like to set up a structure to store our client and supplier documentation and details. What I've done is to create a main suppliers site (/sites/suppliers) and one subsite for each supplier (/sites/suppliers/SUP0001), where we're storing documents for each supplier. Nothing complicated.

One of the aims is to store all the invoices to eliminate paper. So I also have /sites/suppliers/invoices/ where I have a list which contains scanned invoices. I load these pdfs into the list using a small powershell script, which is working fine.

Now I'd like to display the invoices for each supplier under the suppliers site - just a view of the main invoices list. I'm able to create a data view and display it under a suppliers branch, manually adding a filter for the suppliers code. I would like to have the data view filtered based on the supplier reference extracted from the site name.... but this is limited and I would imagine there is a better way.

Whats the simplest way to achieve this? Can it be done using caml? Are the filter fields able to contain variables or something similar?

This posting filter items by Site name and List Name using SPSiteDataQuery seems to be on the same topic but describes a solution based on coding an extension of some kind, which I want to avoid if possible just to maintain things as simple as possible.

At the moment I'm doing this with Foundation, partly as an exercise to see just how much I can do with it before needing the full sharepoint.

1 Answer 1

1

Few points to highlight

  1. Invoices list sits on the top level site and you try to display the same list under each supplier's own site. There is an approach called "Re-purposing a list or library" to achieve this. Basically you save the list or library as a web part in SPD linking contents and add that webpart to your subsite. Problem is this approach is both unsupported and it has its limitations. For example, on document libraries folders doesn't work in the re-purposed view. Would be an issue if number of invoices increases in time and you want to put them in folders for each year for example. I don't recommend this approach unless you absolutely have to.

  2. What is the reason for giving a separate site for each Supplier ? This is only justified if you would like to give access to each supplier to their own site, otherwise it complicates things.

  3. To achieve your specific requirement, I would update document permissions on invoices list for each supplier. And instead of trying to display this list within supplier subsite I would put a link in supplier subsites back to the main document library. This allows them to see only their invoices.

  4. Two ways to update permissions: a. Manually - error prone b. Using a SPD workflow (you would need 2010 workflow with impersonation)

4
  • in answer to number 2 - no reason at all, I'm starting out on this. How else should it be implemented to create separate areas for each supplier? If you want to store stuff like price lists and documentation and have other web parts that, say display data like YTD purchases for that supplier extracted from an ERP.
    – Ian
    Commented Feb 22, 2016 at 17:42
  • answering number 3) this is for internal use. The idea was to be able to have a page you open for each supplier where you could see everything related to that supplier - not a collection of links which make you navigate back and forth to find what you need.
    – Ian
    Commented Feb 22, 2016 at 17:44
  • 1) this is the technique I found, opening a list, publishing a view from there and then using that. If its not supported then why is the option there to allow me to save the view? Seems odd. I'm not sure I understand why you mention document libraries - this is just a list of invoices. The total number of invoices isn't going to ever be huge. I believe the practical limits are in the 10's of thousands of rows, no?
    – Ian
    Commented Feb 22, 2016 at 17:49
  • Sorry about the number of answers, stackexchanges character limit restricts things a bit. The real question is too open to be posted here as its a request for advice - how do other IT outfits implement their own sharepoint sites for their own use? I'm starting from a blank slate with the idea of moving our own existing file structure to sharepoint - but I don't want to just 'xcopy' our file structure into a structure of document libraries in sharepoint. Why bother if its exactly the same? it should be better than a file tree.
    – Ian
    Commented Feb 22, 2016 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.