ProSoundWeb Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 ... 3 4 [5] 6 7   Go Down

Author Topic: The inventory control question again...An idea..  (Read 41233 times)

Phillip_Graham

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1584
Re: The inventory control question again...An idea..
« Reply #40 on: September 22, 2006, 12:39:46 PM »

Reading this thread is a reminder of why people talk about the idea of objects in programming classes in college Smile  I lost track of the number of commercial, and in house, solutions pushed forward in this thread.  Every company really is a software company at some point.

Geri,

I would submit to you to take a step back for a second.  Go through this thread, contact the developers of all the mentioned (commercial) programs.  Put those in a excel spreadsheet, and compare them.  I suspect you will find one that meets your needs.  Post that spreadsheet here and help other people out, too.  Also, expect to pay real money for a program that does quality work.  

If you don't find one you like, then come back and start with a much more rigorous set of details for your software.
_____________________________________________

As a dabbler in this industry I see two guiding principles:

1.  People make your name-their set up/take down, show execution, shaking hands, networking, intangibles.  This IS your reputation.

2.  Your back end makes you pofitable-How you BID, how you PAY your people, track maintain inventory, handle repairs/depreciation, and purchase new capital.

Because the back end covers so much stuff, and your clients could CARE LESS about how it all works behind the curtain, companies like SAP that offer all-in-one solutions, are increasingly popular for businesses.

My 2C
Logged

Michael Prasuhn

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 673
Re: The inventory control question again...An idea..
« Reply #41 on: September 22, 2006, 01:29:17 PM »

Jeff, don't get me wrong I love drupal, but I don't think it would be well suited for this project. I think in the end you would end up with 97% rentalapp.module and then 3%drupal, but everything you do would have to go through drupal just enough to dictate how everything in the rental app portion of it is done... While I had some crazy ideas about this the other night, using CCK to create gear entries and containers for racks and then using the event module to schedule...organic groups to manage crew...I'm just not sure we could get it to the level of functionality that is demanded by most in this thread.

On the other hand,  drupal site or a wiki would be a great way to offload this discussion to a centralized place, and I would be more than willing to set something like that up or host it.

-Mikey P
Logged
Michael D. Prasuhn
Freelance audio engineer and technical director/IT
http://mikeyp.net

Too Tall (Curtis H. List)

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1591
Re: The database idea subthread
« Reply #42 on: September 22, 2006, 03:17:18 PM »

Geri O wrote on Tue, 19 September 2006 23:16

Since I truly believe that the interest is out there ("If you program it, they will come"? Laughing ), I'll start the "official wish list",

Naturally, a maser database to work from. Info such as make, model, serial number, company inventory number. It would have a status listing, such as "available", "unavailable", "Out for repair", "Time for PM", etc.

A "group" database that would be items made up of individual components. A group could be an effects rack, amp rack, or maybe even a console, its power supply, and an EZ-Tilt. I see how this part could get confusing, so it might need some special treatment that anyone might come up with. I imagine that with some folks, the group's contents could change from week to week. That's not a big thing with us at the moment, our racks stay prett consistent.

Once this database is created, you can create a "booking". A booking could be classed as a "show" or a "rental". In either case, the listing would make a change of the item's status in the master database. I like the idea of bar-coding, but that might be too complicated and I do want to keep the program simple.

That's my start of things. I might add or change things as we go.

Geri O




Hi Geri,
Audiopass, the QC (Quality Control) part of Praxis uses bar codes to keep track of any speaker in the inventory so you have a history of how it measures every time it is tested (Usually when it comes back off the truck).
I would think bar code would be mandatory for all the larger pieces of gear or entire racks etc.
I don’t see it putting a bar code on every 10’ guitar cord, but you need to be able to quickly identify the gear to track it.



Logged
Too Tall
        Curtis H. List    
             Bridgeport, Mich.   
        I.A.T.S.E. Local # 274 (Gold Card)
        Lansing, Mich
Independent Live Sound Engineer (and I'm Tall Too!)

David Buckley

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 582
Re: The database idea subthread
« Reply #43 on: September 22, 2006, 04:35:05 PM »

Too Tall (Curtis H. List) wrote on Sat, 23 September 2006 07:17

Audiopass ...  uses bar codes to keep track of any speaker in the inventory so you have a history of how it measures every time it is tested ...  I would think bar code would be mandatory for all the larger pieces of gear or entire racks etc. I don’t see it putting a bar code on every 10’ guitar cord, but you need to be able to quickly identify the gear to track it.


As a ex-professional software developer (which is what keeps me interested in this thread, as well as having some hirable kit), there are two aspects of a simple inventory control system that are (in programming terms) "interesting".  Take away these two (hard!) requirements and the job becomes simple, the sort of thing you can knock up reasonably quickly, as it comes down to things, hirers, bookings, and the relations betwixt said entities.

The first is in the groups mechanism, because the groups can change over time, and worse than that, between bookings yet to be delivered.  Thus a simple concept of a group is x+y+z is not valid except at a point in time.  Next week a rack might have x+y+z, the booking the week after needs x+q+z.  Thus a barcoded rack isn't a permanent entitiy (other than the rack itself), its just a promise of what might be inside.  But you need to be sure the racks have the right contents.

Theres also the possibility that one could ask for there to be layers of groups, or recursive groups.  It would be nice to simply rent out "the disco rig", as a single entity, which is a "group" of things, but some of the things in the disco rig may include groups within, such as a rack or coffin.

The second is alluded to by Curtis, namely that when you book a show you want, say, half a dozen subs, of your total stock of a dozen identical subs.  At booking time you dont care exactly which of six of those twelve subs, any six will do.  But at checkout and checkin, you need to be sure exactly which of them it is, so if it/they goes missing you've got a serial number to report.  As mentioned, you can track usage of stuff for mainenence purposes.  But you really may not care about (example) guitar leads as they are truly interchangeable, but in order to send them out, you need to know if you've got them, so you need to know how many you have...

And certainly in Europe and Aus/NZ (and maybe many other places) your tracking of mains cables is important, and most such cables will already be barcoded on their PAT test label, and some of the "usual suspect" hire packages enable PAT testing data to be held in the inventory.  

Logged

John Roberts {JR}

  • Newbie
  • *
  • Offline Offline
  • Posts: 0
Re: The database idea subthread
« Reply #44 on: September 22, 2006, 05:09:45 PM »

David Buckley wrote on Fri, 22 September 2006 15:35

Too Tall (Curtis H. List) wrote on Sat, 23 September 2006 07:17

Audiopass ...  uses bar codes to keep track of any speaker in the inventory so you have a history of how it measures every time it is tested ...  I would think bar code would be mandatory for all the larger pieces of gear or entire racks etc. I don?t see it putting a bar code on every 10? guitar cord, but you need to be able to quickly identify the gear to track it.


As a ex-professional software developer (which is what keeps me interested in this thread, as well as having some hirable kit), there are two aspects of a simple inventory control system that are (in programming terms) "interesting".  Take away these two (hard!) requirements and the job becomes simple, the sort of thing you can knock up reasonably quickly, as it comes down to things, hirers, bookings, and the relations betwixt said entities.

The first is in the groups mechanism, because the groups can change over time, and worse than that, between bookings yet to be delivered.  Thus a simple concept of a group is x+y+z is not valid except at a point in time.  Next week a rack might have x+y+z, the booking the week after needs x+q+z.  Thus a barcoded rack isn't a permanent entitiy (other than the rack itself), its just a promise of what might be inside.

The second is alluded to by Curtis, namely that when you book a show you want, say, half a dozen subs, of your total stock of a dozen identical subs.  At booking time you dont care exactly which of six of those twelve subs, any six will do.  But at checkout and checkin, you need to be sure exactly which of them it is, so if it/they goes missing you've got a serial number to report.  As mentioned, you can track usage of stuff for mainenence purposes.

And certainly in Europe and Aus/NZ (and maybe many other places) your tracking of mains cables is important, and most such cables will already be barcoded on their PAT test label, and some of the "usual suspect" hire packages enable PAT testing data to be held in the inventory.  




I don't have any expertise in this area but isn't this all just a form of relational database? The magic may be in the middle ware, i.e. bar code scanners, and/or data entry terminals. I hear Motorola just bought Symbol. I'm not sure if that's good or bad but Symbol seemed a little more dysfunctional than Motorola  FWIW.

One idea that I had which is out of left field like so many of my ideas was to have an on board digital processor clock a front panel led in such a way that a bar code scanner might be able to read it as if it was a bar code swipe. Some variant on UPC could identify the product with perhaps additional info like serial number, agency approvals, etc. This would get around the problem of precious front panel real estate. I kind of like S/N that can't be scratched off.

Or not.....YMMV  Cool

JR
Logged
 https://www.resotune.com/


Tune it, or don't play it...
-----

Too Tall (Curtis H. List)

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1591
Re: The database idea subthread
« Reply #45 on: September 22, 2006, 06:30:06 PM »

David Buckley wrote on Fri, 22 September 2006 16:35

Too Tall (Curtis H. List) wrote on Sat, 23 September 2006 07:17

Audiopass ...  uses bar codes to keep track of any speaker in the inventory so you have a history of how it measures every time it is tested ...  I would think bar code would be mandatory for all the larger pieces of gear or entire racks etc. I don’t see it putting a bar code on every 10’ guitar cord, but you need to be able to quickly identify the gear to track it.


As a ex-professional software developer (which is what keeps me interested in this thread, as well as having some hirable kit), there are two aspects of a simple inventory control system that are (in programming terms) "interesting".  Take away these two (hard!) requirements and the job becomes simple, the sort of thing you can knock up reasonably quickly, as it comes down to things, hirers, bookings, and the relations betwixt said entities.

The first is in the groups mechanism, because the groups can change over time, and worse than that, between bookings yet to be delivered.  Thus a simple concept of a group is x+y+z is not valid except at a point in time.  Next week a rack might have x+y+z, the booking the week after needs x+q+z.  Thus a barcoded rack isn't a permanent entitiy (other than the rack itself), its just a promise of what might be inside.  But you need to be sure the racks have the right contents.


Theres also the possibility that one could ask for there to be layers of groups, or recursive groups.  It would be nice to simply rent out "the disco rig", as a single entity, which is a "group" of things, but some of the things in the disco rig may include groups within, such as a rack or coffin.

The second is alluded to by Curtis, namely that when you book a show you want, say, half a dozen subs, of your total stock of a dozen identical subs.  At booking time you dont care exactly which of six of those twelve subs, any six will do.  But at checkout and checkin, you need to be sure exactly which of them it is, so if it/they goes missing you've got a serial number to report.  As mentioned, you can track usage of stuff for mainenence purposes.  But you really may not care about (example) guitar leads as they are truly interchangeable, but in order to send them out, you need to know if you've got them, so you need to know how many you have...

And certainly in Europe and Aus/NZ (and maybe many other places) your tracking of mains cables is important, and most such cables will already be barcoded on their PAT test label, and some of the "usual suspect" hire packages enable PAT testing data to be held in the inventory.  





I realize that would happen. I don’t know the easiest way to handle this so that billing is easy, but you have many choices. A simple way might be to have the bar codes of everything in the rack on the outside of the rack. Slips of paper plastic wrapped and you scan them all when they go in and out. You could still have the bar code on top of the SPX90, but it would also have a loose piece of paper that goes onto the outside of any rack it is installed in.

Or you could print out a sheet of paper for each rack every time the rack goes out and throw it away the next time it goes out. The only permanent bar code would be for the rack itself.

In many cases you would have a rack that does not change much or just has a few things added


Hey what about RFI tags like Walmart and all the big boys use?
Perhaps a little over budget for the reader?
LOL


Logged
Too Tall
        Curtis H. List    
             Bridgeport, Mich.   
        I.A.T.S.E. Local # 274 (Gold Card)
        Lansing, Mich
Independent Live Sound Engineer (and I'm Tall Too!)

Chris Davis

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1790
Re: The database idea subthread
« Reply #46 on: September 22, 2006, 06:53:16 PM »

The relational database lends itself to update all related fields in all matching records.  The benefit is one change can propagate to all linked or related matching fields.  
Although relations should work to tie together most of the database fields, I see a problem in using them to produce permament records of temporary equipment groups, as others have noticed.  

So, I might suggest that "temporary" relations (to produce permanant records) may be used here in the form of scripting.  That way as soon as the script if done executing, then the data is permanantly embedded and no longer linked.  Then at any point in time, the groups (which can be related or linked to the individual equipment records) can be changed and not affect the records from previous transactions where the groups may or may not have contained different equipment.

So, to summarize...individual groups are related (linked) to each piece of individual equipment it currently contains.  This is a temporary arrangement.  It would be feasible for it to be a temporary arrangement because all record-keeping or transactional records have all the group/equipment information permanantly stored in each record, not related or linked.

Scripting can then be used later on to sort through all embedded info from previous transactions to show you exactly what equipment was in each group for each customer.  So you could go back in time and see what you used for a particular gig a year ago.

Also scripting could be used as an interlock to prevent someone from modifying the contents of a related group until the equipment is checked back in to the shop.

Also, the relational db could update all items within a group as checked-in/checked-out depending upon whether one single item in a group is scanned (thus eliminating a group-specific barcode).  

Furthermore, the db program could display all items within a group upon check-out or check-in for quick visual verification purposes.  

Furthermore, checkboxes could be used next to each item to be verified to serve as an additional procedural part of verification as well as account for missing/stolen/out of comission equipment.
Logged

Rich Mullen

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 302
    • http://www.edgeaudioservices.com
Re: The database idea subthread
« Reply #47 on: September 22, 2006, 07:25:50 PM »

That is how we worked out the rack items issue to allow for kits and add flexibility to change and add that stuff. Our system is Access/sql based and structured to allow for a good deal of wheelin' and dealin' with rack and components while still not allowing you to book out 2x 9001's with the same serial number Smile.

We used 'default pack' field in the products table to designate an items normal location. That allows a SPX 990 to be put into a pull over rack numbered 201. Then then when you pick 201 that particular 990 goes with it. You can choose that 990 to rent OTC. The 201 nrack will come up color coded indicating an item has been removed. You can pick loose items out of a shop storage rack and add them to a rack. We achieve that by using again a relational field in our orders table called pack-in.

A relation database with some thought to a decent table structure can work very well in this app. At least it does for us.
Logged
EDGE Man

Chris Davis

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1790
Re: The database idea subthread
« Reply #48 on: September 22, 2006, 08:48:22 PM »

I just thought that up as I typed it, with Filemaker in mind.  It seems the biggest difference between our ideas is that you have default places where your equipment goes and I had a organic approach to let the chips fall where they may.  Thanks for confirming.  
Logged

Riley Casey

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1026
    • http://www.ESPsound.com
Re: The inventory control question again...An idea..
« Reply #49 on: September 22, 2006, 09:02:23 PM »

If the sticker shock of things like HireTrack are a major issue look at this solution :

http://www.projectmaker.com/

After building my own Filemaker based system I was very impressed with this as a commercial offering.
Logged

ProSoundWeb Community

Re: The inventory control question again...An idea..
« Reply #49 on: September 22, 2006, 09:02:23 PM »


Pages: 1 ... 3 4 [5] 6 7   Go Up
 



Site Hosted By Ashdown Technologies, Inc.

Page created in 0.041 seconds with 22 queries.