Product nodes/objects under the web shop menu item

Monday 31 January 2005 3:07:51 am

Hi Erik!

It's nice to see that other developers are concerned with the shop functionality in EZ.

Like you, I've never thought of it this way - but come to think of it, it should be possible to construct a sql query that only fetched items whose attributes contain a Price.

This would indeed be a great addition to the admin interface.
I have the impression that 3.6 seems to be feature frozen by now. We may need to wait until 3.7 to see this implemented by the team in Skien...

<b>Another suggestion: Processing orders</b>

I'm currently setting up some eZ shop solutions, and haven't yet found a way to process orders (like tick off a checkbox that says "Order delivered"). Does such a feature exist? The statictics feature of eZ is great, but the list of incoming orders should be divided into two lists - "unprocessed" and "processed".

---

Perhaps we should team up to expand on the ez shop features, Eirik?

Cheers,

Sven Ryen
sven.ryen at maxus.no

Monday 31 January 2005 5:41:44 am

There are a few things missing from the shop, IMHO:
* an Inventory data type, mainly an int that gets decreased after someone orders something (this should possibly be done by a workflow and a plain int as long as it doesnt create a new version each time)

* the above mentioned processing workflows. It's obvious people need to flag orders depending on their status. If orders at least were content objects that would be trivial but they aren't.

* functionality to generate shipping documents / invoices (mainly: an easy way to convert orders to PDFs which again suffers from the fact that orders aren't content objects).

Above two go into fullblown ERP features but shouldn't be too hard to do (and most smaller onlineshops don't need no SAP ;-).

* sane shipping cost calculation (like adding up weight per item and looking in a per country table)

*

Visit http://triligon.org

Monday 31 January 2005 6:13:21 am

 There are a few things missing from the shop, IMHO:
* an Inventory data type, mainly an int that gets decreased after someone 
orders something (this should possibly be done by a workflow and a plain 
int as long as it doesnt create a new version each time)

Just adding a few thoughts..

If this is implemented (and it should), make sure the int is incremented whenever an order gets deleted without being processed.

Cheers,

Sven Ryen
sven.ryen at maxus.no

Monday 31 January 2005 6:28:16 am

As for deleteion, accounting rules [1] command that you never delete data from relevant sources. What should do instead is mark them as inactive/bogus/whatever and don't display them by default (in the same vain, it should be considered what to do with obsolete objects that have been sold in the past, auditors probably wants to be able look at them).

I'm actually wondering if the whole shop part isn't in need of a rewrite from scratch. The way it SHOULD work IMHO is the following:

For each order, a content object is created that's placed under the users account (so he can see it in the future) in a "pending orders" folder (i.e. one where he can edit his objects). The object holds orders as relations to the items ordered. This way you can use all features commonly used for content objects to manipulate them (render PDFs, have ezselection for status, whatever else you can think of). After submitting the object, it's moved to "submitted orders" where he can only more look at it/write comments attached to it but not change it anymore. Shop clerks can also attach information to it to create an audit trail (again, audit trails are very important) but not change info already there.

Thoughts?

Edit: Yeah, multiple currencies are another highly desired feature (it's pretty disturbing to see ez put local currencies to the prices without thinking about exchange rates one bit).

[1] I should be learning accounting right now but I'm battling the flu, so concentration on stupid numbers isn't too good :-(

Visit http://triligon.org

Tuesday 01 February 2005 2:27:34 am

I think customer data can easily be tied to the user. After all, you're free to change the user class, so why not simply add all address data there?

If I had the time, I'd start rewriting the shop like I think it should be but I'm a little short on time as I should be learning for uni exams this time of the year. If someone cared enough to help, we might be able to join forces, though.

If ez has a revamp of the shop on their list, I'd love to hear about it.

Visit http://triligon.org