Negative on that, you should stop editing inventory through BL or BO (unless items are flagged by '~' in remarks not to be synchronized). If you want to add inventory, use the command add MyBrickStockFile.bsx. Also, see the post above about a "verbose guide how to part out a set with BrickStock and BrickSync".
Would you consider, after your current code set is stable, to create a variant or option that allows the user to define either BL or BO as the "master" and the other as the "slave"? This is probably unique to only the large stores, but we have multiple employees working concurrently. Running through a single PC program won't work for us. We need to be able to manually adjust quantities "on the fly". The staff know they can do this in BL, and I manually sync daily. I might even be willing to pay for this feature. You can PM me if interested. Thanks. -Jason
@DadsAFOL So the program would fetch the whole BrickLink inventory regularly, and instead of seeing any discrepancy as an error to correct, it would rather see it as a change to propagate to BrickOwl. It seems a simple change, although a bit trickier to make robust...
Let's suppose we are in the middle of pushing updates for a BO order to BL, and we never receive a reply to a query (clogged internet tubes, power cut, etc.), therefore having no idea if it succeeded or not. The software can't just compare the current BL inventory to continue the update where it left: it needs to be able to differentiate between our partial BO order updates and external updates. That can be achieved by temporarily appending special markers to item remarks, later removing them to confirm the changes were applied... but that breaks down if your staff is also allowed to edit item remarks.
I'm sure we can figure out something that's robust and compatible with your workflow. Let's wait until BrickSync is out of beta though.
@EricHamby, I assume the file data\errors-2014-09-30\00000.txt contains the "invalid condition" errors you refer to.
I need to see the latest log file in data\logs, to see what exactly it is trying to upload that is being rejected by BrickOwl. It could be new condition codes for a different category of item... (that stuff isn't exactly well documented). I'll then fix it and upload a new version.
Can you send me by private message the ~50 lines from the log file around the first warning? Thanks!
@EricHamby After a quick test, I'm pretty sure the error is related to having "Gear" type items. I'll troubleshot and fix that tomorrow. Thank you for finding bugs!
In the meantime, version 0.18 uploaded: - Fixed a potential completeness status glitch when uploading new sets to BrickLink. - BrickSync is now tracking usage of API calls over the past 24 hours. You can monitor API usage with the status command, but a future version will use that information to avoid hitting BrickLink's limit of 5000 calls per day (delaying lower priority updates and outputting XML files for optional manual upload). - New command: consolidate to merge all identical lots (sharing the same ID, color and condition). It will also list identical lots that differ in their comments or remarks, but will not merge them. After reviewing, if you want to also merge such lots, you can run consolidate -f (with -f being the flag to force a command). - Some other commands also now print warnings which can be overriden with the -f flag (such as when uploading items with no remarks or with a price of 0.00). - Some other stuff.
Version 0.20 uploaded: - The code is now probably robust to handle duplicate lots (same ID, color and condition) after fixing a related glitch and reviewing a bunch of code. Though, when adding new inventory from a BSX file, it will still add the items to the first match it finds (unless there's a LotID match).
And special thanks to PSBricks and budgetkids, amazing beta testers.
Version 0.21 uploaded: - When multiple identical lots (same ID:color:condition) were created at the same time (add command), LotID/OwlLotID could be incorrectly assigned back to the main inventory. When receiving orders for these items, this could later lead to warnings and automatic sync to figure out what's going on. That's fixed. - Better handling of items known to BrickOwl but for which lot creation still fails for other reasons (part 97122, I'm looking at you!). When the server rejects creation of our lot, the operation will be attempted again if a sync command is issued. - New command: loadall to update prices, comments (public notes), remarks (private notes) and bulk from a specified BrickStore/BrickStock .bsx file all at once. As usual, only matching lots are updated and only the modified lots are issued API calls. - More verbose warning/error messages, without having to consult logs. (though *please* still send me log files if you suspect any bug)
Though I didn't have that in mind when I originally wrote the code, multiple identical lots should now be fully supported. Probably. All the commands add, sub, loadprices, loadnotes, loadall, merge will still apply to the first match found (lotID match, otherwise first ID:color:condition match).
The long-awaited Chinese translation of BrickSync is available at last! Okay sorry, that was a bad pun, for those in the know.
Instead, for version 0.23, we get: - New command: evalset to evaluate a set for partout, also optionally output a .bsx file for inspection with per-part evaluation statistics stored in comments (when a part has alternates, the cheapest one is assumed to be the right one). - New command: partout to produce a .bsx file very similar to evalset, but all part alternates are kept and identified as such in the comments fields (as well as being flagged "Extra"). - Other minor corrections and improvements.
Some screenshot of evalset: Note that set inventories or price guides are fetched without consuming precious daily API calls, and that the price guide data is cached in a format that is fully compatible with either BrickStore or BrickStock. There are several new variables in bricksync.conf.txt, I suggest editing priceguide.cachepath and priceguide.cacheformat so that BrickSync can share the same price guide cache as BrickStore or BrickStock.
BrickSync development may slow down a bit. It's fun but it doesn't pay the bills, and the day job's work has been pilling up a little.
I feel I may be mostly talking to myself in this thread!... but since there are several BrickSync users, I figure they may be interested in public updates.
BrickSync 0.24 uploaded: - Since we approach the end of beta testing, the limitation of inventory size has been removed. Though, if your inventory holds more than 250000 parts, you'll be kindly invited to support BrickSync or you'll be asked a small mathematical question/puzzle to "check" for new orders. Sounds fun, eh? - Various other improvements.
By all means you are in no way talking to yourself! Your program has saved us many hours of manually syncing our inventory. You should see me when I see a new post from you.
"Oh look! There is a BrickSync update! I wonder what cool new features were added this time?"
You are welcome, budgetkids! I'm glad it's appreciated.
Let's see, what's new in version 0.26 : - Automated management of the limit of 5000 BL API calls per day - Added support for unusual BL order status: NPB NPX NRS NSS OCR - Other minor improvements and corrections (as usual, an update is recommended)
When running low on BL API calls, BrickSync may now automatically output XML files to upload manually to BL. That being said, you can safely ignore all requests to upload XML files. When the pool of API calls reaches a healthy level again, BrickSync will (after deleting said XML files) check by itself if changes from the XML files have been applied or not (standard sync operation), and resume where it left if necessary. The most significant changes are always prioritized over less important ones.
So, let's suppose you update prices for 14000 lots (using loadprices NewPrices.bsx). It will update the most significant changes and produce several XML files (BL doesn't take XML files above 204800 bytes, so that would be a few files). You can either manually upload the produced XML files, or you can let BrickSync finish the whole update over a couple days.
BrickOwl obviously has none of these issues, all updates are applied straight away.
P.S. BrickSync could be made to submit XML updates itself directly, but this would require BL login information and I wouldn't feel comfortable with that (nor should anyone).
Version 0.27 uploaded (OSX delayed due to remote mac mini to compile not responding): - Bug fix, some threading race condition related to the management of socket recv buffers in specific circumstances (bug can't cause any actual harm, three cheers for data journalling). Thanks budgetkids!
My to-do list prior to BrickSync's non-beta release is getting pretty thin, almost empty I would say.
I'm not fond of the suggested feature to establish BO or BL as a "master" inventory, due to the potential but serious robustness problems that would be encountered by BrickSync updates being interrupted while external agents (not orders) are simultaneously modifying the same items. That risk is indeed small, but I think writing software that is non-robust by design conflicts with my programming ethics.
So... next project: BrickStore-style inventory management software able to connect directly to BrickSync, to display and edit a live inventory (and much more!).
If anyone was wondering its working fine on W/10. Also anyway it can download BO orders in the way it does BL?
Cool for W10 , I'm only testing Windows XP 64 bits on an old laptop.
All new orders, both from BO and from BL, should be saved as BSX files in data/orders/
During initialization, it only downloads past BL orders though, which I guess is what you are asking. Unfortunately, it couldn't save BO orders as BSX because it may not have all the data for the BOID->BLID translation. The BLID<->BOID translation database is built on the fly but it has to see the BLIDs first (and I couldn't distribute BrickSync with a complete BLID<->BOID database, since BL forbids distributing their intellectual property of BLIDs).
If anyone was wondering its working fine on W/10. Also anyway it can download BO orders in the way it does BL?
Cool for W10 , I'm only testing Windows XP 64 bits on an old laptop.
All new orders, both from BO and from BL, should be saved as BSX files in data/orders/
During initialization, it only downloads past BL orders though, which I guess is what you are asking. Unfortunately, it couldn't save BO orders as BSX because it may not have all the data for the BOID->BLID translation. The BLID<->BOID translation database is built on the fly but it has to see the BLIDs first (and I couldn't distribute BrickSync with a complete BLID<->BOID database, since BL forbids distributing their intellectual property of BLIDs).
I'm not fond of the suggested feature to establish BO or BL as a "master" inventory, due to the potential but serious robustness problems that would be encountered by BrickSync updates being interrupted while external agents (not orders) are simultaneously modifying the same items. That risk is indeed small, but I think writing software that is non-robust by design conflicts with my programming ethics.
I can probably figure this out if I run the software, but I'm still pretty nervous. The way I asked/suggested probably wasn't exactly right. Let me try it this way: How does the user control resolving variances? For example, if lot 1234 has quantity 10 on BL and quantity 5 on BO, can I specify "10" or "5" as the correct quantity? So in my case if someone manually changes an inventory on one side or the other, can I control whether that change gets accepted (pushed to the opposite side) or rejected (reverted to the prior value)?
On a separate note related to the to-do list, were you able to find a way to filter/exclude the MOC Shop created inventory lots?
Also, can you mention how you handle "deleting" a lot on BO (relevant to the consolidation of lots)? There doesn't appear to be a BO API documented function to delete a lot.
@DadsAFOL Only for the first time BrickSync is run, it will make sure the inventory on BO exactly matches the one on BL (after you have agreed to the proposed changes). There's one big exception: all items with the character ~ anywhere in remarks (or private notes) will be skipped. It may be necessary to flag all lots reserved for the MOC Shop... Do these lots appear when fetching /api/store/v1/inventories with status=Y? (If they are in some sort of stockroom, then that makes things easier) Consult the log files to be sure.
After that first initialization, the "master" inventory doesn't reside in either of BL or BO, it resides in BrickSync. If BrickSync finds anything that doesn't match the BrickSync inventory on BL or BO (except lots flagged with ~, which it doesn't see), it will be corrected to match. The BrickSync inventory can be found at data/bricksync.inventory.bsx
Manually changing quantities should go through BrickSync (add SomeEditFile.bsx with positive and/or negative quantities, or even setquantity BlLotID +40, setquantity 3001:11:N 314, etc.). I realize it's not quite compatible with your workflow, you would need client software able to connect to BrickSync from multiple workstations.
The software indeed can't delete BO lots, but lots disappear from view entirely in the API when the quantity reaches zero. For all practical purposes, they are deleted from BrickSync's point of view.
Right now, during first initialization, if BO shows 3part, BL shows 8 parts, then BrickSync will change BO part up to 8. I believe what is being asked is if DadsAFOL can make it instead BL would go down to 3.
Speaking of client software, this is related to your other post. You would make a program that would work on various workstations and be editable in the client and then have it uploaded 'instantly' to both websites? That would certainly be nice!
Speaking of client software, this is related to your other post. You would make a program that would work on various workstations and be editable in the client and then have it uploaded 'instantly' to both websites?
Yup, that's the idea, along with offline inventory management. It could take a little while though (it's simple stuff but I have never done GUIs before).
And... version 0.28 uploaded: - Bug fix related to the MUST_SYNC flag not being automatically set when some queries are left without a reply during Init (a manual sync would still check and fix anything). - Little bug fix related to multiple commands outputing BL XML files due to running low on daily BL API calls; we want to create new files, not overwrite previous ones that haven't been applied yet. Note that pending XML files are removed when a sync (manual or automated) checks if the XML was applied or not, and new XML files may be produced if the daily API pool is still too low.
Ok, I am about to see how this program works. There is one thing that worries me a bit:
You opening posts says: - There is NO support for multiple lots of identical items (same ID, same color, same condition). Please don't do that. I'm not sure what features will break exactly, but bad stuff will happen.
Maybe I don't understand it correctly (the same ID part), but say: I have 2 similar sets: 1 with, and 1 without instructions. Or parts, but 1 has a scratch or whatever. Both used, good, however I wan't to list 1 set cheaper because of the missing instructions. Does that meet your requirement in order to make bad stuff happen?
Ok, I am about to see how this program works. There is one thing that worries me a bit:
That was true for the initial beta release (and I can't edit the first post!!1one). Multiple identical lots should now be fully supported, you should be safe from the bad stuff.
@BrickItOn Oh, 32 bits. All right, I'll produce packages for that later today.
On the topic of multiple identical lots, there's a small problem... Existing duplicate lots are fine, but the BL API doesn't allow creation of a new lot when an identical item already exists (in any stockroom), it throws some error: "Invalid Data Status: An inventory with the same item already exists". (You have no idea how many issues/bugs there are in BL's API!)
Also, version 0.30 uploaded: - New experimental "BL master" mode, through the blmaster [on/off] command. See below for details. - New experimental option to retain empty lots (retainemptylots = 1; in data/bricksync.conf.txt). When enabled, empty lots aren't deleted on BO, BL or the tracked inventory. - New command: delete ItemIdentifier to truly delete an item even when retainemptylots is enabled. - The help command had an update, most commands now have at least a few lines of documentation. - Other stuff.
Despites what I posted earlier, some kind of robust BrickLink master mode has been implemented. So, here's how it works: 1) Type: blmaster on. All operations (including order checking) are suspended, BrickSync shall wait until you are done. 2) Edit the inventory on BL as much as your heart desires. 3) Type: blmaster off. All changes are integrated and synchronized, including new BO and BL orders that may have arrived while in BL master mode. 4) Directly editing inventory on BO or BL is forbidden again. The galaxy is at peace...
Wait, so I can stop initializing from scratch all the time as long as I use the "blmaster" command?
Yes, that's the idea, you weren't the only one initializing from scratch to keep editing on BL. And there's no risk related to orders arriving at the same time when "blmaster" is used.
I think the beta testing phase of BrickSync is about over. This thread is now also full of obsolete, contradicting and incorrect information. Starting a new thread could help make the first post not entirely inaccurate... This little project has grown more than I had thought, it could even use a website of some sort.
Version 0.32 uploaded: - Improved registration handling through custom 1024 bits asymmetric encryption. (Note again that an unregistered copy works perfectly well. If your inventory has over 250000 parts, it just asks a small math question to check orders (to keep that mind sharp and agile!).) - Various small improvements.
I currently manually have to create bsx files of my BrickOwl orders to make a pull list for my inventory. Is there a way to use BrickSync to just pull my BrickOwl orders in to bsx without syncing with BL?
I currently manually have to create bsx files of my BrickOwl orders to make a pull list for my inventory. Is there a way to use BrickSync to just pull my BrickOwl orders in to bsx without syncing with BL?
Not out of the box unfortunately, that would involve disabling various big chunks of code...
I have noticed you were present on both BO and BL, do you ask because you already have your own software except for that part? If you want to keep using other software for related tasks, perhaps BrickSync's interoperability could be improved to communicate with external software...
Yes, I'm using the brickpacker service. It works really well, except that the way that I pull orders involves creating a bsx which I'm doing manually at the moment. Painful for any orders over 10 lots, but of course not a fault of the software or service, just my own need.
I love the functionality of Bricksync, fantastic job! I'm a little hesitant to switch over yet, as my current process is working, but it is a bit tedious. If some of the functions could be used as standalone commands to control the process a bit more (especially the downloading of orders as bsx. Like a universal translator or BL / BO babblefish!) I would use it extensively to supplement the brickpacker service.
I was thinking that even if I could disable the authentication to BL and force a BO check, that might work, but the program exits of course.
Again, great job and I'm going to keep playing with it!
Ah, right. Well, the BrickOwl API only allows BLID->BOID translation, therefore BrickSync builds a translation cache of all the items it sees passing by. Such a cache allows to perform the reverse BOID->BLID translation, necessary to save BrickOwl orders as BSX files (LotID matching is actually the primary mechanism but never mind that).
I assume the BrickPacker service also maintains a very similar cache/database of BLID->BOID translation, so performing the inverse translation should be fairly simple from there. Perhaps you could ask them for a way to get BrickOwl orders as BSX? I don't think it would involve too much new code.
Thanks again! I'll check and see if this is a possibility. I just can't see it being that difficult, but I just don't have time to mess around with the coding of it, especially when you and Superbrick have done such a good job of it already.
Not sure how you would like us to report on Bricksync, but I found a problem. I received an order via BL, and it contained an item not in my BO shop along with 10 other lots that were in both shops. I received the message that no BO update was required because the inventory was a perfect match. I manually checked the BO store, and sure enough, the inventories on at least two items was out of sync.
I manually ran the deep sync process, and that seemed to fix the problem.
Ah yes, it seems there was some unforeseen interference from the (experimental) "retainemptylots" option. A manual "sync" would of course fix anything.
thank you so much for this program its a real time saver atm ! a question is it possible to maintain 2 separated prices for bl and bo and determine the optimal price based on supply and demand .
@pwpeter Prices are synchronized, but you can run different sales on each marketplace.
Finding "optimal" selling prices depends on a myriad of factors (including supply and demand). That complex topic is outside the scope of BrickSync, so let's leave that as an exercise to the reader.
Allright, so I ran into a big problem, which was that the software looked for my old BO order and updated BL accordingly. By which I mean it tried to update bricklink with the 200 orders I've had on this website before today, which resulted in destroying my inventory in bricklink.
Luckily, you built the program with nice logging and the backups as failsafe, so I was able to recover my inventory previous to today. But maybe that's a problem that needs to be solved? Not suire if I explained correctly...
@stragus thanks for quick reponse, i will look into the new thread on the forum.
If I set the program onn blmaster on and change the prices on bricklink let say 10% sale. it does not change the prices on brickowl. Thus if I understand it correctly, the program ;syncs the items but if I change the prices on BO or BL it does not change these prices in the tracked inventory ?
I'm looking for a command which can do something like this : setprices to current average [BL/BO] for the whole inventory ? because brickstock calculates only the prices in dollars while bricklink thinks it are the prices in euros so if i use the loadprices command I get the wrong prices without manually adjusting it.
@brick_top what I did the first time was removed the BO and BL inventories from both website (ofcourse make a backup first !!). thereafter filled in the init file with the api keys as mentioned on the bricklink and bricksync website.
Then the software runs a first time sync. when this is done use the add command to update your inventory to both websites. after this point all the processing of others and inventory changes will be excuted automatically when the bricksync software is runned.
with loadprices and loadcomment it is possible to set the prices and the condition of the parts (important for BO).
if you need more help, just pm me. skype is also possible.
Thank you for the offer @pwpeter, I understood it in the end, but it was counterintuitive I think, to sync old orders. Also, do you need to use loadprices for the prices? Aren't the prices automatically loaded from BL?
What I have done is delete my BO inventory, and let it sync with my BL inventory.
@Brick_Top I'm not quite following... BrickSync only propagates new orders, it doesn't processes old orders before the initialization point. That's why it makes sure the two inventories match exactly when it's run for the first time.
Or did you run an old installed copy of BrickSync that was already initialized months ago?
Comments
Let's suppose we are in the middle of pushing updates for a BO order to BL, and we never receive a reply to a query (clogged internet tubes, power cut, etc.), therefore having no idea if it succeeded or not. The software can't just compare the current BL inventory to continue the update where it left: it needs to be able to differentiate between our partial BO order updates and external updates. That can be achieved by temporarily appending special markers to item remarks, later removing them to confirm the changes were applied... but that breaks down if your staff is also allowed to edit item remarks.
I'm sure we can figure out something that's robust and compatible with your workflow. Let's wait until BrickSync is out of beta though.
I need to see the latest log file in data\logs, to see what exactly it is trying to upload that is being rejected by BrickOwl. It could be new condition codes for a different category of item... (that stuff isn't exactly well documented). I'll then fix it and upload a new version.
Can you send me by private message the ~50 lines from the log file around the first warning? Thanks!
In the meantime, version 0.18 uploaded:
- Fixed a potential completeness status glitch when uploading new sets to BrickLink.
- BrickSync is now tracking usage of API calls over the past 24 hours. You can monitor API usage with the status command, but a future version will use that information to avoid hitting BrickLink's limit of 5000 calls per day (delaying lower priority updates and outputting XML files for optional manual upload).
- New command: consolidate to merge all identical lots (sharing the same ID, color and condition). It will also list identical lots that differ in their comments or remarks, but will not merge them. After reviewing, if you want to also merge such lots, you can run consolidate -f (with -f being the flag to force a command).
- Some other commands also now print warnings which can be overriden with the -f flag (such as when uploading items with no remarks or with a price of 0.00).
- Some other stuff.
- The code is now probably robust to handle duplicate lots (same ID, color and condition) after fixing a related glitch and reviewing a bunch of code. Though, when adding new inventory from a BSX file, it will still add the items to the first match it finds (unless there's a LotID match).
And special thanks to PSBricks and budgetkids, amazing beta testers.
http://www.rayforce.net/bricksync-osx64-003.tar.gz
But I'm just unable to edit the first post to add the link there.
The OSX version is completely untested, but since the OS is Unix based, I wouldn't expect any problem. Please let me know otherwise!
- When multiple identical lots (same ID:color:condition) were created at the same time (add command), LotID/OwlLotID could be incorrectly assigned back to the main inventory. When receiving orders for these items, this could later lead to warnings and automatic sync to figure out what's going on. That's fixed.
- Better handling of items known to BrickOwl but for which lot creation still fails for other reasons (part 97122, I'm looking at you!). When the server rejects creation of our lot, the operation will be attempted again if a sync command is issued.
- New command: loadall to update prices, comments (public notes), remarks (private notes) and bulk from a specified BrickStore/BrickStock .bsx file all at once. As usual, only matching lots are updated and only the modified lots are issued API calls.
- More verbose warning/error messages, without having to consult logs. (though *please* still send me log files if you suspect any bug)
Though I didn't have that in mind when I originally wrote the code, multiple identical lots should now be fully supported. Probably.
where i have to enter the api keys?
http://www.brickowl.com/forum#/discussion/2627/bricksync-inventory-synchronization-software/p1
Instead, for version 0.23, we get:
- New command: evalset to evaluate a set for partout, also optionally output a .bsx file for inspection with per-part evaluation statistics stored in comments (when a part has alternates, the cheapest one is assumed to be the right one).
- New command: partout to produce a .bsx file very similar to evalset, but all part alternates are kept and identified as such in the comments fields (as well as being flagged "Extra").
- Other minor corrections and improvements.
Some screenshot of evalset:
Note that set inventories or price guides are fetched without consuming precious daily API calls, and that the price guide data is cached in a format that is fully compatible with either BrickStore or BrickStock. There are several new variables in bricksync.conf.txt, I suggest editing priceguide.cachepath and priceguide.cacheformat so that BrickSync can share the same price guide cache as BrickStore or BrickStock.
BrickSync development may slow down a bit. It's fun but it doesn't pay the bills, and the day job's work has been pilling up a little.
BrickSync 0.24 uploaded:
- Since we approach the end of beta testing, the limitation of inventory size has been removed. Though, if your inventory holds more than 250000 parts, you'll be kindly invited to support BrickSync or you'll be asked a small mathematical question/puzzle to "check" for new orders. Sounds fun, eh?
- Various other improvements.
"Oh look! There is a BrickSync update! I wonder what cool new features were added this time?"
Much appreciated!
Chris
Let's see, what's new in version 0.26 :
- Automated management of the limit of 5000 BL API calls per day
- Added support for unusual BL order status: NPB NPX NRS NSS OCR
- Other minor improvements and corrections (as usual, an update is recommended)
When running low on BL API calls, BrickSync may now automatically output XML files to upload manually to BL. That being said, you can safely ignore all requests to upload XML files. When the pool of API calls reaches a healthy level again, BrickSync will (after deleting said XML files) check by itself if changes from the XML files have been applied or not (standard sync operation), and resume where it left if necessary. The most significant changes are always prioritized over less important ones.
So, let's suppose you update prices for 14000 lots (using loadprices NewPrices.bsx). It will update the most significant changes and produce several XML files (BL doesn't take XML files above 204800 bytes, so that would be a few files). You can either manually upload the produced XML files, or you can let BrickSync finish the whole update over a couple days.
BrickOwl obviously has none of these issues, all updates are applied straight away.
P.S. BrickSync could be made to submit XML updates itself directly, but this would require BL login information and I wouldn't feel comfortable with that (nor should anyone).
- Bug fix, some threading race condition related to the management of socket recv buffers in specific circumstances (bug can't cause any actual harm, three cheers for data journalling). Thanks budgetkids!
My to-do list prior to BrickSync's non-beta release is getting pretty thin, almost empty I would say.
I'm not fond of the suggested feature to establish BO or BL as a "master" inventory, due to the potential but serious robustness problems that would be encountered by BrickSync updates being interrupted while external agents (not orders) are simultaneously modifying the same items. That risk is indeed small, but I think writing software that is non-robust by design conflicts with my programming ethics.
So... next project: BrickStore-style inventory management software able to connect directly to BrickSync, to display and edit a live inventory (and much more!).
All new orders, both from BO and from BL, should be saved as BSX files in data/orders/
During initialization, it only downloads past BL orders though, which I guess is what you are asking. Unfortunately, it couldn't save BO orders as BSX because it may not have all the data for the BOID->BLID translation. The BLID<->BOID translation database is built on the fly but it has to see the BLIDs first (and I couldn't distribute BrickSync with a complete BLID<->BOID database, since BL forbids distributing their intellectual property of BLIDs).
On a separate note related to the to-do list, were you able to find a way to filter/exclude the MOC Shop created inventory lots?
After that first initialization, the "master" inventory doesn't reside in either of BL or BO, it resides in BrickSync. If BrickSync finds anything that doesn't match the BrickSync inventory on BL or BO (except lots flagged with ~, which it doesn't see), it will be corrected to match. The BrickSync inventory can be found at data/bricksync.inventory.bsx
Manually changing quantities should go through BrickSync (add SomeEditFile.bsx with positive and/or negative quantities, or even setquantity BlLotID +40, setquantity 3001:11:N 314, etc.). I realize it's not quite compatible with your workflow, you would need client software able to connect to BrickSync from multiple workstations.
The software indeed can't delete BO lots, but lots disappear from view entirely in the API when the quantity reaches zero. For all practical purposes, they are deleted from BrickSync's point of view.
Speaking of client software, this is related to your other post. You would make a program that would work on various workstations and be editable in the client and then have it uploaded 'instantly' to both websites? That would certainly be nice!
Chris
And... version 0.28 uploaded:
- Bug fix related to the MUST_SYNC flag not being automatically set when some queries are left without a reply during Init (a manual sync would still check and fix anything).
- Little bug fix related to multiple commands outputing BL XML files due to running low on daily BL API calls; we want to create new files, not overwrite previous ones that haven't been applied yet. Note that pending XML files are removed when a sync (manual or automated) checks if the XML was applied or not, and new XML files may be produced if the daily API pool is still too low.
You opening posts says:
- There is NO support for multiple lots of identical items (same ID, same color, same condition). Please don't do that. I'm not sure what features will break exactly, but bad stuff will happen.
Maybe I don't understand it correctly (the same ID part), but say: I have 2 similar sets: 1 with, and 1 without instructions. Or parts, but 1 has a scratch or whatever.
Both used, good, however I wan't to list 1 set cheaper because of the missing instructions.
Does that meet your requirement in order to make bad stuff happen?
However: now I am supposed to let you know I am using a 32 bit machine
On the topic of multiple identical lots, there's a small problem... Existing duplicate lots are fine, but the BL API doesn't allow creation of a new lot when an identical item already exists (in any stockroom), it throws some error: "Invalid Data Status: An inventory with the same item already exists". (You have no idea how many issues/bugs there are in BL's API!)
This is what BrickSync feels like lately.
(Credits: http://www.xkcd.com/ )
http://www.rayforce.net/bricksync-win32-003.zip
Also, version 0.30 uploaded:
- New experimental "BL master" mode, through the blmaster [on/off] command. See below for details.
- New experimental option to retain empty lots (retainemptylots = 1; in data/bricksync.conf.txt). When enabled, empty lots aren't deleted on BO, BL or the tracked inventory.
- New command: delete ItemIdentifier to truly delete an item even when retainemptylots is enabled.
- The help command had an update, most commands now have at least a few lines of documentation.
- Other stuff.
Despites what I posted earlier, some kind of robust BrickLink master mode has been implemented. So, here's how it works:
1) Type: blmaster on. All operations (including order checking) are suspended, BrickSync shall wait until you are done.
2) Edit the inventory on BL as much as your heart desires.
3) Type: blmaster off. All changes are integrated and synchronized, including new BO and BL orders that may have arrived while in BL master mode.
4) Directly editing inventory on BO or BL is forbidden again. The galaxy is at peace...
Chris
P.S. I like the image you shared!
Version 0.32 uploaded:
- Improved registration handling through custom 1024 bits asymmetric encryption. (Note again that an unregistered copy works perfectly well. If your inventory has over 250000 parts, it just asks a small math question to check orders (to keep that mind sharp and agile!).)
- Various small improvements.
I currently manually have to create bsx files of my BrickOwl orders to make a pull list for my inventory. Is there a way to use BrickSync to just pull my BrickOwl orders in to bsx without syncing with BL?
Thanks!
Cory
I have noticed you were present on both BO and BL, do you ask because you already have your own software except for that part? If you want to keep using other software for related tasks, perhaps BrickSync's interoperability could be improved to communicate with external software...
I love the functionality of Bricksync, fantastic job! I'm a little hesitant to switch over yet, as my current process is working, but it is a bit tedious. If some of the functions could be used as standalone commands to control the process a bit more (especially the downloading of orders as bsx. Like a universal translator or BL / BO babblefish!) I would use it extensively to supplement the brickpacker service.
I was thinking that even if I could disable the authentication to BL and force a BO check, that might work, but the program exits of course.
Again, great job and I'm going to keep playing with it!
I assume the BrickPacker service also maintains a very similar cache/database of BLID->BOID translation, so performing the inverse translation should be fairly simple from there. Perhaps you could ask them for a way to get BrickOwl orders as BSX? I don't think it would involve too much new code.
Not sure how you would like us to report on Bricksync, but I found a problem. I received an order via BL, and it contained an item not in my BO shop along with 10 other lots that were in both shops. I received the message that no BO update was required because the inventory was a perfect match. I manually checked the BO store, and sure enough, the inventories on at least two items was out of sync.
I manually ran the deep sync process, and that seemed to fix the problem.
Suggestions?
Thanks!
Version 1.0.3 uploaded with the fix:
http://www.bricksync.net/
Thanks!
a question is it possible to maintain 2 separated prices for bl and bo and determine the optimal price based on supply and demand .
Finding "optimal" selling prices depends on a myriad of factors (including supply and demand). That complex topic is outside the scope of BrickSync, so let's leave that as an exercise to the reader.
P.S. This old thread is full of obsolete information from the first beta, the previous post was 7 months old. That thread is more up-to-date:
http://www.brickowl.com/forum#/discussion/2719/bricksync-website-and-release-version/p1
And of course:
http://www.bricksync.net/
Luckily, you built the program with nice logging and the backups as failsafe, so I was able to recover my inventory previous to today. But maybe that's a problem that needs to be solved? Not suire if I explained correctly...
If I set the program onn blmaster on and change the prices on bricklink let say 10% sale. it does not change the prices on brickowl. Thus if I understand it correctly, the program ;syncs the items but if I change the prices on BO or BL it does not change these prices in the tracked inventory ?
I'm looking for a command which can do something like this : setprices to current average [BL/BO] for the whole inventory ? because brickstock calculates only the prices in dollars while bricklink thinks it are the prices in euros so if i use the loadprices command I get the wrong prices without manually adjusting it.
@brick_top what I did the first time was removed the BO and BL inventories from both website (ofcourse make a backup first !!). thereafter filled in the init file with the api keys as mentioned on the bricklink and bricksync website.
Then the software runs a first time sync. when this is done use the add command to update your inventory to both websites. after this point all the processing of others and inventory changes will be excuted automatically when the bricksync software is runned.
with loadprices and loadcomment it is possible to set the prices and the condition of the parts (important for BO).
if you need more help, just pm me. skype is also possible.
kind regards
peter
What I have done is delete my BO inventory, and let it sync with my BL inventory.
Thank you.
Or did you run an old installed copy of BrickSync that was already initialized months ago?