I'm trying to configure a document code on my environment and I'm continually receiving this error message when I try to complete the fuction:
"Failed to update document code structure. New code definitions cannot be saved because some required fields are empty."
I followed line-by-line what is written in the help file for "Defining Document Codes" and it seems logical. Any thoughts as to what could be causing the issue or something for me to look at? I have an attribute designated to hold the serial number, and I also have an attribute acting as a placeholder for the code.
It seems one of the elements of your document code is "required"
no problem there is an option for optional or required for each element.
But if you set required to a field and some where in the existing database for existing documents the field is question has never been used or is empty then you get an error like this. If this is really what you want you need to fill all the required fields before applying the document code settings..
Also copying your environment to some test name and the testing the setting could help find the issue since there will be no documents attached.
Best Regards,
Ian Emery
That worked...I created a test environment (which has no documents under it) and I was able to generate a code as desired. To apply to my live environment I will just empty out the collection of test files. I noticed that the serial numer which is automatically generated is only 1 digit; do you know where to set it to three digits, so instald of "1" it would be "001"?
Brent Mauti
Architect, BIM Leader
CH2M HILL
Set the format string on your attribute used for the sequence number. Go to the attribute properties, click the Editing tab, and in the format string enter %03d and also probably a good idea to change the maximum input text length to 3.
Please note that I post here on a voluntary basis and am not a Bentley employee.
That worked perfectly! Now two more questions which I hope someone can answer. Below is a screenshot of how I currently have the document code configured. The desire is to have the code registered as DE-DEL-ADD-003, not to include the description. I have a separate attribute where I used the following SQL statement to achieve that: SELECT SUBSTRING('$EDIT#DocumentTypeGROUP$',1,2) + '-' + SUBSTRING('$EDIT#DocumentTypeLEVELONE$',1,3) + '-' + SUBSTRING('$EDIT#DocumentTypeLEVELTWO$',1,3). BUT, attribute which stores my document code as the "Update Value" box under the "Value" tab grayed out stating "this field cannot be triggered because it is a code field. Does anyone know where (if possible) I can enter this formatting to drive the concatenation of the code?
Second question...my client would like to add Project Number as a prefix to the document code (so that serial numbers are numerated under a project number). BUT, I have project number as a rick project property and not a document attribute. Is there a way to add a project property to a document code? OR, is it required...does the serial number work under a rich project, and thus if I have DE-DEL-ADD under different rich projects, will the serial number start back at 001?
A few things to understand about doc code document attributes.
1. Doc code attributes must remain empty until a doc code is applied. If you plan to use the same (or truncated) value of another attribute (which must not be an attribute in the doc code definition), you need another attribute just for use in the doc code definition to store that data. I can't stress enough how important this is to understand. Also, if you set any rules on "Clear attribute value when" you should apply those rules uniformly to all doc code attributes so that you don't run into trouble later on.
2. Doc code attributes' Default values are NOT populated when the document is created. They only apply in the doc code dialog when you want to apply a doc code to a document that doesn't already have one. The default value can be anything, just like any other attribute. If you are modifying an existing doc code on a document, then the values you see in the doc code dialog are those that are stored in the doc code attributes for that document.
3. If you wish to provide the user with drop-down selections on doc code attribute(s), the Value list options can be set for each as needed, just as you can with any other attribute. If you don't want them to be able to select anything, don't put anything in the Value list section.
4. Depending on settings applied to your doc code attributes (read only vs edit, using value list, limit to list, etc.), you might make it such that the user can change the values to whatever they want in the doc code dialog. Just be sure to test your settings to ensure it works as you intend.
For the default value of the Document TypeGROUP attribute, set the SQL to get the truncated value from SomeOtherAttribute (change to whatever attribute you are going to depend on for the data).
SELECT SUBSTRING('$EDIT#SomeOtherAttribute$',1,2)
Do similar for the other 2 attributes.
As for your question about using a Project attribute value in a doc code attribute, it should be possible. Set the Default value of the attribute to System Variable type, and then click the ... button to see a list of variables. Click on the Project properties tab to see available variables. If you are using Project properties (or even just truncating them via some SQL) this case wouln't necessitate having an extra attribute, though you could still set it up that way if you want to have the value in a non-doc code attribute as well.
Serial number generation will be dependent upon what doc codes are already defined and reserved, and will generally go to the next available after the maximum used in conjunction with the other values.. Also, in the last screen of the doc code creation wizard dialog, pay close attention to the "exclude from unique id" option that will be available on for any attributes defined as doc code parts, as it will have an effect on not only serial number generation, but also what values are allowed. Note that you can enter your own serial number in the doc code dialog (individual selection only unfortunately) and if it doesn't violate uniqueness rules, it will be applied.
This makes sense Jeff, thank you. I'm working wiith an organization with a brand new datasource which is empty so initially my test files were causing the issue. I'm now using a test environment with no files under it so anything I configure will be the pure for them to start.
The project number worked like a charm...I created an attribute called "DocumentCODE_ProjectNumber" and set its default value to the project property's ProjectNumber and it now carries through in the document code.
I'm still struggling though with the Document Type fields. Below are the codes which I have created viewed in a testing interface. Initially I setup the Document Type code as shown below with an Update Value of "SELECT SUBSTRING('$EDIT#DocumentTypeGROUP$',1,2) + '-' + SUBSTRING('$EDIT#DocumentTypeLEVELONE$',1,3) + '-' + SUBSTRING('$EDIT#DocumentTypeLEVELTWO$',1,3)". The DocumentTypeGROUP field has a simple value list: "AD_Administrative|DE_DesignEngineering|ES_Estimating|SP_ScheduleProjectControls|PT_Procurement|CN_Construction|CM_Commissioning|OP_Operations|QM_QualityManagement|CT_CommercialAndTechnical". Then DocumentTypeLEVELONE has the following value list: "SELECT $EDIT#DocumentTypeGROUP$ from dbo.I_$EDIT#DocumentTypeGROUP$", and DocumentTypeLEVELTWO as the following value list: "SELECT $EDIT#DocumentTypeLEVELONE$ from dbo.I_$EDIT#DocumentTypeLEVELONE$". I then have pick lists named to match the fields from GROUP creating a cascading pick list. I then proceeded as a test to create the three DocumentCODE attributes, with each having a respective Update Value of "SELECT SUBSTRING('$EDIT#DocumentTypeGROUP$',1,2)" and similar for LEVELONE and LEVELTWO only with 3 characters instead.
So, the logic of the attributes is good, but now Document Coding is making it difficult. What we want to achieve is a document code of DocumentCODE_ProjectNumber-DocumentCODE_TypeGROUP-DocumentCODE_TypeLEVELONE-DocumentCODE_TypeLEVELTWO-DocumentSERIALNO, but I want the users to use the dropdown lists to select the values. I've tried some variations when defining document codes, and here is one of them:
When I view the above result in PW, this is what I see:
The fields for users to select are gray, and the ones we want to utilize are just looking for manual input. If I modify the document code to move the three attributes from "additional attributes" to "other code parts", and then set them to exclude from unique ID, I'm now able to access the pulldowns, but their values are not writing to the DocumentCODE fields, and the longer values are still showing up in the serial number:
Any thoughts?
You've got a lot going on here. Without getting into a lot of detail of what you are doing, some general thoughts.
1. Simplify the interface and naming (it's a bit overwhelming and confusing, at least to me). Attribute interface text labels are your friend here :) Maybe you were planning that for later, but it would help a lot to do it now.
2. The "Additional attributes in unique id" in your document code definition are items that will appear in the final document code string. It looks like you are duplicating them unnecessarily and aren't what you want in the final document code string.
3. In this case, it looks like you are duplicating non doc code attributes in your doc code definition, which isn't necessary or useful.
4. You can build value lists that show "friendly" descriptive text as part of the string in the drop down list items, but only populate the attribute with the value. Example, you could have the group drop-down show "DE - Design Engineering" but the actual value showing in the field after selection would be "DE". This tends to make the interface cleaner and helps avoid having to do string manipulations. To do this in SQL, just select 2 columns normally, the first being the value, the second being the description. ProjectWise will do the string manipulations automatically in the interface. You should also be able to do the same within the | separated list, though I haven't verified this.
5. Doc code attributes by definition do not support the Update options. This is by design because doc code attributes are bound to stricter data rules that are only defined in the doc code definition and as such, its attributes can only ever be modified by the doc code user interface, not as a regular attribute.
Unknown said:What we want to achieve is a document code of DocumentCODE_ProjectNumber-DocumentCODE_TypeGROUP-DocumentCODE_TypeLEVELONE-DocumentCODE_TypeLEVELTWO-DocumentSERIALNO, but I want the users to use the dropdown lists to select the values
If this is what you want, AND you don't need/expect these attributes to have data until a doc code is applied, then you don't need to duplicate attributes since there is no depency upon a non code attribute counterpart to drive the list or a default (I assume anyway, by your wording). In that case, just set up the attributes normally. Don't set anything for update value, but set the defaults (if preferred, not required), and set the value list settings and "limit to list". Then run through the doc code creation wizard, add these attributes, marking the required ones as such, and you should be set.
Lastly, the "Document Type" field appears to be a string you want to contain partial doc code data for other (non doc code) purposes. If that is the case, it does not need to be part of the doc code definition. You can populate as a non-doc code field via update settings that get triggered ("Update field when") any/some/all of the doc code fields (or even any attribute update). This way, the field gets populated/unpopulated in lock-step with application or removal of a doc code, without it being part of the doc code definition. You would also want to mark it as a read-only attribute so you know users aren't manipulating it directly in the attributes interface.
Thank you Jeff...you have given me a lot of great information and I sincerely appreciate your time!
Jeff, this information has been very helpful, especially Step 4 with creating value lists using SQL. ProjectWise being able to do the string manipulations manually is pretty great.
Another question I have for you, do you know of a way to get the ProjectWise filename to be updated when the document code is updated after the initial creation of the document code? Right now when generating the document code, ProjectWise creates the file with the same name as the document code name but if anyone makes changes to the document code afterwards, the ProjectWise filename and physical filename do not get updated.
Any help is appreciated. Thanks again for the all of the information above, it has really helped me.
There is an option to keep the ProjectWise Document Name and Document File Name locked together. I believe the default behavior is controlled at the datasource level, and can also be controlled per document (there is a tick box in the Properties dialog, general tab IIRC).
That said, the Document Name nor Document File Name (whether linked together as above, or not), does not get updated by changes to document code. There is no way to make that happen without some sort of SDK customization distributed to the clients to enforce this type of behavior. I wrote such a customization some time ago so I know its possible. It is not a menial task and your operational and environmental situation may not make that a practical option, but it is the only option I know of.
Thanks for the response Jeff, I agree with it not being a menial task but we may not have another choice.