Tout d'abord, examinons un tableau général de ce que la Oracle BRM facturation le fait :
- Compile le montant total des impacts sur le solde qui ont eu lieu au cours du mois dernier. Il peut s'agir de frais d'utilisation et d'abonnement.
- Le statut de toutes les factures associées à la facture passe de "en attente" à "ouverte", de sorte qu'elles cessent d'accumuler des frais et que des paiements puissent y être appliqués. En outre, une date d'échéance de paiement est ajoutée à la facture.
- Demande automatiquement des paiements à un organisme de traitement des cartes de crédit ou demande des paiements par l'envoi de factures.
- Met automatiquement à jour le solde du compte d'un client lorsqu'un paiement est enregistré dans la base de données BRM.
Comment cela se passe-t-il dans la pratique ?
Avant d'exécuter une facturation brm en production, il est nécessaire d'exécuter toutes les étapes préalables. La première étape consiste à préparer une copie de l'environnement de production - il peut s'agir d'un environnement de préproduction ou d'un environnement de test. Cette étape comprend l'installation de la dernière version de production sur cet environnement et la copie de la base de données de production. Ensuite, les configurations de l'environnement doivent refléter celles de la production. Voici les principales configurations qui doivent être définies de manière appropriée :
- cm ($HOME/pin/sys/cm/pin.conf),
o Vérifiez que l'entrée loglevel est réglée sur 1
o Remplacer le paramètre agent_return par 0
o Modifiez la valeur du paramètre simulate_agent en la fixant à 1
Ces deux derniers changements sont effectués de manière à ne pas impliquer d'action de provisionnement pendant le cycle de facturation.
- dm_oracle ($HOME/pin/sys/dm_oracle/pin.conf),
o Réglez le paramètre dm_bigsize sur 8388608 ou plus.
o Réglez le paramètre dm_shmsize sur 33554432 ou plus.
o Fixer dm_n_fe à 8
o Fixer dm_max_per_fe à 16
o Réglez dm_n_be sur 24
o Fixer dm_trans_be_max à 22
- pin_bill_accts ($HOME/pin/apps/pin_billd/pin.conf),
o Vérifiez le niveau du journal. Modifiez-le à la valeur appropriée en fonction de ce qui doit être vérifié pendant le test de facturation, soit 1 ou 3.
o Modifier le paramètre "enfants" pour pin_billd et pin_mta en le fixant à 5
o Modifier le paramètre per_batch pour pin_billd et pin_mta à 20000
o Modifier le paramètre fetch_size pour pin_billd et pin_mta à 150000
- pin_inv_accts ($HOME/pin/apps/pin_inv/pin.conf),
o Vérifiez le niveau du journal. Modifiez-le à la valeur appropriée en fonction de ce qui doit être vérifié pendant le test de facturation, soit 1 ou 3.
o Modifier le paramètre "enfants" pour pin_billd et pin_mta en le fixant à 5
o Modifier le paramètre per_batch pour pin_billd et pin_mta à 2000
o Modifier le paramètre fetch_size pour pin_billd et pin_mta à 15000
Pour obtenir la meilleure simulation possible de la production, le pin_virtual_time de l'exécution de factures doit être réglé sur la date à laquelle l'exécution de factures réelles sur la production sera exécutée. Une fois que cela est fait, l'exécution de la facture peut être lancée.
Nous exécutons la facturation mensuellement avec le script pin_bill_day qui crée environ 100 000 factures par heure. Le script crée des factures pour les comptes dont la date de facturation est antérieure à minuit le jour où nous exécutons la facturation. Que fait le script pin_billd_day ? Il exécute les utilitaires de facturation suivants :
- pin_deferred_act : Exécute des actions différées ; par exemple, si un compte doit devenir inactif, cet utilitaire effectue le changement d'état à la date prévue.
- pin_bill_accts : Calcule le solde dû pour les comptes et crée une facture pour le solde dû.
- pin_collect : Recouvre le solde dû pour les comptes qui utilisent des cartes de crédit et des méthodes de paiement par débit direct.
- pin_refund : Recherche les comptes qui ont des éléments de remboursement et effectue des transactions de remboursement en ligne.
- pin_inv_accts : Crée une facture pour chaque compte facturé.
- pin_cycle_fees : Applique l'impact du solde des frais d'avance de cycle sur le compte du client et annule les produits dont la date d'annulation en attente a expiré.
Pour vérifier la progression et les performances du script pin_bill_day, nous lançons des requêtes dans la base de données afin d'obtenir des informations sur le nombre de factures effectuées, le nombre de factures restant à effectuer, les erreurs éventuelles dans les factures, etc.
Une fois que la partie facturation de brm est terminée et que toutes les factures sont créées, la facturation commence. Une fois les factures créées, elles sont exportées vers des documents XML, qui sont ensuite convertis au format PDF.
Outre les requêtes mentionnées précédemment, d'autres requêtes doivent être exécutées une fois la facturation terminée, afin de vérifier l'exactitude des données générées par ce processus. Nous exécutons un lot de requêtes ; en voici quelques-unes :
- La facturation a-t-elle échoué ?
select * from billinfo_t where billing_state = 4 and bill_info_id 'Bill Unit(1)' ;
-Résultats attendus : Aucune ligne trouvée
- Y a-t-il des comptes non facturés ?
select poid_id0, first_name,last_name,a.status from account_t a, account_nameinfo_t an where
a.poid_id0=an.obj_id0 et
created_t< et
n'existe pas (select b.account_obj_id0 from bill_t b
where end_t= and
b.account_obj_id0=a.poid_id0) ;
-Résultats attendus : Aucune ligne trouvée
- Y a-t-il des projets de loi qui n'ont pas de numéro ?
select * from bill_t where end_t= and bill_no is null ;
- Attendu : Aucune ligne trouvée
Tous les problèmes constatés sont ensuite examinés et corrigés par le biais du système de contrôle des versions, où les corrections sont ensuite incluses dans la version suivante.
