Supp E-Kenz Solution Ben Heynderickx

DEMARCHE PROJET
REFONTE DU SYSTÈME INTÉGRÉ DE GESTION SAP POUR LA

VILLE DE LUXEMBOURG
(2101034)
Reference: VdL_2101034
Date: 25/08/2021
Auteur: e-Kenz
Version: 1.0
Propriétaire du
Projet : Démarche projet Date Version
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Intellectual Property Rights and Copyright Statement
Copyright © E-KENZ S.A., 2021. All Rights Reserved.

This document contains materials, the copyright and other intellectual property rights in which are
vested in e-Kenz S.A. or which appear with the consent of the copyright owner. These materials are
made available for Ville de Luxembourg employees to review and to copy for companies own purposes.
All other commercial use is prohibited. It is not permitted to view, download, modify, copy, distribute,
transmit, store, reproduce or otherwise use, publish, licenses, transfer, sell or create derivative works (in
whatever format) from this document or any information obtained from this document otherwise than
for personal academic or other non-commercial purposes. All copyright and other proprietary notices
contained in the original material must be retained on any copy that you make. All other rights of the
copyright owner not expressly dealt with above are reserved.
2
SaaS | Cloud | Business Solutions
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Table des matières
1 Couverture du périmètre fonctionnel............................................................................................................4

1.1 Comptabilité Générale..........................................................................................................................4
1.2 Structure organisationnelle...................................................................................................................5
1.3 Données de base...................................................................................................................................6
1.4 Flux 1: Budget.......................................................................................................................................7
1.5 Flux 2: Projet.........................................................................................................................................8
1.6 Flux 3: Maintenance..............................................................................................................................9
1.7 Flux 4: Gestion des marchés................................................................................................................10
1.8 Flux 5: Stock........................................................................................................................................11
1.9 Flux 6: Factures fournisseurs...............................................................................................................12
1.10 Flux 7: Recettes clients........................................................................................................................16
1.11 Flux 8: Activités de la recette communale...........................................................................................31
1.12 Flux 9: Bâtiments.................................................................................................................................32
1.13 Flux 10: Partenaire..............................................................................................................................33
2 Couverture du périmètre technique............................................................................................................34
2.1 Infrastructure......................................................................................................................................34
2.2 Développements & Reporting.............................................................................................................35
2.3 Interfaces............................................................................................................................................36
2.4 Messagerie..........................................................................................................................................37
2.5 Documentation...................................................................................................................................38
2.6 Accès SAP, Autorisations.....................................................................................................................39
2.7 GED.....................................................................................................................................................40
2.8 Autres attentes : GDPR........................................................................................................................41
3
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1 COUVERTURE DU PÉRIMÈTRE FONCTIONNEL

e-Kenz structure cette section par ligne d’activités tel que recommandé par SAP (Comptabilité Générale,
Comptabilité Analytique, etc.). Une correspondance avec les exigences fonctionnelles de la Ville de Luxembourg
présentées dans le document « 2 Besoins techniques et fonctionnels.pdf» est ajoutée.
Chaque ligne d’activité est détaillée suivant les éléments suivants :
 Données de base / structure organisationnelle

Cette partie définira les données de base ou structures organisationnelle SAP impliquées dans les
exigences décrites.
 Best Practices SAP S/4HANA
SAP Best Practice (également connue sous le nom de SAP Rapid Deployment Solutions, SAP RDS) est
une bibliothèque de contenus normalisée pour prendre en charge les projets de mise en œuvre avec
des processus métier prêts à être exécutés. Cette partie détaillera quelle Best Practices SAP répond
aux exigences mentionnées.
 Fonctionnalités Standard SAP S/4HANA
Cette partie détaillera les fonctionnalités standard de SAP S/4 HANA, qui ne sont pas des Best Pratices.
Du paramétrage pourrait être nécessaire pour adapter la fonctionnalité aux exigences, mais pas de
développement particulier.
 Développement
Cette partie détaillera les propositions de développements pour répondre aux exigences qui ne
peuvent être mises en place via une Best Practices ou une fonctionnalité standard.
1.1 Comptabilité Générale
4
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.2 Structure organisationnelle
5
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.3 Données de base
6
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.4 Flux 1: Budget
7
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.5 Flux 2: Projet
8
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.6 Flux 3: Maintenance
9
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.7 Flux 4: Gestion des marchés
10
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.8 Flux 5: Stock
11
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.9 Flux 6: Factures fournisseurs
Description flux
Avec la comptabilité fournisseurs, vous pouvez gérer vos factures partenaire (fournisseurs) ouvertes qui sont
automatiquement créées à partir des processus d’achat ou manuellement dans la comptabilité. Le système
permet également de gérer des notes de crédit, des pièces préenregistrées …
Lors de la définition et de la configuration de la société, vous pouvez spécifier pour chaque société que le
système doit rechercher les factures en double lors de la saisie des factures. Ce contrôle évite que les factures
entrantes soient saisies accidentellement et payées plusieurs fois.
L’application de paiement permet de traiter les opérations internationales de paiement concernant vos
fournisseurs et permettra d’afficher les paiements à effectuer et de mettre en place un processus de validation
des paiements. Cette application traite en effet les postes non soldés en trois étapes :
 détermination des postes non soldés à payer et création d’une liste de propositions. Vous pouvez
traiter la liste des propositions de façon interactive. Vous pouvez notamment modifier les modes de
paiement ou les instituts bancaires, bloquer des postes ou annuler des blocages au paiement.
 exécution du paiement à l’aide de la liste des propositions. Le cycle de paiement ne prend en
considération que les postes non soldés contenus dans la liste de propositions. Le programme
comptabilise les pièces et fournit les données relatives à la création des supports de données, des avis
de paiement et des listes d’accompagnement.
 création du fichier de paiement à destination des banques, par exemple au format SEPA XML.
Il est aussi possible de gérer via le programme de paiement les domiciliations et ordres permanents.
Vous pouvez gérer et contrôler les postes non soldés à l'aide de divers outils analytiques, par exemple, pour
planifier vos dettes futures et analyser le résultat des paiements, telles que l'utilisation des escomptes et les
jours créditeurs.
Le processus de gestion des comptes fournisseurs est axé sur les activités suivantes :
 Données de base fournisseur complètes
 Saisie de facture sans bon de commande
 Préparation du paiement de la facture :
 Gérer les blocages de paiement
 Cycle de paiement :
 Calendrier des propositions de paiement
 Révision de la proposition de paiement
 Paiement sortant unique
 Paiement manuel en ligne
 Approbation du paiement
 Téléchargement de fichier de paiement
 Réinitialisation du rapprochement pour factures et paiements
 Correspondance
1.9.1 Fonctionnalités standard SAP S/4 HANA
Vous trouverez ci-dessous la liste des fonctionnalités demandées, mais étant cependant des fonctionnalités
standards SAP qu’e-Kenz veillera à activer :
12
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Numéro Description des principaux besoins Standard S/4HANA

Paiement automatique
3.8 Preparation Facture fournisseurs - S4/H Fiori
3.8.1.2 Flux des exceptions (Flux DP) Paiement automatique
Les versions VIM les plus récentes , ainsi que celles de tous les autres
3.8.2.1 Intégration VIM-PSCD
outils y attachés , doivent étrë installées
Les recommandations SAP/OpenText (SAP-IC, BusinessCenter,
…) les plus récentes doivent être prises en considération.
Analyser les étapes de validation : Implementation S/4 Hana
3.8.2.1 Flexible workflow
flexible workflow
Déterminer la faisabilité de la mise en place d’une signature
digitale de l’ordre de paiement est à analyser
Analyse de remplacement du "Bon à Payer" par la tuile "Confirm
quantity and price"
Analyse déterminer la nécessité de l’étape « Confirm quantity
3.8.2.4 and price » dans un environnement « Cloud » pour permettre Flexible workflow
cette étape en dehors du réseau VDL
Déterminer comment on peut intégrer les annexes, bons de
3.8.2.4 livraisons dans le flux des factures (cfr chapitre Attentes liées à Paiement général
la réception)
3.8 Mise en place de reporting Correspondance
integrégration SD-PSCD-FM , Développement d'une tuile
integrégration SD-
3.9.2 spécifique pour chargement de commandes SD depuis Excel
PSCD-FM
(copier/coller FKKORD1)
3.12.2 Lien depuis flux en amont PEPPOL Paiement général
3.12.2 Mise en place d'un outil de capture IC ou BCC ! Paiement général

Execution budgetaire - Les opérations qui consumment le
integrégration SD-
3.3.1.3 budget de paiement : les factures fournisseurs, les opérations
PSCD-FM
diverses FI, ordres de compensation FM
3.8.1.2 Toutes les interfaces devront créer des commandes de vente Paiement général
PSCD module supports all commonly used payment methods for incoming and outgoing payments in public
sector companies including any country-specific features.
1.9.1.1 Paiement général

Le flux de processus du programme de paiement est le suivant : les postes non soldés sont sélectionnés ;
les postes non soldés sont regroupés pour le paiement ; les articles nécessitant un traitement spécial sont
déterminé; les modes de paiement et les coordonnées bancaires sont déterminés ; la date de valeur
et la détermination du compte a lieu ; les paiements sont affichés et les supports de paiement
créé.
S i vous le souhaitez, vous pouvez exécuter un test du programme de paiement avant le
cycle de paiement. Le test crée une liste de paiement mais ne crée pas de paiement
documents.
13
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Les données de paiement et les exceptions de paiement peuvent être consultées dans la liste des paiements,
mais
ils ne peuvent pas être modifiés.
À partir des données de paiement, des supports de paiement sont créés. Des supports de paiement peuvent
être créés
sous forme électronique ou sur papier.
Le programme de cycle de paiement utilise la technique du traitement parallèle.
Vous pouvez définir un code par poste pour les exceptions (dans le programme de paiement) si un
élément doit être placé dans la liste de clarification.
Les données qui contrôlent le cycle de paiement existent dans : Données de base, document, Customizing,
paramètres du cycle de paiement en cours..
1.9.1.2 Paiement automatique

Le programme de paiement (Automatic Payment (FPY1)) est utilisé pour effectuer des paiements automatiques
et contient les actions suivantes :
Le programme de paiement est utilisé pour effectuer des paiements automatiques et contient les actions
suivantes :
 Le système détermine les postes dus. Les avoirs validés pour paiement peuvent être pris en compte
automatiquement ici.
 Les postes d'un partenaire commercial peuvent être payés en un seul total, séparément par compte
de contrat ou individuellement. Le système respecte vos règles de regroupement individuelles et tout
montant minimum défini.
 Le système détermine le mode de paiement respectif à utiliser sur la base des informations contenues
dans les comptes de contrats du partenaire. Vous pouvez définir le mode de paiement pour des
articles spécifiques sur une base individuelle. Vous pouvez proposer les modes de paiement à traiter
pour chaque cycle de paiement. Ceci est par exemple conseillé si vous souhaitez uniquement créer des
14
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
chèques de remboursement sur une base hebdomadaire mais souhaitez exécuter des notes de débit
sur une base quotidienne.
 Le système prend en charge la détermination automatique de la banque société tout en observant les
informations sur l'optimisation des paiements.
 Le système passe automatiquement les écritures pour les documents de paiement et toutes les
écritures de rapprochement et rapproche les postes qui ont été payés.
 Le système crée ensuite les supports d'édition requis (tels que les objets de données pour les banques
et les sociétés émettrices de cartes de crédit, les chèques, etc.) et les lettres d'accompagnement et les
avis de paiement. En plus du paiement des factures et des avoirs, le système permet également de
traiter automatiquement les montants des factures budgétaires et d'effectuer des remboursements à
partir de la liste de travail de clarification ou des acomptes. Les clients qui utilisent la méthode de
collecte bancaire peuvent être récompensés pour le faire.
 La liste de clarification de crédit traitera et permettra de maintenir toutes les exceptions
Pour la gestion des factures fournisseurs, nous envisageons l’implémentation de la solution SAP VIM aussi
connue sous le nom de VIM (Vendor Invoice Management). A cette solution peut s'ajouter une solution d'OCR
des factures garantissant les demandes de performances de la Chambre des Députés.
Les flux présentés décrivent la solution complète avec OCR, mais celui-ci est optionnel (suivant la demande de
la Chambre des Députés).
Les principaux avantages de cette solution sont :

 Réduire le temps de saisie de la facture
 Faciliter la communication
 Réduire le temps de traitement d’une facture
 Améliorer le cash-flow en profitant des escomptes.
15
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Etapes clés du flux

 Import de la facture (Scan ou fichier)
 Transformation (OCR ou Correspondance des champs)
 Vérification et complétion
 Gestion et résolution des exceptions
 Validation de la facture
 Transfer et créer des écritures comptables dans PSCD
 La facture est alors prête pour le paiement dans PSCD
Les factures peuvent être scannées, importée à partir d’un fichier PDF, d’un fichier XML ou d’autres format.
Pour le scenario des factures scannées, un OCR performant permet d’interpréter les principales informations
de la facture.
La reconnaissance des informations est complexe, mais est prise en compte par VIM.
16
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
 Afin de décaisser les factures provenant du processus VIM/OCR une intégration vers PSCD est
nécessaire.
 Dans cette solution la position de SAP PSCD, et particulièrement autour du rôle centralisé du
partenaire, ce ne sont plus les documents qui seront postés vers SAP AP (Vendors) mais au
contraire, seront postés sur les partenaires concernés.
 Ce processus personnalisé sera transféré aux écritures de crédit ouvert vers PSCD. Le module z
existant pour transférer les articles sera réutilisé, mais sera réévalué vers S4Hana
1.9.1.4 Correspondance
Public Sector Collection and Disbursements ( PSCD), les possibilités d'impression sont centralisées autour d'un
mécanisme vendu et à volume élevé et offre un degré élevé de fonctionnalité and S/4HANA permet l’exécution
de nombreux rapport
 impression des listes sortantes
 écritures sortantes d'exception
 document comptable
 relance
 projet de loi du secteur public
 facture FI-CA
 Avis de radiation
 relevé de compte
 Information sur le compte
Avec S/4HANA en version on premise, SAP a apporté de nombreuses innovations dans le domaine d'activité des
achats notamment les workflows flexibles pour les demandes d'achat, les factures fournisseurs et les bons de
commande.
Les worklows flexibles permettent de répondre aux exigences de la Chambre des Députés en termes d’étapes
d’approbations et de notifications. Les fonctionnalités des workflows flexibles sont les suivantes:
 Le workflow flexible est un workflow flexible basé sur un scénario qui peut avoir plusieurs conditions
de démarrage
 A la possibilité de déterminer les approbateurs à travers de nombreuses options différentes
 A une option pour spécifier sous quelle condition l'étape de workflow flexible doit-elle être déclenchée
/ applicable
 Peut être configuré à l'aide d'une application Fiori et une action d'approbation peut être effectuée à
partir de l'application Fiori
 Prend en charge les notifications push Fiori 2.0
Il est possible de créer plusieurs scénarios de workflow flexibles pour un document d‘achat plutôt que de faire
un seul et workflow flexible complexe.
17
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
18
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.10 Flux 7: Recettes clients
1.10.1 Description Recettes clients
Avec la comptabilité clients, vous gérez les factures clients ouvertes qui sont automatiquement créées à partir
des processus de vente ou manuellement dans la comptabilité. Vous gérez et contrôlez les postes non soldés
avec divers outils d'analyse pour optimiser le traitement des comptes clients.
Les relevés de banque entrants chargés dans le processus de gestion de trésorerie constituent la principale
source de paiements entrants. Ils peuvent être automatiquement rapprochés avec les factures en cours. Des
vues faciles à utiliser rendent le post-traitement des éléments ouverts pratique et efficace.
Vous pouvez également enregistrer manuellement les paiements entrants et rapprocher facilement le
paiement d'une position ouverte. Plusieurs outils analytiques sont disponibles pour surveiller les créances, ce
qui vous permet de réagir rapidement si vous découvrez une discipline de paiement en déclin chez vos clients.
Vous pouvez facilement créer des lettres de relance pour les positions en retard et suivre l'historique de
relance de vos clients.
Avantages métiers
 Intégrer les comptes clients dans la gestion des ventes

 Enregistrement des écritures de comptes à recevoir directement dans PSCD
 Fournir une analyse plus détaillée des comptes partenaire / débiteurs
 Traiter facilement la relance des articles en retard
Etapes clés du flux
 Analyser les positions ouvertes

 Rapprocher automatiquement les factures en cours avec les paiements entrants
 Traiter les encaissements non affectés pour ouvrir les factures facilement et efficacement
 Analyser l'efficacité du traitement de la collecte des paiements
Information supplémentaire
Etant donné que le client n’a pas d’exigences particulières concernant la comptabilité des tiers clients, seules
les fonctionnalités de base présentes dans le flux Best Practices présenté ci-dessus seront mises en place. Ceci
permettra à le client de comptabiliser, rapprocher et suivre les éventuelles comptabilisations sur tiers clients.
1.10.2 Fonctionnalités standard SAP S/4 HANA
Vous trouverez ci-dessous la liste des fonctionnalités demandées, mais étant cependant des fonctionnalités
standards SAP qu’e-Kenz veillera à activer :
19
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Standard
Numéro Description des principaux besoins
S/4HANA
3.9.1 Mise en place des transactions standards dans le GUI et dans Fiori, comme PSCD concept
décrit dans le cahier des charges
3.9.2 Analyser et propose les tarifs suivant le règlement taxe, les décisions du C.E., Intégration SD -
les conventions, Dériver automatiquement les données budgétaires PSCD-FM
3.9.2 Realiser des statistiques plus fines Comptabilité a
PSCD
3.9.2 Passer par un schéma de prix pour déterminer les différents éléments de tarif Intégration SD -
(TTC, HTVA, montant négatif, bonification) PSCD-FM
3.9.2 Utiliser plusieurs textes différents (en-tête, poste) pour mieux communiquer Correspondance
aux différents interlocuteurs, Utilisation de BRF+ pour les impressions
3.9.2 Gérer des acomptes Comptabilité a
PSCD
3.9.2 Gérer un calendrier de facturation permettant d’émettre des propositions de PSCD concept
factures automatiquement. Le service Seniors l’utilise par exemple pour les
contrats Digifon
3.1.1.2.1 Pouvoir gérer des partenaires différents dans un document de vente Comptabilité a
(donneur d’ordre, facturé, payeur) PSCD
3.9.2.1 Réduction des différents formats d’interfaces (grâce à l’outil de gestion PSCD concept
intégrée des interfaces)
3.9.2.1 Analyser une interface de saisie manuelle rapide, sous Excel reste envisagée PSCD concept
3.9.2.2 PSCD général configuration tarifs et prix Comptabilité a

PSCD
3.9.2.3 Replacement la déclaration de recette et la remplacer par une nouvelle PSCD concept
logique de validation
3.9.2.3 Maintenier le titre de recette avec plusieurs élément PSCD concept
3.9.2.3 Analyser la possibilité d'avoir d'une facture pro-forma PSCD concept
3.9.2.4 Formulaires Correspondance
3.9.2.4 Mise en place d'un dispositif de validation des commandes Comptabilité a

PSCD
1.10.2.1 PSCD concept

Le module de collecte et de décaissement du secteur public (Public Sector collection and disbursement ,PSCD)
prend en charge toutes les méthodes de paiement couramment utilisées pour les entrées et les sorties dans les
entreprises du secteur public, y compris toutes les fonctionnalités spécifiques au pays. Dans ce module, la
notion de partenaire commercial en tant qu'entité centrale est essentielle et contient toutes les
caractéristiques vis-à-vis de la relation client.
Le processus principal consiste à enregistrer et à comptabiliser le poste débiteur non soldé du partenaire
commercial/client, à collecter et traiter le relevé bancaire et à apurer le ou les postes non soldés
conformément aux règles commerciales.
20
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.10.2.2 Compatibilité a PSCD
Les écritures sont généralement générées automatiquement par les processus commerciaux correspondants
dans PSCD ou par la facturation. Des options supplémentaires pour le transfert automatique de données sont
décrites dans le « Concept d'interface » de ce document. Les documents peuvent également être enregistrés
manuellement. La fonction de détermination des comptes peut être utilisée pour déterminer
automatiquement les comptes généraux et proposer des échéances à l'aide des conditions de paiement dans le
compte de contrat.
Un FI-CA document est généré pour chaque écriture.
Il y aura 3 options possibles pour poster un document comptable:
 Affichage direct dans PSCD, L'application PSCD Fiori standard « poster le document dans PSCD » sera
utilisée
 Intégration SD -PSCD-FM (chapitre Intégration SD – PSCD- FM)
 Publication via une interface externe (Interface générique pour faciliter les systèmes externes )
1.10.2.3 Intégration SD -PSCD-FM
De plus, les documents SD sont enregistrés dans FICA en tant que postes non soldés et sont ensuite
pris en compte au moment de la facturation au client (ISU) pour la tenue du compte et pour l'ajout
d'autres postes de débit, cela dépendra encore une fois de vos paramètres de facturation.
tout dépend des paramètres que vous avez définis pour le nœud d'intégration dans les comptes
clients et fournisseurs sous SPRO.
21
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Comme indiqué par le projet de loi-événement 4000 a le point de départ pour le transfert à PSCD /
FICA.
Lors de la saisie d'une commande SD, vous devez sélectionner un compte de contrat. Ce compte de
contrat doit être affecté au partenaire FI-CA. S'il n'y a qu'un seul compte contrat pour le payeur, ce
compte contrat est automatiquement transféré à la commande.
1.10.3 Paiement / retour traitement des lots /(Payment Lots/ return lot processing)
 Les lots de paiement regroupent des paiements ayant une origine commune ou devant être traités
collectivement. Ils contiennent des données sur l'origine du paiement et la note au bénéficiaire. Il
existe trois principaux types de lots :
 Les données de chèques entrants sont saisies manuellement dans un lot de chèques.
22
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
 Les paiements par carte de crédit sont soit saisis manuellement, soit saisis dans un lot de cartes de
crédit via une interface.
 Les virements entrants peuvent être transférés manuellement, par une interface, ou en utilisant un
virement du relevé bancaire électronique vers un lot de paiement.
 Les lots sont traités une fois les données saisies. Les paiements sont affectés automatiquement aux
postes non soldés à l'aide de règles spécifiques à l'entreprise. Les éléments qui ont été affectés sont
automatiquement effacés. Les trop-payés peuvent être comptabilisés en tant qu'acomptes et les
moins-payés peuvent être comptabilisés en tant que paiements partiels.
1.10.4 Clearing / (Open items can be cleared by various processes):
 Lors de la comptabilisation d'un titre de paiement

 Par le cycle de paiement
 Lors du traitement des lots de paiement
 A la caisse
 Lors de la facturation (si les montants de facturation budgétaire qui ont déjà été payés sont
compensés lors de la facturation ou si la tenue de compte automatique est déclenchée à partir de la
facturation)
 Lors de la maintenance automatique du compte
 Lors de la maintenance manuelle du compte
Le cycle de paiement (FPY1) est basé sur les articles qui sont dus, à payer ou prêts à être collectés. Dans ces
situations, le titre de paiement est automatiquement lié au poste, ce qui rapproche le poste. Les montants de
facturation budgétaire qui ont déjà été payés sont reconnus et automatiquement compensés par le système
lors de la facturation. PSCD contient également un contrôle de compensation pour des processus
supplémentaires, qui peuvent être utilisés pour représenter la stratégie de compensation utilisée par votre
organisation de manière flexible. Le contrôle de la compensation peut être défini différemment selon le
compte de contrat et l'opération commerciale concernés. Lors de l'affectation des encaissements, l'objectif est
de déterminer le plus précisément possible le billet au bénéficiaire du paiement. Toutes les spécifications faites
par le client sont traitées. Des règles spécifiques à l'industrie et à l'entreprise peuvent également être
appliquées. (Si, par exemple, la note au bénéficiaire est manquante, le paiement des créances en conjonction
avec un type de contrat spécifique peut prévaloir sur d'autres créances ou le montant du paiement peut être
réparti entre plusieurs créances.) postes d'un compte de contrats déjà saisis. L'affectation des éléments une
fois le montant convenu n'est pas significative. La manière dont les éléments d'avoir et les créances doivent
être rapprochés mutuellement dans des limites spécifiques (telles que la société ou au sein d'une division) est
d'un intérêt bien plus important. Cela peut conduire à un éclaircissement partiel. Lors du traitement du
dialogue (par exemple, à la caisse ou pour la gestion manuelle des comptes), les règles de contrôle de la
compensation signifient que même si le système propose des postes pour la compensation, vous pouvez
23
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
prendre une décision alternative. Vous pouvez suggérer que les créances d'une division spécifique ou les
créances plus anciennes soient prioritaires.
Returns Processing
Les retours peuvent apparaître dans les notes de débit et les procédures de recouvrement, les dépôts de
chèques ou les paiements. Les retours sont regroupés en lots de retours. Ces lots peuvent être créés
manuellement sur la base des documents de retour ou automatiquement en transférant les données de retour
de la banque. Les retours sont ensuite traités automatiquement comme suit :
 La compensation de paiement est annulée. Cela signifie que les créances ou les dettes rapprochées par
la note de débit deviennent alors des postes non soldés.
 Un document de retour est créé qui contient des écritures de contrepartie pour les postes du
document de paiement. Ces deux documents ont un solde collectif de zéro.
 Des écritures supplémentaires sont générées qui sont nécessaires en raison des frais de dépenses et
des taxes incluses.
 Les frais bancaires et les frais internes supplémentaires sont inscrits sur la facture au partenaire
commercial
Clearing / (Clarification Processing)

Le traitement de clarification permet des situations exceptionnelles qui peuvent survenir lors du traitement des
paiements entrants et sortants, des retours et des soldes créditeurs, afin qu'ils puissent être traités
efficacement. Les situations exceptionnelles suivantes peuvent survenir :
 Une note au bénéficiaire est disponible pour un encaissement, auquel aucun poste non soldé ne peut
être affecté.
 Une échéance ne peut pas être réglée par le programme de paiement puisqu'un blocage de paiement
a été
effecté au compte de contrats.
 Un client a effectué un trop-payé ou un acompte.
 Les retours avec un motif spécifique doivent toujours être traités manuellement.
Le système exécute toujours les entrées dans la réserve de travail de clarification si l'opération commerciale ne
peut pas être traitée manuellement ou si le traitement manuel est explicitement demandé dans une situation
spécifique. Les utilisateurs responsables des cas de clarification peuvent être déterminés automatiquement à
l'aide de la structure organisationnelle. Vous pouvez également réserver un cas de clarification pour un
utilisateur spécifique, ce qui signifie qu'il est bloqué pour le traitement par d'autres utilisateurs (cela peut être
une restriction de temps). Vous pouvez supprimer le blocage à tout moment. Les cas de clarification peuvent
également être transférés entre les utilisateurs. Différentes actions sont disponibles dans le système en
fonction du type de cas de clarification concerné. Les paiements entrants à clarifier peuvent être affectés à un
poste non soldé dans la boîte de dialogue, débités ou marqués pour remboursement. Le système prend
également en charge la clarification des montants partiels. Lors de la clarification du solde créditeur, vous
pouvez transférer le montant qui sera clarifié au partenaire, le marquer pour le suivi, le rapprocher ou le
republier.
24
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Relance / Dunning
Les partenaires commerciaux sont informés des échéances (en retard) par des rappels de paiement ou des
relances. Le système utilise le programme de relance pour surveiller le comportement de paiement des clients
et lancer les activités requises. La procédure de relance respective joue un rôle central lors de la relance. Il
contrôle la date de début du processus de relance, le nombre de niveaux de relance et les exigences du niveau
de relance respectif. Un exemple de ce type d'exigence est l'intervalle de relance, qui définit la durée entre les
rappels. Cela signifie que vous pouvez éviter d'envoyer à un partenaire trop de rappels de relance en
succession rapide.
Vous définissez les actions à exécuter par le système pour chaque niveau de relance. Les activités de relance
suivantes sont disponibles en standard :
 Créer une relance
 Créer un relevé bancaire
 Créer un document de blocage
 Demander un dépôt de garantie en espèces
 Désactiver le plan de versement
 Remettre la ou les créances à l'agence de recouvrement
Vous pouvez définir toutes les activités de relance supplémentaires requises, telles que celles requises pour
répondre aux exigences de relance légales. Vous pouvez déterminer la limite de montant à partir de laquelle la
relance doit commencer. Les frais peuvent être calculés automatiquement en fonction de vos besoins et
enregistrés dans le grand livre ou simplement créés sous forme d'écritures statistiques. Les intérêts peuvent
être calculés automatiquement pour les articles. La procédure de relance est enregistrée au niveau du compte
de contrat. Vous pouvez remplacer des éléments individuels et exclure temporairement l'élément ou le compte
de la relance. En plus des créances standard, vous pouvez effectuer une relance pour d'autres postes, tels que
les demandes de facturation budgétaire et les postes de plan de versements. Vous pouvez contrôler quels
postes sont relancés collectivement en fonction des besoins de votre entreprise en définissant des groupes de
relance en conséquence. Cela signifie que vous pouvez vous assurer qu'une relance distincte est créée pour
chaque contrat ou division.
Pour garantir que vous disposez d'instructions sur les activités de relance exécutées à n'importe quelle étape,
les données de relance sont répertoriées dans l'historique de relance. Des propositions de relance spécifiques
ou un cycle de relance complet peuvent être annulés si nécessaire (par exemple, si un client dépose une
réclamation). Cela annule les frais de relance et les activités de relance spécifiques (telles que la remise à une
agence de recouvrement ou le blocage de l'appareil).
25
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Mise en place du suivi des étapes de recouvrement (debt recovery

management comparable avec FSCM / Collection
Le module PSCD permet de remettre les objets à une agence de recouvrement externe en cas d'échec de la
relance et vous assiste lors des processus ultérieurs. Cela implique les fonctions suivantes ::
 Libérer les éléments pour remise à une agence de recouvrement La libération automatique peut avoir
lieu à partir des processus de relance ou d'imputation précédents. Vous pouvez également libérer des
articles manuellement.
 Détermination flexible de l'agence de recouvrement responsable
 Saisie automatique des encaissements de l'agence de recouvrement. Cela comprend la cession des
créances associées et la saisie automatique des intérêts et des frais, y compris toutes les écritures
pertinentes. Si les écritures sont totalement ou partiellement irrécouvrables, les montants
correspondants peuvent être automatiquement amortis. Les offres PSCD prennent en charge
l'échange électronique de données avec les agences de recouvrement.
La communication suivante est possible :

 Transférer les modifications apportées aux données de base (comme une modification de l'adresse du
partenaire)
 Rapports des paiements de l'agence de recouvrement, y compris les intérêts et les frais Étant donné
que le système répertorie toutes les étapes de traitement d'un article, vous avez la possibilité de créer
des évaluations détaillées à tout moment (afin de vérifier l'efficacité de votre agence de
recouvrement).
.
1.10.4.1 Correspondence
La correspondance avec vos partenaires commerciaux peut être contrôlée par des événements standard dans
PSCD (par exemple lors de la relance) ou peut être créée périodiquement (extraits de compte). Le système vous
permet également de demander une correspondance unique (telle qu'un reçu ou des informations de compte).
Des formulaires standard sont disponibles pour chaque type correspondant que vous pouvez modifier pour
répondre à vos besoins. Les lettres suivantes sont disponibles
 Notification de solde /(Balance notification)

 Relance / Dunning notice
 Lettre sur les accords de paiement échelonné / (Letter about instalment payment agreements)
26
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
 Imprimer l'avis de retour (Print returns notice)

 Lettre de calcul des intérêts / (Interest calculation letter)
 Notification de clarification de crédit / (Notification about credit clarification)
 Notification about incoming payments and payment usage
 Confirmation of changes made to the master data
 Reçu pour un paiement en caisse , (Receipt for a cash-desk payment)
 Relevé bancaire / (Bank statement)
SIGNALER CE PARAMÈTRES DE CONFIDENTIALITÉ

Vous pouvez joindre un formulaire de paiement à la correspondance qui demande le paiement
automatiquement. Le système offre également des options flexibles pour déterminer le destinataire de la
correspondance ou enregistrer des destinataires de correspondance supplémentaires. Vous pouvez définir
différentes adresses pour différents types de correspondance.
Rapprocher les comptes clients et fournisseurs de contrats avec le grand livre
Compte tenu des volumes importants de documents, les chiffres de vente ne sont pas mis à jour
consécutivement dans le grand livre lors de la comptabilisation dans PSCD. Au lieu de cela, les documents FICA
sont résumés sous forme de comptes rendus sommaires. Ceux-ci sont périodiquement transférés au grand livre
dans la composante Comptabilité financière FI ou dans un système externe. Cela améliore les performances et
réduit les volumes de documents dans le grand livre. La clé de rapprochement relie le grand livre au grand livre
auxiliaire. Il permet de détailler les montants imputés au grand livre et d'effectuer le rapprochement entre le
PSCD et le grand livre.
Caisse et journal de caisse / Cash Desk and Cash Journal

Les fonctions de caisse sont utilisées pour saisir les paiements entrants et sortants dans le traitement du
dialogue avec les clients. En plus des paiements en espèces, des méthodes de paiement par carte de crédit,
chèque et mandat postal sont également disponibles. Les articles à payer peuvent être déterminés
automatiquement par le système. Ils peuvent également être attribués par l'utilisateur (en accord avec le
client). Des acomptes ou des paiements partiels pour divers articles sont également possibles. Le système crée
tous les documents requis (tels que des chèques ou des reçus). La caisse est intégrée au journal de caisse et
peut être implémentée avec ou sans le journal de caisse. Si le journal de caisse est utilisé, des fonctions
supplémentaires sont disponibles et sont décrites dans les sections suivantes.
27
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.11 Flux 8: Activités de la recette communale
28
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.12 Flux 9: Bâtiments
29
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
1.13 Flux 10: Partenaire
Vous trouverez ci-dessous la liste des données de base SAP S/4HANA répondant à vos besoins métiers :
Numéro Description des principaux besoins Standard SAP
Création de fiches fournisseur Business Partenaire

2.3 Aura comme données requises pour la création des fournisseurs :
 Nom et adresse du fournisseur ;
 Personne de contact auprès du fournisseur (nom et prénom ;
nom du service auquel appartient le contact ; téléphone ; GSM
(mobile) ; fax ; email) ;
Business Partenaire
 Coordonnées bancaires du fournisseur ;
 Numéro de TVA ;
 Délais de paiement (ex. 30 F) ;
 Adresse internet
 Champ libre pour complément d’informations.
2.4 Permettra, si possible, de classer des fournisseurs et de les gérer dans
Business Partenaire
le logiciel via une notion de catégorie ou de groupe.
2.5 Permettra que les fonctionnaires, employés, salariés,
étudiants/stagiaires, députés ainsi que le Président de la Chambre
des Députés, les Présidents des groupes politiques, les coordinateurs Business Partenaire
des groupes techniques les groupes et sensibilités politiques puissent
être créés comme des fournisseurs.
2.8 Permettra la mise à jour automatique de la liste des fournisseurs
Business Partenaire
après modification des fournisseurs.
1.13.1.1 Business partenaire

Le partenaire commercial ou business partenaire permet d’unifier la gestion des données de base en
fusionnant les fiches tiers (clients, fournisseurs, employés...) dans un seul référentiel, tout en gardant la notion
de rôles dans les processus métiers.
Les types de business partenaires suivants sont définis dans SAP S/4HANA :
 Type de partenaire client : Un client est un partenaire commercial avec lequel vous échangez des biens
et des services.
 Type de partenaire fournisseur : Un fournisseur est un partenaire commercial auprès duquel des biens
et services peuvent être achetés ou bien des paiements effectués. Les fournisseurs peuvent être des
sociétés, associations, particuliers …
 Autres types de partenaires : Une personne de contact est un exemple d'un autre partenaire
commercial dans le système ERP.
Les business partenaires remplissent différentes fonctions, décrites comme des fonctions de partenaire, en
relation avec votre organisme. Les fonctions de partenaire son utilisées pour définir les droits et les
responsabilités de chaque type de partenaire dans une transaction commerciale. Lorsque vous vendez ou
commandez des marchandises, par exemple, vos partenaires commerciaux peuvent assumer des fonctions de
partenaire telles que :
Fonction Partenaire Client Fonction Partenaire Fournisseur
Donneur d’ordre Adresse de commande
Réceptionnaire marchandise Fournisseur
Destinataire facture Auteur de la facture
Payeur
30
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Différents partenaires commerciaux peuvent exécuter une ou plusieurs fonctions partenaires. Pour cette
raison, vous pouvez affecter des partenaires individuels à un certain nombre de fonctions partenaire.
De plus, il existe une classification affectée à un partenaire lors de sa création appelée « regroupement de
partenaires ». Ce regroupement permet d’attribuer des tranches de numéros distinctes.
Vous saisissez des données sur les partenaires avec lesquels votre société entretient une relation commerciale
dans des fiches. Les fiches contiennent toutes les données nécessaires au traitement des transactions
commerciales (comptabilité et la logistique). Ceci est appelé données de base. Il est possible grâce au
paramétrage de rendre des informations obligatoires à la saisie d’une nouvelle fiche de business partenaire.
Vous pouvez créer et modifier des fiches à l'aide de groupes de données dont le niveau de détail diffère. Les
fiches principales des partenaires clients ou fournisseurs ont les structures suivantes :
Donnée de base Rôle = client Donnée de base Rôle = fournisseur
Donnée Générale (General Data)
31
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Les données générales ne dépendent pas de la société, de l'organisation de vente et de distribution ni de

l'organisation des achats. Les données générales s'appliquent à un partenaire pour toutes les sociétés et pour
tous les domaines de vente et organisations d'achats. Elles comprennent entre autres :
 Nom de la société / personne
 Adresse
 Informations de contact comme le n° de téléphone, fax, e-mail …
 Coordonnées bancaires
 Identifiants de sociétés (registre du commerce, n° TVA national, n° TVA intracommunautaire, …)
Donnée société (Company Code Data)
Les données de société ne s'appliquent qu'à une seule société. Ces données ne concernent que la comptabilité
financière et comprennent par exemple :
 Données de gestion de compte
 Mode de paiement
 Conditions de paiement
Données d'organisation d'achat (Purchasing organization data)
Les données d'un fournisseur peuvent différer pour chaque organisation d'achats. Ces données ne concernent
que les achats et comprennent :
 Données d'achat
 Fonctions partenaires pour les achats
Les mises à jour de données des business partenaires sont synchrones dans la base de données, c’est-à-dire
que les modifications effectuées (et si besoin validées) sont immédiatement visibles dans les données de base
ou les rapports.
1.13.2 Best Practices S/4 Hana
Vous trouverez ci-dessous la liste des solutions complètes proposées par SAP S/4HANA Best Practices retenues
afin de couvrir les exigences de la Chambre des Députés concernant la comptabilité des tiers clients et
fournisseurs.
Ligne d’activité Best Practice Résumé

Cette solution vous aide dans la gestion de vos factures
Comptabilité Comptabilité business partenaire
ouvertes payables créées automatiquement à partir de
Générale avec le rôle fournisseurs
vos processus d'achat.
Cette solution vous aide dans la gestion de vos factures
Comptabilité Comptabilité business partenaire
de créances ouvertes créées automatiquement à partir
Générale avec le rôle clients
de vos processus de vente.
Vous trouverez ci-dessous l’association de vos principaux besoins aux Best Practices SAP S/4HANA relatifs à la
comptabilité des tiers Fournisseurs et Clients :
32
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2 COUVERTURE DU PÉRIMÈTRE TECHNIQUE
2.1 Infrastructure
33
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.2 Développements & Reporting
34
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.3 Interfaces
35
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.4 Messagerie
36
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.5 Documentation
37
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.6 Accès SAP, Autorisations
38
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.7 GED
39
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
2.8 Autres attentes : GDPR
40
Contern, Luxembourg
Propriétaire du
document
Ref : VdL_2101034 25/08/2021 e-Kenz 1.0
Business Solutions | Support Center | Cloud

e-Kenz S.A.
www.e-Kenz.lu Z.A. ‘Weiergewan’
2, rue Edmond Reuter
linkedin.com/company/e-Kenz-s.a.
L-5326 Contern
27 35 37 - 1
41
Contern, Luxembourg

Supp E-Kenz Solution Ben Heynderickx

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Supp E-Kenz Solution Ben Heynderickx

Transféré par

Droits d'auteur :

Formats disponibles

DEMARCHE PROJET

REFONTE DU SYSTÈME INTÉGRÉ DE GESTION SAP POUR LA

Intellectual Property Rights and Copyright Statement

Copyright © E-KENZ S.A., 2021. All Rights Reserved.

Table des matières

1 Couverture du périmètre fonctionnel............................................................................................................4

1 COUVERTURE DU PÉRIMÈTRE FONCTIONNEL

Chaque ligne d’activité est détaillée suivant les éléments suivants :

 Données de base / structure organisationnelle

1.1 Comptabilité Générale

1.2 Structure organisationnelle

1.3 Données de base

1.4 Flux 1: Budget

1.5 Flux 2: Projet

1.6 Flux 3: Maintenance

1.7 Flux 4: Gestion des marchés

1.8 Flux 5: Stock

1.9 Flux 6: Factures fournisseurs

1.9.1 Fonctionnalités standard SAP S/4 HANA

Numéro Description des principaux besoins Standard S/4HANA

3.8.1.2 Flux des exceptions (Flux DP) Paiement automatique

3.12.2 Mise en place d'un outil de capture IC ou BCC ! Paiement général

1.9.1.1 Paiement général

1.9.1.2 Paiement automatique

1.9.1.3 Intégration VIM-PSCD

Les principaux avantages de cette solution sont :

Etapes clés du flux

1.9.1.5 Flexible workflow

1.10 Flux 7: Recettes clients

1.10.1 Description Recettes clients

 Intégrer les comptes clients dans la gestion des ventes

Etapes clés du flux

 Analyser les positions ouvertes

1.10.2 Fonctionnalités standard SAP S/4 HANA

3.9.2.2 PSCD général configuration tarifs et prix Comptabilité a

3.9.2.3 Analyser la possibilité d'avoir d'une facture pro-forma PSCD concept

3.9.2.4 Formulaires Correspondance

3.9.2.4 Mise en place d'un dispositif de validation des commandes Comptabilité a

1.10.2.1 PSCD concept

1.10.2.2 Compatibilité a PSCD

Un FI-CA document est généré pour chaque écriture.

Il y aura 3 options possibles pour poster un document comptable:

1.10.2.3 Intégration SD -PSCD-FM

1.10.4 Clearing / (Open items can be cleared by various processes):

 Lors de la comptabilisation d'un titre de paiement

Clearing / (Clarification Processing)

Mise en place du suivi des étapes de recouvrement (debt recovery

La communication suivante est possible :

 Notification de solde /(Balance notification)

 Imprimer l'avis de retour (Print returns notice)

SIGNALER CE PARAMÈTRES DE CONFIDENTIALITÉ

Rapprocher les comptes clients et fournisseurs de contrats avec le grand livre

Caisse et journal de caisse / Cash Desk and Cash Journal

1.11 Flux 8: Activités de la recette communale

1.12 Flux 9: Bâtiments

1.13 Flux 10: Partenaire

Numéro Description des principaux besoins Standard SAP

Création de fiches fournisseur Business Partenaire

1.13.1.1 Business partenaire

Donnée de base Rôle = client Donnée de base Rôle = fournisseur

Donnée Générale (General Data)

Les données générales ne dépendent pas de la société, de l'organisation de vente et de distribution ni de

1.13.2 Best Practices S/4 Hana