pricedright

My feedback

  1. 176 votes
    Vote
    Sign in Sign in with ShipStation
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Hey, @all

    Thanks for your continued support on this idea, we don’t have any updates to report on the status of how we authenticate email addresses based on client domains, but any updates will be posted through this thread.

    But, please continue providing your experiences with how the lack of this feature impacts your workflow.

    pricedright supported this idea  · 
  2. 79 votes
    Vote
    Sign in Sign in with ShipStation
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    An error occurred while saving the comment
    pricedright commented  · 

    This has been under review for nine months. Isn't it time to move forward with this bug?

    An error occurred while saving the comment
    pricedright commented  · 

    This idea should be merged with "Support for common foreign characters".

    pricedright supported this idea  · 
    An error occurred while saving the comment
    pricedright commented  · 

    Thanks for the reply. Despite the OP's description of the problem, the real issue isn't which character set is supported by ShipStation, but which characters are supported by the postal service.

    As per the USPS Development Guide for their API (https://www.usps.com/business/web-tools-apis/general-api-developer-guide.htm), the only allowable charaters are from the ISO-8859-1 standard, which is essentially the first Unicode block of characters. It covers the alphabets of most Western European countries.

    That leaves out Cryllic, Hebrew, Arabic and most Asian languages. That's a real problem for those of us with broad international distribution.

    I think that my last post describes a good way to deal with the problem.

    An error occurred while saving the comment
    pricedright commented  · 

    Any updates here? We'll soon be on Amazon Japan. The manual correction of each address will be a time consuming process.

    An error occurred while saving the comment
    pricedright commented  · 

    This thread has become about two separate issues. It started with importing Latin characters that are not part of English. However, other people have complained about Cryllic characters appearing as question marks. I think that they may be different problems that both need fixing.

    I have the Cryllic alphabet issue. They import correctly from the marketplaces, but print as question marks (ie ??????) instead of the proper character. This is not ShipStation's fault, but due to a postal regulation that requires Latin characters on labels, so the problem applies equally to other non-Latin alphabets.

    My manual workaround is to first paste the original address into Internal Notes (to help recover from errors), then paste the address into Google translate and then paste the translated address into the ShipStation fields.

    Google Translate and other translation services have easy to use APIs. ShipStation should use one to automatically duplicate my manual process.

  3. 270 votes
    Vote
    Sign in Sign in with ShipStation
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Hi! ShipStation is still in the process of understanding the best way to address multiple currencies within a single ShipStation account. We greatly thank you for your patience as we work towards supporting this much-desired feature.

    An error occurred while saving the comment
    pricedright commented  · 

    This bug was first posted 2.5 years ago and has been under review for nine months. There really isn't that much to research so you've obviously put this on the backburner and haven't lifted a finger towards consideration or implementation. It's beyond me how you can be so cavalier with such a serious bug. You thanked us for our patience, but no one is being patient, we just have no choice. We're just seething with frustration.

    An error occurred while saving the comment
    pricedright commented  · 

    I do not see how a little anecdotal info on frequency could possibly effect "an informed decision on possible changes".The few who have participated in this discussion represent the tip of the iceberg, as it does for any issue on this site. It is most likely that one piece of anecdotal evidence is not representative of the frequency of shipments getting held up for all users. It's kind of obvious that correlates to frequency of exports, average order size (the more expensive, the more likely a delay) and which countries are the destination since they all operate differently.

    More importantly, it is just one of several negative impacts, each of which are sufficient to make a decision. Either you fix the bug or you don't. It is clear that this bug is much more important than many that you have fixed since this was first presented. This bug impacts all international shippers that sell in foreign currencies. That's a huge portion of your customers.

    Please take us out of our misery and prioritize fixing this issue.

    An error occurred while saving the comment
    pricedright commented  · 

    @admin I'm surprised to hear the question. I only use USPS, but from the other comments in this thread, I suspect that the problem exists for all carriers.

    So let's take a step back and describe the issue using my experience on Amazon Great Britain as an example. However, the same issue exists for all foreign marketplaces and web sites that sell in currencies other than USD.

    Today's exchange rate is 1 USD = .67 GBP. I have a product that sells for 26.99 GBP, which today is worth 40.34 USD.

    Shipstation picks up the 26.99 from the marketplace, but instead of calling it GBP, Shipstation calls it USD. That creates two issues.

    1. The invoice on the shipping label values the product at $26.99, or 33% less than actual value. For my low price products, it's not as a big deal as bigger ticket items. The customs declaration is materially inaccurate, which could lead to legal issues and delays.

    2. The reports are also inaccurate. All reports also treat the GBP as USD, so in the above example the report shows $26.99. That destroys any chance to use Shipstation's numbers for analysis or accounting.

    My suggestion is that you add three fields to all currency fields, for a total of four fields as follows:
    1. Home currency (USD in above example)
    2. Amount in home currency (40.34)
    3. Selling currency (GBP)
    4. Selling amount (26.99)

    There are several APIs available to obtain real time conversion data.

    I'm not familiar with customs best practice, but it seems that it would make most sense to use the USD value in the customs declaration.

    All reports should be able to print all four fields, with the option to remove the foreign currency fields for companies that do not need it.

    An error occurred while saving the comment
    pricedright commented  · 

    I think of this a a bug, not a feature request. ShipStation is playing in an international arena and supports international marketplaces which inherently implies handling currency exchange issues. However, the support is compromised by the lack of basic currency features. Not only does it make every customs declaration inaccurate unless tediously altered before label printing, for some of us it screws up the accounting.

    Since it is a bug, please give this issue the priority it deserves.

    pricedright supported this idea  · 
  4. 11 votes
    Vote
    Sign in Sign in with ShipStation
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Hello!

    Thanks for submitting this request! While we don’t have a direct integration with SalesForce, there is a service called Cloud Conversion that can send integrate your SalesForce and ShipStation accounts. You can learn more about them here: http://www.cloudconversion.com/

    Please note that this will be a beta integration until there is an official partnership in place.

    Thank you,

    ShipStation

    An error occurred while saving the comment
    pricedright commented  · 

    I can't see how Cloud Commerce helps. Can you post a URL to a specific page that mentions Sales Force?

    Thanks

  5. 77 votes
    Vote
    Sign in Sign in with ShipStation
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    pricedright supported this idea  · 
    An error occurred while saving the comment
    pricedright commented  · 

    I second the option to make the return address optional.

    Currently 3 fields can be mapped to labels. I'd like to see that continued on envelopes.

    Also, for international shipments, I'd prefer for the international label with customs info format be used.

  6. 162 votes
    Vote
    Sign in Sign in with ShipStation
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Hi, everyone! Thanks for showing your support here! Can you tell us more about what you would use this feature for?

    From the previous comments it looks like some users are looking to use this for exchanges or more accurate accounting. Do you all agree?

    What do you think about our re-ship feature? Every time you re-ship an order, we will show you all the tracking numbers related to that order and its status. You’re able to change the order details for each label you re-ship.

    More info on re-ship (not to be confused with re-print): https://help.shipstation.com/hc/en-us/articles/206638607

    Please let us hear your comments in the forum and add your ideas with other users so we can get the full picture!

    pricedright supported this idea  · 
    An error occurred while saving the comment
    pricedright commented  · 

    This would be very helpful. Currently I add the original order to the Loading Dock and then when ready ship, add all other shippable orders to the Loading Dock (I otherwise do not use Loading Dock), then Ship all from the dock.

    Since I often need to edit the order details, this is insufficient so I am reduced to using the Add a note to the customer feature. Also, if I lose my session, the Loading Dock is lost.

Feedback and Knowledge Base