Import customers via csv

[sylvainkalache]

Hello!

 

I'm trying to import customers that I extracted from my 1.4 Prestashop.

 

I upload the file with success, can view my data successfully, even get the message "Your .CSV file has been sucessfully imported into your shop. However no customer appears in my list.

 

On a side not I've successfully imported products via the same method.

 

To exclude the possibility of something wrong with the document I've created a testing CSV file, attached to this post. I also did a video to make sure I'm not doing anything wrong http://www.slideshare.net/secret/8y7AumhJmvOHtI

 

I'm using Prestashop 1.5.4.1.

 

 

Cheers!

Sylvain

[rturner]

I had trouble doing the same thing. Makes sense because the two database structures are different. What "sort of" worked for me was to take the csv exported from the 1.4 store and open it in Excel. Then I opened the sample Customer csv file that you'll find in the 1.5 BO and saved it to my desktop. Then I copy/pasted the different customer cells from the old csv to the new. After 3 or 4 customers I was tired and tried importing that. It worked.

 

I'm sure it's possible to re-arrange the csv file in Excel to resemble the new file and import the whole thing, but my Excel skills are very weak and I'll need to do some reading before I try to get the whole thing in. The copy/pasting is time consuming. I also wasn't sure that I exported it with the correct formatting to be able to transfer the encrypted passwords.

[jontobey]

I just moved my customers from another platform to Prestashop and all I can say is Prestashop is STUPID.

Customers is not one database, but two, full of redundant information. (Hugely bad DB design) So clean all of your data first or you'll be doing it in two places later.

Also, the Phone Number fields, for whatever reason do no accept (), ".", /, or numbers without spaces. It seems like there is a bug where it compare the data to a type. This is so stupid

(XXX) XXX- XXXX, XXX.XXX.XXXX, XXXXXXXXX, XXX-XXX-XXX, N/A, etc are all perfectly human readable. I would much rather have varied data than have to clean my data for a stupid bug! And if you are going to have data requirements in a CSV, then freaking document it somewhere.

I never would've started down this path if I had known what a nightmare of poor design this platform is.

[jnelson]

Does anyone know if there is a way to import your customers as well as their past orders from one PrestaShop to another??

[NemoPS]

At the moment you have to use third party modules to export, then you can import back with the standard CSV import prestashop comes with

[jontobey]

This is why I hate forums: You post for help, and the person who is "helping" you gives you some vague answer which  might get you where you want to go if you do more research or you have to ask again.

 

In this case a moderator with 6000 posts lets you know there are modules available, but doesn't bother to give you links to them. Thanks!

[jnelson]

@Nemo1, thank you for replying to my question, however, your reply is not helpful.

 

I'm not that much of a "newbie" with Prestashop considering I've been with this dysfunctional platform since 1.4. No wonder Prestashop is not on ANYONE's top 15 list unlink Shopify, Volusion or even Magento for that matter. If your company spent as much time perfecting your flaws as you do giving these see-in-the-dark answers (or your fellow moderators like Mr. Utterback) stop talking to people as though they do not know what errors they are seeing across their screen; you just might come out on top....or at least in the top 15.

 

The "standard" CSV import opens as a blank excel document with no headers. There is no way to use the "standard" sample Customer CSV import file or any file for that matter if they are all going to open up as blank pages. If you could give me some useful information that will help solve the problem I would greatly appreciate it.

 

Thank you

[jontobey]

I feel your pain. I almost made a tutorial on my blog when I went through this very disagreeable process.

Go to Advanced Parameters | CSV Imports

In typical crappy PS UI format there are a couple of hidden links which you can easily miss (why is this not a drop down...). Click View our sample CSV files. (csv.gif)

 

NOTE: At least one of these files has a bug that won't let you save it because it starts with "ID" upper case and you have to change that to lower case or it wants to save it as a special kind of file (SYLK).

I don't remember all the details, but if you get stuck and it won't save as a CSV that's why.

 

When you pick and entity to import,  you will see the columns on the right, use these for your Excel column names if none are in the file you downloaded (csv2.gif).

 

Note that some of these will have commas in them (EG Default 0= No, 1=Yes) - you will need to change that comma in red there a semi colon.

 

There is some remedial checking that will help you make sure you have the right stuff in the right place, but it pretty much sucks and will tell you your files are good even if they are not. Then you are in the discovery phase where we help document bugs here on the forum and call it "help."  For instance, note the ridiculous issues I had with the phone numbers above. Oh, and if you import state names, you must spell them out, becuase two letter abbreviations will break things downstream, like your tax rules. I really do not make this stuff up.

 

Also, for no good reason on earth, PS denormalizes your data, keeping redundant data in separate tables. So if you, like me, had to break one normalized table into multiple tables, make sure you get it all right and then force your own ID numbers on the system (there is a checkbox for this somewhere).

 

That's all I have time for at the moment. Best of luck.

Edited July 14, 2014 by jontobey (see edit history)

[jontobey]

So, the supplier import format doesn't contain any of the contact information for the supplier that you can enter through the UI.

I would have to say this is a bug, if there are tables to manually enter the data, but you cant import it.

 

!@#$%^&*()_

 

And the sample supplier file will also give you the SYLK error.

Edited July 14, 2014 by jontobey (see edit history)

[jnelson]

Thank you @jontobey

 

I am just not looking at this msg since I am at the end of my rope with PS and their ridiculous changes. Looking at your attached images, it looks like you may be using PS1.5; is this correct? Only asked bc my PS1.6 is not laid out like the old PS is. The sample links are on the right hand side. My error msgs are attached...in the end, I am still unable to open the "sample CSV".

[jontobey]

I think I originally opened the files in Notepad, resaved as .csv, and then opened in Excel.

However, really those files only contain column headers, there is no content in them (at least in 1.5), so you can also ignore all of the errors, and open in Excel. They opened for me.

All you should  really need are the column headers so that the order of your data matches the order of the data in PS. In practice, PS does some stupid type checking (it appears that phone numbers without dashes get converted from strings to numerals, for instance; and state names do not follow the standard two letter abbreviations but must be spelled out). So once you get the columns set up right it will tell you the file is good, but you may still have to sleuth out other errors as you go.

Honestly, if you are still at this point it's not too late to consider a better platform, which is what I'm going to do. Import your data into a platform that works and has support.

[cjrhoads]

I feel all of your pain.  I too had tremendous problems with importing, and ended up hiring someone who had a little more experience (though the information they had was also, sadly, out of date).

 

I've come to the conclusion that these are growing pains for the newer versions that were, perhaps, released before any of the documentation and supporting tools (like import) were ready.  I suppose I just accepted the growing pains, figuring that eventually they would catch up.  Again - this is a free program with volunteers doing all the work.  I don't expect the same sort of support as I would had I paid for the system.  Yes, my time is valuable; but I could always go with a paid shopping cart solution and then I would have a right to complain about out of date documentation and less-than-patient technical support responses in a free support forum.

 

In the meantime - I did manage to get everything imported, and so I provide this advice:

1. Enter a row of fake data in a CSV file and act like you are going to import it in order to get the list of fields being imported.  This field list doesn't appear to be documented anywhere (the sample CSV files are all incorrect, I suppose from an earlier version).   You are not actually going to import it yet so it doesn't matter what's in it - but you can't see the fields to map until you have a file with some data in it

2. Include only the barest minimum.  For example, I tried to include the available dates, but when I did, nothing imported.  Through trial and error I discovered which fields were importable and which were not.

3. Image files, I found, could only be imported if they exist in a top-level folder in the domain.  When I tried to put them under  domain.com/img/prestaimport they would not import.  I finally figured out that if I put them in domain.com/nwimg  they imported just fine.

 

I can't remember off the top of my head of any other issues I found with importing, but I wish you luck.  Trial and error should be expected until the documentation is updated.

 

Just my opinion

CJ Rhoads

[jontobey]

My general feeling about PS is that it's written by developers with no real feel for the business requirements and therefore it's a continuous game of Battleship to figure how and why something works. For example, they way combinations is done has got to be the stupidest possible implementation from a business standpoint, but it probably looks elegant to some developer somewhere. "Free" turns out to be pretty pricey, especially when you have to buy modules to do anything, and in my case I have almost $1000 in modules that don't work (A Quickbooks module that does nothing of value, a shipping module that does everything the out of the box program does, a Store Manager that doesn't work with the advanced Stock Management, a POS that doesn't take credit cards!!!!) BTW, I will sell all of these to anybody who wants them.

[cjrhoads]

While I agree with you, jontobey, I must add that ALL shopping carts (indeed, all software) is written by developers without a clue as to how business actually works.  It's the bane of my existance, but a reality that has not changed in the 25+ years that I've been in the field.  (BTW - I am a serial entrepreneur, have started, developed, run, and sold several technology-based businesses, so I know of what I speak).  The truth is that all software is poorly designed; the key is to figure out which programs have design flaws you can live with and which ones do not. 

 

Also - I guess I learned (the hard way) over the years not to trust that ANY software system does what it says it will do.  80% of them don't.  Wishing they did doesn't change the ratio.  So - be careful what you spend actual dollars on, and be absolutely sure that it does what you need before spending the money.  For example, the whole world is littered with Quickbooks interfaces that don't work.  (Quickbooks keeps changing their system, so many quickbooks interfaces work for about a year, and then don't work anymore - though vendors continue to sell them because there are many people who keep buying them even though they don't work.)  I purchased perhaps a half-dozen before I finally faced the truth - you have to enter the information into Quickbooks manually.  Period.  Don't waste your time trying to get an interface.  If you want your sales to go directly into Quickbooks, you have to use the Intuit/Quickbooks interface/merchant account system directly.  Third party systems need not apply (anymore - since about 2012 when Intuit launched their own).

 

Peace

CJ 

[jontobey]

Ironically I gather requirements for companies like Microsoft, Starbucks, Boeing, Panasonic...I'm trying to move from PDG which was written in 1997 and actually does integrate with QB, but the connection keeps breaking. So one of my biggest reasons is to do this and it's sad that "modern" software hasn't surpassed a 20 year old piece of sw.

However, there is no excuse for not having a working POS. None. And I don't need QB, but I do need some way to get this data. I can't even invoice. Even something which on the surface seems like  I could co-opt it (Advanced Stock Management), has no value since it doesn't include shipping charges!  It doesn't even read my current inventory from my catalog, but requires manual reentry of all of my products. It's like they make up the names for modules and features but they don't actually do what they say they do.

I finally got so sick of trying to make this undocumented stuff work that I'm paying for support, and even that is a joke. You can only file tickets when they are open and it takes days to even get aknowledgment.

I'm ready to launch with what I have so I can start developing on a better system, but suddenly I have licensing issues on the main server....

I find it hard to believe I cannot do better.

[cjrhoads]

What type of website are you launching?

[jontobey]

ecommerce for raw vegan food

[cjrhoads]

Sounds extremely interesting.  Can you send me more info or put me on your mailing list?  [email protected]

Thanks

CJ

[jontobey]

Just as soon as I have a viable site.