<< Back to Projects page
Main editor: Ingo Schmitt, Volker Graubaum
notice - Note
- 1 Download
- 2 Current Status
- 3 Feature list
- 4 Implemented Shops
- 5 Status
- 6 Wish List
- 7 Product categories
- 8 Products
- 9 Articles
- 10 Attributes
- 11 Offers
- 12 discount
- 13 Manufacturer
- 14 Shopping cart
- 15 shopping list
- 16 checkout
- 17 billing
- 18 order
- 19 Additional Features
- 20 Technics
- 21 Analysis
- 22 Relations
In TER: commerce
Commerce is availiable in the sourceforge SVN t3xdev, project commerce. [typo3xdev.svn.sourceforge.net - tx_commerce]
Please do only register for the "new" bugtracker at https://forge.typo3.org and use the mailinglist:
The current class documentation is availiabe at [doc.typo3-commerce.org].
Original thread is at ...
Here you can enter the URLs of the shops you have implemented with Ext-commerce .
The features have been put in an project sheet to let other developers participate and to get funding for this project. Generall discussion about this project is done via the newsgroup projects.tt-products or via regular irc-chats.
Developing has started after we finished the DB model which can be found here:
See also the project description here:
- Have some fun
- Multilanguage shop system
- Catalogimport via XML
- Catalogexport via XML
- The possibility to change an order's status (i.e. from Pending to Sent) by clicking a link in an e-mail (makes it easy to manage orders if order processing is done only by e-mail and not with the T3 backend/frontend)
- "Downloadable" products. It would be great if you could not only sell physically unique articles via the shop but also digital resources like images, PDFs, software ... Would be great to have the ability to build bundles of downloadable products (for example: the shop has single mp3 tracks (products) and albums containing 4 tracks (4 products) acting as a bundle.
- For Downloadable products: Secure Delivery Service for Download Links via Email (Without login to FE/BE) using for example PayPal Instant Payment Notification (IPN). If the customer finish a pending payment he´ll get the dl-links to his paypal emailadress. Customer can download each product n times within m hours
- For pictures: They should be displayed as a gallery which mirrors the folder structure where the pictures are stored. The pictures should be automatically included into the shop when creating a new subfolder with pictures, because it is often exhausting to add each picture to the shop separately when having large picture folders. Each picture folder should have an own description and price per picture. The pictures should contain a watermark which is removed after payment.
- Ability to combine physical and downloadable Products in one order
- Selling website content. It would be cool if it would be possible, to sell access to TYPO3 pages with commerce. So you could for example sell access to the "Community Corner" of your website. Technically, this would be selling access to usergroups. So the customer (having a fe_user account) then buys the membership of the fe_group "Customer Corner Access" for example. Read this for more info.
- add possiblity to get products information from robert lemkes document
- real time price calculator - By selecting multiple feautures, the total amount will change accordingly in real time. See www.dell.com for an existing example. (=> This is a *must*, for shops in germany, by law.)
- suit extension
- templating with templa voila
- api/hooks for payment gateways (paypal) ? Hooks for payment gateways are available, there is an implementation of the paypal-express-checkout feature
- api/hooks for shipping gateways (UPS,GLS,GP,DHL ... )
- add functionality from zk_produkts (stock/deals/...)
- different prices for different customer groups
- different prices for different localized pages (countries)
- different products in teaser sections based on criteria, such as locations and dates.
- Add related 'extras' to a product, when one product is shown allow related extras to be added at the same time
- Customers who bought this also bought these.....
- You recently viewed these products.....
- offer single items which disappear when sold (for selling used stuff) and which can't be bought twice or more often by editing the basket.
- Product attributes which might change the price of a product (eg colour1 = price + $20; colour2 = price + $30), maybe attributes are separate products which then are linked
- alternating list displays
- different tax rates for one product
- should mostly adapt the main neat functions of osCommerce
- The possibility to use many images for each product
- The possibility to use tables created in RTE (doesnt work in current version of tt_products)
- The possibility to download user manuals (PDF) for each product
- The possibility for multivendor shops, to enable different suppliers (providers) to sell products and services or downloadable goods in one check-out session to customers directly
- Feedback and comments from users
- Rating of products
- support for each category its own admin who can see only the orders for its own category --> bigger shops with different catergoy administrators
- Advanced stock management: prognoses based on history (no. sold previous year), cost, turnover and profit calculation, low stock warning based on delivery time, extend product with features (i.e. colour, size, etc.) and statisics based on product features (most sold size, colour, etc.). This feature could create high efficiency with low effort.
- Affiliate system
- The ability to sell time interval -based subscriptions (of an electornic product, etc.) with automatic expiration of user group membership (for an excellent example, see AgileBill, http://www.agilebill.com )
- Import of cvs, excel, openoffice, SAP, navision and other formats should be supported for import product data
- Payment gateways from osCommerce (paypal, secpay, ipayment, credidcards, 2checkout.com etc. etc)
- Possibility to enter slide-scaling prices according to quantities (Staffelpreise, i.e. 100 units=10,00/unit 500 units=8,99/unit etc.)
- Possibility to use 4 decimals (0,0231) for wholesale items.
- User/buyer-tracking with remote adress
- Cookie-ing last visit
- Catalogpagelike presentation of different artikels in one picture and selection by active areas.
- Colormanagemant of navigation/titlebar/etc. depending on category or artikel or usergroup etc. to support "emotional selling"
- Drag and drop of articles to shoppingcart
- An Interfacte to different commodity management systems/softare (in german: Warenwirtschaftssysteme).
- Links from textpages to products and articles and links from products/articles to other products/articles.
- Supplements for products or articles through the radio buttons (PC = 300$ / +1GB RAM = +20$ / +2GB RAM = +40$ /...).
Real Time Price Calculator (i.e. you see the total value of the product in real time, when you select or deselect multiple features - see dell.com for an existing example)
Should have payment gateways like paypal, firstpay Click&buy (germany),creditcards Did I miss any gateway? fell free to add some... (osCommerce has the following payment gateways: 2checkout.com, authorize.net, ipayment, paypal, psiGate, SECpay, trustcommerce)
Needs flexible pricing methods, e.g. XML-Catalogs that define a certain pricing mechanisms for a customer-article-relationship or for customer groups, article categories.
And flexible product catalogs, depending on the status of the customer. Could be a XML-solution.
RealURL integration to get nice URLs, e. g.: /products/shoes/boots.html, /products/shoes/boots/12345.html
- multiple parent categories
- multiple languages
- access via normal t3 features (hidden, group, time)
- defining article attribute kinds per category which are inherited to all child articles
- related categories
Booksellers need more database fields. A good range is: author, title, subtitle, bibliographical data (such as binding, no. of pages etc. - no use having those as attributes of a product), description, picture (the rest pretty much as mentioned). Products are usually sorted by author's name in a product list, and it's helpful for customers if author and title show up in the shopping cart. Good alternative: allow users to create their own database fields.
- can have more than one parent category
- multiple languages
- access via normal t3 features (hidden, group, time)
- defining article attribute kinds per product which are inherited to all child articles
- description (using RTE)
- search key words
- variable Attributes
- variable tax rates
- minimum order unit
- multimedia content
- access via normal t3 features (hidden, group, time)
- related articles
- stock handling
- action attributes (new, price off ..)
- flexible pricing
- multiple currencies
- Plugin-Concept for stock
- Tax-Handling in general - Static Tables vs TypoScript, Handling of US States
- special offer handling
- multimedia content handling via DAM
- selling DAM Content
- prices quantity stored (with control and report of stock size)
- article numbers
- additional information (pagelink & filelink)
attributes are storing article specific informations, such as size, wheight, color (attribute-kinds)....
Must Features: attribute kinds can be defined as must/can per categorie/ product for all articles below attribute kinds can be added to articles Values are stored via attribute-kind, calue relations
Can Features Separate handling for values
Offers can store information for separate placments for articles. E.g. Jubilee, trade off, new.
- Flexible Duration
- Variable Price
- Price check for new price, shows everytime the cheapest price.
Price offs can be handed via different systems. It could be e.g. connected with a FE_user_group, or with offers or within the amount of the shopping basket
Default handing for following Types:
- people and group (for product and in general)
- discount for a special shopping value (e.g. 200 â¬)
- discount for a special shopping quantity (e.g. 5 of a product will give one more)
Felxible Configuration features via TS Plugin-Concept for more discount types
related to Article
A Shopping Cart is handeling the information about what items are currently put into the cart during the Session
Issue: How to store Cart data (DB/Session Data) and how to identify user.
Must Features: API for adding, storing, changing articles in cart Currencies handeling
Can Feature A shopping list stores old carts for the next visit. Normally carts are stored
Issue: how to store the List (Cookie, Login..)
The Checkout is handels the complete User interaction process, as Adress, payment, userdata, delivery. A Checkout uses the prior filled Cart
- handeling user registration via FE_user (with API) incl. automated user generation with first order
- ability to add separate deilivery adress
- plugin system for different Payment Methodes
- different country options
- different payment and shipment options (with different prices) (handles also credit card number encryption)
- Support for payment by debit entry (Lastschrift)
- special payment options for special groups
- overview shopping cart
- confirmation of terms and conditions (AGB)
- Transport costs handeling (incl. API)
- General Shipping API to include different Weight/Place tables
Provides an API for handling billing points like
Calculation of shipment costs by weight or item-no.
Order Systems holding the information belonging to the order.
- change and see status of order (ordered, shipped, rejected, finished)
- add notes for orders
- Proof customer satisfaction
- Add shipping API so Status of shipping could be seen (future)
- wish list
- Coupons (eg. gift certificate that gives some arbitrary discount)
- bonus (when he has returned the last order he can get a bonus for the next time)
- complete breakup/separation between logic(php,classes) and HTML, means *no* HTML in any class! =), tableless CSS-Templates
- support of multiple database systems (DBAL)
- automatic creation of billing and delivery papers
- order tracking and sending of order emails
- search for articles
- monitoring system for lack of products in the stock
- MVC design: separation of classes for data model and view/controller
- interfaces to other software (e.g. popular business-software like LexWare in Germany)
- Using DAM for mediafiles
- Following a personal wishlist based on experience OSC, CRELOADED =OSC+all extensions etc.:
- Avoid OSCOMMERCE set-back: Avoid >3 directory levels.
- Avoid OSC problems: Define entry ports for extension modules (code modifs prohibited!)
- Avoid OSC problems: Config data mostly into files, secured dir's, no softw panic if DB down
- Avoid OSC problems: put multi-language data into arrays, allow for operation on them.
- Avoid OSC problems: Avoid many single DB tables; insert dummy free char fields =Reserve
- (first Step csv Export of orders, with filters) file (XML) import / export for products / categories basic setup during installation
- wide ranging settings and customization with TScript flexforms for general settings on the pages
- Commerce Shop Extension This extension use an 1:N relation for addresses and included an own addressmanagement, which should be part of the Party Information Framework.
- Enhanced Rights Management - a pear class for a RBAC / Role Based Access Control.
- Inline Relational Record Editing - 1:n relations for BackEnd-Forms -- Oliver Hader
- Newloginbox development coordination - Ingmar Schlecht and Stefan Strasser
The User list plugin (pi3) of Newloginbox is related to the Party Framework. If the Party Framework will ship with a user listing plugin, the pi3 of Newloginbox wouldn't be needed any more.
- Users Addresses - relations between fe_user and tt_address, best practice discussion - Elmar Hinz
- dkd_feuser_belogin - relation between fe_user and be_user