Dites le avec un dessin.

Un dessin est souvent une très bonne manière d’illustrer une idée, de faire passer un message.  Cette méthode est parfaitement applicable aux nouvelles technologies. « Draw My Innovation » permet de faire passer des message simples sur des technologies complexes. Vous en trouverez une illustration en suivant le lien ci-dessous : https://www.youtube.com/watch?v=CVQnsl7Wtbc

Pourquoi et comment vérifier le numéro de TVA intracommunautaire de ses partenaires commerciaux européens ?

Pour se protéger des risques de fraudes et d’escroqueries, ou pour vérifier les conditions d’exonération d’opérations commerciales intracommunautaires, les entreprises doivent vérifier la validité d’un numéro de TVA intracommunautaire.

Ce numéro doit obligatoirement figurer sur les factures dans le cadre d’opérations intracommunautaires pour lesquelles la TVA est auto-liquidée par le client.

Si le numéro de TVA intracommunautaire du partenaire européen est signalé comme « non valide », il est nécessaire de solliciter une attestation d’assujettissement à la TVA. Si le partenaire commercial ne fournit pas ce document, l’entreprise française n’est pas en mesure d’appliquer l’exonération de TVA liée aux opérations intracommunautaire et doit donc facturer la TVA française à son client.

La base VIES vous permet de vérifier en ligne les numéros de TVA Intracommunautaire de vos clients européens : http://ec.europa.eu/taxation_customs/vies/vieshome.do?locale=fr

Si vous nous communiquer une liste de numéro de TVA intracommunautaire, nous pouvons vérifier pour vous ces numéros. Ce travail n’excède pas une journée. Nous vous fournirons la trace de nos recherches pour alimenter vos contrôles permanents et documentés.

Nous pouvons également implémenter dans votre ERP une routine de vérification du numéro de TVA Intracommunautaire pour valider le numéro saisie. Cette routine se connecte en temps réel à la base VIES pour valider le numéro de TVA intracommunautaire que vous venez de saisir.

Traçabilité des modifications dans la base de données comptable.

La traçabilité des modifications dans certaines tables répond à des objectifs de sécurité et de reproductibilité.

Sécurité : Il est indispensable de pouvoir tracer les modifications réalisées sur certaines tables pour éviter la fraude. La donnée originale doit être sauvegardée dans son état avant modification. Ainsi, il est possible de tracer l’ensemble des modifications d’un enregistrement et d’identifier les différentes personnes qui les ont réalisées. C’est typiquement le cas des tables contenant les informations des comptes bancaires ou les tables contenant les données d’habilitation.

Reproductibilité. Le « Principe de la permanence du chemin de révision », développé dans l’article 911-3 du plan comptable général et repris par l’administration fiscale dans le cadre des contrôles des comptabilités informatisées, impose aux entreprises de pouvoir rejouer les traitements informatiques qui ont conduit à la génération d’une écriture comptable. Pour faire cela, il est indispensable de connaitre l’ensemble des valeurs des paramètres existants à la date du traitement. Il est donc nécessaire d’historiser les données des tables contenant des valeurs utilisées comme paramètre par les traitements. C’est typiquement le cas des valeurs des options de profil, des devises, des taux de change, des paramètres spécifiques, des tables de trans-codification, des jeux de valeurs, …

Avec une base de données Oracle, l’exercice est relativement simple.

D’un point de vue fonctionnel, il suffit de mettre sur chaque objet à monitorer un « mouchard » qui va identifier tous les actes de modification ou de suppression de données et sauvegarder la donnée d’origine avant sa modification ou sa suppression. Il ne faut pas plus de quelques heures de travail pour déployer ce mouchard sur l’ensemble des tables identifiés.

D’un point de vue technique, il faut :

  1. Créer une table d’historisation contenant les mêmes champs que la table d’origine et cinq champs supplémentaires (HISTORISATION_MODE (U/D), HISTORISATION_DATE, HISTORISED_BY, HISTORISED_LOGIN, HISTORISED_CONTEXT)
  2. Positionner sur la table d’origine un trigger (AFTER UPDATE OR DELETE) qui va écrire dans la table d’historisation. Les cinq champs supplémentaires sont alimentés avec les valeurs suivantes  (exemple pour Oracle E-Business Suite) :
    1. ‘U’ for Update, ‘D’ for Delete.
    2. sysdate
    3. nvl(fnd_profile. value (‘USER_ID’), -1)
    4. nvl(fnd_profile.value(‘LOGIN_ID’), -1)
    5. nvl(SYS_CONTEXT(‘USERENV’,’SESSION_USER’)||’ – ‘||SYS_CONTEXT(‘USERENV’,’HOST’)||’ – ‘||SYS_CONTEXT(‘USERENV’,’IP_ADDRESS’)||’ – ‘||SYS_CONTEXT (‘USERENV’,’OS_USER’), ‘UNKNOWN’)

La mise en place de ce « mouchard » a un impact imperceptible (pour ne pas dire aucun) sur les performances du système.

Une fois l’historisation mise en place, il est possible de tracer tous les changements et toutes les suppressions. Il devient alors possible d’exécuter un traitement avec des anciennes données et d’avoir la certitude que le résultat produit sera « Permanent ».

Dans les entreprise de grande taille, avec des supports délocalisées, ce mouchard permet également d’identifier qui est à l’origine de chacune des modifications.

La société ATTRIBUTE se propose de déployer cette fonctionnalité dans votre entreprise en une seule journée.

Les Disques SSD révolutionnent l’écriture des requêtes SQL et l’utilisation des index.

Les disques SSD se généralisent sur l’ensemble des serveurs de base de données. La particularité de ces disques est qu’ils n’y a plus de rotation du disque et plus de bras de lecture qui se déplace. Exit la mécanique. Ces disques sont en réalité de la mémoire, un peu comme une clé USB mais avec des temps d’accès beaucoup plus rapide. La base de données Oracle s’est adapté à cette nouvelle technologie ( Direct Path Read ). Reste à adapter la manière d’accéder aux données. En synthèse, il s’avère qu’il est maintenant souvent plus rapide de faire un accès complet à la table en parallèle plutôt que passer par un index.

Pour observer la différence, faite un simple test : mesurer le temps de traitement de ces deux requêtes :

La requête numéro 1 utilise l’index :
select count(*)
from GL_JE_HEADERS GJH
where GJH.PERIOD_NAME = ‘DEC-18’

La requête numéro 2 parcours toute la table en parallèle :
select /*+ FULL(GJH) PARALLEL(GJH, 32) */ count(*)
from GL_JE_HEADERS GJH
where GJH.PERIOD_NAME = ‘DEC-18’ ;

Si votre nombre de période n’est pas très important (très discriminant) la requête numéro 2 pourra s’avérer plus rapide si vous avez activé la fonctionnalité « Parallel Query ».

Bien évidement, le partitionnement et le sous-partitionnement de vos tables ( par exemple PERIOD_NAME / LEDGER_ID pour GL_JE_HEADERS ) améliorera très significativement les temps de réponse de vos requêtes et de vos traitements.

IFU – L’imprimé fiscal unique

La déclaration récapitulative des opérations sur valeurs mobilières et revenus de capitaux mobiliers doit être envoyée par voie électronique (TD-RCM ou EFI) avant le 15 février 2019.

Si vous avez pris soin de payer les jetons de présence, les dividendes avec Oracle Payables, l’établissement de votre déclaration sera grandement simplifié. L’état ART « 23200 – Payment Detail Register » vous donnera toutes les informations nécessaires à l’établissement de votre déclaration.

ART – 55 Pays déployés !

L’outil de reporting ART (Accounting Reporting Tools) est maintenant utilisé dans 55 pays, sur tous les continents. Cet outils, directement connecté à l’ERP Oracle E-Business Suite, permet aux comptables d’éditer en temps réel l’ensemble de leurs états à partir d’une solution unique. La restitution des données comptables, nativement au format Excel, apporte un gain de productivité.