[FONCTIONNEL]
Corriger le libellé du produit dans les factures de vente.

[TECHNIQUE]
Correction de l'expression ProductName dans l'EV IPInvoiceLineReportView

[TESTS]

Done : //Mettre ici les Task/Fix à passer en Done avec #numéroduworkitem
Resolved :#244

[FONCTIONNEL]
Description fonctionnelle de la PR

[TECHNIQUE]
Description technique de la PR

[TESTS]
Copies d'écran, vidéos, etc qui illustrent le bon fonctionnement de la demande

Done : //Mettre ici les Task/Fix à passer en Done avec #numéroduworkitem
Resolved :24434Nom du produit dans les éditions de facture de vente

[FONCTIONNEL]
Correction de la création d'une nature depuis la fiche matériel.

[TECHNIQUE]
La catégorie de produit n'était pas renseignée, ce qui empêchait la récupération des valeurs par défaut ainsi que l'enregistrement de la nature.
Il n'y a pas d'autre appel concerné par cette modification.

[FONCTIONNEL]
Modification du système de filtrage des produits de vente afin de résoudre les problèmes de performance.
Tenant client le plus impacté : AGRIMECA SERVICE

[TECHNIQUE]
Suppression des migrations qui n'ont plus lieu d'être (facilite les migrations).

Ajout d'indexes sur les tables liées :
ProductSupplier : IDX_ProductSupplier_ProductId_IsPurchasable_CompanyId
ProductCompany : IDX_ProductCompany_Company_Product_U
Product : IDX_Product_IsActive_CategoryId
StockLine : IDX_StockLine_ProductId_StockQuantity_ReservedStockQuantity
BinProduct : IDX_BinProduct_ProductId_BinId

Modification des filtres afin d'éviter des jointures.
On filtre sur les id nature et id category plutôt que sur les codes des références.

[TESTS]

Done & Resolved après cherry pick develop

[FONCTIONNEL]
L'édition des factures est en échec si elle est associée à un BL qui a des lignes qui ont été ajoutées sur le BL ( et donc ne proviennent pas d'une commande ).

[TECHNIQUE]
Dans la retrieved de IPSalesOrderReportView, la récupération de la ( ou des ) commandes associées à un groupe de lignes de BL filtre sur les lignes de BL qui sont associées à une commande.

[TESTS]
Pour tester:

• créer une commande
• valider, puis livrer
• sur le BL généré, ajouter une ligne de frais.
• Valider puis facturer le BL
• L'impression de la facture doit être possible.

Done :28084Facturation > Edition de facture de vente impossible

[FONCTIONNEL]
Corriger les défauts de l'édition des devis atelier ( première page blanche, Description répétées sur toutes les pages )

[TECHNIQUE]
Correction du .mrt

[TESTS]
Testé avec @Etienne GENDRON

Done :28302Bug - Problème d'édition

[FONCTIONNEL]
Le problème impacte tous les bons de réception qui ont été générés depuis une commande d'achat et dans lesquels une ligne (non liée à une CA) a été ajoutée par l'utilisateur.
Dans le cas de Terre de Quad, ce sont les lignes de Frais (PORT) qui ont déclenchés le problème.
Les données ne sont pas impactées, il s'agit du même BR affiché 2 fois. Il ne devrait y avoir aucun problème fonctionnel, seul l'affichage dans la liste est impacté.

[TECHNIQUE]
POReceiptListView: Exclusion des valeurs nulles dans l'expression Orders qui provoquent un effet de bord lors de l'utilisation du string.Join
https://community.neos.groupeisagri.com/t/chargement-dun-doublon-lie-a-une-expression-contenant-un-string-join/4950/2 

[TESTS]
Avant :

Après :

Done :28341Doublon de bon de réception

[FONCTIONNEL]
Description fonctionnelle de la PR

[TECHNIQUE]

• Suppression de l'utilisation des transactions dans le saving et le saved des lignes d'OT

• La réservation automatique sur des nouvelles lignes se fait forcement dans le saving puis la livraison automatique dans le saved.

• Pour l'instant mis en place seulement sur les lignes d'OT car c'est sur ces documents que l'on rencontre le bug, à voir si cela corrige le pb on pourra le répercuter sur les commandes de vente

• Mis en place des colonnes de dates de création et de modification sur STockReservation et purchaseOrderReservation

[TESTS]
Création d'un OT => ouverture de l'OT => Création de deux lignes sur des produits différents avec du stock
=> la réservation puis livration est ok et stockline ok

Création d'un OT => Création de deux lignes sur des produits différents avec du stock
=> ouverture puis livraison => la réservation puis livration est ok et stockline ok

Création d'un OT => Création de deux lignes sur des produits différents avec du stock
et des rérservations forcée en commande d'achat => ouverture puis livraison => la réservation puis livration est ok et stockline ok

Création d'un OT => ouverture de l'OT => Création de deux lignes sur des produits différents avec pas assez de stock => réservation sur stock et commande d'achat et livraison est ok et stockline ok

Done :28512Ajout date de création et la date de dernier update sur les stocks réservations

FONCTIONNEL

📋 Contexte

Sur l'environnement de production, la zone de note dans les rapports imprimés (facture de vente, devis de vente, bon de clôture d'ordre de travail) tronquait le contenu lorsque le texte dépassait la hauteur fixe du champ. Les lignes situées en haut et en bas du texte n'étaient pas affichées.

🎯 Objectif de la PR

Correction du rendu des rapports : la zone de note s'agrandit automatiquement en fonction du contenu saisi, garantissant l'affichage complet du texte sans troncature.

TECHNIQUE

⚙️ Changements techniques

Modification de 3 templates de rapports (.mrt) pour activer l'agrandissement automatique (Auto-extensible/CanGrow) du champ note :

• Modification de IPInvoice/reports/SalesInvoiceReport.mrt
• Modification de IPQuote/reports/SalesQuoteReport.mrt
• Modification de IPWork/reports/WorkOrderClosingReport.mrt

Points d'attention pour la review :

• Changements purement visuels, aucun impact sur la logique métier ou les données.
• Vérifier que le rendu reste cohérent avec la mise en page globale des rapports (pagination, marges).

TESTS ET QUALITE

🧪 Tests

Tests réalisés

•  Tests unitaires
•  Tests manuels
•  Tests d’intégration

Preuves

Facture de vente avec une note de plusieurs lignes:

Facture de vente avec une note vide:

✔️ Checklist avant merge

Qualité

•  La PR compile correctement
•  Les tests unitaires passent
•  Les nouveaux tests sont ajoutés si nécessaire
•  La Quality Gate est respectée
•  Pas de code mort ou de debug

Code

•  Le code respecte les conventions du projet
•  Pas de duplication inutile
•  Les erreurs sont gérées
•  Les logs sont pertinents

Impact

•  Pas de breaking change
•  Migration nécessaire documentée
•  Impact performance vérifié si pertinent

📦 Déploiement

Aucune action spécifique requise.

🔗 Work items

• Done :28668Edition de vente : Rendre la zone note extensible
  Done
• Resolved :28390Edition de vente : Rendre la zone note extensible
  Resolved

FONCTIONNEL

📋 Contexte

Lors de la création de factures de vente depuis l'écran de facturation (facturation par OT ou par BL), la numérotation des factures n'était pas séquentielle : le numéro attribué à chaque nouvelle facture était égal au numéro précédent +2 au lieu de +1, créant ainsi des trous dans la suite de numérotation (ex : factures 45, 47, 49… au lieu de 45, 46, 47…).

🎯 Objectif de la PR

Correction des trous dans la numérotation des factures de vente lors du processus de facturation depuis le menu de facturation.

TECHNIQUE

⚙️ Changements techniques

Cause racine identifiée :
Le compteur de numérotation définitif des factures (NextFormatedValueAsync sur le compteur validé) était appelé deux fois pour chaque facture créée :

1. Une première fois dans les processus de facturation (WorkOrderListInvoicing, DeliveryNoteListInvoicing) dans SetupInvoiceHeaderAsync, via _iPTransactionalCounterHelper.NextFormatedValueAsync(...).
2. Une deuxième fois dans la règle de domaine Saving de InvoiceHeader (IPX.IPInvoice.Application.InvoiceHeaderDomainEventRules.Saving), dans SetFinalInvoiceCounterAsync, appelé lors du SaveAsync.

Le premier appel produisait un numéro qui était ensuite écrasé par le second, mais le compteur avait déjà été incrémenté, laissant un numéro "brûlé".

Corrections apportées :

• Modification de SetupInvoiceHeaderAsync dans WorkOrderListInvoicing et DeliveryNoteListInvoicing : le NumberInvoice est désormais alimenté par le compteur temporaire (TemporaryInvoiceCounterName) au lieu du compteur de numérotation définitif. Le numéro définitif est uniquement attribué par la règle de domaine Saving lors du SaveAsync.

Points d'attention pour la review :

• Le bug se produit quand on utilise un compteur séquentiel pour les factures de vente. Un compteur annuel ou mensuel ne provoque pas d'erreurs de numérotation.
• Le commentaire dans SetupInvoiceHeaderAsync explique explicitement le rôle du numéro temporaire et pourquoi le compteur définitif ne doit pas être appelé ici.
• Vérifier que la règle de domaine Saving (SetFinalInvoiceCounterAsync) est bien le seul endroit où le compteur définitif est incrémenté pour une facture validée.

TESTS ET QUALITE

🧪 Tests

Tests réalisés

•  Tests unitaires
•  Tests manuels
•  Tests d’intégration

Preuves

✔️ Checklist avant merge

Qualité

•  La PR compile correctement
•  Les tests unitaires passent
•  Les nouveaux tests sont ajoutés si nécessaire
•  La Quality Gate est respectée
•  Pas de code mort ou de debug

Code

•  Le code respecte les conventions du projet
•  Pas de duplication inutile
•  Les erreurs sont gérées
•  Les logs sont pertinents

Impact

•  Pas de breaking change
•  Migration nécessaire documentée
•  Impact performance vérifié si pertinent

📦 Déploiement

Aucune migration BDD requise.

🔗 Work items

• Done :28566Facturation - Facturation : trous dans la numérotation des factures de vente (1.2.X)
  Done
• Resolved :28427Facturation - Facturation : trous dans la numérotation des factures de vente (1.2.X)
  Resolved