E-commerce with Plone - need of a new framework?

Hi Plone Community!

We are a small sized society working with Plone for around 10 years.

Here is our situation:

About 5-6 years ago we were asked to make some ecommerce websites. As we are Plone convinced, we have used PloneGetPaid to start our projects. Very fast we've seen the limitations of PloneGetPaid and we've developped our own extension of PloneGetPaid, Solgem.GetPaid with many improvement over PloneGetPaid.

In the same time we've started to use and sell Odoo (OpenERP) as ERP for many of our customers. In their latests versions, Odoo provides a fully functional website builder which is really e-commerce oriented, nothing to do with Plone.

So now we have a Solgema.GetPaid, based on PloneGetPaid which is quite old (everything is zope 2 form system) and not maintained anymore and there is no real invoicing, no accounting...

And on the other hand we have an Odoo which is (mainly) open source, with a strong invoicing and accounting management with a website builder which is ok for pure e-commerce but quite far away from Plone.

Now our aim would be to get rid of Solgema / PloneGetPaid and use a real ERP as backend with a strong Plone as front end with a connector between the two to handle the e-commerce part.

Mainly there shoud be a modern Plone framework that would basically do the following things:

  • Get and display article attributes (at least price, quantity and cart button)
  • Get and display steps an ordering process wizard (at least billing/shipping address, delivery choice, payment choice, validation)
  • Get and display customer's orders

All those views should be extensible with plugins.
The use of a tile (plone.app.tile / Mosaic) to display a form with the price, quantity and cart button next to the article (which can be any dx content type).
The use of collective.z3cform.wizard to get, show and handle the ordering process steps (address, delivery choice, payment choice, coupon, ...).
The use of crud to display the cart (with quantity as editable field) and the list of orders passed by the customer.

All the product datas, orders, shipping costs, payment modes shoud be retrieved from external plugins and not stored in Plone.

So the product's informations (price ATI, ET, discount, ...) would be taken from adapters and not stored in plone content.
The aim is that the framework can be connected with an ERP like SAP, Odoo, ..., and also the old PloneGetPaid.

So what do you think?
Is that a good strategy? a good starting point?
Is there other people interested in such a framework?
Where could we find help to make that project come true, financially or with the help of the community?

We're waiting for your advices and comments. Many thanks.

It is a common requirement integrating third-party applications and services into Plone on top of existing APIs.

Such projects become reality either by implementing it yourself or by bringing the necessary money for having it implemented by someone.

-aj

have a look at Plone and Ecommerce

Thank you for pointing that module. The framework seems well developped and flexible, but it seems also to be deeply linked to the ZODB and portal_catalog isn't it? For example is that possible to get and display orders from an third party ERP by defining our own adapter?

Ok this seems to be possible with cart items with ICartItemDataProvider

If you want to use Odoo, why not have one Plone site and one Odoo and just a 'rewrite rule', so for example
shop.mydomain.com (odoo ) shows up for the user as my domain.com/shop ?

If you NEED to use Plone for the shop, I would drop Odoo completely, and use bda.plone.shop.
For the user, it will be flashy enough (other Plone e-commerce add ons are not) and do most of what you want.

(I am a bit uncertain about the discount part (with things like a coupon)

One thing to consider is probably: How big is this shop going to be ?

Weird and unserious recommendations if you no insight in the overall requirements here. Plone can not replace Odoo and Odoo can not replace Plone. Both can live happily side by side and interact through their APIs.

-aj

1 Like

One of our biggest e-commerce on Solgema.GetPaid has more than 7000 articles, around 60 orders for an amount of € 5000 per day.
It's quite a big e-commerce.
We would try to avoid having two website builders systems in parallel and we don't really like the Odoo's website building approach which is far from Plone philosophy.

For our clients we're importing/updating products on a regular basis into Plone.
Live updates of stock and other properties could also be done by JSON calls.

I've "heard" that even some bigger shops, that use Magento and Odoo together,
go with import strategy for various reasons.

Open to other ideas too :wink:

Because you want to achieve 24x7 availability for shops. Backends like SAP are often not designed to work as primary data sources due to necessary downtimes. E.g. the SAP system of a customer of mime is used as primary source for parts of the articles of a shop. And the system is at least one hour down in the night and they have frequent outages on weekends...that's why you want to work on export data inside a shop instead of a real-time connection to the backend.

-aj

Thats exactly Odoo's strength to allow 100% availablity 24x7. It works as a web service the same as Plone does.
We're already using import/export with GetPaid but it would be much more powerful to have things in realtime, especially when you have online shops and real shops for stock handling.

bda.plone.cart seems promising but I see some (few, a lot?) limitations:

The product part seems well done with adapters and data provider that will allow us to use Odoo to get price, stock, ...

Unfortunately, the cart and cart items doesn't seem to follow the same logic.
As I understand, storing and getting cart items are made with a cookie. We might want to use Odoo's orders to handle the cart and cart items. So there shoud be a getCart and getCartItems adapter that would return cart data and items data from Odoo.

We would also like to use Odoo's mailing system for order confirmation, payment confirmation...

So as I can see for now, bda.plone.cart shoud be improved to be more flexible.

I think every ordered item in bda.plone.shop must exist in Plone , as far as I know they are looked up by UIDS in the javascript.

(did you want to add the sellable items in Plone or Odoo ?)

PS: bda.plone shop is pretty pluggable and I am quite sure all contributions are welcome

Fork it, extend it, send pull requests...that's how open source works.

-aj

1 Like

The Jazkarta.com folks have built some nice integrations with Plone that work with ordering and inventory systems.

If you need a "strong and complete e-commerce solution" you should use Magento or for lower requirements Prestashop. If you want to manage warehouse, orders, etc outside them, plug them with Odoo (or any other system you like). Odoo 9 has a new connector system to do this.

If you like Odoo there's still the option to use its e-commerce features. Even if they are pretty immature you'll have a solid base for them and, above all, you will not need to worry about setting up, maintain and keep in sync 2 different systems.

Is still not clear to me why you want to use Plone in your case. If you do not need granular permissions, per-content permission, advanced workflows, document management, etc then you don't need it. About page design: Odoo has its own page builder and i works pretty nicely.

If you don't need an e-commerce but just "sell some stuff from Plone" then go w/ one of the products that have been mentioned already, or use some fancy JS lib like https://cartjs.org/ to just add a cart and code backend stuff yourself.

As you see, there are many "if" here :slight_smile: so it really depends on the balance between

  • how many ecommerce features you want
  • how many CMS/DMS features you want
  • how much time for coding you have

my $0,02

1 Like

soon or later on an ecommerce site you need ERP things, that's why an erp on the back is a good idea. There is also a so good fork of oddo (tryton) that could do the job. But at the same time an ERP is not the place to manage rich Content Management Solutions. better to go with plone on this side..

1 Like