Enregistrez vos documents Word directement dans SAP, en un clic
Contrats, offres, courriers : de nombreux documents sont générés depuis SAP puis finalisés dans Word. Notre Add-In permet de les renvoyer dans SAP, rattachés au bon dossier, sans quitter Word.
Le problème : un aller-retour manuel source d'erreurs
Une fois le document modifié dans Word, l'utilisateur doit l'enregistrer sur son poste, retrouver le bon objet dans SAP, puis y joindre le fichier. Une procédure fastidieuse, et des risques bien réels : pièce jointe ajoutée au mauvais dossier, ancienne version envoyée, copies qui s'accumulent sur les postes de travail.
La solution : un bouton « Sauvegarder dans SAP » dans Word
L'Add-In ajoute un groupe SAP au ruban de Word. Le document sait d'où il vient : lors de sa génération, SAP y inscrit le système et l'objet concernés, en remplaçant tout le contenu dynamique du document (comme l'adresse du client par exemple). L'utilisateur n'a donc rien à rechercher ni à saisir.
Ouvrir le panneau
Un clic sur « Sauvegarder dans SAP » dans le ruban.
Se connecter
Avec son compte SAP habituel, via "Single Sign-On"
Envoyer
Le document est joint à son objet SAP. C'est terminé.
Ce que l'Add-In fait pour vous
Rattachement automatique
Le document est joint à l'objet SAP dont il est issu, sans aucune recherche ni saisie de numéro.
Nom du fichier maîtrisé
Le nom est proposé automatiquement, à partir du document ou du modèle SAP, et reste modifiable avant l'envoi.
Gestion des versions
Si un fichier du même nom existe déjà, l'utilisateur choisit : créer une nouvelle version ou renommer. Rien n'est écrasé sans son accord.
Copie en un clic
Une copie complète du document, avec ses informations SAP, s'ouvre dans une nouvelle fenêtre : idéal pour préparer une variante.
Ne jamais écraser un document par erreur
Lorsqu'un document du même nom est déjà présent dans le dossier SAP, l'Add-In le signale clairement et propose deux choix :
- Remplacer le fichier existant, en créant une nouvelle version dans SAP ;
- Choisir un autre nom, pour conserver les deux documents.
C'est toujours la version affichée à l'écran qui est envoyée, y compris les dernières modifications.
Test ou production ? Impossible de se tromper
Chaque environnement SAP a sa couleur, et le système est rappelé en haut du panneau. Un utilisateur voit immédiatement s'il travaille sur un système de test ou sur la production.
Les couleurs sont adaptables à votre charte.
La sécurité au cœur de la conception
- Connexion standard OAuth 2.0 : l'authentification se fait directement auprès de SAP. Votre mot de passe n'est jamais saisi dans Word ni transmis à l'Add-In.
- Jeton d'accès protégé : il reste côté serveur, chiffré, et n'est jamais accessible au navigateur ni aux scripts de la page.
- Cloisonnement des systèmes : un document généré en production ne peut pas être envoyé vers un système de test, et inversement.
- Liste blanche : seuls les systèmes SAP explicitement autorisés par votre configuration sont accessibles.
- Vos droits SAP s'appliquent : l'Add-In agit au nom de l'utilisateur connecté, avec ses autorisations habituelles.
Une intégration légère dans votre infrastructure
L'Add-In s'appuie sur un petit serveur Node.js hébergé chez vous, qui fait le lien entre Word et l'API REST de SAP. Côté SAP, il utilise le serveur OAuth 2.0 standard et un service REST dédié à l'ajout de pièces jointes. Aucune donnée n'est stockée en dehors de SAP : les documents ne font que transiter.
Le déploiement auprès des utilisateurs se fait de manière centralisée, via le centre d'administration Microsoft 365.
Envie de simplifier la gestion de vos documents SAP ?
Nous adaptons l'Add-In à vos objets SAP, à vos modèles de documents et à votre infrastructure.
Contactez-nousSAP CRM data model
Le modèle de données SAP CRM que j’avais publié sur le wiki.scn.sap n’étant plus disponible, je le remets à disposition ici :
SAP AppGyver pour une application grand public ?
De nombreuses publications traitent des outils de développement Low-code / No-code pour créer des applications mobiles, et cela nous a donné envie d’essayer. Nous voulions nous rendre compte par nous-mêmes de l’effort nécessaire à la création d’une application simple, utilisable par tous, et disponible à la fois sur les plateformes iOS et Android.
Concernant la plateforme de développement, nous avons inventorié de nombreux outils tels que : Adalo, Andromo, AppGyver, AppMachine, AppSheet, Appian, Appy Pie, Bildr, Bravo Studio, Bubble, Caspio, Clutch, Cronapp, Draftbit, Drapcode, FlutterFlow, etc. Parmi ces solutions, nous avons éliminé celles qui ne permettaient pas l’hébergement des données par le prestataire de notre choix, car nous ne voulions pas que le logiciel utilisé pour développer notre application serve aussi de stockage pour nos données – restées bien à l’abri en Suisse. Ensuite le prix et la pérennité de l’éditeur ont été les principaux critères de choix, mais nous avons également étudié les possibilités de formation en ligne, la documentation, le support gratuit, les forums ainsi que les contributions de « Citizen Developers ». Finalement notre choix s’est porté sur SAP AppGyver : non pas qu’il s’agisse du meilleur outil dans tous les domaines (Nicolas a préféré Bubble, et Martial Draftbit ou FlutterFlow), mais il cochait pas mal de cases, d’autant que Swiss Computing travaille dans l’écosystème SAP depuis des années…
Pour le stockage des données c’est Google Firestore qui a été retenu, ce qui nous a permis de découvrir la manipulation des enregistrements dans une base No SQL. Mais Xano a été un véritable coup de cœur pour les habitués de bases relationnelles que nous sommes.
Une fois le choix des outils effectué, nous nous sommes vite rendu compte que la création d’une application, même très simple, requiert de l’expertise à plusieurs niveaux :
- Base de données : pour modéliser les différents objets et générer des requêtes performantes.
- Sécurité : pour gérer l’enregistrement des utilisateurs, les validations par email, les autorisations sur chaque prêt, etc.
- Développement : pour manipuler les objets JSON et envoyer des notifications via les fonctions Firebase.
- Déploiement : pour rendre l’application disponible à la fois sur Android et iOS. Si nous avons pu constater que cette étape est relativement simple pour Android puisque l’application générée par AppGyver peut être importée sur la plateforme Google Play Console, ce n’est pas vraiment la même musique sur iOS !
En conclusion : étant nous-mêmes développeurs depuis plusieurs années, au départ nous pensions réaliser ce projet en quelques jours. Finalement il nous a fallu plusieurs semaines durant lesquelles nous avons beaucoup appris… ce qui nous laisse à penser que la propagande de certains éditeurs qui promettent de créer une application en quelques clics est assez loin de la réalité, à moins de sacrifier certains aspects comme la sécurité.
Contactez-nous pour en savoir plus !
Comment réceptionner dans SAP les demandes en provenance de portails ?
Les demandes de prestations en ligne peuvent être de toutes natures (raccordement à un réseau, demande d’autorisation, de permis, de document, annonce d’incident, etc.). Ces demandes ne correspondent pas forcément à un objet SAP mais déclenchent des actions et souvent une facturation de prestation. C’est dans ce contexte que nous implémentons la demande de service comme point d’entrée des processus SAP.
La demande de service, initialement Service Request du CRM 7.0 est maintenant intégrée à S/4HANA. Créée par interface, elle nécessite une licence de transaction indirecte (c.f. Indirect Digital Access) mais les documents SAP subséquents, créés depuis ce point d’entrée, en sont dispensés.
La demande de service permet de regrouper les données récoltées et de suivre les actions jusqu’à sa clôture :
- Les données saisies sur le portail peuvent être répliquées ;
- Les sociétés et contacts du cas sont identifiés ;
- Des courriers peuvent être générés sur la base de modèles ;
- Une checklist permet de valider les étapes de traitement ;
- Les documents SAP subséquents peuvent être déclenchés, tels qu’une commande ou facture ;
- Les niveaux de services peuvent être vérifiés, le temps de travail saisi, etc.
La digitalisation des processus élimine les documents papiers et multiples e-mails. Notre réserve de travail est alors visible dans une liste de tâches. Les tâches sont représentées par une action sur un objet, par exemple, la validation sur une demande d’achat.
Contactez-nous pour en savoir plus !
L’adoption du cloud public, un challenge pour les éditeurs d’ERP
Un modèle de données collaboratif grâce au cloud public
Les ERP actuels ont été conçus pour répondre aux besoins internes de l’entreprise, avec d’un côté des clients et de l’autre des fournisseurs. Une commande entre deux sociétés est gérée sur deux ERP, une commande d’achat sur le premier et de vente sur le second.
Une application native cloud est conçue globalement, son modèle est simplifié. Une commande est représentée par un seul objet qui relie les deux contractants.
Les objets se simplifient pour correspondre aux entités réelles
|
Modélisation ERP actuel
|
Simplification Public Cloud |
|---|---|
|
Client
|
Personne physique/morale (registre du commerce)
|
| Fournisseur | Personne physique/morale |
| Collaborateur | Personne physique (ID unique) |
| Commande d’achat, de vente | Contrat entre deux personnes |
| Contrat de travail | Contrat entre deux personnes |
L’identification unique des personnes physiques et morales facilitera l’utilisation de services globaux. Les bases légales permettent maintenant aux administrations de digitaliser leurs services à la population. Les entreprises pourront bénéficier de nouvelles conditions-cadre, des services centraux et divers référentiels.
La simplification du processus d’achat/vente pourrait séduire rapidement les PME actives dans les services (et leurs fiduciaires). Une invitation à contracter sur une plateforme commune deviendrait virale.
Ce concept vous séduit, contactez-nous pour en savoir plus !