@Massimo: The first phase of our project is only going to generate invoices with bar-codes that are taken to our registers for payment, due to the complexity of our discount system and how it ties into our member data (not to mention accounting/ reconciliation). So no on-line payment at this time.
After looking at the web2py e-store appliance, I also think our requirements differ to the point that extending/modifying the e-store will add more overhead than it will take away. That said, I will keep modularity in mind during the design and see if there is a way to contribute anything back during the course of development. @David: I forgot to address your last point about getting staff to do reports. This is an idea I've been trying to advocate, as well. I'm using a central DB repository that is ETL'd from several disparate operational systems. So I'm thinking of using OOBase and training some "power users" to build their own reports. On Feb 15, 9:34 am, mdipierro <[email protected]> wrote: > Mind that there is a new google checkout plugin under development. It > needs testing. If you want to help with that it can make everybody's > life easier. Let me know. > > On Feb 15, 11:05 am, snfctech <[email protected]> wrote: > > > Thanks for the good tips. > > > @David: > > > I've considered precisely the points your making. I've already > > designed my "dream schema", which is another argument for not using an > > existing product and getting locked into it's schema. As for the > > ongoing maintenance - I'm hopeful that the combination of readable > > Python/web2pyand some good docstrings will help ease the maintenance > > transition to my successor. > > > On Feb 13, 5:06 pm, villas <[email protected]> wrote: > > > > Anyone who has good programming skills (or can develop same) has big > > > advantages in having a home-grown system. But sometimes less is more. > > > > The downside comes if you personally have to support it over it's > > > lifetime and be distracted from other business opportunities. Then > > > there's a big headache when you've outgrown your architecture and must > > > refactor everything. At that point, you have years of integrated > > > logic, data and staff training to migrate to something better. > > > > IMO it's crucially important to design a really thoughtful database > > > schema. Your apps can come and go, but that legacy data is a long- > > > term ball and chain. When you've got several sub-systems accessing > > > your DB, just changing one field can becomes a real hassle. > > > > Tip for an on-going time-saver: find a way to get staff able to > > > produce their own reports. An end-user reporting module can be worth > > > it's weight in gold. You really have to try to take every opportunity > > > to get yourself out of the loop and make yourself as dispensable as > > > you can. > > > > Good luck with your endeavours! > > > --David -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
