Email Oct 10,2013

Hi,

In general I agree with Doug's answers.

The idea for payment is that someone will create an user profile online, then make an order. In Belize the customer will take money (cash) to our Belize representative and make one or more payments, each of which needs to be recorded (I now realize that the design I sent yesterday is incomplete, we need to be able to record a series of dated payments toward a total value.)

At some point, after the payment(s) are greater than some threshold value (say 50%) the order will be reviewed and approved, probably by someone in the US. So we need to be able to produce a list of currently orders awaiting approval.

Once approved, we will order the laptops from our supplier. We need to have a way of tracking total numbers of laptops approved for order, and number of laptops currently on order from our supplier. This could be tricky. What I suggest is a way to mark a customer order at status "ordered" to indicate that a order has be made to our supplier to fulfill that order. I did include a order status ENUM field in the design I sent out yesterday. It made need refinement.

Once the laptops are received, and sent to Belize, we should be able to update the status of each order along the way. What might be nice is to associate a order with a shipment, and then it will allow easier management of all the users associated with a shipment of computers. This is not in the design I sent yesterday.

Once the devices reach Belize, the Belize rep must collect the rest of the payments befor turning the laptop over to the customer.

As each device is given out,, it's SERVICE CODE (ID) must be recorded, and the system must be associated with the current owner.

Finally, there must be a what of tracking actives (like repair) done on each device. So there need to be a table to track this (this is in my design).

I'm going to be honest - it seem unlikely an existing package will support these goals.

SO - we have the following options: 1. Take what we can get, and leave it at that. 2. Use an existing system, and build a associated system to add the other functionality. 3. Take an existing system and augment it. 4. Build something from scratch. 5. Probably other options in between these....

Anyway - I suggest we meet and look carefully at the package suggested before we buy. Also - that we review the design, and decide what is essential, and what is option, and prioritize functionality.

Jim

Topic revision: r1 - 2013-10-11 - JimSkon
 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback