Import Csv Produits Probleme D'affichage Des Réductions

[davmems]

Lorsque j'importe un csv de produits (environ 3000) avec des réduction en pourcentage, la réduction bien que présente dans mon back office ne s'affiche pas dans le front office.

J'ai testé d'importer le meme fichier en ne laissant que 999 produits et cela fonctionne bien. 

J'ai donc essayé de passer mes 3000 produits en créant 3 fichiers de 1000 produits. Le premier passe bien et affiche les réductions mais le second recréé le problème et même mes 1000 premiers produits n'affichent plus la réduction dans le front office (liste des produits et fiche produit). 

Avez vous rencontré ce problème ? Est ce un bug de PS? Y a t il une limite dans le code à modifier ?

Avez vous une solution ?

[davmems]

Je précise que je suis en version 1.6.1.2

 

Merci d'avance

[Eolia]

Je pense plutot qu'il doit y avoir une règle dans la 2ème série des 1000 qui pose problème et qui fait planter les autres.

[davmems]

Merci pour ta réponse

J'ai vérifier et il n'y a pas de soucis sur mon fichier.

La preuve:

Les 1000 premiers passent avec l'affichage de la réduction en pourcentage

Les 500 suivants passent avec "suppression des produits avant l'import"

Mais si j'importe 1500 d'un coup la réduction en pourcentage ne s'affiche pas et si j'importe les 1000 premiers puis les 500 suivants sans supprimer les produits avant l'import plus aucun produits n'affiche la réduction

[Eolia]

Ce qui est sur c'est que l'import partiel ne marche sous 1.6.

Pour le reste, postez sur la forge pour remonter le bug.

[Oron]

Bonjour

 

Je déplace votre topic dans le forum Configuration et Utilisation de prestashop.

[decome2013]

As-tu essayer de réimporter uniquement un fichier avec une colonne ID et une colonne réduction ? (moins lourd en traitement pour presta).

 

Franchement par expérience et après avoir tourner en rond parfois des semaines sur l'origine d'un bug éventuel de presta durant les import, ca vient toujours du fichier.

 

Revérifie, si besoin ligne par ligne.

 

Essaie aussi d'importer tes 3000 premiers produits mais contenant par exemple 3 fois tes 1000 premiers qui ne créent aucun problème. Ca t'indiquera à coup sûr si le probleme vient du fichier ou pas.

[Baba deCode]

Salut,

est ce que tu peux mettre en fichier joint ton csv pour qu on puisse regarder.

 

CDT

[davmems]

Merci pour vos réponses

J'ai du nouveau. 

En complément d'information je dois dire que je travaille sur un serveur local (mamp sur mac).

En gros après plusieurs tests je me suis rendu compte que le nombre de produits (lignes) importés max est de 1009 avant que le probleme concernant les réductions n'intervienne.

J'ai tenté d'importer directement sur l'hébergeur (OVH) et là je n'ai plus de problème.

En revanche j'ai du créer 4 fichiers de 750 produits car le temps de chargement était trop long et je me retrouvais déconnecté avant de finir l'import.

Du coup je me dis que cela doit venir de mon ordinateur .. 

Est ce possible que ce bug soit lié à la puissance de l'ordinateur ?

Tout ceci m'amène à un autre soucis.. le temps de chargement de l'import... Je pense que c'est un sujet qui a du être traité maintes fois mais auriez vous un lien vers une réponse claire? Sinon je n'ose pas imaginer comment je vais m'y prendre pour mes 9000 déclianisons ...

[Baba deCode]

en fait ton serveur MAMP manque de configuration, il faut que tu modifie le php.ini .... max execution time max input vars etc...

[davmems]

Merci Alexandre mais je dois avouer que je ne m'y connais pas assez pour comprendre comment faire pour améliorer la config de mon serveur MAMP.. 

S'agit il de modifs dans le code ? si oui, où dois je faire les modifs ? il y plein de dossiers php5 avec des fichier php.ini

Donc selon toi mon problème ne viendrait que de la config de mon serveur virtuel..

Du coup je comptais acheter un nouvel ordi plus puissant mais ça ne changerait donc rien..

 

Sinon au niveau de mon site sur internet comment puis je m'y prendre pour importer mon fichier de 9000 déclinaisons qui prendra au moins 1 heure ? Je serai forcément déconnecté avant .... Peut on réduire le délais d'import pour pouvoir tout charger ? Doit on modifier les paramètres de l'hébergeur pour supprimer/modifier le timeout ?
Merci de m'expliquer comment faire ?

 

J'espère que mes questions ne paraissent pas trop idiotes ...

 

Merci d'avance

[Baba deCode]

En fait tout depend du systeme de ton serveur, mais le plus souvent c'est le fichier php.ini d'apache2, sur un environnement ubuntu serveur ce fichier se situe dans /etc/php5/apache2/php.ini

 

Je te donne ma config a titre indicatif:

max_execution_time = 30000
memory_limit = 1024M
post_max_size = 500M
upload_max_filesize = 800M
max_execution_time = 30000
max_input_vars = 50000
max_input_time = -1

Tu auras plein de config et de tuto en recherchant le web...

Sinon tu peux egalement configurer mysql en editant ou en créant un fichier de configuration

 

/etc/mysql/mysql.cnf

 

Je te donne ma config a titre indicatif:

 

!includedir /etc/mysql/conf.d/

!includedir /etc/mysql/mysql.conf.d/

 

 

[client]

 

port = 3306

socket = /var/run/mysqld/mysql.sock

 

 

[mysql]

 

no_auto_rehash

max_allowed_packet = 16M

prompt = '\u@\h [\d]> '

default_character_set = utf8 # Possibly this setting is correct for most recent Linux systems

 

 

[mysqldump]

 

max_allowed_packet = 64M

 

 

[mysqld_safe]

 

open_files_limit = 8192 # You possibly have to adapt your O/S settings as well

user = mysql

log-error = hostname_error.log

 

 

[mysqld]

 

# Connection and Thread variables

 

port = 3306

socket = /var/run/mysqld/mysql.sock

 

max_allowed_packet = 500M

default_storage_engine = InnoDB # Defaults since 5.5

 

# character_set_server = utf8 # If you prefer utf8

# collation_server = utf8_general_ci

 

 

max_connections = 505 # Values < 1000 are typically good

max_user_connections = 500 # Limit one specific user/application

thread_cache_size = 505 # Up to max_connections makes sense

 

 

# Query Cache

 

query_cache_type = 1 # Set to 0 to avoid global QC Mutex

query_cache_size = 32M # Avoid too big (> 128M) QC because of QC clean-up lock!

 

 

# Session variables

 

sort_buffer_size = 2M # Could be too big for many small sorts

tmp_table_size = 64M # Make sure your temporary results do NOT contain BLOB/TEXT attributes

 

read_buffer_size = 128k # Resist to change this parameter if you do not know what you are doing

read_rnd_buffer_size = 256k # Resist to change this parameter if you do not know what you are doing

join_buffer_size = 128k # Resist to change this parameter if you do not know what you are doing

 

 

# Other buffers and caches

 

table_definition_cache = 400 # As big as many tables you have

table_open_cache = 512 # connections x tables/connection (~2)

 

 

# MySQL error log

 

log_error = hostname_error.log

log_warnings = 2

# innodb_print_all_deadlocks = 1

# wsrep_log_conflicts = 1 # for Galera only!

 

# Slow Query Log

 

slow_query_log_file = hostname_slow.log

slow_query_log = 0

log_queries_not_using_indexes = 1

long_query_time = 0.5

min_examined_row_limit = 100

 

 

# General Query Log

 

general_log_file = hostname_general.log

general_log = 0

 

 

# Binary logging and Replication

 

server_id = 42

log_bin = hostname_binlog

# master_verify_checksum = ON # Since 5.6

binlog_cache_size = 1M

binlog_stmt_cache_size = 1M

max_binlog_size = 128M # Make bigger for high traffic to reduce number of files

sync_binlog = 0 # Set to 1 or higher to reduce potential loss of binary-log data

expire_logs_days = 5 # We will survive easter holidays

binlog_format = ROW # Use MIXED if you experience some troubles

# binlog_row_image = MINIMAL # Since 5.6

# auto_increment_increment = 2 # For Master/Master set-ups use 2 for both nodes

# auto_increment_offset = 1 # For Master/Master set-ups use 1 and 2

 

 

# Slave variables

 

log_slave_updates = 1 # Use if Slave is used for Backup and PiTR

read_only = 0 # Set to 1 to prevent writes on Slave

skip_slave_start = 0 # To avoid start of Slave threads

 

 

# Security variables

 

# local_infile = 0 # If you are security aware

# secure_auth = 1 # If you are security aware

# sql_mode = TRADITIONAL,ONLY_FULL_GROUP_BY,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES # Be careful changing this afterwards

# skip_name_resolve = 0 # Set to 1 if you do not trust your DNS or experience problems

 

 

# MyISAM variables

 

key_buffer_size = 16M # Set to 25 - 33 % of RAM if you still use MyISAM

myisam_recover_options = 'BACKUP,FORCE'

 

 

# MEMORY variables

 

max_heap_table_size = 64M # Should be greater or equal to tmp_table_size

 

 

# InnoDB variables

 

innodb_strict_mode = ON

innodb_file_format_check = 1

# innodb_file_format = Barracuda # For dynamic and compressed InnoDB tables

innodb_buffer_pool_size = 256M # Go up to 80% of your available RAM

innodb_buffer_pool_instances = 16 # Bigger if huge InnoDB Buffer Pool or high concurrency

 

innodb_file_per_table = 1 # Is the recommended way nowadays

# innodb_flush_method = O_DIRECT # O_DIRECT is sometimes better for direct attached storage

# innodb_write_io_threads = 8 # If you have a strong I/O system or SSD

# innodb_read_io_threads = 8 # If you have a strong I/O system or SSD

# innodb_io_capacity = 1000 # If you have a strong I/O system or SSD

 

innodb_flush_log_at_trx_commit = 0 # 1 for durability, 0 or 2 for performance

innodb_log_buffer_size = 8M # Bigger if innodb_flush_log_at_trx_commit = 0

innodb_log_file_size = 256M # Bigger means more write throughput but longer recovery time

 

 

# Galera specific MySQL parameter

 

# default_storage_engine = InnoDB # Galera only works with InnoDB

# innodb_flush_log_at_trx_commit = 0 # Durability is achieved by committing to the Group

# innodb_autoinc_lock_mode = 2 # For parallel applying

# binlog_format = row # Galera only works with RBR

# query_cache_type = 0 # Use QC with Galera only in a Master/Slave set-up

# query_cache_size = 0

 

 

# WSREP parameter

 

# wsrep_provider = none # Start mysqld without Galera

# wsrep_provider = /usr/lib/galera/libgalera_smm.so # Location of Galera Plugin

# wsrep_provider_options = 'gcache.size = 1G' # Depends on you workload, WS kept for IST

 

# wsrep_cluster_name = "My cool Galera Cluster" # Same Cluster name for all nodes

 

 

 

# wsrep_node_name = "Node A" # Unique node name

# wsrep_node_address = 192.168.0.1 # Our address where replication is done

# wsrep_node_incoming_address = 10.0.0.1 # Our external interface where application comes from

# wsrep_causal_reads = 1 # If you need realy full-synchronous replication (Galera 3.5 and older)

# wsrep_sync_wait = 1 # If you need realy full-synchronous replication (Galera 3.6 and newer)

# wsrep_slave_threads = 1 # 4 - 8 per core, not more than wsrep_cert_deps_distance

 

# wsrep_sst_method = mysqldump # SST method (initial full sync): mysqldump, rsync, rsync_wan, xtrabackup

# wsrep_sst_auth = sst:secret # Username/password for sst user

# wsrep_sst_receive_address = 192.168.0.1 # Our address where to receive SST

Edited December 7, 2015 by Alexandre-KM (see edit history)

[davmems]

Bon j'ai réussi à améliorer la config de mon serveur.

J'ai bien vérifié avec un info.php

Mais cela ne solutionne pas mon problème. 

C'est vraiment étrange. J'ai cherché sur les forums et sur le net. J'ai trouvé un post qui semble être le même problème que moi mais il est resté sans réponse.

Je ne sais plus comment m'y prendre .. Je suis à cours d'idée..

[davmems]

Pour rappel, il s'agit d'un import sur mon serveur local MAMP.

 

J'ajoute que l'import fonctionne puisque tous mes produits se retrouve dans mon BO et dans toutes mes fiches produits en BO, dans la rubrique "prix" j'ai bien le prix spécifique avec la réduction en pourcentage qui apparait. Cependant, ce prix spécifique n'est pas prix en compte pour le calcul du prix final. De même, le prix barré et le montant de la réduction en % n'apparait pas en front office. 

 

Je me répète mais si je n'importe "que" 1000 produits, je n'ai pas le problème.

Si j'importe 1200 produits, le problème concernent même les 1000 premiers qui passaient normalement.

Le fichier n'a pas de problème puisque lorsque je le charge sur mon serveur ovh, il n'y a pas eu de soucis.

 

Auriez vous des idées ?

[davmems]

J'ai fait apparaitre la console debug et il apparemment

specific_prices => false

 

C'est bizarre puisque le prix spécifique est bien renseigné dans ma fiche produit > Prix de mon BO .. 

[davmems]

Enfin j'ai vérifié sur phpmyadmin et tous les prix spéciques sont bien dans ma table ps_specific_price ..

[Baba deCode]

donc ce n'est pas un probleme d import vu que les prix sont en base

[davmems]

Dernier test effectué:

750 produits importés -> Prise en compte des prix spécifiques

750 produits importés ajoutés -> Non prise en compte des prix spécifiques pour l'ensemble des produits

Suppression via le BO de 500 produits (de façon aléatoire)-> les 1000 produits restant reprennent en compte les prix spécifiques

 

Pour moi il est clair que le système ne prend plus en compte les prix spécifiques à partir d'un certain nombres.

 

Je suis en version 1.6.1.2 

 

Comment faire les modifs pour supprimer les limites ?

[davmems]

Bon j'ai essayé sur un ordi plus puissant et tout fonctionne ...