An add followed by loadprices isn't entirely the same thing as a merge command.
The add command will not update comments/remarks/myprice of existing lots; it will only add to the lot quantity. An add followed by loadall is identical to merge though.
You probably should use add for cancelled orders, as a merge would also overwrite the comments/remarks. For example, if you use remarks to hold storage locations, and a lot has been moved somewhere else, you really don't want to overwrite the lot remarks.
I wish there was an option for the merge command to only update comments where the .bsx file includes them, leaving the comments of all updated lots unchanged if the corresponding .bsx lot comment was empty.
@Hoddie Right, you mentioned that... It's not as convenient, but you can remove the lots with empty comments and do a loadnotes on the rest.
Or, preferably, before writing new comments in a BSX file, do a sort to copy all the comments/remarks for matching lots from your inventory to that file.
@lotsofbricks don't forget to reward Stragus once in a while ;-)
Why would anything change? The catalog and numbering won't change, neither will the API functionality (most likely), those are the only 2 keys that are important to sync...
And besides, there is not going to be a new BL website, it's just 'patchwork' to freshen up some pages and add some improved functionalities, not much more ;-)
As RobErNat said, the API will remain the same, so that shouldn't make any difference. As usual, I'll update the software if there's any problem (possibly new bugs to work around, BL introduces new bugs whenever they touch anything).
Speaking of which, I'll try to post an update soon, there are 2-3 minor issues that have been reported and fixed...
Great work @Stragus , I have been using bricksync for a few months and I'm discovering new things sometimes.
My question now is about the command checkprices? Is there a way that you can add an argument to make an output brickstock file so you can there update all the prices? I say that because it is a helpful info but there is no easy way to use it.
Are there problems with resolving BLID to BOID? I was planning to also start selling here, so I used Bricksync to upload my BL inventory to BO. I got some errors with failed BOID lookup so I decided to submit some of them but got a message for two of them that they are already mapped.
11:33:11 INFO: The BLID "90398pb003" already resolves to the BOID 61343. 11:33:11 INFO: No update was submitted to the BrickOwl catalog.
11:33:11 INFO: The BLID "90398pb005" already resolves to the BOID 621144. 11:33:11 INFO: No update was submitted to the BrickOwl catalog.
But when doing another owlresolve I still get the error about failed BOID lookup: INFO: Failed BOID lookup for BLID "90398pb005", this BLID is unknown to BrickOwl. Item name (M) : "Nick Fury Statuette". INFO: Failed BOID lookup for BLID "90398pb003", this BLID is unknown to BrickOwl. Item name (M) : "Hawkeye Statuette".
@paulvdb Hi Paul, the reason seems to be quit simple: Looks like these blid's have been attached to the 'colored' entry instead of the uncolored 'base' entry. BL considers these 'minifigs', so always uncolored, if you sync they will try to sync to a color while your listing is uncolored, so it's a basic mismatch caused by a submitter who doesn't really know quite well 'where' a BLID should be attached to (must always be the 'uncolored' version). I'll submit the numbers to the 'uncolored' version (others have been wrongly attached as well), soon approved they should resolve correctly.
So BS does see this numbers in the BO database, so rejects a submittance of these, and the owlresolve rejects them because the color doesn't match with yours ;-)
Close guess, @RobErNat@paulvdb I see what's happening. BL lists these items under "Minifigs", but BO lists them under "Parts".
The owlsubmitblid command checks if the BLID resolves to anything for all item types, while owlresolve will only attempt to resolve a BL minifig BLID under the BO types "Minifig" and "Minibuild". Note that the software has to be careful about attempting to resolve under different types, there are BLID collisions across different item types.
I think this may be the first case of a BL Minifig matching a BO Part. I'll check if adding that fallback path could lead to any erroneous lookups... For the moment, note that you could use the owlforceblid command.
@Stragus Thanks for the extra input :-) Do you think changing the BLID's towards the uncolored parent shouldn't resolve things when syncing? I always assumed BS does not check 'item type' when it tries to sync and purely looks for the BLID itself?
btw: It won't be the last one where something is considered 'differently' on both sites, I see potential issues comming up with the Angry Birds Pigs as well. I have been working on them and some are going to be treated 'minifig' (if they have no accessories) and others as 'parts', if they have additional accessories. Dunno how BL is going to deal with them (no inventories last time I looked), so for now I'm holding back on them...
I found another BL minifig that resolves to a part on BO: Slimer from the Ghostbusters Firehouse Headquarters. This causes some problems because in BO these parts are listed with colors while the minifigs on BL have color N/A. So with owlforceblid I can list them on BO but they will be listed without color. It would be nice to be able to force an item to a specific color. Or is that already possible?
That would also help with another problem item that I found: the parrot 2546p02 "Bird with Parrot Marbled Red Pattern" is known on BO as "Parrot with Green Feathers Pattern" with BOID 859909. So on BL it should be listed in color green while on BO it should be listed with color red.
Besides minifigs becoming parts between marketplaces, I didn't anticipate non-matching colors either.
I don't see an easy solution to this... I think I/we will have to maintain some kind of override/correction list, probably hosted on www.bricksync.net, that the next version of the software would monitor for updates regularly.
Hopefully that list of corrections will remain short!
@Stragus That idea could work. It would certainly be easier than having every seller manually adding them to their own list and these are situations where the BL and BO entries would refer to exactly the same items so every seller would want to sync them.
In addition to that there are also some issues that I ran into with minifigure inventorying standards being different between the sites. I have some Friends minifigures that are inventoried on BL with headgear accessories such as bows, flowers, sunglasses or tiaras. BO inventories them without those accessories which is why they don't have a BLID attached to them. I used owlforceblid to list those minifigures on BO because buyers probably won't mind getting an extra bow, flower or tiara with their minifigures.
But those should probably not be added to an override/correction list because sellers might not include those accessories with their minifigs if they list minifigures based on the BO inventories. That could lead to complaints from BL buyers about missing accessories if those sellers list their minifigures on BL.
@paulvdb Right, I'm quite aware of these minifigs that don't match perfectly (due to an extra hair accessory or such); Lawrence has rejected a bunch of my BLID submissions for these.
He was right of course, since the inventories don't match exactly... And yet that's the kind of thing I would be tempted to override. If the seller's original inventory came from BL, I expect no BO customer will complain about receiving an extra $0.05 minifig accessory.
@paulvdb@stragus There are other mismatches between the 2 sites, personally I skip them out from syncing to avoid problems (it's not loke 2 dozens items are going to make a difference for a store) The 'ghost legs' is another example of those color mismatches. http://www.brickowl.com/catalog/lego-minifigure-ghost-legs-19859
I'm surprised to hear @lawrence does not approve BLID's for the friends girls with bows and flowers and such as indeed the BO buyer would end up with 'more' then what they ordered compared to the BO inventory, logically this should not be a problem at all. Could you reconsider Lawrence?
Another known issue are CMF packages in regards to 'random' packages, due to the different numbering system, the random package on BL resorts to the first 'non random' CMF on BO, so never never never list a random package on BL and then sync !! example: 71014-1 (random) on BL is Joachim Löw on BO: http://www.brickowl.com/search/catalog?query=71014-1 These random baggies should have a forced 'unmapping' from within BS (so the opposite method).
Paul, also keep in mind BO does not support 'binded' lot's, if you have any, it might be wise to skip those out as well (for example, I skip out sails, as I usually bind sails of a set together on BL to sell them as a complete set of sails). And I sure hope you will put in energy in contributing to this catalog, this site can really use a few extra pair of hands in regards to adjusting and adding data, and knowing you that should make an awesome difference in the long run :-)
PS stickers are not sepperated here between 'NA version' and 'international version', so both blids (or 3 if there is an undetermind version as well) can be attached to the same entry ;-) Stickers do have a color on BO, but they do not cause a mismatch at all when syncing, so nothing to worry about.
Another problem I ran into is one BLID for more than one BOID. BLID 21008pb01 can be BOID 277165 (in dark azure, medium lavender and magenta) or it can be BOID 329203 (in white).
And something not related to mapping BLID to BOID: Bricksync apparently does not create tiered pricing when it syncs an item for the first time. I first noticed this when I ran Bricksync for the first time to copy my Bricklink inventory to Brick Owl. None of my items had their tiered pricing on Brick Owl. Tiered prices were only created for those items when I ran the "sync brickowl" command after some of my BLID submissions had been approved. But the newly created lots at that time did not have their tiered prices.
@RobErNat Well, the BrickOwl catalog is a database, open to all for a variety of purposes. I can understand the point that non-matching BLIDs shouldn't be accepted, even if we would find it more convenient.
I guess all this underlines the need for a separate list of overrides/corrections. I'll look into that.
@paulvdb BLID 21008pb01 does not seem to cause any errors, because those actually exist in those 4 colors, the attached BOIDs might differ but that is completely irrelevant as those are just randomised (no structure) and might be due to the fact they where not attached to a parent to begin with (so each their BOID). Syncing therefor should not cause you any trouble (because it's BLID + color that makes the match). Unless you noticed something else that doesn't look on those ?
I have 21008pb01 in dark azure, magenta and medium lavender. According to BO only BOID 277165 comes in those colors while BOID 329203 only comes in white. But Bricksync mapped my 21008pb01 to BOID 329203 so I had to use owlforceblid to map them to BOID 277165
COMMAND: owlqueryblid 74188c01 INFO: The BLID "74188c01" does not resolve to any BOID.
COMMAND: owlsubmitblid 879856 74188c01 INFO: The BLID "74188c01" already resolves to the BOID 879856. INFO: No update was submitted to the BrickOwl catalog.
And how is that magnet a "gear"? That is slightly messed up. Gears are supposed to be complete items/mini-sets sold as such, a magnet part (found in several Gears) doesn't qualify at all.
Is it not possible to use non-integer numbers with the owlsubmitdims command? I used it to submit dimensions for some items and got error messages for all entries that had a decimal point. For example:
21:34:38 INFO: Runfile command: "owlsubmitdims *59377 101 101 0.3" 21:34:38 ERROR: Usage is "owlsubmitdims ID length width height".
The catalog API provides dimensions as integers, I believe it only accepts integers as well.
Even stickers seem to have a thickness of zero, though I haven't checked if the web interface allows/displays floating point values. Are there other stickers with 0.3mm of thickness?
This was a cloth part. Stickers are all listed with a thickness of 0.2 mm. If you look at the catalog entry it will be listed as 0 cm but if you go to the edit tab you can see the 0.2 mm in the height field for all stickers. For example http://www.brickowl.com/catalog/lego-sticker-sheet-for-set-76042-21231-21232
I was mistaken, the catalog API does now provide and accept floating point values for dimensions (I think that was changed at some point, didn't notice). Thanks for pointing that out.
I'm really due for pushing a new version with all this, eh.
If you are going to do a new version, can you also make it an option for owlsubmitdims to leave one or more of the dimensions unchanged? I've noticed that stickers automatically get a height of 0.2 mm when they are created, so it would probably save Lawrence some work if submissions for stickers would only submit length and width. And if noticed one or two other entries as well where one of the dimensions was already in the system.
@stragus, @paulvdb Alexis, thanks for changing and adding size dimensions with non-integer numbers, had been an issue indeed for a long time (I guess I could have mentioned it earlier on), reason I've always submitted 'parts' and 'sticker' dimensions straight on BO, and only used the txt imports on 'figs' (rounded values=less a problem). Submitting 3 sizes when 1 or more sizes are already in catalog (like with stickers) is also indeed a problem as Paul states, as BO seems to refuse the submission (@Lawrence: even when it differs from the existing size) once 1 size is already in catalog. So Pauls suggestion is legit: we would need to be able to skip out a size (maybe a syntax like L=22 W=60 H=, if no fill= no submittance, but that would depend on the API call Lawrence has created for such).
I have been using the owlforceblid command with some items in my inventory and was wondering how I can find out which BOID/BLID matches I made with that command. Does Bricksync store a list somewhere or is there a command to list them all? Or do I have to go though all of Bricksync's logs and search for all instances of owlforceblid?
Please ignore my previous post. Looks like the API errors only started after they fixed the slowness. I see errors in Bricksync when it's trying to fetch the Bricklink order list.
Yes, I have received a couple messages, but I'm not experiencing any problem myself.
Lawrence recently told me that he updated the DNS for the BrickOwl API server, and that he noticed traffic was still hitting the old IP (it's cached within BrickSync until the software is restarted).
Can you try restarting BrickSync and see if that solves it?
There was indeed an issue on the old server, this issue has now been resolved, but restarting BS would have also resolved it as that would then use the new server.
Hello ! I have a Bricklink shop and I'm thinking about create a BrickOwl one. So I've found many things about BrickSync, but I've seen that the soft hasn't been updated since Feb. 2016. So I'm wondering if it's still OK to use it at this time and if it's still supported ? Thanks for your answers ;)
Comments
Summary for blmaster:
http://www.bricksync.net/guidefaq.html#faqblmaster
Will use merge from now on
The add command will not update comments/remarks/myprice of existing lots; it will only add to the lot quantity. An add followed by loadall is identical to merge though.
You probably should use add for cancelled orders, as a merge would also overwrite the comments/remarks. For example, if you use remarks to hold storage locations, and a lot has been moved somewhere else, you really don't want to overwrite the lot remarks.
Or, preferably, before writing new comments in a BSX file, do a sort to copy all the comments/remarks for matching lots from your inventory to that file.
Will there be any changes to the program or how we use it when BL switches to their new website?
don't forget to reward Stragus once in a while ;-)
Why would anything change? The catalog and numbering won't change, neither will the API functionality (most likely), those are the only 2 keys that are important to sync...
And besides, there is not going to be a new BL website, it's just 'patchwork' to freshen up some pages and add some improved functionalities, not much more ;-)
Speaking of which, I'll try to post an update soon, there are 2-3 minor issues that have been reported and fixed...
I have been using bricksync for a few months and I'm discovering new things sometimes.
My question now is about the command checkprices? Is there a way that you can add an argument to make an output brickstock file so you can there update all the prices?
I say that because it is a helpful info but there is no easy way to use it.
thanks again for your great work Stragus,
Sergio
Stellar Bricks
11:33:11 INFO: The BLID "90398pb003" already resolves to the BOID 61343.
11:33:11 INFO: No update was submitted to the BrickOwl catalog.
11:33:11 INFO: The BLID "90398pb005" already resolves to the BOID 621144.
11:33:11 INFO: No update was submitted to the BrickOwl catalog.
But when doing another owlresolve I still get the error about failed BOID lookup:
INFO: Failed BOID lookup for BLID "90398pb005", this BLID is unknown to BrickOwl. Item name (M) : "Nick Fury Statuette".
INFO: Failed BOID lookup for BLID "90398pb003", this BLID is unknown to BrickOwl. Item name (M) : "Hawkeye Statuette".
Hi Paul, the reason seems to be quit simple: Looks like these blid's have been attached to the 'colored' entry instead of the uncolored 'base' entry. BL considers these 'minifigs', so always uncolored, if you sync they will try to sync to a color while your listing is uncolored, so it's a basic mismatch caused by a submitter who doesn't really know quite well 'where' a BLID should be attached to (must always be the 'uncolored' version). I'll submit the numbers to the 'uncolored' version (others have been wrongly attached as well), soon approved they should resolve correctly.
So BS does see this numbers in the BO database, so rejects a submittance of these, and the owlresolve rejects them because the color doesn't match with yours ;-)
Cheers, Eric
The owlsubmitblid command checks if the BLID resolves to anything for all item types, while owlresolve will only attempt to resolve a BL minifig BLID under the BO types "Minifig" and "Minibuild". Note that the software has to be careful about attempting to resolve under different types, there are BLID collisions across different item types.
I think this may be the first case of a BL Minifig matching a BO Part. I'll check if adding that fallback path could lead to any erroneous lookups... For the moment, note that you could use the owlforceblid command.
Thanks for the extra input :-)
Do you think changing the BLID's towards the uncolored parent shouldn't resolve things when syncing? I always assumed BS does not check 'item type' when it tries to sync and purely looks for the BLID itself?
btw: It won't be the last one where something is considered 'differently' on both sites, I see potential issues comming up with the Angry Birds Pigs as well. I have been working on them and some are going to be treated 'minifig' (if they have no accessories) and others as 'parts', if they have additional accessories. Dunno how BL is going to deal with them (no inventories last time I looked), so for now I'm holding back on them...
That would also help with another problem item that I found: the parrot 2546p02 "Bird with Parrot Marbled Red Pattern" is known on BO as "Parrot with Green Feathers Pattern" with BOID 859909. So on BL it should be listed in color green while on BO it should be listed with color red.
Besides minifigs becoming parts between marketplaces, I didn't anticipate non-matching colors either.
I don't see an easy solution to this... I think I/we will have to maintain some kind of override/correction list, probably hosted on www.bricksync.net, that the next version of the software would monitor for updates regularly.
Hopefully that list of corrections will remain short!
That idea could work. It would certainly be easier than having every seller manually adding them to their own list and these are situations where the BL and BO entries would refer to exactly the same items so every seller would want to sync them.
In addition to that there are also some issues that I ran into with minifigure inventorying standards being different between the sites. I have some Friends minifigures that are inventoried on BL with headgear accessories such as bows, flowers, sunglasses or tiaras. BO inventories them without those accessories which is why they don't have a BLID attached to them. I used owlforceblid to list those minifigures on BO because buyers probably won't mind getting an extra bow, flower or tiara with their minifigures.
But those should probably not be added to an override/correction list because sellers might not include those accessories with their minifigs if they list minifigures based on the BO inventories. That could lead to complaints from BL buyers about missing accessories if those sellers list their minifigures on BL.
He was right of course, since the inventories don't match exactly... And yet that's the kind of thing I would be tempted to override. If the seller's original inventory came from BL, I expect no BO customer will complain about receiving an extra $0.05 minifig accessory.
There are other mismatches between the 2 sites, personally I skip them out from syncing to avoid problems (it's not loke 2 dozens items are going to make a difference for a store)
The 'ghost legs' is another example of those color mismatches.
http://www.brickowl.com/catalog/lego-minifigure-ghost-legs-19859
I'm surprised to hear @lawrence does not approve BLID's for the friends girls with bows and flowers and such as indeed the BO buyer would end up with 'more' then what they ordered compared to the BO inventory, logically this should not be a problem at all. Could you reconsider Lawrence?
Another known issue are CMF packages in regards to 'random' packages, due to the different numbering system, the random package on BL resorts to the first 'non random' CMF on BO, so never never never list a random package on BL and then sync !! example: 71014-1 (random) on BL is Joachim Löw on BO:
http://www.brickowl.com/search/catalog?query=71014-1
These random baggies should have a forced 'unmapping' from within BS (so the opposite method).
Paul, also keep in mind BO does not support 'binded' lot's, if you have any, it might be wise to skip those out as well (for example, I skip out sails, as I usually bind sails of a set together on BL to sell them as a complete set of sails).
And I sure hope you will put in energy in contributing to this catalog, this site can really use a few extra pair of hands in regards to adjusting and adding data, and knowing you that should make an awesome difference in the long run :-)
PS stickers are not sepperated here between 'NA version' and 'international version', so both blids (or 3 if there is an undetermind version as well) can be attached to the same entry ;-)
Stickers do have a color on BO, but they do not cause a mismatch at all when syncing, so nothing to worry about.
And something not related to mapping BLID to BOID: Bricksync apparently does not create tiered pricing when it syncs an item for the first time. I first noticed this when I ran Bricksync for the first time to copy my Bricklink inventory to Brick Owl. None of my items had their tiered pricing on Brick Owl. Tiered prices were only created for those items when I ran the "sync brickowl" command after some of my BLID submissions had been approved. But the newly created lots at that time did not have their tiered prices.
I guess all this underlines the need for a separate list of overrides/corrections. I'll look into that.
BLID 21008pb01 does not seem to cause any errors, because those actually exist in those 4 colors, the attached BOIDs might differ but that is completely irrelevant as those are just randomised (no structure) and might be due to the fact they where not attached to a parent to begin with (so each their BOID). Syncing therefor should not cause you any trouble (because it's BLID + color that makes the match). Unless you noticed something else that doesn't look on those ?
COMMAND: owlqueryblid 74188c01
INFO: The BLID "74188c01" does not resolve to any BOID.
COMMAND: owlsubmitblid 879856 74188c01
INFO: The BLID "74188c01" already resolves to the BOID 879856.
INFO: No update was submitted to the BrickOwl catalog.
???
And how is that magnet a "gear"? That is slightly messed up. Gears are supposed to be complete items/mini-sets sold as such, a magnet part (found in several Gears) doesn't qualify at all.
21:34:38 INFO: Runfile command: "owlsubmitdims *59377 101 101 0.3"
21:34:38 ERROR: Usage is "owlsubmitdims ID length width height".
Even stickers seem to have a thickness of zero, though I haven't checked if the web interface allows/displays floating point values. Are there other stickers with 0.3mm of thickness?
I'm really due for pushing a new version with all this, eh.
Alexis, thanks for changing and adding size dimensions with non-integer numbers, had been an issue indeed for a long time (I guess I could have mentioned it earlier on), reason I've always submitted 'parts' and 'sticker' dimensions straight on BO, and only used the txt imports on 'figs' (rounded values=less a problem).
Submitting 3 sizes when 1 or more sizes are already in catalog (like with stickers) is also indeed a problem as Paul states, as BO seems to refuse the submission (@Lawrence: even when it differs from the existing size) once 1 size is already in catalog. So Pauls suggestion is legit: we would need to be able to skip out a size (maybe a syntax like L=22 W=60 H=, if no fill= no submittance, but that would depend on the API call Lawrence has created for such).
Lawrence recently told me that he updated the DNS for the BrickOwl API server, and that he noticed traffic was still hitting the old IP (it's cached within BrickSync until the software is restarted).
Can you try restarting BrickSync and see if that solves it?
Thanks for your answers ;)