Hello to all contributors of this thread. It's taken me about a week to install Zen-Cart v1.3.9h from the FreeBSD Ports, sniff around the PHP code and configure a working custom template.
This is my first post . . .talk about jumping from the kettle into the fire. Drop shipping is indeed a can of worms. Kuroi is on point, as is mybiz9999's comment regarding SAP. SAP is expen$ive, and expen$ive to implement.
During January - October, 2003, I was part of a small team that developed an API for a major fiber optic cable manufacturer's "backend" purchasing system (ERP) with a web browser based interface provided by (what was then) CableNet International, Ltd. (a UK company). Development involved IBM's OS/400 DB/2, COBOL and the CLP. The cable mfgr's ERP system was an ASI (American Software, Inc.) product. The bigger parent company has bought back the stock of the cable mfgr. held by a "partnered" corporation, and now has now elected to convert to SAP. the system used by the parent company. . . .enough of my resume'.
One complex consideration of interaction with a vendor's ERP system (assuming the vendor is willing to let you interact with their in-house/backend system) is the fact that a web browser application is a stateless protocol, and the vendor's system is probably a stateful session.
One issue, for example, involves quantities on hand. If your web-store receives a purchase transaction, then you need to check the vendor's QOH by initiating a query for the same which, for example, returns a transaction that posts a current QOH of three items. The Catch-22 here is that let's assume your web customer sees that three items are available, but the customer decides to go get a cup of coffee before placing the order. In the mean time, your vendor sells two of the three on hand, and your web customer's stateless web browser still displays three on hand. Fifteen minutes later, your web customer returns to his/her desk and proceeds to complete a purchase of two of the three items that the vendor's system previously posted as available.
Obviously your web customer is going to be disappointed (to say the least) because now your vendor only has one item left. How this scenario is handled can become very complex. Your vendor's stateful/session system doesn't know what your web customer's browser has done . . .your web customer may have clicked out of your web store and purchased elsewhere. In any case, it's unlikely that your vendor's system will try to maintain state and generate an event driven transaction to update a web browser display that may not exist (and essentially, it can't because . . .remember, we're dealing with the HTTP protocol).
To protect the integrity of the web customer's purchase, you need to go back to the well with an instruction that tells the vendor's system that your web customer has committed to the purchase of two items. In our example, the vendor now has to return a transaction that informs your web customer that insufficient quantities exist.
OK . . .fine. Your web customer decides to purchase the remaining one item. Essentially, the process starts over at this point, but once the commitment to purchase the one remaining item is received by the vendor's system, then ideally, the vendor's system should allocate or lock the item record while the purchase is completed (this to prevent another customer from jumping in and purchasing the item out from under you . . .other inquiries should also reflect QOH less the allocation qty.). This completion process could involve such things as calculation of shipping cost and taxes, ship-to/bill-to addresses, etc.
Payment will depend on your relationship with your vendor. If you're say . . .net 30, then you take payment from your web customer and no payment is transmitted for verification to your vendor and you pay your vendor with a single end-of-month payment, but on the other hand, if you're COD with your vendor, then this becomes more complicated and time consuming. You want to make sure that you're paid before you transmit a payment from your purchasing account.
Now, remember that locked item record in your vendor's system? Suppose for whatever reason, the purchase transaction falls through . . .credit card authorization declined, your web customer blown away by a tornado . . .your vendor's system has no way of knowing, so how long to maintain the allocation lock on the item? Who knows . . .a rhetorical question?
Developing this type of interaction will require a lot of "face-to-face" meetings with your vendor's IT people. Hopefully, your vendor will already have a drop ship system in place. Testing your interface will be time consuming and tedious. What if your vendor (probably) does not have a test system? Ultimately, your vendor's willingness to provide the service may very well depend on how much volume you're projecting to do with them.
I hope I haven't come across as too negative on this. In fact, I'm very interested in drop shipping.
OTTF,
Ron W.
