Ok, couple more questions...
Is this a library that you'll be managing yourself, as in: are you the only one adding items to it, or would others be as well?
Do you need approval on the documents added? Or do you normally just upload them and call it good?
What is your preference on workflow initiation? I ask this one because of the following gotcha's:
On Item Creation:
In a list, when you create a new item, you're filling in all of the needed fields at the time of creation, whereas in a document library, this is accomplished after the document has been uploaded. Because of this, having the workflow initiate on item creation will not work correctly because it will be looking for the existance of specific metadata (columns populated with information) that will be added after the document is loaded. "Pause" actions could be added to the workflow to help accomodate this, but they're unreliable sometimes and may or may not work as intended (known problem - even after updates and SP'sthat have supposedly fixed the issue).
On Item change:
The logic of this particular workflow has a few item updates in its logic, so initiating the workflow on item change will make it error out because it will be calling the workflow again on each update (endless looping scenario).
So far, this seems to be the best and only option because in order for the workflow to work without errors, all pertinent fields must be filled in before the workflow can run...and as in the first scenario of initiation on item creation, none of these will be populated until after the document has been loaded. This in itself may be enough for this process to not work out for your specific needs since part of the idea here is to be able to move you away from as much manual operation as possible...so its up to you.
To give you an understanding of why "Manual" initiation of the workflow will be needed, here's a breakdown of the solution I was able to come up with:
We have a "Master" list which contains a single item - the "Next Available Number", which we will be using as our auto incrementing number for our Project ID.
In our document library, we have a "New Project" field (lookup) that points to the "Next Available Number" and will be used in the "xxxx" portion of our final Project ID. We also have a "Auto Number" field that will be updated with the "Next Available Number" via the Workflow - this is neccessary because we'll be deleting the existing item on the "Master" list and replacing it with a new "Next Available Number" item after we've used the current number to build our Project ID...and, in order to match up the existing "Next Available Number" item on the Master list with what we want to delete, we'll be comparing its item ID (SharePoint generated) with that of the current item ID that we're creating in the document library. It gets a bit confusing when trying to explain how it works, but the walkthrough I'll be posting as an article later will better illustrate it with screenshots :)
Also, in the document library, we have the "xx.xx" portion of the final Project ID as a choice column containing all of the values we'd need, and another choice column for the "A, B, C..." version values.
Next, we have our calculated column which brings together the "Project Code" ("xx.xx"), "Auto Number" ("Next Available Number"), and "Version Code" ("A, B, C...") and concats them together as the final Project ID ("01.01.1234.A").
We also have an "Existing Project" field (lookup) that is connected to our current library and is used with the "Version Code" values in order to match up any projects that are of any type other than "A" and not increment the "Next Available Number" item on the Master list (no need to increment it if the document is just a "B" or "C" of an existing project - instead, it will just build a Project ID containing the version and add it to a "Grouped" view of all related projects).
The workflow itself checks to see what the version is (IF "A" do this, else IF not "A" do that), then gets the "Next Available Number", increments it if needed, creates a new item on the Master list (will always do this, even if its not incremented - this insures that the next document added will always be able to match up with the system ID between itself and the Master list), then deletes the old one (again this step will always occur in order to keep the ID's matching for comparison in the workflow steps).
The last piece is the update that occurs on the new document added to the library (or rather, the last if its version is "A", and first if its version is not "A"). This update will take the value from the lookup and write it to the "Auto Number" field because after we've deleted the corresponding item on the Master list, the value is removed from the lookup column (we actually capture it at the beginning of the workflow and assign its value to a variable so we still have it after the deletion takes place).
After the workflow completes, the Project ID is built and displayed and we either have a new item added with what was the last "Next Available Number" value, or if adding a new version, the Project ID reflects the new version letter and contains the rest of what made up the previous version's ID ("01.01.1002.A" remains, and we add a new document with the ID of "01.01.1002.B").
In the view, I'm grouping by "Auto Number" in order to group together all versions - and the "Auto Number" field is the only one that is common between them (although a new column could be created that concated the "Project Code" and "Auto Number" [xx.xxxx] and grouped by that, but thats a simple addition if needed that doesn't affect any of the above functionality).
So, after this lengthy explanation, does this sound like something that would work? Even if the workflow has to be initiated manually? (haven't figured out a way around that given the requirments of having both an auto-number, and the ability to re-use existing numbers for versioning).
Let me know what you think...