@RobErNat Cool. Sure, I can make the commands use the BLID if you prefer that, it would be converted to BOID by BrickSync's translation cache.
Adding the commands is trivial... although I should also add a little code to retrieve the current width/length/height/weight from the catalog. Like BLID updates, we want to make sure we are submitting new values; BrickOwl doesn't seem to automatically discard duplicate submissions.
@Stragus Personally I'd still check wether an item has a known size or not, but that can be done on first glance by checking the item (if sizes are present or not on the main overview of the item). The whole point for mass uploads is to save time, when submitting page loads on BO are a bit slow and to do so repeatly is quite a burden ;-)
@stragus Il give it a shot this weekend (well, I surely hope I can clear my backlog on orders first), need to download the new Bs version as well, I skipped a few updates ;-)
How about a request for a feature that would be used only rarely, but which should be easy to code (so they balance out!)
I'd like to see a HaveIPricedAnythingStupidly command.
Once in a while, I check my inventory against the 6-month sales average, to see if I have accidentally priced something way off, or if averages have moved a lot since I listed.
Here's how I do it:
Download inventory to Brickstock, save as .bsx. Open .bsx file in text editor and Replace All "Price>" with "Remarks>". Open the altered .bsx file in Brickstock and set prices to 6-month average. Change the extension to .xml and open that in Excel. Create a new column to calculate ratio of my price to 6-month price. Sort by that new column to find the outliers.
Ouch.
With a new command in BrickSync, all of that could be one step -- just run the command and check the log. It could even do the ratio for both BL and BO.
@monochrome That new command sounds simple, it has a catchy name too.
Just checking though... Are you aware of the loadprices command? It updates your prices for all matching lots from a BSX file. Every few weeks, it would probably be a good a idea to load your entire inventory in BrickStore, adjust prices, save as BSX and loadprices that file.
Yes, but I don't actually want to set my prices to average prices -- I only want to see the ratio. Some items I price above average, and some I price below.
loadprices doesn't actually give me a way to make the comparison, it just provides a way to update, unless I am misunderstanding.
@monochrome That's right. I was assuming that updating all prices would be more convenient than reviewing your existing prices, but it implies a different work flow.
I'll add a command to print prices outside a specified bracket relatively to current selling prices then, it's a quick feature to add.
There's a new feature in BrickSync 1.5.0 that several users should find useful, although it may require some explanations.
Previously, when the mapping between a BLID and a BOID was unknown, the software encouraged the submission of BrickOwl catalog changes (manually or through owlsubmitblid, etc.).
But many users have expressed frustration that some submissions would take days/weeks to be approved (myself included), during which time the items wouldn't be made available for sale on BrickOwl (reminder: use the command owlresolve to list unresolved BLIDs).
So, there's a new command: owlforceblid BOID BLID to immediately force a BLID<->BOID mapping in BrickSync's local translation cache. You can then sync brickowl to upload these items right away, with no further delay.
If you want to revert that BLID<->BOID mapping, you can use the owlforceblid command again, or owlqueryblid -f SomeBLID to try resolving the BLID (the -f flag is required to bypass the local cache). If, for some reason, you want to wipe out your entire translation cache, you can delete the file data/bricksync.trs in BrickSync's directory then restart BrickSync.
Note that the commands owlforceblid and owlsubmitblid take the same arguments; you can force a local BLID<->BOID mapping and submit a BLID to the BrickOwl catalog with the same syntax.
Trying to update all my remarks in my inventory and when I use the loadnotes function it only updates some of them. I also tried just updating a few at a time instead of the entire inventory and the same thing happens. Any ideas?
@Badlove That's weird, I'm using the command all the time. The load* functions first try to match items by LotID (if present), then by ID:Color:Condition if there was not LotID match.
Anything special about the lots being skipped? Does the ID:Color:Condition match exactly? Are these multiple identical lots?
It is roughly half of my inventory so about 4500 lots and I see no common theme between them. New, used, all item types. I double checked and all the LotID's seem to be matching up correctly as do all the ID:Color:Condition on all the ones I randomly checked.
Just noticed that some of the lots that had not been updated are now updated. Not all of them but a few more. Could it be possible that it just exceeded the api calls for the day.
When BrickSync runs out of BL API calls, it should clearly say so. It also outputs BL XML file(s) which you can upload (this is absolutely optional), or you can just let it finish the job when the pool of API calls is healthy again. Did you see these messages? I realize it's possible to miss these messages, with the BrickOwl update progress being printed next. You can check in the log file to make sure.
Also, BrickOwl should always be fully updated right away (no API limits here!).
BrickSync 1.5.2 has a new command to change the ID of a lot, setblid. It's especially useful to quickly fix these lots listed with the wrong variant.
So, here's me now fixing an incorrect variant in my inventory:
Usage is very similar to commands such as setprice, setquantity or setremarks, useful to change other lot properties.
Note that, unlike other set* commands, setblid must delete and recreate the lots. Any existing custom "My Weight" value will not be preserved (I'll add support for custom weights once they are supported by BrickOwl's API...).
Comments
Adding the commands is trivial... although I should also add a little code to retrieve the current width/length/height/weight from the catalog. Like BLID updates, we want to make sure we are submitting new values; BrickOwl doesn't seem to automatically discard duplicate submissions.
Personally I'd still check wether an item has a known size or not, but that can be done on first glance by checking the item (if sizes are present or not on the main overview of the item). The whole point for mass uploads is to save time, when submitting page loads on BO are a bit slow and to do so repeatly is quite a burden ;-)
And it is done. New commands in BrickSync 1.3.6:
owlsubmitdims ID length width height
owlsubmitweight ID weight
The ID can be a BLID or a BOID with a '*' prefix, such as 3001 or *771344.
Il give it a shot this weekend (well, I surely hope I can clear my backlog on orders first), need to download the new Bs version as well, I skipped a few updates ;-)
I'd like to see a HaveIPricedAnythingStupidly command.
Once in a while, I check my inventory against the 6-month sales average, to see if I have accidentally priced something way off, or if averages have moved a lot since I listed.
Here's how I do it:
Download inventory to Brickstock, save as .bsx.
Open .bsx file in text editor and Replace All "Price>" with "Remarks>".
Open the altered .bsx file in Brickstock and set prices to 6-month average.
Change the extension to .xml and open that in Excel.
Create a new column to calculate ratio of my price to 6-month price.
Sort by that new column to find the outliers.
Ouch.
With a new command in BrickSync, all of that could be one step -- just run the command and check the log. It could even do the ratio for both BL and BO.
Whaddya think?
--
Marc.
Just checking though... Are you aware of the loadprices command? It updates your prices for all matching lots from a BSX file. Every few weeks, it would probably be a good a idea to load your entire inventory in BrickStore, adjust prices, save as BSX and loadprices that file.
loadprices doesn't actually give me a way to make the comparison, it just provides a way to update, unless I am misunderstanding.
--
Marc.
I'll add a command to print prices outside a specified bracket relatively to current selling prices then, it's a quick feature to add.
Meanwhile... any chance this command could be run against an optional .bsx file instead of the default full inventory?
--
Marc.
Previously, when the mapping between a BLID and a BOID was unknown, the software encouraged the submission of BrickOwl catalog changes (manually or through owlsubmitblid, etc.).
But many users have expressed frustration that some submissions would take days/weeks to be approved (myself included), during which time the items wouldn't be made available for sale on BrickOwl (reminder: use the command owlresolve to list unresolved BLIDs).
So, there's a new command:
owlforceblid BOID BLID
to immediately force a BLID<->BOID mapping in BrickSync's local translation cache. You can then sync brickowl to upload these items right away, with no further delay.
If you want to revert that BLID<->BOID mapping, you can use the owlforceblid command again, or owlqueryblid -f SomeBLID to try resolving the BLID (the -f flag is required to bypass the local cache). If, for some reason, you want to wipe out your entire translation cache, you can delete the file data/bricksync.trs in BrickSync's directory then restart BrickSync.
Note that the commands owlforceblid and owlsubmitblid take the same arguments; you can force a local BLID<->BOID mapping and submit a BLID to the BrickOwl catalog with the same syntax.
Anything special about the lots being skipped? Does the ID:Color:Condition match exactly? Are these multiple identical lots?
Along with some examples of failing lots.
My email address is printed out when starting BrickSync. Thanks!
Do you have bracket's or other special characters in your remarks fields ?
When BrickSync runs out of BL API calls, it should clearly say so. It also outputs BL XML file(s) which you can upload (this is absolutely optional), or you can just let it finish the job when the pool of API calls is healthy again. Did you see these messages? I realize it's possible to miss these messages, with the BrickOwl update progress being printed next. You can check in the log file to make sure.
Also, BrickOwl should always be fully updated right away (no API limits here!).
So, here's me now fixing an incorrect variant in my inventory:
Usage is very similar to commands such as setprice, setquantity or setremarks, useful to change other lot properties.
Note that, unlike other set* commands, setblid must delete and recreate the lots. Any existing custom "My Weight" value will not be preserved (I'll add support for custom weights once they are supported by BrickOwl's API...).