Améliorations fonctionnelles
API
| Pour les endpoints permettant de récupérer les prestations et les primes d'un contrat, un paramètre de requête "orderby" a été ajouté afin que vous puissiez déterminer vous-même l'ordre. Avec cette version, il est seulement possible de trier selon l'id (ascendant et descendant). Ainsi, avec le paramètre "pagination" déjà existant, vous pouvez déterminer si les données les plus récentes ou les plus anciennes sont récupérées. De cette façon, le paramètre peut être utilisé. Le plus récent en premier :
Le plus ancien en premier : {{url}}/webservice/integration/employmentcontract/:employmentcontractid/performances?orderby=id.asc {{url}}/webservice/integration/employmentcontract/:employmentcontractid/premiums?orderby=id.asc {{url}}/webservice/integration/employmentcontract/:employmentcontractid/performances?orderby=id {{url}}/webservice/integration/employmentcontract/:employmentcontractid/premiums?orderby=id
|
| Les endpoints pour créer ou modifier un régime de travail du client des codes de Pratoflex sont attendus pour le RTT payant. Comme les codes sont différents pour l'ancien et le nouvel écran de contrat (redesign), nous les avons énumérés. L'API se chargera elle-même de la traduction vers les codes internes, en fonction de l'écran de contrat activé.
Les valeurs possibles de l'enum sont : worktimereductionfulltime (string) = ['paid', 'unpaid', 'no_reduction', 'paid_and_unpaid'] worktimereductionparttime (string) = ['paid', 'unpaid', 'no_reduction', 'paid_and_unpaid']
Ce changement est un changement radical pour l'API. Veuillez informer votre constructeur ou intégrateur de site web de ce changement (Au moment de la création des RN, l'endpoint n'était pas encore utilisé). |
| Le nouvel endpoint pour récupérer les contrats (GET {{url}}/webservice/integration/employmentcontract/:employmentcontractid) a été modifié de sorte que dorénavant il récupère également les contrats à durée indéterminée et les contrats qui durent plus d'une semaine. Dans PratoFlex, ce sont les contrats master.
La différence avec la version précédente du GET est que désormais, plusieurs instances de l'attribut Annex seront renvoyées.
|
| Le nouvel endpoint pour créer un contrat créera toujours un contrat principal en cas de scission mensuel. La raison en est qu'un seul contractid est renvoyé. Lors de la scission en contrats normaux, cela deviendrait 2 contractids. Pour l'instant, nous ne prévoyons pas d'endpoint pour établir 2 contrats séparés en cas de scission mensuel. Si cela devait s'avérer nécessaire, veuillez contacter votre Customer Success Manager ou customercare@prato.be. |
| L'endpoint pour la création de nouveaux contrats peut désormais également enregistrer les contrats d'une durée supérieure à une semaine et à durée indéterminée. Dans PratoFlex, ces contrats deviennent des contrats master.
Le modèle (request + response) de l'endpoint POST {{url}}/webservice/integration/employmentcontract n'a pas été modifié. |
| Le modèle sans implémentation pour l'endpoint DELETE {{url}}/webservice/integration/employmentContract/:employmentContractId/premium/:premiumId était déjà fourni avec une version précédente. A partir de maintenant, la suppression se fera effectivement. Les paramètres de l'url sont : |
| Un nouvel endpoint est fourni pour changer les primes d'un contrat. Cet endpoint permet de modifier une (seule) prime existante. PATCH /integration/employmentContract/{employmentContractId}/premium/{premiumid} Les paramètres de l'url sont : |
| Il est désormais possible d'ajouter de nouvelles primes pour un contrat via l'endpoint POST {{url}}/webservice/integration/employmentContract/:employmentContractId/premiums Les paramètres de l'url sont : |
| Un nouvel endpoint est prévu pour supprimer les prestations d'un contrat. Cet endpoint permet de supprimer une prestation existante sur la base d'un ID de contrat. DELETE /integration/employmentContract/{employmentContractId}/performance/{performanceid}
Les paramètres de l'url sont : |
| Le Core API (webservice/integration dans Swagger) a été modifiée pour tenir compte de l'accès aux agences. Un token (une connexion à l'API) est également configuré via une fiche de personnel qui obtient l'accès aux agences. Dans la version précédente, un token avait accès à toutes les agences de l'entreprise. À partir de cette version, les tokens tiendront compte des agences qui ont été configurées. Cela n'a pas été fait pour la Basic API (webservice/sollicitation dans Swagger). 
|
Correctifs
Général
API
Lors de la modification des régimes de travail via l'API, il pouvait arriver qu'un certain champ de la fiche client soit rendu vide à tort. Lors de la sauvegarde d'un contrat, vous avez ensuite reçu des messages d'erreur incorrects concernant les contrôles Heures à temps plein par rapport au RTM.
Ce problème a été résolu avec cette version.
DRS
Lors de la création automatique d'un document C4, une erreur système se produisait si des personnes étaient également marquées comme archivées. Ce problème a été résolu, les personnes archivées ne sont pas incluses dans la création automatique du C4.
(Remarque: la création automatique des C4 est un module payant.)
Contract Redesign
Si le filtre par date pour une formule salariale ou de facturation était vidé, un message d'erreur système s'affichait. Nous avons résolu cette erreur système. Si aucune date n'est indiquée, toutes les formules seront affichées.
Nous avons apporté une modification à l'onglet Contacts. Vous pouvez activer ici un paramètre qui vous permet uniquement de modifier les contacts, mais pas de les ajouter/supprimer.
