bemade-addons/account_credit_hold/migration18.md
2025-01-27 07:17:59 -05:00

246 lines
No EOL
9.3 KiB
Markdown

# Migration vers Odoo 18.0 - Module account_credit_hold
## Fonctionnalités
- Ajoute un champ "Place on Credit Hold" sur les lignes de suivi de compte (account_followup.followup.line)
- Ajoute des champs et fonctionnalités sur les partenaires:
- postpone_hold_until: Date de report du blocage
- hold_bg: Champ technique pour le statut de blocage
- on_hold: État calculé du blocage de crédit
- Bloque la confirmation des commandes de vente si le client est en blocage de crédit
- Ajoute des indicateurs visuels (ruban rouge) sur:
- Commandes de vente
- Fiches partenaires
- Transferts de stock
- Ajoute des boutons pour mettre/lever le blocage de crédit dans la vue de suivi des comptes
## Analyse pour la Migration
### Dépendances
- sale
- account_followup
- stock
### Changements Techniques Requis
1. Mettre à jour la version dans __manifest__.py vers 18.0
2. Vérifier la compatibilité des vues XML avec Odoo 18.0
3. Vérifier si des changements dans l'API account_followup en 18.0
### Points d'Attention
1. Le module utilise l'héritage de vues et de modèles standard d'Odoo:
- account_followup.followup.line
- res.partner
- sale.order
- stock.picking
- account.followup.report
2. Fonctionnalités critiques à tester après migration:
- Calcul automatique du statut on_hold
- Blocage de la confirmation des commandes
- Nettoyage automatique des reports de blocage expirés (@api.autovacuum)
- Affichage correct des rubans d'avertissement
- Propagation du statut hold aux contacts liés (commercial_partner_id)
3. Implémentation Technique:
- Utilisation de champs computed avec store=True et compute_sudo=True
- Mécanisme de nettoyage automatique via @api.autovacuum
- Héritage de _execute_followup_partner pour automatisation du hold
- Messages de chatter automatiques lors des changements de statut
4. Points Spécifiques aux Vues:
- Utilisation du widget web_ribbon pour les indicateurs visuels
- Boutons conditionnels dans la vue de suivi des comptes
- Champs invisibles pour la logique d'affichage (hold_bg, on_hold)
- Groupes de sécurité sur le champ postpone_hold_until
## Questions et Considérations
1. Vérifier si Odoo 18.0 n'a pas introduit des fonctionnalités natives similaires dans account_followup:
- Système de blocage automatique des clients
- Gestion des périodes de grâce
- Indicateurs visuels de blocage
2. Points à valider:
- La structure des vues héritées est-elle identique en 18.0?
- Les champs related et computed fonctionnent-ils de la même manière?
- Le système de suivi des comptes (account_followup) a-t-il évolué?
- Le décorateur @api.autovacuum est-il toujours supporté?
- Le widget web_ribbon utilise-t-il toujours la même API?
3. Considérations d'Architecture:
- Le mécanisme de propagation du statut hold via commercial_partner_id est-il optimal?
- Possibilité de simplifier la logique de calcul du statut hold?
- Pertinence de stocker le champ hold_bg vs calcul à la demande
4. Alternatives Potentielles:
- Utiliser le système de credit limit natif d'Odoo avec des règles personnalisées?
- Intégrer avec le système de blocage des partenaires d'Odoo?
- Utiliser les étapes de facturation (invoice_status) plutôt qu'un champ séparé?
## Alternatives Natives Odoo 18.0
### Système de Crédit Natif
1. Odoo 18.0 inclut des fonctionnalités natives de gestion de crédit:
- Champ `credit_limit` sur res.partner
- Configuration du blocage au niveau de la société
- Règles de blocage basées sur:
- Montant de crédit maximum
- Factures échues
- Âge des factures
2. Possibilités d'utilisation des fonctionnalités natives:
- Utiliser `credit_limit` au lieu de `on_hold`
- Configurer les règles de blocage dans la configuration de la comptabilité
- Utiliser les notifications natives de dépassement de crédit
### Améliorations Possibles
1. Intégration avec le système natif:
- Synchroniser notre `on_hold` avec le système natif de blocage
- Utiliser les API natives de vérification de crédit
- Conserver uniquement les fonctionnalités non disponibles nativement
2. Simplification du code:
- Remplacer les champs custom par des champs natifs quand possible
- Utiliser le système d'alertes natif pour les rubans
- Intégrer avec le système de workflow natif
## Recommandations pour la Migration
### Approche "Vanilla First"
1. Évaluer chaque fonctionnalité custom:
- Est-elle disponible nativement dans Odoo 18.0?
- Peut-elle être remplacée par une configuration native?
- Le besoin business existe-t-il toujours?
2. Prioriser l'utilisation des fonctionnalités natives:
- Système de crédit natif
- Système de workflow natif
- API de notification standard
- Widgets standards de l'interface
### Modifications Techniques Recommandées
1. Remplacer les attributs obsolètes:
- Supprimer les `attrs` dans les vues (Odoo 16.0+)
- Utiliser `list` au lieu de `tree` (Odoo 17.0+)
- Adapter les widgets aux nouvelles conventions
2. Optimisation des performances:
- Utiliser les indexes de base de données appropriés
- Optimiser les recherches et calculs
- Implémenter le lazy loading quand possible
### Plan de Test Approfondi
1. Tests fonctionnels:
- Validation du comportement avec le système natif
- Tests de régression sur les fonctionnalités custom
- Vérification des performances
2. Tests d'intégration:
- Interaction avec le workflow de vente
- Synchronisation avec la comptabilité
- Comportement avec les autres modules
## État de la Migration
⚪ En analyse préliminaire
## Plan de Migration
### Étape 1: Analyse des Changements Odoo 18.0
- [ ] Examiner les changements dans account_followup
- [ ] Vérifier les nouvelles fonctionnalités de gestion de crédit
- [ ] Analyser les modifications des vues héritées
### Étape 2: Adaptation Technique
- [ ] Mise à jour du manifeste
- [ ] Vérification de la compatibilité des décorateurs
- [ ] Adaptation des vues XML si nécessaire
- [ ] Test des champs computed et related
### Étape 3: Tests Fonctionnels
- [ ] Validation du mécanisme de hold
- [ ] Test de la propagation aux contacts
- [ ] Vérification des nettoyages automatiques
- [ ] Test des indicateurs visuels
### Étape 4: Optimisation
- [ ] Évaluation des alternatives natives
- [ ] Simplification potentielle du code
- [ ] Amélioration des performances
## Notes de Version
- Version originale: 17.0.1.1.1
- Dernière analyse: 26/01/2025
## Fonctionnalités Natives dans Odoo 18.0
Odoo 18.0 inclut nativement plusieurs fonctionnalités de gestion du crédit :
1. **Gestion des Limites de Crédit**
- Champ `credit_limit` sur les partenaires
- Champ `use_partner_credit_limit` pour activer/désactiver par partenaire
- Configuration globale `account_use_credit_limit` au niveau de la société
- Champ `credit` pour le total des créances
- Champ `trust` pour le niveau de confiance du débiteur
2. **Visibilité et Contrôle**
- Champ `show_credit_limit` basé sur la configuration de la société
- Groupes de sécurité pour la gestion des limites de crédit
### Différences avec Notre Module
1. **Fonctionnalités à Migrer**
- [ ] Indicateurs visuels spécifiques pour les clients en dépassement
- [ ] Blocage automatique des commandes en dépassement
- [ ] Workflow d'approbation personnalisé
2. **Fonctionnalités à Adapter**
- [ ] Utiliser les champs natifs plutôt que nos champs customs
- [ ] Intégrer nos règles de blocage avec le système natif
- [ ] Adapter les rapports et vues pour utiliser les champs natifs
## Plan de Migration
### Phase 1 : Préparation
1. **Analyse des Données**
- [ ] Identifier les clients avec des limites de crédit
- [ ] Mapper les champs actuels vers les champs natifs
- [ ] Lister les règles de blocage personnalisées
2. **Configuration**
- [ ] Activer la gestion du crédit dans la configuration de la société
- [ ] Configurer les groupes de sécurité appropriés
- [ ] Préparer les scripts de migration des données
### Phase 2 : Migration
1. **Migration des Données**
- [ ] Transférer les limites de crédit vers le champ natif
- [ ] Migrer les configurations de blocage
- [ ] Mettre à jour les vues et rapports
2. **Développement**
- [ ] Adapter le code de blocage des commandes
- [ ] Implémenter les indicateurs visuels manquants
- [ ] Ajouter les fonctionnalités spécifiques non disponibles nativement
### Phase 3 : Tests
1. **Validation Fonctionnelle**
- [ ] Tester les limites de crédit
- [ ] Vérifier le blocage des commandes
- [ ] Valider les workflows d'approbation
2. **Tests d'Intégration**
- [ ] Tester avec les autres modules
- [ ] Vérifier la compatibilité avec les processus existants
## État de la Migration
🟡 En cours d'analyse - Utilisation partielle des fonctionnalités natives
## Notes Importantes
- La gestion du crédit est maintenant une fonctionnalité native d'Odoo
- Certaines fonctionnalités spécifiques devront être maintenues
- L'approche recommandée est d'utiliser au maximum les fonctionnalités natives et de ne conserver que les extensions nécessaires
## Prochaines Étapes
1. Valider l'approche avec l'équipe
2. Créer les scripts de migration des données
3. Développer les fonctionnalités manquantes
4. Planifier la formation des utilisateurs