#45 Unable to save assemblies

[Nicolas Piganeau]

Hello,

I am using OpenERP 7.0.1 and Solidworks 2014. I installed the latest version of OpenERPPLM (from 2 days ago) both server and client.

Creating individual parts from Solidworks (.sldprt files) and saving them to OpenERPPLM works like a charm. And then editing them again is not a problem either.

However,

• when I create an assembly from two individual parts in solidWorks (.sldasm file) saving to OpenERP fails at "getting file structure".
• saving an empty assembly works (but is quite useless !)

Am I missing something?
Which file(s) am I supposed to link with the OpenERP Engineering part of the assembly? .sldprt files of each part? the .sldasm file alone? All of them? I tried all the combinations, but none seem to work.
My primary objective is to load the BOM of my solidworks files to OpenERP.

I attach the debug files if it is of any help.

Thanks for your help.

Nicolas Piganeau

[Fabio Colognesi]

Hello Nicolas,
Thanks for your interest in our PLM module. As far you saw using parts, so for assemblies is easy to work... When you are into an assembly, you can use SW "Edit Part" command, now you can launch "Edit Part Data" (PLM command) and you'll allow to edit that component properties. Place in "Edit Part" each components are in your assembly and "Edit Part Data" for each one... When you'll save assembly to PLM any data will be saved into OpenErp. Top-down method.

Be careful, create or select "Default" configuration, first time you are editing and saving to PLM your assembly. In that way we will manage right document for any configuration you'll add to your file.

Yes, we let the capability to save a raw assembly to OpenErp, of course it won't declare any kind of BoM, but it will save any relationship between documents, so you could re-open your assembly and complete it.

Of course, you can prepare each SW Part, already saved and then embed them into assembly, using SW command "Insert Component", it works too. Bottom-Up method.

By the way, we found a small bug on latest changes, so please, download again Client with latest one. Thanks.

About log files you attached, yes I found an error editing part data, but I can't understand what is that. Please, attach the file that raises the error (sldprt or sldasm with its files).

Please, let us know if have any other issue.
Regards
Fabio

[Nicolas Piganeau]

Hello,

I have done all you said (well I think so ...) and it still does not work (actually half of it works, since I can see in OpenERP all the parts, but not the documents).
It still hangs when it tries to get the file structure.
I enclose the test files I used, with the logs once again.

Thanks

Nicolas

[Fabio Colognesi]

Hello Nicolas,
The issue is only in configuration names they haven't to contain "unicode" chars. Take a look to the same assembly that I edited (changing configuration names). Take care, if you use templates, to set to "default" the configuration name used to generate the items.

In general, for configurations any name is good, if composed of standard ASCII chars (A-Z,a-z,0-9) avoid accents or non ASCII chars.

We will provide a fix to this issue in next releases.
Please, let me know if it solves.

Thanks
Regards
Fabio

[Nicolas Piganeau]

Thank you very much Fabio, it works.
Actually, I had been warned, it is written everywhere in your documentation, but I was misled by the fact that "Default" in french is "Défaut" which is very similar, but obviously not the same.

I found another of such "bug" linked to encodings:
in install/plm_component.py line 489 when the exception is raised and the name of the component includes a non-ascii char, it raises a UnicodeEncodeError which hides the "real" exception.
This is particularly important when you do CSV import of products because the text of this exception is brought up on the UI. So when the UnicodeEncodeError is raised, it is this one which is brought up and it is of no help to the user.

Similarly, and for the same reason, I would have changed the text of this exception to something like: "Unable to create product %s, %s", which is more clear for the user when the exception is raised after a CSV import.

Thanks again

Regards

Nicolas

[Fabio Colognesi]

Hello Nicolas,
I'm happy to hear good news.
About the issue related to encoding, I've just ended to solve it in OpenErp app distribution. Of course it's a quick change, we will provide to manage better those characters in any of our files, so we will upload to SourceForge on next week or more a complete set of changes.

Any way, to help traceability it would be better to open a new specific bug of this issue. Issue is server related and not to Client, etc. etc.

We will be in Bruxelles for OpenErp "Open Days 2014" with our booth.

Many Thanks
Best Wishes
Fabio