Hi - I notice on 16.1 that .rpt report files now reside in the SITE folder. So what happens now when we have modified a particular report for a particular machine ? We have a machine on the counter that uses a modified version of orders.rpt to print on a labels printer. This used to be fine as the machine had its own copy of orders.rpt. Now the reports are in the shared folder, how is this machine to have its own custom copy ?
Announcement
Collapse
No announcement yet.
16.1 Reports now in shared sites folder ?
Collapse
X
-
Hi there
Thanks for the reply.
Negative - I have not dragged them into the sites folder.
To install 16.1 I had to uninstall 16.0 first.
So, a clean install of 16.1 - but no reports are in the c:\program files\sellerdeck\sellerdeck 2016
Please note: reports such as invoice etc are working correctly so something must have happened programatically otherwise surely I would be getting an error.
I logged a call with helpdesk the other day, but alas no update from them.
Comment
-
In SD16 the report files are stored in the site folder for each site.
You can confirm this by licensing a new site and checking in the new site folder.
You might need a registry tweak to point to a different location on a particular PC perhaps.
Not sure, needs a bit of thought,
EDIT or maybe look into adding the modified reports into MyReports. See the info in the Reports.ini file.
Comment
-
Yes, so that's is what I originally said - reports are in the sites folder for 16.1
My question was, how do we now handle situation where one machine needs a modified version of a standard report. It used to be a no-brainer, as reports were held locally. So one machine could have a special tweaked version of, say orders.rpt.
How is this handled now ?
Comment
-
Originally posted by Duncan Rounding View PostIn SD16 the report files are stored in the site folder for each site.-----------------------------------------
First Tackle - Fly Fishing and Game Angling
-----------------------------------------
Comment
-
The file location wasn't changed in v16.0.1
In my SD 14.0.3 the .rpt files are in C:\Program Files (x86)\SellerDeck 2014.
In my SD 16.0.1 the .rpt files are not in C:\Program Files (x86)\SellerDeck\SellerDeck 2016.
In my SD 16.0.1 they are in C:\Program Files (x86)\SellerDeck\SellerDeck 2016\Versioned\16.0.1.0.0.0.QCHB\Original and thus get copied to the particular Site folder for any new site that I create.
Just like Jez has found.
This is in contaradiction to SD 2016's own Release notes that state:
Code:6.1.1 Installation directory structure Program Files (x86) SellerDeck Extensions By default SellerDeck Extensions are installed here. SellerDeck 2016 The default installation directory. Holds files common to all sites, such as reports and help files.
Norman - www.drillpine.biz
Edinburgh, U K / Bitez, Turkey
Comment
-
I need to understand whether we're talking about the source or the target here - ie where the original files are stored, or where they end up when a site is created.
The original question referred to .rpt files in the sites folder, which I took to mean (in my case) C:\Users\Bruce Townsend\Documents\SellerDeck 2016\Sites. They don't end up there in my v16.0.1 installation, and I'm not aware of any reason why they would.
If the question is about where the originals are stored, then yes, that has changed. I'm afraid the release notes are out of date in that respect. At this point in time I don't know the reason, and I'm not sure if the effect of copying to the site folder was intended. I'm going to check with our development team about it.
Comment
-
They are not ending up in the Sites folder. They end up in all sites created (with whatever name the user chooses) within the Sites folder.
E.g. Sites\Site1 will now contain a set of .rpt files.Norman - www.drillpine.biz
Edinburgh, U K / Bitez, Turkey
Comment
-
I'm talking about a fully installed, working installation of Sellerdeck 16.1 with a site that is working.
In this scenario ".rpt" files, without any intervention of any kind are in the sites\sitename folder, along with with all the sites images and other stuff. In my case this is a network mapped driver on our server.
They used to be in the C:\program files(x86)\sellerdeck 2014 folder on every local machine. We have 14 users so I know this is happening.
Comment
-
OK, I've had clarification from the development team.
The .rpt files are now copied to the site folder so that they can be included in snapshots and properly backed up, and so that customised .rpt files are no longer lost when upgrading sites. Hopefully you will fine this beneficial in the long run.
You can still run a different version of a report on a particular machine, but you will have to use a different .rpt file.
Sorry for any confusion. I will make sure the release notes are updated in a maintenance release.
Comment
-
Hi - thanks for the clarification. My original question still remains: HOW?
The file "orders.rpt" is a Packing List - as in click on Packing List, Standard report.
Our shop computer uses a customised version of this which is formatted to print on a label.
The other computers print the standard, unmodified version.
So, now reports are pooled and shared:
How does Computer-1 use a customised version of orders.rpt ?
A packing list is also available via the "complete" button - again, how do you have different versions on different machines?
Come on Sellerdeck - why are we finding out this crucial information by accident? Where is the how-to guide for this massive change ?
Comment
-
Sorry, you seemed to know about custom reports so I thought you would know that. I apologise for assuming :-(
You will need to follow this Knowledge Base article to add the shop version of the report to the 'Packing List' menu:
http://community.sellerdeck.com/showthread.php?t=44994
If you need more help with that, please contact support. I don't think it's possible to add another packing list to the right-click menu so unfortunately you will have to adapt your processes a bit.
Your scenario is not one that I've come across before, and unfortunately we hadn't considered it. We do try to take account of the many different ways our software is used, but they are very diverse, and it's simply not possible for us to anticipate everything.
Comment
Comment