Document and Archiving System

Frappe Framework App Development
21

Hi @Dale_Scott
Let me mull over this and your last few messages and get back to you during the weekend? I’m currently wading through the learner waters of erpnext with totally banal things like the Italian tax regime and how to make my first invoices on it.

As I told you my experience is with extremely complex and powerful research PLM systems of the mid 1990’s. These have nothing to do with commercial systems. That time commercial PLM systems such as teamcenter were not even on the horizon of mid scale companies.

Anyhow, among the leaders in PLM are actually three systems, one from Dassault, one from PTC and one from Siemens/EDS/UG. I’ve seen all of them and none work well in a mix CAD/CAM/CAE environment. Besides in our business we need ITAR and other security guarantees.

TTYL.
Cheers,
Naresh

22

Hi @Dale_Scott

Understanding, at least superficially, frappe and erpnext took some time. Now I’ve run through the frappe tutorial, made the library app and understand some preliminary capabilities of frappe. Frappe appears to be a platform on which we could realize most of the features that we need. I’ve also installed and run your ncloud in a VM and stress tested it. ncloud, does really well what it claims but extending it to do what we’d like to do may be difficult. Allow me to outline how we are forced to work, under the ISO9100 and aerospace requirements we must meet. Currently we do this using a paper trail. I’d like to move all of this in either 1. ERP Next or 2. Erpnext + Frappe+custom apps or 3. number 2 + a PLM and document tracking system.

Within ERPNext, I may be wrong, but it stores all external files (pdf’s or else) in a common repository in the file system and stores only the file identifiers in the DBMS. This may work for some, but it will not work for us. Since we need document level partitioning between our work, and work of some of our clients. The documents themselves should be stored as blobs in the DBMS which should run on an encrypted file system. Lets take a simple example of material acceptance from a supplier. Let us say we get an epoxy-resin-system in the goods-in of the company. Before it is stored for usage, we need to sample each drum of material, measure its viscosity, its amine content, its strength by making coupons and testing them. All that data needs to be stored with the material as images + pdf’s. Now say one operator is supposed to do a test, what we’d like to do is give him/her an application that shows an image of the workstation, to start the test procedure, it should give them all the instructions in their language if they click on a button or other bunch of images that show the sequence of instructions, each time asking for a response, job done or problem or something else. In the end the application should allow the user to click on the operation finished, and perhaps (s)he make a photo of the job done in some case upload the results file from the machine, or does something else that proves that the job was done. That should pass on the results to the next in route which is usually a Q&A person and the job is checked and approved, and the operator should get the next scheduled job.

Another thing is a rigid structure of naming and numbering everything based on where it is used based on FAA and EASA requirements. So say if the part being worked is going to be used in the Wing_lower_surface all operations and their numbering will be for that. If they’re used on the fuselage_nose they have a different naming. This applies to workstations, operations, operators, machines, tooling, Q&A and all the rest.

As far as CAE assets are concerned, one should have a way for:

  1. revisioning them (through CAD interfaces).

  2. Vaulting them in a safe encrypted and partitioned manner with several levels of safety.

  3. storing their references in the database. The better thing would be to store the entire file as a blob in the dbms in their own column, but that could make a huge table. The attributes such as meta-data on the file could be easily extracted out of the original file before saving.

This will be at the minimum and would be doable. In the erpnext or the PLM application, one could link the file sources for processes.

Currently, I don’t know erpnext enough to make an implementation of whats in my mind and would like to spend a day with someone who’s done a fairly complex implementation to understand whether we should even go this way. There’s a german gentleman, whose company makes electronic parts, who has a few videos on erpnext and I think that their implementation has the same order of complexity as what we’d end up with. I don’t know if he’d even consider a visit from me.

So that is all that I’m working on now.

Have a great day,
Naresh

23

Hi @nash, no real solutions here, only critique from the sidelines…

Yes, but this is common among PLM in general because it is usually not efficient to store large binary blobs in a DBMS and can also reduce performance of the DBMS in general.

Why? Can you show compliance by demonstrating adequate control over documents, regardless of the storage mechanism? Are you required to comply with a specific system architecture? (some standards do, I understand PCI financial payment processing is one, but often ISO and management of change standards only require that you have processes which meet some more general requirements).

Storing document blobs in a database is only as good as the dbms user password. If the password is exposed it really doesn’t matter if the file system is encrypted (unless physical theft of the drive is your greatest concern). Vice versa, if you have good authentication processes, a “belt-and-braces” strategy may only make the system more complicated, not safer (and more complicated is often less safe).

IMHO the key is to have well defined traceable control over documentation related to Items (part numbers) and stock (physical substantiation of a part number). There must be controlled verified entry into the system, controlled management within the system, and no access from outside the system.

These steps can be configured as workflows within ERPNext, with flow moving from one step to the next based on user permissions and assigned roles.

A formal naming and numbering system customized to your unique needs is undoubtedly code you will need to write. I would suggest you keep naming and numbering under centralized manual control (e.g. a “doc control” office) and look to automate later. This can certainly be automated given an appropriate set of rules, but I would not recommend mixing the two.

IMHO you are setting a high minimum bar. I would look for parts of your process that do not need to change (i.e. your manual processes work as-is, although not as efficient as you would like) and initially implement ERPNext for what must be changed (either to correct an aspect of your current manual processes, or if required as part of a minimal ERPNext installation).

If possible, I would try to move automated naming and numbering to a parallel project, Even though it is desirable to complete both projects before going live, any delays in the naming and numbering should not impact the basic ERPNext implementation project. You may argue this is just “tomato tomahto” but perception is everything, and you do not want momentum in the erpnext implementation to be upset if it is difficult to achieve consensus on a definitive naming and number rule, or in its implementation (or just struggling to get consensus on the user interface).

How are you storing CAD documents now? Do you have the concept of a PLM now, or do you have the classic system where design documents are stored by domain (e.g. mechanical, electronics, PCB and especially firmware all have their their own way).

An ERP can be an opportunity to clean house, but only so much before the project loses clarity and focus (and you know where that leads… :wink: ).

What is the primary source of friction in your current system? Is it more related to the transaction processes in an ERP, or the change management of PLM? Can I also assume your “paper trail” process is well documented, and your new electronic system will require certification? I might consider how I might adapt the current certified process to the new process, and if one approach might be preferred over another based on ease of re-certification.

Cheers,
Dale

24

Hi @Dale_Scott

Thanks for your, “Critique from the sidelines”! Much appreciate that, and I mean it.

So here is my plan: I’m going to slowly get something running that represents how we need to do our business. Once it is done, I intend to give it to all for free… including the meta-data tool for the CAE products we use. You can use it or improve it and convert your critique to a viable solution if you dislike it in its native form.

Some of the basics… the reason we cannot do the things as they currently stand. We work very often with customer data that is ITAR and one of the requirements for the data we use is complete transparency in how it is stored in case we’re audited. If that is the case, the data store should not be accessible to anyone else. Now if all the files are stored in one area for all customers, that kind of thing will not work. A local directory separated by customer names + projects may work. A cloud store will not, this is something that is specific to some data we work with. I may be wrong about it, but I believe that in earlier versions of ERPNext, it was possible to create separate directories for customers, and in V12 and in future that may not be the case. Is that true?

Just got back from a longish trip, am going to now huddle up into some preliminary coding.

Cheers,
Naresh

1 Like
25

@nash, I wish you the best of luck and look forward to watching the progress. I was at a very small hardware startup (7 staff) working on their first product, and they will probably start with ERPNext simply attaching related documents to an Item or BOM. For the number of people involved, the risks, and the duration for something better, this will perfectly adequate (but they also working in an industry that, at least in north america, is generally exempt of regulatory compliance requirements).

Regarding specifics of physical file storage, it seems at least by default there is only separation by public or private (although I do not fully understand the reason for, now why one would make one document public but another private). In the v11 ERPNext VM, all uploaded files are in:

/home/frappe/frappe-bench/sites/site1.local/private/files
/home/frappe/frappe-bench/sites/site1.local/public/files

File names of uploaded files are initially preserved, and an upload timestamp is appended to files being uploaded if a file already exists with the same name. For example, if I uploaded file “20000001_WI-01.pdf” for the first time, it will be stored as …/sites/site1.local/private/files/“20000001_WI-01.pdf”, but if I realized the PDF hadn’t been updated yet, fixed the PDF and then uploaded again, the second file will be named (e.g.) “20000001_WI-01 2020-01-25 15:45:02.pdf”.

Good luck and I hope you will post your progress. If you want a beta tester, you know where you can find me… :wink:

1 Like
26

@Dale_Scott

Thanks, will definitely keep you in the loop.

Best,
N

27

Hi @nash, how’s is your product data management journey going? Have you found a solution?

Cheers,
Dale

1 Like
28

@Dale_Scott, we’re still reeling with the drop in business due to the pandemic. No stones treaded yet, unfortunately, in the PDM space. Although that is priority #2 now, #1 is to get some paying customers for the bunch of metal paperweights in the from of standing machinery assets that we currently hold.
Hope things are better at your end.
Naresh

29

No stones treaded as you say, but making progress and talking to more people about potential opportunities…