Project setup when a customer sends a detailed document list with numbers, instead of a list of doc codes

There is a temptation to upload the customer document list to the DocBoss CODE LIST, putting doc numbers as doc codes. This generally causes confusion in DocBoss as every card is linked to every piece of equipment (order level), and the outputs for document numbers become jumbled with the doc code.

While it may take a few more minutes, the following options allow you to ensure you are delivering ALL of the required documents, and in the proper format.

Generally – options 1 and 3 seem to be the most typical solutions for our users.

Option 1: “Make” a code list for the customer.

Look carefully at the customer provided list of documents. Often you can “see” the groupings of document type. Often, the customer includes the “doc code” as part of the doc numbers, so look closely at the pattern of the doc numbers. From there create a list of code/code names from their data and upload it to the project.

Then
– Set levels to generate the list of cards.
– Go to card list, and compare the results (qty of docs) to customer list. Possible you need to create packages if customer has only one card for what is *really* several internal documents.
– Update titles and doc numbers to match (can download/upload).
* COULD try to set doc numbers using the numbering function and a pattern. Can be complex – so manually numbering is often preferable.

PRO:
+ Can set stage lists to define workflow for each TYPE of doc. IFA/IFC for drawings.
+ Allows you to manage sub cards. Customer may want ONE document for drawings, but you actually must manage 5 drawings (internally). In this way – you can create packages for the customer, while managing individual docs internal (and hidden from customer).
+ Can search based on doc code (i.e. show me all outstanding drawings).
+ All equipment is correctly allocated to each card (tag list is correct).
+ Code output on templates is recognizable to customer.

CON:
– Must verify number of documents match customer request. If not – must determine why not. This is a GOOD step in the project, as you align your deliverables with customer requests.
– Must do cross references to update doc numbers/titles to match customer. Requires download/upload of card list.

 

Option 2: Use your internal codes list.

For each customer document, find the related code in your list. Add it to the project.
Then proceed to set levels, compare and update the card list.
Then proceed with same matching/updatingsteps as option 1:

– Set levels to generate the list of cards.
– Go to card list, and compare the results (qty of docs) to customer list. Possible you need to create packages if customer has only one card for what is *really* several internal documents.
– Update titles and doc numbers to match (can download/upload).

PRO:
+ Can set stage lists to define workflow for each TYPE of doc. IFA/IFC for drawings.
+ Allows you to manage sub cards. Customer may want ONE document for drawings, but you actually must manage 5 drawings (internally). In this way – you can create packages for the customer, while managing individual docs internal (and hidden from customer).
+ Can search based on doc code (i.e. show me all outstanding drawings).
+ All equipment is correctly allocated to each card (tag list is correct).
+ If you have set default levels for internal codes, they will be applied.

 

CON:
– Must verify number of documents match customer request. If not – must determine why not. This is a GOOD step in the project, as you align your deliverables with customer requests.
– Must do cross references to update doc numbers/titles to match customer. Requires download/upload of card list.
+ Code output on templates is not recognizable to customer, but code names are approximately the same.

 

Option 3: Put a fake code in the code list, and do everything manually

If you are confident that the customer will NOT require any form of doc codes during the project, you can add a SINGLE code to the project where level = Manual.
We suggest the following code/codename pair:
Doc Code: “.”
Doc Code Name: “Project Document”

Then go to card list and MANUALLY upload the documents. AS part of original upload you can set the title and doc numbers exactly as your customer has set them. Ensure you link each document to the “.” code in docboss, and link the appropriate equipment manually in the upload.

NOTE: This is really not recommended if it is a large complex project. You will encounter issues with compilations/packages as there is only one doc code.

PRO:
+ Very quick to setup.
+ No matching of auto generated cards to customer cards
+ No manipulation of meta data after the fact.
+ Can set stage list on each document.

CON:
– A workaround to the typical doc code concept in docboss. Possible that customer wants codes later…
– If you are using standard templates, often the doc code / code name generally appears in the output, so be prepared for a slightly strange output (i.e. the “.” and “Project document”)
– No filtering of card list based on document code. All cards have the same docboss code of “.”
– Packages / Compilations are not functional. They are driven from the code list, and include only specific doc codes inside. In this case – there is only one doc code, so all docs would always be included.