[Storerb-devel] Storerb-devel Digest, Vol 1, Issue 8
paul.vaillant at gmail.com
Mon Nov 14 17:04:38 EST 2005
I certainly hear what you are saying, and I agree that a consolidated view
of a whole business is required in todays marketplace, but I disagree that
all these systems need to be the same system.
I agree that linking together seperate systems can be a hugh pain,
especially when each system was never designed or intended to be linked with
another system, but I'm proposing that we build this system with the idea
that it will be integrated with those other functions which is different. I
don't disagree that this consolidated item needs to be addressed, but I
think that I can be addressed with another system linked into the ecommerce
site. In particular, this would be a great place for a sister project that
was a complete accounting or erp system, but in this way, it also provides
the ability for someone to integrate our ecommerce system with another
accouting or erp application that they already have.
In this case it helps us two folds to take this type of approach; one is
that we can move forward and complete the store without having to worry
about implementing a full accounting system and two that it allows the
flexibility for someone to use their own system if they want.
I my position makes more sense now.
On 11/14/05, Andrew Ballantine <andrew.ballantine at homecall.co.uk> wrote:
> Paul Vaillant <paul.vaillant at gmail.com> wrote:
> "I think that we certainly need to be able to export financial
> information for import into a real system, but that this should be limited
> to export of orders. I do not think that this system should be a full
> accounting system. This is a sales system. We might supplement importing
> some A/R information to display for customers their outstanding balances in
> a B2B scenario, but otherwise exporting orders and payment processing
> success sufficient.
> In particular, there is a mark difference in the inventory for accounting
> purposes (which is increased during receipt of shipping and decreased during
> order fulfilment, which for a web store is not order placement) and
> inventory for sales purposes (not over selling specific items). If someone
> is interesting in adding in an accounting package to go with the system, I
> think we add in some web service hooks to allow them to read in the order
> information and customer information. They can then get customer information
> and keep track ."
> I am currently involved in the development and modification of a system
> that has evolved from various packages. It is a nightmare trying to extract
> data from one system to suit another and visa versa. If I wanted to find an
> ecommerce system, a sales system, there are hundreds to choose from and they
> all end up with the same problems when the volume ramps up. The head of the
> business wants to know what the business situation is now, not what it was
> 24 or 48 hours ago. The system I am involved with leaves the sales reps to
> phone in their results which are always late. The business owner is tearing
> his hair out a 10:30 am each morning wanting to know how yesterday's sales
> went. This is a business that turns over in excess of £10M a year.
> Close integration of all departments of a business is essential for
> easier management. I have managed my own retail business which had an
> ecommerce site and I had headaches linking together 3 separate systems and
> that was only small volume. Had the volume ramped up I would not have been
> able to cope with those systems and would have had to spend a lot of money
> in a short space of time putting in yet another system at a critical moment
> of the business's growth. I have seen it happen to many others too.
> I think you should reconsider what it is that you want to develop.
> Kind regards,
> Storerb-devel mailing list: Storerb-devel at rubyforge.org
> Project site: http://trac.vaillant.ca/store.rb
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Storerb-devel