Important Data Points Not Mapped

[TexasGreg]

I have Opencart integrated with Shipstation. I'm finding that Shipstation has not and will not map basic data fields imported from Opencart. It is very annoying to see all the column options and not be able to use half of them.

Example fields available using the basic API:

"gift": true,
"giftMessage": "Thank you!",
"paymentMethod": "Credit Card",

"warehouseLocation": "Aisle 1, Bin 7",

"customField1": "Custom data that you can add to an order. See Custom Field #2 & #3 for more info!",
"customField2": "Per UI settings, this information can appear on some carrier's shipping labels. See link below",
"customField3": "https://help.shipstation.com/hc/en-us/articles/206639957",

I have sent all these fields to Shipstation and they confirmed that they received them. In order for me to benefit from this data, Shipstation needs to map these fields. I have to do workarounds. I send gift messages in the internalNotes field, the only extra fiield available, and add that text to packing slips. I send the product warehouse location as a prefix to skus. I send a sorting variable as Tax Paid. Because I can't designate that an order is a gift and I have to use the Tax Paid field I can't show prices on any packing slips.

The response I get from tech support is that Opencart is a closed system and that is why I can't use these fields. That makes no sense whatsoever. There is no issue on the Opencart end and it's not a closed system anyway. It's all on Shipstation.

I thought it was just Opencart being treated like a red-headed stepchild but then I saw that each shopping cart platform is limited to varying degrees.

Can anyone give me a good reason why Shipstation accepts these and other data fields using their basic API but not when using shopping cart platforms?

[GoodSpeed]

I'm not familiar with OpenCart, but I think the simplest answer is that neither side (ShipStation or OpenCart) wants to be responsible for creating/maintaining the custom mappings. This was more or less the response I got when I wanted to integrate our inventory software with ShipStation so that kitted items could be sent as individual components. If 100% of ShipStation's users were also using OpenCart, then it would be extremely beneficial for them to take the time to build the custom mappings (or at least add functionality for users to select the mappings themselves); however, since each shopping cart software is different it is likely too complicated and not worth it to ShipStation to create that functionality yet. 

Unless you want to brush up on PHP and see if there is any way to write your own function into OpenCart, then the custom fields and gift flag may not be something you can use. For example, with WooCommerce there is supposedly a way to include the custom fields by adding a bit of code into your site's theme, but I haven't tried it. 

As far as the warehouse location, that one I may actually be able to help with. ShipStation has the ability to track warehouse location at a product level and save it to their own database. When we first started using ShipStation I exported all my products from my inventory software, tweaked it to match the import CSV format for ShipStation, and was able to save all my SKUs into ShipStation with the warehouse location. This information is under the Products section -> select a product -> Shipping tab. With that we were able to add the warehouse location to packing lists. The biggest downside? We have to keep track of the locations in two different spots so anytime a location change occurs it must be updated in our inventory system and in ShipStation. 

[TexasGreg]

GoodSpeed it's not custom mappings. It's basic mappings. There is no maintaining of mapping, only creating. Once created, there is nothing more to do.

Mapping data points is not complicated since as a shade tree programmer, I did it on the Opencart side.

[GoodSpeed]

Okay, some definitions might help:

By "custom mappings" I was referring to the idea that the mappings could be different across users. For instance, if ShipStation built the mappings, they would have to account for different shopping carts calling the "gift" flag by their own specific name. Plus, I was saying "custom" because some of the mappings being discussed were called "customField1." Clearly a poor choice of words on my part.   

By "maintaining" I meant that after creation there could be changes that affect the behavior of the mappings. WooCommerce uses "customField1" to pass coupon codes so it overrode the values we were currently using there, which required us to change our mapping process. I also include support under maintenance because any pre-built solution would end up adding some customer questions/problems to their queue (with the hope that the solution decreased the questions/problems elsewhere). 

Anyway, it sounds like you have done some similar work in Opencart that might help the OP; why don't you share what you did?

[SpencerW]

We're having the exact same issue with our BigCommerce and Shipstation integration. Shipstation have confirmed that BigCommerce's BPN is being sent to Shipstation, but they are unable to use that data to amend their Warehouse Location. So, what is the point in them receiving the data if they cannot use it? The alternative is to manually upload the product inventory with updated shelf numbers, but our shelf numbers change regularly - daily, in fact. Having to do it on two different systems, doubling our work, because this integration doesn't work is really frustrating. 

[GoodSpeed]

Since writing the above response over a year ago, we too got to the point that our locations were changing so frequently that we were unable to keep up with updating in two systems. ShipStation has enough good features to make it worth trying to keep so we ended up having to use a custom built API integration so that I could pick what data was brought over and how ShipStation should use it. Not the answer you wanted, but I wasn't able to find an easy solution (with ShipStation or elsewhere) and we have come to find that the bigger we have gotten, the more "custom solutions" we have needed. Growing pains are real and they suck.