Chris & John, thank you both. This is very helpful.
Hi John, is there an ability to bulk change package dimensions for a bunch of listings instead of one by one?
Is there ability to do BULK change item dimensions that would allow us to select X amount of listings and apply set dimensions across the board?
We have exact same problem. Installed on two systems and application no longer loads. Hopefully Sixbit team can get this resolved ASAP.
Hi John, hope all is well. Was wondering if you had an update on this request? Thanks in advance as always.
To clarify I am referring to eBay payment details for eBay managed payments.
So far, so good. Hopefully you’ve built in safety mechanisms I described that prevent order from going to fulfilled unless 100% confirmed uploaded. If eBay servers can’t be reached, sixbit client crashes, power goes out, api stops working, really doesn’t matter, no matter what the issue is unless the client is able to confirm 100% it was successful, it should not move the orders to fulfilled. It creates major issues if it does. Anyhow thank you for taking care of this. Enjoy your weekend.
In normal operation (outside of this bug that recently started) suppose someone marked the orders as shipped it’s going through submission and all of sudden their system crashes, power goes out etc… Would those records end up getting transferred or you built in logic to account for this type of scenario as well as a safety mechanism. Basically I am hopeful that order status does not change or goes to fulfilled unless 100% it was able to confirm successful upload.
John, are you able to change logic in code to prevent eBay orders from moving to fulfilled in the event upload was not successful? The logic should be in such way that if it times out, or any other error comes up and application cant confirm if successful the order should not move to fulfilled. It should go to confirmation errors or remain where it’s at.
John, keep in mind that with the unshipped orders from few days back means your eBay metrics most likely have not been met assuming you are targeting top rated seller metrics. For over a year I’ve been reporting to Sixbit that they need to fix this. Every time there is an issue with tracking# not uploading to eBay orders get moved to fulfilled. When you have a batch of 100 orders that are being uploaded it’s extremely difficult to catch the ones that transferred to fulfilled status and didn’t upload. Basically forces you to go order by order and manually trying to figure out. This needs to be a top priority change, and frankly speaking it’s a simple fix. If order doesn’t upload transfer to confirmation errors not fulfilled. Only orders that confirmed tracking# was successfully uploaded should go to fulfilled etc… Hopefully not only do they fix the freezing issue but also change program logic. It’s frustrating having to work hard to get orders out on time, and have the application screw up the metrics.
Glad to see we are not the only ones that are having this issue. We also noticed it’s not just with tracking# upload that is freezing up but other aspects as well like submitting items at times and using other features of application. Not sure if those users ran into issues while a member of order processing team was uploading a tracking# that locked up the database etc… But regardless I’ve been reporting for years that eBay tracking# upload code needs to be changed and designed in such a way that if the order doesn’t upload it does not move it to fulfilled. Luckily we have staff that pay attention to these things and try to catch the orders that didnt upload but overall this is in hope they notice and catch it. When we are taking a bulk amount of orders, it’s hard later to locate each and every one in fulfilled status to be re-uploaded. Hence I recommend that upon upload if upload is not successful or can’t be verified as successful to either leave the order with current status rather than to move it to fulfilled or to move it to confirmation errors status until a successful upload is confirmed. And lastly please look to see why the whole application is freezing up and working poorly as the issue of application hanging is not just with uploading but when other tasks are being done, although perhaps tied to same issue.
Also when marking as complete, whole application slows down. Recent user reported “SixBit is working too slow, it doesn’t submit items from first time. It started yesterday evening. For submitting items I do it for three times in a row and it doesn’t work. Then I turn it off, reopen, but it submits only from second or third time.”
Last post was close to 14 minutes ago, since that time updating transactions has finished processing 2 of 7 transactions. This is ridiculous. It’s impossible to work like this. Also finally 1 transaction shows as failed to update. After pressing close window transaction got moved to fulfilled even though tracking may or may not have gotten uploaded to market. It should not have moved if tracking# did not upload. I’ve reported this issue in the past. This is a problem that needs to be resolved as it causes risk that some transactions are not having tracking# uploading causing sellers to lose their top rated status solely due to the software issues.
The progress window I am referring to is the one that says “Updating Transactions” after hitting marked as shipped. I am wondering if perhaps the issue has to do with multiple people hitting transactions as marked as shipped at the same time from multiple client stations? I have not confirmed if multiple people selected same transactions to upload tracking from different client stations, but definitely not working like it used to for years prior to recent changes of the past 3 or so builds.
Build 4.00.136 seems to have improved things in comparison to build 4.00.135, however overall experience has become much worse than builds released a month back. Essentially since the moment you started making changes that are in relation to eBay tracking# upload when marking as shipped. Currently with build 4.00.136 sometimes tracking # is uploaded quickly, while at other times there is a slow down and progress window stays on screen for significant amount of time.