Cycle de vie d'une facture

Le diagramme ci-dessous illustre le cycle de vie possible d'une facture.

Une facture est initialement sauvegardée dans l'état En attente.  A ce stade, vous pouvez créer une ou plusieurs sections de facture pour les éléments de contrat du compte.  Pour plus d'informations sur la génération des sections de facture, voir Procédures.

Une facture prend l'état Finalisé lorsqu'elle est prête à être envoyée au client. La finalisation d'une facture déclenche de nombreux événements.  Pour plus d'informations, voir la section ci-dessous.

Quand vous finalisez une facture, plusieurs choses se produisent :

• Les algorithmes de pré-finalisation associés aux types d'EdC des éléments de contrat du compte sont exécutés. Le système exécute tout d'abord ces algorithmes dans l'ordre de la séquence du traitement de facturation figurant sur chaque type d'EdC puis dans l'ordre de la séquence de l'algorithme. Ceux-ci ne sont pas exécutés pour la finalisation des avoirs.
• Les algorithmes de pré-finalisation associés à la classe client du compte sont exécutés.
• La date d'échéance de la facture est calculée. Elle équivaut à la date de la facture plus le nombre de jours défini dans la classe client du compte. Si la date qui en résulte n'est pas un jour ouvré, la date d'échéance est définie sur le jour ouvré suivant. Notez que cette date d'échéance ne peut pas être remplacée si un algorithme de substitution existe sur la classe client du compte.
• Les informations d'acheminement de la facture sont définies à l'aide de Compte - Informations acteur.
• Si l'option d'installation Valider à la finalisation de facture a été activée, les sections de factures validables et les régularisations liées au compte sont validées. Notez que seules les régularisations validables dont le type de régularisation indique Valider à la finalisation de facture seront validées à ce stade.  Pour plus d'informations, voir Empêcher l'impact des soldes EdC et de la CG tant que la facturation n'est pas finalisée.
• Si une section de facture finale d'un EdC de dépôt de garantie est détectée, le dépôt de garantie est remboursé au client à l'aide de l'algorithme de mode de remboursement associé à la classe de dépôt de garantie de l'EdC concerné.  Pour plus d'informations, voir Remboursement de dépôt de garantie. Cette étape est ignorée durant la finalisation des avoirs, ou si la facture est associée à un générateur de factures hors cycle.
• Les algorithmes de finalisation de facture associés aux types d'EdC des éléments de contrat du compte sont exécutés. Le système exécute tout d'abord ces algorithmes dans l'ordre de la séquence du traitement de facturation figurant sur chaque type d'EdC puis dans l'ordre de la séquence de l'algorithme.
• Les algorithmes de finalisation de facture associés à la classe client du compte sont exécutés.
• Les messages sur facture sont collectés à partir de différentes sources et associés à la facture. Pour plus d'informations, voir Source des messages sur facture.
• D'autres transactions financières validées depuis la dernière facture et marquées pour apparaître sur la facture sont associées à la nouvelle facture.
• Pour les clients avec postes non soldés, les régularisations et corrections sont associées.
• Pour les factures correctives ou avoirs, les transactions financières d'annulation de facture sont associées.
• Pour les factures émises par le générateur de factures hors cycle :
• Les régularisations associées au générateur de factures hors cycle sont liées à la facture.
• Si le générateur de factures hors cycle est associé à un élément de contrat, toutes les transactions financières de non-paiement associées à l'EdC sont liées à la facture.
• Dans tous les autres cas, les paiements, les régularisations et les corrections sont liés, dès lors que les régularisations ne sont pas associées à un générateur de factures hors cycle.
• Toutes les transactions financières qui n'ont pas déjà une date chronologique définie par l'utilisateur seront datées à la date actuelle. Autrement dit, elles démarrent le classement chronologique à compter de la date de finalisation de la facture.
• Si le compte procède par prélèvement automatique et que l'option de création de prélèvement automatique de l'installation est Créer à la finalisation de la facture, un prélèvement automatique est créé. Pour plus d'informations sur l'algorithme de création de paiement automatique, voir APAY-CREATE. Cette étape est ignorée lors de la finalisation des avoirs.
• Si la classe client du compte indique que le compte est un client de postes non soldés, un événement de lettrage est créé. Les TF de la facture et les TF de prélèvement automatique lui sont associées.  Pour plus d'informations sur les événements de lettrage, voir Paiements et événements de lettrage. Cette étape est ignorée lors de la finalisation des avoirs.
• Si le compte procède par prélèvement automatique et que l'option de création de prélèvement automatique de l'installation est Créer à la date d'extraction, la facture est indiquée avec la date de création du prélèvement automatique. Pour plus d'informations, voir APAYCRET, le processus en arrière-plan qui crée le prélèvement automatique, et APAYDSFR, le processus en arrière-plan qui ventile et valide le prélèvement automatique. Cette étape est ignorée lors de la finalisation des avoirs.
• La date de retard de paiement de la facture est calculée. Elle équivaut à la date d'échéance plus le nombre de jours de grâce défini dans la classe client du compte. Si la date qui en résulte n'est pas un jour ouvré, la date de retard de paiement est définie sur le jour ouvré suivant. Cette étape est ignorée lors de la finalisation des avoirs.
• Le compte est marqué pour vérification par le moniteur de compte débiteur dans sa date d'échéance plus le délai de grâce défini sur sa classe client. Cette étape est ignorée lors de la finalisation des avoirs.
• Si la classe client du compte indique que le compte est un client de postes non soldés, le système crée un événement de lettrage si les nouveaux montants sont décalés par d'autres transactions financières.  Pour plus d'informations sur les événements de lettrage, voir Paiements et événements de lettrage. Cette étape est ignorée lors de la finalisation des avoirs.
• La facture prend l'état Finalisé.
• Les algorithmes de post-finalisation de facture associés à la classe client du compte sont exécutés.

Si le système ne peut pas finaliser la facture (pour quelque raison que ce soit), la facture reste En attente et un message d'erreur s'affiche sur la page Facture - Principal. Dès que l'origine du problème est corrigée, tentez de nouveau de finaliser la facture.

Une facture finalisée peut être redéfinie à l'état En attente à l'aide du bouton Rouvrir figurant sur la page Facture - Principal. Il est possible de rouvrir une facture pour :

• Ajouter d'autres sections de facture à une facture finalisée.  Pour plus d'informations sur l'association des sections de facture à une facture, voir Procédures.
• Personnaliser les paiements, régularisations et corrections associés à une facture finalisée. Pour des instructions détaillées, voir Procédures.

Si vous êtes satisfait de la facture, vous pouvez de nouveau la finaliser.

Vous pouvez supprimer une facture en attente de la base de données. Vous ne pouvez pas supprimer une facture en attente si : a) des sections de facture validées sont associées à cette facture, ou b) si des transactions financières étaient associées à la facture (ce qui se produit uniquement si la facture a été finalisée au préalable).

Outre la suppression de la facture, le système supprime également les sections de facture associées à la facture.