Results 1 to 3 of 3
  1. #1
    Join Date
    Jan 2006

    Unanswered: Sequential Path Database Structure

    I have been out of the hands-on programming field for quite some time so a solution might be obvious to those closer to the subject matter.

    I would like to have a database able to route a series of information (a requisition in this case) by defining a specific route containing a series of sequences (Route1=ABCD, Route2=ACD, Route3=ACDB ....) and then defining the individuals within each of those sequences (A=Bill, B=Susan, C=Doris,...). I would need to capture when they "sign off", then send it to the next sequence.

    In my mind, there would be (at least) the following tables:
    a requisition table,
    a routing table,
    a routing transaction table to capture the details.

    This database would be an electronic capturing of what is now done by a cover sheet and a stack of papers. Requisition details captured and then a defined sequence of individuals applied based on details of the requisition. As it makes its way through the approval process, information is captured.

    An email feature to notify the approval/disapproval at each step would be great but asking a lot of any lingering programming skills I may have since my days of professional programming go back to Clipper97.

    Is there a public domain template out there similar to what I have described? If not, any general table and relationship recommendations? I have the concept on paper but I dont want to reinvent the wheel if something already exists. Overall thoughts recommendations appreciated.

  2. #2
    Join Date
    Mar 2003
    The Bottom of The Barrel
    Provided Answers: 1
    Ok, so basically you have these "requisitions" that require approval from different individuals in a specific order. Is that about right?

    You're on a pretty good track as is. The requisition table is fairly obvious. We'll get into what else you may consider hooking up to it:

    'Gives us a number to group all information pretinent to a specific requisition:


    We need a way of identifying those involved in the requisition:


    Now we need a way of associating people with a given requisition:

    ordinal_value 'optional, you could use this to superficially define a required order of authorization

    Ok, this is where you need to decide how and what you'll be storing with regard to people affiliated with a requisition. Do you just want to store a time and date that they signed? Do you need to store detailed information about each signature?

    If it's the former, simply add a date field to tblRequisitionIndividual. If a date is present, that's when they signed. If it's null, they have not yet signed. If it's the latter, we'll need a bit more information about what other details you want to store.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Jan 2006
    Thanks Teddy!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts