ecommerce

Hi there

I'm trying to locate developers (any skill level is ok) who have the same E-Commerce focus that I do. The idea is that I am available for feedback, reviews, advice, escalation, and even tuition. Yes, tuition, which means I'm happy for this to be a mentor arrangement (which is why I've posted to Dojo).

The problem with developing for E-Commerce is a) we are not giving out CVS access and b) patches in the queue can be painfully slow to commit. We already have 5 maintainers. So the challenge is to have patches committed promptly by one of the maintainers. I can do this, as long as the patches are for areas that I am familiar with.

Big changes

Today marks a big day for certain parts of the store.module. The store_transaction_save function was retooled and is less than half its original size.

Key points to get out of this are the increased emphasis on the use of the hook_ec_transactionapi. A good deal of the store transaction logic is now in store_ec_transactionapi and all the product/item logic in now in product_ec_transactionapi. This lead to some greatly simplified code to which is great for everyone.

Quickbooks is coming to drupal soon, but I may need help from the community.

I currently have a module that uses SOAP and the RDS (Remote Data Sharing) server from Intuit (a program that runs locally on your machine locally and runs. It acts as a "proxy" b/t you and your quickbooks file, and accepts SOAP requests and pulls the information from quickbooks for you and returns the information in XML format). The module is pretty simple in form currently.

• On a users "My Account" form, an admin user is presented with a drop down of current customers from Quickbooks. The admin then selects what "customers" the registered user can view.

Howdy

I finally got around to writing some simple shipping (ie. with no external apis) code for E-Commerce 4.7. I had intended to do this for a while, but was always held back by the fact that it had to involve changes to store and address modules.

I have just now had the time to do a preferred solution. It is not going into E-Commerce 4.7, because I've made extensive changes to core modules. However, if there are no major complaints, I have semi-permission from gordon to build this into head (soon to be 5.0).

Hello Folks,

I just have a little question regarding eCommerce in Canada. This question regards Payment Gateways. What are our options?

I see in the handbook (http://drupal.org/node/66299) a handful of gateways supported by E-commerce. Can these be used from here? If not, any alternatives?

Thanks
Francis

Do you guys have any suggestions for online giving/offerings? Thoughts?

While writing the code for ec_useracc I hit a massive, unclimbable wall. Sale of a user account requires a valid email address and without address or ecivicrm installed your site is out of luck. This post discusses the problem at hand. If you're short for time you can skip the discussion and get straight to the point.

I've managed to completely translate E-Commerce modules to German. Translation is based on 4.7 and needs a one-liner-patch to cart.module (missing t()-function). So now I've got 9 gettext files and 1 mini patch I'd like to contribute.
After several hours of translating, testing and translating I don't want to create one issue for each file, so can I please mail them to someone to commit them? (gordon?) I doubt I should use the file attachments here. So please come by and help me to get this in!

My motivation is to get more German users to E-Commerce. Drupal with E-Commerce is a fantastic solution compared to other online store systems like osC, xtC, JOS VirtueMart and so on. Altogether we have to remedy some major deficiencies in E-Commerce, f.e. the incomplete tax system and some legal rules we have to implement for usage of E-Commerce in Germany/Europe and even more important for selling internationally (different currency and tax per language and the like).

Heya Walt

Nice to see my pic on the move! Here is an alternative that might work better in this context. Let me know if you want something slightly different.

Simon

Hi guys,

I recently updated the worldpay.module for 4.7 and included an automated "callback" after the order is processed...i.e. the worldpay server tells the drupal site that the transaction was either APPROVED or CANCELLED (Denied happens at the worldpay end and the order is cancelled).

So a Drupal site admin who is setting up their worldpay enabled shop, enters in the worldpay_callback the worldpay server sends the "y" or "c" flags to. The problem is securing that transfer of information or in other words, validating the source.