XiVO Community

Bonjour,

Pour la taxation il faut vous baser sur les journaux d'appels de XiVO qui sont contenu dans la base de donnée asterisk call_log;

su - postgres
psql asterisk
SELECT * FROM call_log;

Nous n'avons pas non plus l'information de context dans cette table.
Par contre il est possible de renseigner le champs "Champ utilisateur" dans la fiche de chaque utilisateur avec cette information afin qu'elle remonte dans cette table.

Vous pouvez importer en base de donnée cette information dans le champ "userfield" de la table userfeatures.

Cordialement,

Parfait !

Il me reste à peupler le champ userfield, sinon c'est parfait !

Il serait bien de modifier un peu dans xivo-web la page "journaux d'appels" afin de pouvoir trier un peu plus finement que par date.

Et pourquoi pas enregistrer un type d'extraction et une récurrence (type cron) avec envoi du fichier par mail ...
ça serait bête de développer une application de taxation tierce alors que xivo est facilement capable de faire cela.

Par exemple, je m’intéresse uniquement aux appels sortant, qui ont été décrochés, sur une période de 1 mois, en indiquant la durée en minute:seconde, et rend le tableau plus lisible.
j'utilise cette query:
\copy (SELECT date::timestamp::date AS date, date::timestamp::time AS heure, source_name AS appelant, source_exten AS numero, destination_exten AS destination, to_char(duration, 'MI:SS') AS duree_m_s, user_field AS service FROM call_log WHERE LENGTH(destination_exten) > 7 AND duration > '1' AND date::text >= '2016-01-01' AND date::text < '2016-01-31') TO 'call_log_01_2016.csv' CSV HEADER;

Pour remarque et information (ça peut servir à quelqu'un peut-être)
je me rends compte que ma colonne:

• "source_name" contient parfois la valeur du champ "nom d'appel", mais lorsque l'utilisateur a son champ "nom d'appel : personnaliser", alors je me retrouve avec la valeur personnalisée (le numéro SDA sur 10 chiffres dans mon cas)
• "source_exten" contient le numéro de l'extension (numéro à 5 chiffres dans mon cas) mais si l'utilisateur a le champ "nom d'appel : personnaliser", alors je me retrouve encore avec la valeur personnalisée (encore et toujours le numéro SDA dans mon cas) --> des variantes donc dans le "nom d'appel" change la lisibilité du fichier à considérer et à régler selon votre convenance/préférence.

En revanche, je pense mettre à jour le champ userfield via la fonction "mise à jour à partir de fichier" dans le menu "utilisateurs", à moins qu'une requête simple me permette de le faire sur un interval de numéro précis sur la table "userfeatures".
Tu as ça sous la main Thomas ?

Merci Thomas !!!

j'suis pas "psql user", mais ça devrait être quelque chose comme ça:

dans l'exemple, je veux que le champ "userfield" de la base "userfeatures" soit égal à "dgdsi" si la colonne "entityid" est égale à "2":

INSERT INTO userfeatures (userfield) VALUES ('dgdsi') WHERE entityid='2';

je peux avoir confirmation ?

Merci !!

je me réponds tout seul ...

INSERT sert à créer une ligne ... à ne pas utiliser donc !

toujours dans mon exemple:
je veux que le champ "userfield" de la base "userfeatures" soit égal à "dgdsi" si la colonne "entityid" est égale à "2":

UPDATE userfeatures SET userfield = 'dgdsi' WHERE entityid='2';

ça marche bien, et c'est rapide !

j'ai fait du script bash simple pour extraire des tableaux de facturation depuis la table call_log.
Le premier:
on choisi l'année et le mois, et ça sort un tableau par service de taxation
Le second:
on choisi l'année, et ça sort un tableau par mois et par service de taxation + un tableau annuel par service de taxation

Si ça intéresse quelqu'un, je peux partager.

je pense fortement à faire un github pour une application web dédiée à la taxation, car cela ne semble pas être la préoccupation de avencall qui souhaite plus sous-traité à son partenaire SLIT éditeur de la solution NovaTax.

Il faut encore penser à prendre en compte les évènements suivants:

• renvoi (tous types) vers l'extérieur
• transfert (tous types) vers l'extérieur

On m'a parlé des tables call_data et call_elements sur le xivo-cc, mais je doute que ça soit les plus intéressante.

A vérifier et tester.

merci

Bonjour,

Oui cette requête est correcte, pour la rendre dynamique vous pourriez récupérer l'ID en faisant

SELECT user_id FROM linefeatures,user_line WHERE linefeatures.id = user_line.line_id and number = '1000'

Où 1000 pourrais éventuellement être un variable dans un fichier.

Ce qui donnerai :

UPDATE userfeatures set userfield = 'dgdsi' WHERE id IN (SELECT user_id FROM linefeatures,user_line WHERE linefeatures.id = user_line.line_id and number = '1000');

Où dgdsi pourrais aussi être une variable.
On aurais donc un fichier csv avec 1000,dgdsi

Le plus simple restant d'exporter les utilisateurs, ajouter le champs userfield et réimporter

Il n'est pas prévu d'apporter cette fonctionnalité de taxation sur XiVO pour le moment. Nous nous interconnectons avec des outils déjà existants (novatax).

Cordialement,

Bonjour,

je suis encore en 16.03 (et c'est si vieux).

Sur cette version, les imports massifs ne sont pas bien supporté ...
disons, souvent au delà de 20 utilisateurs, j'ai une erreur (requête trop longue).

et j'ai plus de 700 utilisateurs ^{^}

bref, j'ai bien avancé sur une interface web, ça marche pas trop mal.

Il me reste à mieux traité les conditions de transfert ... cela cause un écart entre ce que l'opérateur m’envoie et ce que je vois.
J'attends un retour de l'équipe xivo à ce sujet, via un autre chemin que le forum.

Mais je vais bientôt avoir un (ou plusieurs) serveurs supplémentaires, et cette appli aura besoin de se connecter à une seule base qui contient toutes les tables à jour de tous les serveurs.

Il va donc falloir que je mette en place un cluster pgsql.

Y'a t-il des contraintes ou "meilleures" pratiques pour mettre ça en place, sachant que j'ai un xivo-cc qui fait déjà un réplicat de la bdd asterisk ?
(mais je souhaite avoir une seule base master comprenant les bdd asterisk des 2 serveurs).

Merci