While some of it is pretty messy, I think Interchange has improved
quite a bit of it over the years, and it is easy to grok if you need
different functionality from it. They have moved more towards an MVC
model over the years. Their website is http://www.icdevgroup.com, and
it is Perl and/or Mod_Perl-based. Backcountry.com uses this right
now. I know there are some QuickBooks extensions for it as well that
will probably make your accountants happy.
Jesse
On 11/6/06, Kimball Larsen <[EMAIL PROTECTED]> wrote:
On Nov 6, 2006, at 2:00 PM, Daniel C. wrote:
> Why does the language it's written in matter? I realize I know
> nothing about your architecture, etc. and I'm giving you the benefit
> of the doubt here, but it seems like a weak reason to me.
>
Your original question was:
You can't modify something like Zen Cart to make the accountants happy?
And my response:
> On 11/6/06, Kimball Larsen <[EMAIL PROTECTED]> wrote:
>> Zen Cart / OS Commerce and their ilk are lacking several things that
>> would require major plumbing changes to achieve (notably, that they
>> are not written in Ruby on Rails - natch), thus I wish to roll my
>> own.
Your implication is that I can start with OSCommerce/ZenCart and
simply modify it to do what I need. That locks me into PHP. I have
decided not to use PHP for this, thus I can't just modify
OSCommerce. I would have to re-implement it all in RoR. This would
be fine, if I thought OSCommerce offered some best practices.
My original question is where can I go to find some best practices
with regards to setting up a Point of Sale solution. I have done
extensive work with OSCommerce, and don't feel it really adheres to
what I consider to be best practices in several areas, not just
accounting.
The language of good example software is irrelevant to me - as long
as I can grok it and learn from it. It's best practices techniques
I'm after here.
(stuff like - at the time of an invoice it is a good idea to take a
snapshot of all the relevant data, flatten all relationships and
store it all with the invoice - thus when you later change the items
offered for sale in your store, you don't have item_id fields in an
invoice that point to a now non-existant item, but rather have stored
all the item's details with the invoice.) (of course, it could be
argued that flattening data is a horrible idea, and you should just
never delete/modify the stuff you have for sale, but just add new
inventory items when you wish to change your inventory)
-- Kimball
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
--
#!/usr/bin/perl
$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
