-1

I need to borrow some wisdom from a Drupal expert.

We are hiring a marketing firm to build our website. They are building the front end using Drupal 7, and hiring yet another firm to do the programming. Once the front is complete, they will be handing it to me to implement the shopping cart and eCommerce, along with integrating into our CRM and ERP

From what little I've worked with Drupal, I know that it generally manages everything as a chunk of content. I am also aware that you can create a custom content type which we could build to make a product model. And I have read in a few places that Ubercart can use this to build the product catalog essentially.

So, if I allow them to continue in this way, will there be a way for me to pull or update information about products through an API (SOAP or otherwise)? Is there a better alternative?

My concern is that handling products as content seems a bit flimsy, and I fear that when it comes time to link together our CRM and ERP, that I won't have any way (short of working with the database directly), to update or pull information. Ultimately, the goal is to have Drupal only deal with layout and actual content, and our ERP/CRM duo will handle maintaining product information. Is there an established method or best practice for what we are looking to do?

++ I'm more interested in the database structure than anything else.

BayssMekanique
  • 894
  • 1
  • 14
  • 27

1 Answers1

0

I think it depends on what type of products are you going to sell, are you going to sell them online and regarding to this realize which software will be primary(master) and which one will be secondary(slave).

If you plan just to tell people you have several products you can store these products inside ERP and then export ERP/CRM products data and import them into Drupal on a daily basis. ERP/CRM will be your master storage then.

If you plan to sell something online and you have to manage stock levels then you can follow one of these solutions (or make up another one):

  1. ERP/CRM is a master storage for everything (products, clients, stock levels). Drupal is used only for authentication process and for your products storage "gateway" so your site visitors will browse through your site and that browsing won't affect your ERP/CRM but if one will buy something you will let Drupal get all information abuot logged customer and let him boy something regarding to your stock levels.

  2. Drupal is a master storage for everything. I think this is not a good idea because you already have ERP/CRM, products, descriptions and so on so you will need to make them synchronized and that's always lots of hard work.

  3. ERP+CRM are for products and clients offline, Drupal is for e-commerce only. You just need to export your products from your ERP system and import them into your Drupal site on a daily basis. Then if someone will want to buy something online he will interact with Drupal site (cart, checkout etc).

Technically importing/exporting nodes is not as difficult as it could be. For instance you just create a stdClass() object, fill its values ($node->title, $node->body, etc) then call node_prepare(), node_save() and that's all.

If you could provide more information about your business and what are you going to do with your Drupal site, maybe, you will get more answers. Also sorry for my English, I'm not native.

Alex Smirnoff
  • 478
  • 4
  • 10