Skip to content

Development Plans for the Parts Web App

Jump to bottom
jmrowe edited this page Jan 3, 2012 · 2 revisions

Development Plans for the Parts Web App

Imported from original google doc

Edits

  1. Add new customer
  2. Add new supplier
  3. Add new part
  4. Add new quote
  5. Add new order
  6. Generate new delivery note
  7. Generate new invoice
  8. Generate new delivery label

Queries

  1. Monthly payment statement for accountant
  2. Orders outstanding
  3. Payment outstanding
  4. Documents types by customer or document number

Quote

  1. Quote ID
  2. Customer Name
  3. Customer Address
  4. Date
  5. Item number e.g. 1 of 5
  6. Part number
  7. Part description
  8. Quantity ordered
  9. Delivery time
  10. Product Cost
  11. Delivery Cost (Estimated)
  12. Total Cost
  13. VAT Total
  14. Total + VAT

Order

  1. Order ID
  2. Item number e.g. 1 of 5
  3. Part number
  4. Part description
  5. Quantity ordered
  6. Quantity delivered
  7. Outstanding items
  8. Date ordered

Delivery Note

  1. Delivery note ID
  2. Deliver to name
  3. Deliver to address
  4. Invoice to name
  5. Invoice to address
  6. Invoice number
  7. Customer order number
  8. Customer order date
  9. Dispatch date
  10. Post Office delivery barcode or signature if hand delivered contains an Order
  11. Delivery label with
  • Delivery Name,
  • Address,
  • Customer
  • Order Number
  • Return to Name, Address

Invoice

  1. Invoice ID
  2. Company order number
  3. Customer order number
  4. Customer name
  5. Customer address
  6. Date
  7. Line Items
  8. Part number
  9. Part description
  10. Quantity invoiced
  11. Product Cost
  12. Delivery Cost
  13. Total
  14. VAT Total
  15. Total + VAT
  16. Notes

Internal Records

Has customer paid invoice or is it outstanding Date paid Method of payment

Parts

  1. Part number - Need two values for MoD and Supplier
  2. Part description
  3. Vehicle
  4. Cost

There is no definitive parts list. All parts go through an identify process e.g. they are located in the PDF relevant to each vehicle (there are multiple vehicles supported) and this contains the part name, and an ID number (the ID is not always clear). The cost is determined from this and contact with other suppliers. The intention is to build up a list of parts and costs which will be added to as required, identified on demand by new orders. These PDF files will be stored on the server with the database, and a quick link to them will be required in the web UI. Sometimes the order is split, and delivered as the parts arrive in stock.

Notes

  • Stock Control is outside the scope of this project
  • The customers and suppliers are multinational, so the addresses will have to manage this however all payment is in sterling.
  • There is two methods for proof of delivery, either the Post Office delivery barcode and date, or a date and signature if the package is hand delivered.
  • The orders can be paid before delivery if the part is not in stock and it is near to the end of the financial year. Some customers have a yearly budget which the remainder gets spent at the end on parts.
  • Multiple quotes can be used for a purchase order, some customers change their mind on an expensive part and buy other parts they have been quoted for before.
  • Carriage is estimated, it will vary +/- to the quote for the carriage.
  • All the data demonstrates typos can be a real threat here, any ideas to minimise this is required.
  • All “labels” are really printed out addresses on an A4 sheet of paper, this is scaled up/down to fit the size of parcel. So all that is required is to generate a Large A4 size, Medium A5 size and Small Envelope size print out on paper.

UI Design

(To Own Page) The UI needs to be very basic and easy to use.

Tim's Thoughts

  • I was was thinking we could have a section for each area in the Edits list, i.e. customers, parts etc. These sections would then provided the add / edit / view details capabilities.

  • We could enclose the whole workflow in a 'Transaction'. That way it its possible to view all transactions in different states, quoted, invoiced, delivered, paid, completed, outstanding etc.

  • The transaction can link to or create the relevant customer entries etc to avoid duplication.

    Transaction 1 ---> 1 Quote 1 ---> 1 Order 1 ---> * Delivery (Note) 1 ---> * Invoice 1 ---> 1 Customer 1 ---> * Supplier

  • It looks as if there is a small accounting part to this, an invoice should have a due date (possibly linked to a terms field on the customer) so that a search for overdue items is easy. This should probably be overrideable if needed (maybe the invoice inherits the terms value and this is modified?)

  • Documents should be 'modifiable', but a reason should be added. This is a bit like a commit message for a source file edit. Probably most applicable to Quotes, Invoices and Delivery Notes.

  • Doesn’t an order represent the total required items and the deliveries make the parts of it?

  • Customer details for Quote, Order, Delivery & Invoice are all taken from the Transaction

Printable Items

  • Invoice
  • Delivery Note
  • Delivery Label
  • Statement of Account
  • Quote

It should be pretty simple to enable all of these to be sent by email as well, as a pdf attachment.

Code Objects

All items have an Id field (a long generated from the database?) so every item is unique. Identifiers are either internal or external. External identifiers have a three character type identifier and are used on Documents and other items that will be needed to be looked up by id from the web gui directly. Internal identifiers have no type identifier so are just a unique number. They are used within the code (specifically storage in the database) to allow linkage to other objects. This is primarily to avoid duplication of entries in the db document storage.

Customer

  • Name
  • Billing Address
  • Delivery Addresses
  • Payment Terms
  • Contact Details
  • Notes

Suppliers

  • Address
  • Contact Details (Phone No & Name (s))
  • Parts Supplied (this will be from the Parts information)
  • Do we need to do anything about orders from suppliers?
  • Items Ordered & not delivered
  • Items to pay for
  • Order History etc.

Address Object

  • Short Name (used for 'friendly' identification.
  • Address Text (free text to allow for different address types).
  • Country Code
  • Others - Delivery Rates etc.

The above items (Quote etc., can be used as is with appropriate object grouping)

Line Item

(for Order, Quote, Invoice & Delivery Note - i.e. all Documents)

  • Line Number
  • Part Code & Description
  • Quantity
  • Price

Notes from December Demo

  • Part numbers, there are two values for MoD and Supplier
  • There are multiple suppliers for each part, with differing costs
  • A timestamp would be useful for a part quote
  • VAT needs to be added and must be configurable
  • A markup value box in addition to the actual costs
  • The markup box would allow the viewing of the cost price and the selling price at the same time
  • A link to the vehicle book appropriate to each part
  • Search options for vehicles with their related parts
  • Carriage for the quote needs to be manual entry, weight will make a difference this can not be automated
  • Some parts can form collections e.g. Filter kit
  • By making the part optionally be a collection of parts this allows the company to understand the cost breakdown, when a customer orders one collection
  • Report problem email option
  • Invoice must be associated to an Order
  • Some invoices are raised before the delivery is made
  • Who raised the quote

Links

Clone this wiki locally