in reply to RFC, a web based application

When I tried to submit an RFI myself, I got this report: 
DBD::mysql::st execute failed: Duplicate entry '010' for key 1 at init
+iate_rfi_send.pl line 173.

[download]
That might just be the test environment, or it might be something you really need to fix. The form for entering the RFI showed this information for the "RFI Number" field: "10 auto increment last RFI number was 9", so I'm wondering if you are assigning this key field prematurely. You should only need to report such an ID number after the RFI has been fully submitted, not before; that is, don't assign an ID (or insert a row in the table) until the person submits all information in an acceptable manner, then report back what the primary ID value is (as assigned by the autoincrement that is done as a result of the insert).

(Just a thought: in terms of reporting ID numbers of requests for use by people who submit requests: you might want something in addition to just an autoincrement numeric key -- e.g. prefix the number with the submitter's initials (or company initials, or some other short letter string), such that two different submitters (or submitters from different companies) get different letters, which are derivable from some other field in the entry for each RFI. This may help identify and sort out problems when people make mistakes like transposing, skipping, adding or changing digits in the numeric ID.)

I noticed that you ask the person submitting the RFI to fill in the "Creation date"; shouldn't that be set automatically upon submission? (ie. the table field for "creation_date" is set to the return value of "NOW()" when the insert is done). You also ask for a "PCR number if any" -- how sure are you that users know what this is?

Finally, you probably have some of this on hand or in mind already, but obviously the RFI submitter will want clear feedback on when to expect a response, how that response will be conveyed, who to contact if the response doesn't arrive as expected, and how to contact that person.

People charged with responding to RFI's will of course need a "response" table that allows them to submit entries reflecting phone conversations, independent email and IM dialogs, and maybe even office visits, in addition to internet transactions. (And requesters should be able to review all response records for a given RFI that they submitted.)

Replies are listed 'Best First'.
Re^2: RFC, a web based application
by demonlazeros (Acolyte) on Jun 03, 2008 at 15:40 UTC
    1) this one of the tweaking tasks that I need to refine. I am still trying to asses if the user needs to know the next number before or after completing the form.

    2)good suggestion.

    3)Yes the creation date will be automatic. Some companies have internal ways of keeping RFI's that they have. The PCR(I cant remeber what PCRstands for but it is meant to give the sub a choice if he keeds his own records) number will let them reference back to their system. Some contractors may not have computer based filing methods.

    4)The feed back will usually be based on the way the contract is set up between the developer and the architect. Some contractors may have negotiated different responce times, but it may be a policy that a responce time be entered in the text message. The responce will be emailed to any one the responder feels needs to get the responce, the admin gets all responces and may add forwarding to any one ledft out. The program will also log when some one reads the responce, or at least opens that page. Whether they read it or not is a different matter all together but at least the admin can present a report that the responce was received.

    MY thought is that the agreement between the architect and all parties involved must communicated via the RFI, but you are right there should be an additional log of none system communications.

    Requesters will have access only to RFI's that concern them or their trade or as given permission by the admin.

    MY goal is to give the admin full and total control of the RFI process and storage. He will be able to create reports on the fly at meetings rather than waite till he gets back to the office. If he has internet connection he can answer any question concerning the project at any meetings.This goes for all the subs, they will be able to report from the same database any info strictly pertaining to them.
[reply]

In Section Meditations