1. M. Circella, A few issues, QA/QC meeting, 12 June 2015 Product history and status in DB Customs rules Remarks on documentation 1 A few issues

2. M. Circella, A few issues, QA/QC meeting, 12 June 2015 1. Quite convenient to store the history of products in DB – this is possible by means of: explicit records (already implemented) – maximum flexibility on what to record QA/QC forms (to be implemented shortly) – selected actions (shipments, non-conformities) 2.History table already implemented in DB for each product (but we might need some tools to record efficiently information for batches of products) 3.But how about a clear record of the current status of each product? i.e., a table which shows: where the product is & what the status is Some discussion is probably useful in order to define what we need for point 3 above. Some hints: a)Do we need more than place and status in such table? b)Status should be with 2 values (ok/not ok) or 3 values (ok/don’t know/not ok)? c)How to set status ok for a new product? (suggestion: once the relevant test report or acceptance sheet, or COC is loaded on the DB) d)How to change status for a product? (suggestion: it will change to not ok/don’t know as appropriate due a NCR, it can be changed back to ok once the NCR is closed) e)How to determine the status of a product? (various options: 1. the status is explicitly written in a field in the DB; 2. the status is determined by looking at the history of a product – my preference is for 1) f)How to cure the situation for all existing products? Proposal: Let’s try to prepare a suggestion for points a-e and pass it on to the DB team, leaving to them the solution of point f 2 Product history and status in DB

3. M. Circella, A few issues, QA/QC meeting, 12 June 2015 1. LNS will take charge of customs activities for installation in KM3NeT-It (I will check for KM3NeT-Fr) 2.A file is in preparation for that (draft uploaded on indico) 3.We will need to collect all invoices and documentation transportation for each component declared in the file very convenient if all these documents are uploaded in DB! very convenient if UPI allows to tell the production history of a product (by means of proper variant/versions – please let’s define these together) 4.We should define what is the minimum level of breakdown of the structure that we need to report in the file. My proposal (still to be validated) is: “Whatever components are recognizable (i.e., not mounted inside a container) and/or need to be declared for VAT reasons (purchased VAT-exempt or VAT to be recovered)” 5.REMARK: all transportations of components purchased from KM3NeT-It budget need to be authorized by the LNS Director 3 Customs rules

4. M. Circella, A few issues, QA/QC meeting, 12 June 2015 1. Google Drive allows us to dump whatever we want – that’s very nice! Equivalent to being able to share the HD of our computer with the full collaboration!! But… 2.We all use our own personal style in managing our files on our computer. Such style is of course 100% clear to the owner, but may be simply absurd for others! 3.Hence, we need order! Document repository rules have been defined for that (you see the advantage of that: if I make reference to document KM3NeT_INT_2015_008-v1, there is no confusion ever on which document it is and where to find it) – This is already defined (and soon we will have a tool to prevent errors) 4.Two further remarks here: a)The documents should be fully consistent with how they are recorded in the depository: the identifying label HAS to be reported inside the document. In other words: inside the document KM3NeT_INT_2015_008-v1 I need to see that it is indeed KM3NeT_INT_2015_008-v1. If this is not so, for instance the document is internally tagged as MC_azzo_2015_abc_1 (or whatever), only the author will be able to see that it is indeed the correct document (and maybe not even at a glance!) b)For all “applicable documents” (i.e., documents which have to be applied in some activities, for instance integration or test procedures), we need well-defined rules on how they can be updated (not anyone should be allowed to do it!) – this is what is being defined in the DOM integration plan for DOM integration, but it would be nice if general rules are set (or are they already set?) 4 Remarks on documentation