Skip to content

feat: Add integration to shiprocket, delhivery, aramex, envia, shippo #50

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 22 commits into from

Conversation

ravibharathi656
Copy link

As a part of this PR, I am introducing a new doctype called Shipping Provider to refactor the existing design and introducing the following integration.

  • Shiprocket (In Indian context)
  • Delhivery (In Indian context)
  • Aramex (In Oman context)
  • Envia (In Indian context)
  • Shippo (In US context)

The existing ones such as letmeship, sendcloud is not affected by this refactoring.

This PR also changes how the shipping providers are configured. As ERPNext can have multiple companies in it, we need to configure multiple shipping accounts of the same shipping provider.

Copy link
Collaborator

@barredterra barredterra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the Shipping Provider doctype: when you want to contribute new features, it's a bad idea to change the architecture at the same time. Please stick to the existing architecture. I'm sure there are pros and cons to both. But I think there is not a good reason to change or use two different architectures at the same time.

@Vigneshsekar
Copy link
Collaborator

Hi @barredterra ,

The existing way is creating new single doctypes for each of the providers. We will end up creating 5 new single doctypes for this. Also, when there are multiple companies on the same site, when two different companies have to use the same shipping provider with two different accounts (and so their credentials), the existing way isn't supporting it. That is limiting.

We should consider moving LetmeShip and Send Cloud to the Shipping Provider in a different PR with a patch to migrate their data. What do you suggest?

@barredterra
Copy link
Collaborator

It is a very established practice that every integration gets its own settings doctype. (except when all use the same protocol, e.g. social login). Here, every shipping provider is different, as indicated by the many conditional fields and individual interfaces. Trying to fit them all into the same DocType isn't helpful and breaks with the existing architecture. You get one overly complex DocType instead of many simple ones.

Regarding multi-company support, the individual provider settings could be a list with one entry per company.

@Vigneshsekar
Copy link
Collaborator

Yes, as we are also considering bringing in a few more providers, we might be heading towards one overly complex doctype. Will move towards a non-single doctype for each of the providers.

Please suggest what will be the right place to set up a preferred provider. If this isn't set, on the fetch price, the call is made to all the configured providers.

(cherry picked from commit b2caef9)
(cherry picked from commit 14aacee)
@barredterra barredterra changed the base branch from version-15 to develop February 24, 2025 16:19
* fix: phone number regex

* fix: suggested change

Co-authored-by: Raffael Meyer <[email protected]>

---------

Co-authored-by: Marc-Constantin Enke <[email protected]>
Co-authored-by: Raffael Meyer <[email protected]>
(cherry picked from commit 5e3df2c)

Co-authored-by: Marc <[email protected]>
@ravibharathi656 ravibharathi656 force-pushed the shipping_integration branch 2 times, most recently from aa159e2 to ce1422c Compare February 25, 2025 14:02
@barredterra
Copy link
Collaborator

@ravibharathi656 @Vigneshsekar maybe you faced the same issue. If you like, add your two cents here: frappe/erpnext#46454

@ravibharathi656
Copy link
Author

Hello @barredterra @Vigneshsekar , I have tested the integration for all providers after refactoring.

Comment on lines +369 to +399
elif service_provider == SHIPROCKET_PROVIDER:
shipping_label = []
shiprocket = ShiprocketUtils(company=pickup_company)
label_url = shiprocket.generate_label(shipment_id, shipment)
if not label_url:
frappe.throw(_("Failed to generate label."))
file_url = save_label_as_attachment(shipment=shipment, url=label_url)
shipping_label.append(file_url)
elif service_provider == ENVIA_PROVIDER:
shipping_label = []
file_url = get_shipping_label(shipment)
if not file_url:
frappe.throw(_("Failed to generate label."))
shipping_label.append(file_url)
elif service_provider == DELHIVERY_PROVIDER:
delhivery = DelhiveryOneUtils(company=pickup_company)
shipping_label = delhivery.get_label(shipment_id)
elif service_provider == SHIPPO_PROVIDER:
shipping_label = []
shippo = ShippoUtils(company=pickup_company)
label_url = shippo.get_label(shipment_id, shipment)
if not label_url:
frappe.throw(_("Failed to generate label."))
file_url = save_label_as_attachment(shipment=shipment, url=label_url)
shipping_label.append(file_url)
elif service_provider == ARAMEX_PROVIDER:
shipping_label = []
file_url = get_shipping_label(shipment)
if not file_url:
frappe.throw(_("Failed to generate label."))
shipping_label.append(file_url)
Copy link
Collaborator

@barredterra barredterra Mar 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd expect that all of these to look and behave roughly the same. Right now, some raise an error and some don't; some save as attachment and some don't.

Also, could we pull out the "Failed to generate label" check to the end, just before the return statement, so it's the same for all providers?

@barredterra
Copy link
Collaborator

@ravibharathi656 did you address all previous review comments / is this ready for a final review and merge?

@ravibharathi656
Copy link
Author

ravibharathi656 commented Jun 20, 2025

@ravibharathi656 did you address all previous review comments / is this ready for a final review and merge?

Hi, @barredterra the current PR has a lot of merge commits. Would you prefer I open a clean new PR with all previous review comments addressed, or can I continue using this PR?

Thanks for your patience.

@barredterra
Copy link
Collaborator

@ravibharathi656 either way is fine.

@ravibharathi656
Copy link
Author

@ravibharathi656 either way is fine.

Hi @barredterra,
Thanks for confirming. The current PR has too many merge commits and it's becoming difficult to clean it up properly. I'll go ahead and open a new PR with all previous review comments addressed.

Thanks again for your patience

@ravibharathi656
Copy link
Author

@barredterra @Vigneshsekar

Closing this PR to maintain a clean commit, I will make the required changes in this PR: #72

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants