| Completed orders |
| Multishop for osCommerce |
|
|
General information |
The Web application for multi-administration of the removed shops created on the basis of osCommerce 2, further Multishop
The Code - Multishop
Testing of work by uploading of the ready a web application Multishop on server of Bogdanovich Software House. Creation of separate access for the customer, completion according to customer’s representations regarding structure and design of Multishop.
The Web application should completely exclude necessity of a separate input for an administrative part of the removed shop on the basis of osCommerce 2.
Web application will be used on standard virtual webhosting in a view of restriction of execution of scripts not less than 30 seconds without additional restrictions established by hoster.
REQUIREMENTS TO FUNCTIONING A WEB OF THE APPENDIX:
1. AN OPPORTUNITY OF ADDITION IN A MULTISHOP OF NEW SHOPS, AND ALSO THEM removal in case of need.
2. Gathering and data processing about the orders acting in a multishop from all shops.
3. An opportunity of change of statuses of orders from a multishop. The status of the order can be following:
a) pending
b) Order is confirmed (thus there should be a check if this client has already did the order and money have been received (the status of the order "is paid") the status of the order automatically varies with
c) Order is paid (this status is exposed manually by the operator)
d) Order is sent (also exposed manually) Change of the status on " Order is sent " transferred to corresponding sites, than letters from sites in a standard mode should be sent (as are normally sent at change of the status of the order manually on a site). All other changes of statuses are considered only in a multishop and not transferred on sites.
4. An opportunity of listing of forms for sending by a cash on delivery. Departures happen 4 kinds:
a) A registered postal packet with declared value,
b) Valuable parcel with declared value,
c) Usual post parcel (without the declared value),
d) Foreign departure (small package). Each kind of departure has its forms.
5. Conducting the general database of clients in a multishop (it is necessary for checks of auto-acknowledgement of the order, see p.3.b)
6. An opportunity of checking IP address of the client from a multishop, it should look like, as copied from base of a corresponding site the reference a kind of (http://www.dnsstuff.com/tools/whois.ch?ip=81.201.28.31), opening in a separate window.
7. IMPORTANT and enough uneasy moment: use of the reference post indexes in a multishop: (http://info.russianpost.ru/database/ops.html) . This is necessary since very often clients specify an incorrect index, or the name of region. So formation of the final address of sending occurs by a following principle:
a) We obtain data about an index from the order.
b) 1) We find place according to index in a post database . Eg. We have index: 628422. In the base this index corresponds a next line: Tumen Region, AUTONOMOUS REGION HANTY-MANSIJSKIJ-JUGRA, SURGUT. These data is substituted in the final address.
c) We add the address specified in the order and full name of the client to it. All this data is automatically formatted under the uniform standard since all clients enter all differently. We receive a final variant of the address. Other fields, which are specified by the client in the order, Eg. The city and area are displayed and are used for check by the operator.
b) 2) Also there should be an opportunity of input of an index manually by the operator with substitution from a post DB of all data corresponding these index.
8. Reports.
a) the Report on cumulative sales for any period
b) by paid orders,
c) on constant clients.
d) list of orders for a day in the form of convenient for the employee who is processing orders. Probably, still aome more reports.
9. Archiving records about the order. It should occur automatically in case if statuses of orders are noted all, i.e. the order is confirmed, money are sent, and it is received. Thus the order is cleaned from basis also moves to archive.
10. For each record (each order) on its page there should be a list of the ordered goods with an opportunity to notice already prepared goods by a tick
If it is possible, to automate process of orders gathering from shops so that, for example at 20:00 every day all orders were updated without participation of the manager. |
Column by:
Michael Dorofeeff
Order materials are published without editing, but with saving style and spelling of the Author
Leave your feedback
|
