Import/Exports complexes du catalogue
Rajouter la possibilité d'un export "complexe" du catalogue (avec des sous niveaux permettant de prendre en compte les produits composés). Ces fichiers d'export "complexes" permettrait ensuite de transférer un catalogue d'une enseigne à une autre via la fonction d'import. Le format du fichier d'export est à réfléchir, du JSON ou autre format pourrait convenir. Peut être prévoir un modèle de contenu pour le format en question ? L'équivalent du XSD pour le XML ?
Fait suite à #2775 (closed) réalisé dans la v6.5
Use-cases considérés
- UC1 Un EA ou ES migre son catalogue d'un serveur endi à un autre : export d'une enseigne sur un serveur puis import dans une enseigne sur l'autre serveur
- UC2 Un EA ou ES transfére des produits d'une enseigne à une autre : export dans une enseigne puis import dans l'autre
Use-cases ignorés
- Mettre à jour son catalogue en éditant le JSON (c'est une différence avec l'export/import CSV, que l'on peut souhaiter éditer avec un tableur pour mettre à jour sa base client)
- Tout import/export multi-enseigne
Stratégie d'import pour les Produits de Catalogue
-
BaseSaleProduct a exactement la même stratégie (simple) que
- SaleProductProduct
- SaleProductMaterial
- SaleProductWorkForce
- SaleProductServiceDelivery
-
SaleProductWork
- On les importe en dernier (après tous les produits simples) ; normalement, tous leurs produits liés ont déjà été importés, on a donc pas besoin de les importer
- On importe en cascade les SaleProductWorkItem ;
- Si on exporte tout le catalogue : on n'a pas à re-créer les sous-produits : ils l'ont déjà été car présents dans le catalogue (donc le format d'export d'un produit composé n'a qu'à inclure les IDs des sous-produits)
- Si on permet de n'exporter qu'une part du catalogue : il vaut mieux inclure les sous-produits nestés dans l'export des produit composé, et au sein d'un même batch d'import on s'assure de ne pas importer 2x le même sous-produit (on a l'ID, qu'on peut utiliser localement à un process d'import pour dédoublonner)
Points d'attention
-
conserver WorkItem.base_sale_product_id ET sale_product_work_id (Les ID changent…) -
il faut conserver le typage des enfants de BaseSaleProduct
Limitations
-
on ne supporte pas les liens SaleProductWorkItem ➡ SaleProductWork et WorkItem➡ BaseSaleProduct pointant vers l'extérieur de l'import. Ces liens sont locaux à l'import. -
Pas de gestion du dé-doublonement
Stratégie d'import pour les autres modèles liés
Modèle | Détection pré-existence | si non pré-existant | colones à exporter (a minima) |
---|---|---|---|
Product (via BaseSaleProduct.product) | Product.compte_cg && Product.tva.value && Product.active==True && match unique. |
set BaseSaleProduct.product_id = None (+ afficher warning) |
|
Tva (via BaseSaleProduct | (Tva.name && Tva.value && Tva.compte_cg && Tva.active==True) OU (Tva.name && Tva.value && Tva.active==True) OU (Tva.value && Tva.value==True) |
set BaseSaleProduct.tva_id = None (+afficher warning) |
|
WorkUnit (via BaseSaleProduct.unity et/ou WorkItem.unity) | WorkUnit.label (case insensitive) |
set BaseSaleProduct.unit = None / set WorkItem.unit = None (+afficher warning) |
|
SaleProductCategory (via BaseSaleProduct.category_id) | SaleProduct.category.title && SaleProductCategory.company_id | créer à la volée (avec company_id courant) |
|
Supplier | (Supplier.label || Supplier.registration(si non nul)) && Supplier.company_id |
set BaseSaleProduct.supplier_id = None (+ afficher warning) |
|
TrainingTypeOptions (via SaleProductTraining.types) | TrainingTypeOption.label && TrainingTypeOption.active |
[] |
TrainingTypeOption.label |
ExpenseType (via BaseSalePRoduct.purchase_type) | Expense |
Questions diverses
- On recopie l'historique de stock ? ça n'a pas de sens que pour UC1. OUI si possible
- Est-ce qu'on permet de n'exporter qu'une partie du catalogue d'une enseigne ? NON
- Si on est sur le même serveur, avoir une option pour gérer les absences de match sur le compte.