eshipper carrier and service mappings differ in prod

[jacobshilitz]

apparently eshipper has different mapping in production than in development.

I was trying to play around here, (you did it by hand till now?)

my approach has two problems:

1. there are duplicated Ids with the same name, and it results in a duplicate key in the Enum .
2. the website only shows you the carriers that are enabled on the account. see the file

I was wondering that maybe we can just use the names they return in the API serviceName?

 {
      "baseCharge": 15.3,
      "carrierName": "UPS",
      "currency": "CAD",
      "fuelSurcharge": 2.18,
      "fuelSurchargePercentage": 13.75,
      "modeTransport": "GROUND",
      "serviceId": 604,
      "serviceName": "Standard",
      "surcharges": [
        {
          "amount": 0.52,
          "name": "Demand Surcharge"
        }
      ],
      "taxes": null,
      "totalCharge": 18,
      "totalChargedAmount": 18,
      "transitDays": "4"
    },
    {
      "baseCharge": 15.81,
      "carrierName": "Federal Express",
      "currency": "CAD",
      "fuelSurcharge": 2.35,
      "fuelSurchargePercentage": 13.75,
      "modeTransport": "GROUND",
      "serviceId": 3,
      "serviceName": "Fedex Ground",
      "surcharges": [
        {
          "amount": 1.25,
          "name": "Delivery Area Surcharge"
        }
      ],
      "taxes": null,
      "totalCharge": 19.4,
      "totalChargedAmount": 19.4,
      "transitDays": "2"
    },

@danh91 please let me know what you think about this.

Thanks

[danh91]

Hi @jacobshilitz,

I collected the carrier and service data from this page on their Network calls on the page. I believe it has everything even the non-active carriers 🤔.

I didn't know that they were different in production.

Having the JSON file seems like a good idea because I spent hours trying to make sense of the Metadata and formatting for the enums and the rest. Having an exhaustive JSON file that has the full metadata would be useful to map it back. Then we can simply have a function under eshipper/utils.py that makes sense of it during parsing.

That said, we should take into account the unexpected. If they return a new carrier or service that the code is unaware of, we need to be able to capture the data as is and forward it for Rates. Even be able to generate labels. Then we identify and update the Metadata files on a PR.

[jacobshilitz]

I collected the carrier and service data from this page on their Network calls on the page.

the same as I did..

I believe it has everything even the non-active carriers 🤔.

Having the JSON file seems like a good idea because I spent hours trying to make sense of the Metadata and formatting for the enums and the rest. Having an exhaustive JSON file that has the full metadata would be useful to map it back.

we can't call it becouse that api need auth, that's makes me think that each reply is crafted based on user, also there is no canada post becouse its diabled on our account

Did you miss my commit (it still need work becouse of the duplicate enums)? https://github.com/karrioapi/karrio/commit/2fef596b433a53dea42da4c832a513fe8233fd68

[jacobshilitz]

@danh91 please advice how you want to go about it, currntly eshipper is broken working becouse it falls back to the names they pass as a string

[danh91]

@danh91 please advice how you want to go about it, currntly eshipper is broken working becouse it falls back to the names they pass as a string

I am reviewing the data mapping again. But we basically need to add the production ids

[jacobshilitz]

I am reviewing the data mapping again. But we basically need to add the production ids

Thats correct, let me know what we do with the problem that they have they have duplicates and for enum we need to have only one same name, and that i'm not sure they show the data for everyone the same.

I did some half baked code please review and let me know what aproich you would like to take