Normal user will use this feature hopefully once in his lifetime - so why bother? - The obvious answer is that it’s one of the most important entrance gates to Tryton - every beginner needs to import his products. So it IS important to provide a really good user experience here, in order not to frustrate newbees too much.
At present, I learned about two approaches to do the job:
using the import feature
use a proteus script
there may be others I’m not aware of
on 1: In the meanwhile, I can use the import feature - thanks to fellow @htgoebel. But usage is painful. I could list a number of (very small) improvements which may reduce pain - but I do not know whether this is the best approach.
on 2: Other option could be to make use of those quite some proteus scripts several fellows made and create an pretty import wizard.
I’d really like to know what experts think about this issue, and I’m willing to fund this with 100€. Hopefully some others will join in and raise this sum to a reasonable amount.
Please do, maybe we can improve the import feature to make it more usable.
In our experience, there is no script that fits for everybody. What we do for our customers is to develop a script that picks all the data from the current database and migrates them. That means importing not just products but also parties, accounting, stock levels, boms, etc. Indeed the data depends on each setup.
Having said that, we’ve found some people that are not willing to pay for such service, so for me the unique alternative is to use the CSV import. We try to provide templates to our customers to fill data on best effort, but sometimes its not easy.
Agreed - there cannot be a 100% solution which fits all. There will always be quite some space for customized solutions. But we should have a good enough basic feature which will cover the needs of ~80% of newbees with a small business - who have just articles with prices, maybe categories and accounting categories and not more.
Allright. Your fault - as you asked…
Bare in mind that newbees will need 10s (or 100s) of attempts untill everything is in place. Developers will not, as they know structures behind. Newbees don’t. So it’s essential to make repetitions quicker and easier:
the import window should remember settings in the bottom line (CSV, encoding etc.) used before - and settings in export and import window should be synchronized (tks to @acaubet for this hint)
is there any good of the “hide settings” triangle for the bottom line of the window? - IMHO not, the window has lots of empty space in the lower third. In case we have the sync mentioned above, in fact its really harmful.
let’s provide a keyboard shortcut to call the import window.
a “reload” button (and a keyboard shortcut for that) for the import file would speed up things considerably
importer stops after the first error, eg one missing category. So newbee has to start it several times. Would be better if a comprehensive list of errors (missing categories etc) would be thrown out, newbee could then correct many mistakes in one pass. Or even better: Importer asks “The given category “###” is not available. Should I open the appropriate dialogue, so you can create it?”
Some more aspects:
the import procedure seems not to accept translated attributes, such as type (goods, service…) etc. This is a problem, as the exporter exports the translated words and newbee thinks he can use them
In general: Error messages are hardly understandable. We should apply special care here - as in this stage of usage newbee has got hardly any trytonic thinking, he needs VERY detailed instructions. Please leave the creation of error messages to ignorants - such as I am. I started a table with suggestions for improvement here.
It could make sense to highlight (bold print) required data fields, maybe italic recommended ones - and to write a hint “bold (italic) printed fields are required (recommended)”. - And this may be a good idea for other import windows (parties, stock & inventory…).
Finally I succeded to do am import - but products cannot be used as they do not have an active (but empty) variant: variants section is grayed, but can be activated by hitting the small ‘+’. I Is there a reason why? Could it be activated by default, or could there be a control to achieve activation?
There should be a hint “stock figures cannot be imported here” - can they be imported in “stock & inventory” ?
Thanks @herrdeh for your notes, let me add some notes about:
the import window should remember settings in the bottom line (CSV, encoding etc.) used before
Also the save export but for import for me is important here as when you succeed at importing you will be saving that final csv as template, but if the fields to select are not a thing you will remember for time.
It could make sense to highlight (bold print) required data fields, maybe italic recommended ones - and to write a hint “bold (italic) printed fields are required (recommended)”. - And this may be a good idea for other import windows (parties, stock & inventory…).
The problem I see here is that required could depend on other ones, so not always is true or false: for example, for products, default sale uom is required only if the product is salable.
Finally I succeded to do am import - but products cannot be used as they do not have an active (but empty) variant: variants section is grayed, but can be activated by hitting the small ‘+’. I Is there a reason why? Could it be activated by default, or could there be a control to achieve activation?
You should add the column Variants/Active on the import with value 1.
There should be a hint “stock figures cannot be imported here” - can they be imported in “stock & inventory” ?
Yes, to import stock from csv you need to create first manually a inventory, see the ID, and import a csv for the lines when one of the columns should be the ID of the inventory where should be imported.
So your import should have ID , Lines > Product, Lines > Quantity.
And your csv will look like:
Thank you @all for your contribution - it feels good to see that people agree with me on the importance of the issue.
I absolutely agree that there cannot be a 100% solution which fits all. There will always be quite some space for customized solutions. But we should have a good enough basic feature which will cover the needs of ~80% of newbees with a small business - who have just articles with prices, maybe categories and accounting categories and not more.
Absolutely agreed. With your permission, I added that into the OP.
Understood. Can we say there are definitely required fields in any case? - And can a reasonable share for the rest be handled by good error messages newbees can understand?
Thank you for this hint - works for me.
But how can we handle that for newbees? - Can it be the default setting - which will be overridden by a column “Variants/Active = 0” for those experienced users, who actually need this?
I’m not yet convinced. Thanks for pointing me to blank state improvements, that’s really important. But here, I think it’s just about a little nudge, something like We expect you to think this - but that’s not how it can be done here, so please have a look at ###. - Otherwise, we’d be back to a wizard.
While not an actual user, I am a long-time lurker intending to use Tryton. I have had regular, fruitless periods of trying out other ERPs and I cannot stress more, how correct and important the above quote is.
I’ve not tried the import, but from past experience once you have battered your head a few times against php warnings, code errors, sloppy/incomprehensible (for non-technical new users) error messages etc., the reaction is “f**ck this, I have a business to run, I’ve wasted enough time on this, if this is the quality of the code and development, I’ll stick with my legacy software a bit longer until something turns up that actually works”.
I fully understand that with a limited development team/contributors, the idea of investing time on a one-off pile of import code seems very wasteful.
But it’s not. It’s an investment. The import does not have to be perfect, it just has to be really, really well-documented and well-tested and spit out error messages that make sense to your non-geek friends to allow users to make progress.
Once my data is imported, I’ve invested something and am much more predisposed to persevere with subsequent problems and doubts.
So in a parallel universe when I eventually get around to using Tryton, I shall be contributing.
1 Like
pokoli
(Sergi Almacellas Abellana)
Split this topic
8
Instead of putting work in enhancing the Tryton import functionality for a first-time import of data when starting new with Tryton,
I would favour a well documented Proteus script which imports a defined set of files with well chosen structure.
Maybe in combination with a beginner’s tutorial on Proteus scripting, and some tipps on
how to handle test environments and reset them after a test import to try multiple times.
Reason:
People who do not want to have any contact with python programming would have a fixed set of files where they can “copy and paste” their data into. Therefor they can use their tool of choice, maybe some spreadsheet application or text editor.
The exact format must be part of the documentation, especially for related fields.
This is not very flexible, but it is doable by technically oriented users.
Python beginners could take the standard script as good starting point and adapt few areas to special needs, leaving it in the whole as it is.
For doing this, they have to check up the source code of the Module in question, which is a step in the right direction anyway, and a good way to improve Python skills.
Python pros could use the script as a good example and do not need to reinvent the wheel when they develop their own individual importer.
In my opinion, being able to use Proteus to import data into Tryton is one of the glorious functionalities of the “Tryton system”. But it is hard to understand for a beginner who has little experience with Tryton, Python and/or OOP.
So instead of improving the import feature of the client, I think it is more useful to bring people to Proteus scripting by giving a good example they can start with.
This is my personal experience over the last two years, and I am willing to help to improve the “entrance” for beginners into Proteus scripting.
Main problem here is that the Tryton database structure depends on the number of modules installed. So there is no set of files that works for all setups.
Then an ordered set of proteus scripts and input files, that one can use in the right order and only if the corresponding modules are used.
Or make the script detect the modules, and only import content for activated modules.
Or have a list of «supported» module at the beginning of the script, in which the user can comment lines for unused modules.
I think that there are multiple solutions. But right now, a beginner is just stuck there, with plenty of technical documentation, but no idea where and how to start.
Just had an amazing session with Frederik on this issue. In something like 20’ we were able to create a table header which successfully could handle quite a complex products import scenario, containing measures and supplier. Over 4 years, peu á peu I found that the Tryton’s onboard CSV importer is quite powerful and really can do a lot. But even some really experienced Trytonies cannot raise its full potential, which is a pity. For example:
you can import images by coding them base64 and copy that string into the table
no problem to import suppliers, if they already are saved as parties
tbc…
So I think this is a pragmatic way to go:
Let’s provide a set of table headers for some more or less vanilla scenarios, comment on how to fill tables correctly and advice how to deal with all of it. The hard part is to find the correct header strings, I think you really need profound knowledge for that job. Once they are created, the rest is sort of a breeze… I started that for German language and published it at tryton-community.org. Hope some folks will come and do it for other languages. No problem to integrate other languages at the tryton.community repo.
One thing remains we could not solve:
When dealing with product attributes, we used “Attribute Set” as header and {"jahr": 2020} as contents, following hints given in this issue. Error message is "relation not found: {“jahr”: 2020} in “Product Attribute Set” (attribute_set). Maybe some fellow knows how to deal with product attributes?
All above may not be the summit of elegance, but as we didn’t really get forward for quite some time, it may be acceptable bridging till somebody shows up with the final killer.
