WooCommerceConnector development

Hi guys,

I have an online shop running currently PrestaShop 1.6 with around 2000 items and 3000 monthly orders. I’m planning to migrate to erpnext and so far this connector is the best interface to a frontend that I saw.

I tried to use it (libracore version) but noticed a lot of bugs, especially on erpnext v13.

So I started working on improving it and today I noticed the Muzzy73 fork.
Since we’re both working at this I would like to use this thread to discuss fundamental principles and organize our collaboration if you consider it appropriate. Anyone is welcome to join.

  1. Purpose. I believe the purpose of this connector is to isolate the erp from the store. The erp should be ran in a safe environment, without external attacks and the store should be robust and sufficiently separated so that when it’s attacked or hacked it doesn’t bring down the whole erp (which is used for many other internal operations of the company and I consider to be a critical piece of software). For this reason I consider the erpnext shop an anti-feature since it’s too tightly linked to erpnext and any problem with it is automatically transfered to erpnext.
    Woo should handle the following: frontend, order reception, customer creation/authentication, payment processing for live payments (credit card, paypal, crypto), product bundles, fb/google feeds, recommended products. For most of this functionality there are Woo modules in the store.
    Erpnext should do: product management (including variations, categories), stock management, order processing, payment processinf for offline payments (cash on delivery, T/T), delivery management (create carrier shipping labels, poll for shipping status and update delivery notes).

  2. Source of truth for products. In my use case, that would be erpnext but I noticed @Muzzy uses Woo. I don’t think we will come to an agreement about which is “correct” so maybe there should be a big setting during install that sets the source of truth.
    I believe it 2 way product sync is enabled this can just mess up everything by creating duplicated products everywhere.
    In my use case, all the product management is done on erp, woo is just a skin that presents the producst to the users, takes the orders and then notifies erpnext about the payment status (for credit card and paypal).

  3. Source of truth for stocks. Again, I believe this should be on erpnext and it should work like this. Let’s say we have 100 pcs on erp. When we sync stock, 100 items are set up on Woo. Now a customer makes an order for 10 pcs. The stock on Woo is decreased to 90 and a notification is instantly sent to erpnext via a webhook. A sales order is created and 10 pcs are reserved (reserved_qty). When the stock is modified on erpnext, the trigger will also update on woo, but will decrease the amount reserved for unprocessed orders (and quotes in the future) so it will be actual_qty - reserved_qty. Or we could run a mysql slave with replication and modify Woo to get the stocks live from there via an API.
    If the source of truth for stocks is on Woo, that means the whole stock management system on erpnext is completely disabled. You can’t do proper accounting, no sales/purchase orders, no supplier management, nothing from the Buying module. For me, this stock management system is the main reason to use erpnext.

  4. Multi-store. Do I even want to open this can of worms? Maybe we should slowly work on improving the functionality so that we can do this in the future.

Please let me know your opinion about these subjects and also how we should proceed with development collaboration.

Should we work on merging Muzzy73 on libracore or continue on Muzzy73?
Should we organize a discord/skype/whatsapp channel?

What about the integration done by the erpnext team? That seems to be in a very basic state, maybe we should combine the versions (especially the webhooks for order status callbacks) and provide a single good connector.

@Muzzy @iRaySpace @lasalesi @joelios @Nanipi @rohit_w @ankush anyone else?

2 Likes

Hi @BrunoG,

thanks for your recap on this topic. I do admit that we have a rather tight scope as we focus on our customer base with a sort of defined/similar infrastructure, where we operate this successfully (on v12 to be noted, due to stability issues in v13). Still, we feel that this is a worthwhile piece of software that should be available open source (part of the core or separate I have no preference as long as fully scoped).

Part of the frustration of the team here probably came when core integrated the connector with a very limited feature set but the same doctype name, which required the team to refactor the connector to even be compatible again for the public (which was really not necessary; but thanks to the work from Carsten was done).

Seeing the various efforts going into this (each with individual interest but the good intentions to share it, special mention to @Muzzy) would indeed call for collaboration on this matter and we would be more than happy to contribute to that!

A difficulty that might come up is the large variety of configurations. To connector has grown over the years, and has been adapted to new scenarios. Still, as you mention, other configuration option will exist and present us with challenges.

Maybe we should to a fit/gap of the current options and take it from there… We are also open to invite contributors to the repo. We should also keep sustainability on the radar.