I don't really want it to look like a spreadsheet, I want it to be a page full of the relivant info such as name, owner, details of what the product contains, where it's come from, release date etc, all the important detail needs to be on the first page (or tab) then on teh second tab it needs to transfer some of the info from the main page but have all the shipping info such as where it went, tracking numbers etc, this info is added by another dept, then on another tab it would need to have the costings etc, then on another it would have the QC info and reports etc - each tab or page would need to pull through various bits of info from other tabs/pages so taht when the item is shipped it then migrates this info back to the main page and ticks a box saying it's been shipped etc - each set of tabs/pages would relate to one item/ident so all the relivant info for that one ident/item/version etc is all held in the one package of info that had various tabs/pages
Makes total sense.
If I were building that, I'd use MySQL (a database system on the same basic principles as MS Access, but not MS, and free) and present the pages/tabs as pages on an internal web site using PHP (a language that writes web pages, also free).
But I'd charge several thousand for doing so
Almost certainly there's a ready-made stock control software package that does all this, sort-of, in its own way, with its own names for the names of things-in-the-world. There's probably one that integrates with an accounts package. One question is whether it costs more to customise this than it does to build a new system.
then I would need to have all the idents listed somewhere so that I could search for them via the ident number, I would also need to look at a list of idents that were worked on between a certain date or came in from a particular company etc
It sounds as though you have "got" the fundamental principle of database design.
You have one table in which each row is a stock item, indexed by ident.
You have another in which each row is a customer, indexed by some arbitrary (and, ideally, hidden) customer ID.
You have another in which each row is an order, indexed by order number, stock ident and customer ID.
You might have another that tracks manufacturing and other fulfilment steps (indexed by stock ident and department) or you might store those details as columns in the order table - hard to be sure without an initial £1000 for consultancy
You don't need to update across tables because (as I said earlier) each piece of information is stored exactly once. You build a "view" of an order that pulls stuff about the stock item from the stock table and about the customer from the customer table, and so on.
that's the type of thing - as long as I can add sections to it and change wording etc that's definitely the type of thing I am looking for - I do want to have one section per product and all movement and data relating to that product to be together - I take it that that is possible?
