Home
The Toolkit for Online Communities
17364 Community Members, 0 members online, 2219 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Building a sales tracking/CRM system from the ecommerce module

Forum OpenACS Q&A: Building a sales tracking/CRM system from the ecommerce module

Icon of envelope Request notifications

For my undergraduate thesis, I'm working on a sales tracking system + CRM using OpenACS. The application will be deployed on a possibly-offline company - this means they will not be using the ecommerce module.

It will have the following features/modules:

  1. sales order data entry
  2. accts. receivables
  3. daily, weekly, monthly sales reports
  4. customer information tracking (note that, if the application is deployed offline within the company intranet, the customer *may* not be an OpenACS user)
  5. sales analysis reports like
    • (if profit per unit of product is known) who among our customers contributed the most profits?
    • (if profit per unit of product is not known) who among our customers contributed the most in revenue?
    • who bought the most number of product X?
    • who bought the most number of products from product category Z?

I initially planned to copy the data model from the FreeMoney project (www.freemoney.org) but I realized that most of what I need is already in the ecommerce module data model. I plan to create an interface for the data-entry of offline purchases. This is necessary because the ecommerce pages assume that 1) the current user is the customer, and 2) order will be paid through a credit card. The interface that I plan to create assume that the current user is not the customer, and the user will select from a list of customers (I have already created a customers table for this), and the sales order is not yet paid and will be paid through a separate module - the accts. receivable module, which I will also create. Is this feasible? Any pointers on how to proceed?

I also noticed the ec_customer_serv_interactions table, which seems to have been designed to record customer complaints and inquiries. Yet I failed to find a page in /ecommerce that uses this table. Was this table part of a CRM application that aD did not release with ACS?

Radamanthus, I just wanted to drop you a note to encourage you in your endeavor. I think this could be a great addition to OpenACS. Something like this could really help integrate the back office at a company that is already selling products, but also wants to sell on the web.

While I don't have any experience with the e-commerce, I liked where EC 4 was headed, as far as keeping the system very modular and easy to expand.

Of example, what if I was interested in using this system, with EC, but I already have a system tracking my orders and customers (as it runs the rest of my company), like Fourth Shift (http://www.fs.com). While I would not expect you to come up with an interface for such a system, it would be nice if the code was written in such a way that integration would not be an impossible task.

Keep us updated!
Sam

I am building a site right now that could use these features immediately. In fact the ability to export transactions via XML to external accounting apps would be most useful as well (this I will probably be doing any day now)... also, manual transaction entry on behalf of the client (for the many people who call and want to buy stuff, but still dont trust the web).

Most importantly, figure out a seamless way to replace Cybercash. I was told today by an informed source at Cybercash that they will be shutting registrations any day now as they port all clients to Versigns system.... there will be a period where they redirect transactions but eventually all ACS users will have a problem.  I suggest check out IONGATE who have a fairly good gateway transaction set which could be made to work on ACS. ... mostly .. its cheap ...

Good stuff Rad .. keep us informed.

We have an ACS 3.4 compatible e-commerce module that integrates with SecPay rather than Cybercash. It's kind of ready to submit though we don't know where to submit it :-) since ACS aren't interested in 3.4 any more. We've just been sending it out to people who've asked for it. Don't know if there'd be any interest in porting to OpenACS 3.4 (pretty easy) or OpenACS 4.0 (not so sure).
Steve,

From what I can see Secpay is a UK outfit.. i'd prefer a local (USA) outfit...
I 'd love to see your code anyway, if I you wouldn't mind.

With thanks

Hi,

This is obviously an old thread, but I was wondering if anything ever came of these efforts to establish CRM functionality for OpenACS. I would be particularly interested in hearing about contact and account management functionality as there is a possible requirement for this from our press office.

Thanks,

Stephen Donnelly

There was a CRM package for ACS 3.4. I never used it, but if it was good, it could be easily ported to OpenACS.
Hi Stephen, Jade,

There is a "Customer Management" module for OpenACS 5.0 at http://www.project-open.com/modules/crm/.

Of the mentioned features, the following is working already:
- Customer Contact Management
- Integrated Customer File
- Customer Transaction History
- Online Web Registration
- Mass Mailings
- Import interfaces with MS-Outlook

I'm currently working on (available in about two months):
- Customer Web Tracking (add markers in a static web site and/or import web logs)
- Customer Classification (based on OpenACS classification module)
- Customer Status Engine (a status engine driven by hand-made SQL statements)
- Integration with a mail server to track customer emails

Jade, I think you are referring to the Status Engine, is that right?

Features for later:
- Import interface with ACT!
- ISDN Call Center Integration

Actually, did you check out ACT!? I've seen most sales professionals of smaller companies working with it. It's quite handy and there is a cracked version at e-Donkey for the ignorants. I think a combination of ACT! and OpenACS-based CRM would end up to be a serious kick-ass solution.

Bests,
Frank

I'm going to be at the Heidelberg event...

I really think that it is very important to *always* state which packages run under which license as there might be more proprietary oacs-packages in the future..

Frank, I am not quite sure, how your three different licenses interact and how independent your packages that run under GPL are towards your PL or CL licensed packages.

http://www.project-open.com/license/index.html
http://www.project-open.com/roadmap.html

I have nothing against proprietary packages, I just think that they should very visibly be labeled as such.

Hi David,

very good point, thanks. I have to admit that we still still working on it, and that it isn't 100% clear to us how we should license the stuff. So we didn't include the license in the package itself in order to be able to change them... We are currently working on new web site, and we'll include license terms in all package descriptions.

However to summarize it, all of the above mentioned packages are free for the end customer to use and modify (GPL or PL).

What the PL restricts is "decentral redistribution" in order to make sure nobody else is making money with it, except the developers. But _you_ can become a developer by extending/modifying the code and contributing it to Project/Open ("centralized redistribution"). Your revenues are calculated according to how much of the module is "yours" and depending on the weight of your module compared to other modules.

Heck, I think this is still too complicated, isn't it? I'll try to introduce some more explanations and diagrams in the license section of the new web site at  http://www.projop.com/license/ (check this afternoon, after 15:00 CEST).

But isn't it funny that the announced CRM package was never written and that it now appears under such a strange license? I'm still trying to figure out how "boring ERP software" and open-source are going together... For me it's ok to work for free on "sexy" software, but I want to get paid if I'm doing boring stuff like accounting or CRM. And you've got no idea _how_ boring that can be...

Bests,
Frank