Vous trouverez ici un guide complet sur la manière de créer une commande dans Skyplanner avec toutes les données connexes. Certains aspects ont déjà été abordés dans le didacticiel sur l’intégration, mais nous examinons ici plus en détail la structure des données de Skyplanner et le processus d’intégration.
Structure des données #
Tout d’abord, nous allons voir comment une commande Skyplanner est structurée. Les points d’accès à l’API pour les entités de données mentionnées ici sont mis en évidence comme suit : /phaser-orders
Au niveau supérieur, nous avons la commande(/phaser-orders).
Chaque commande doit avoir un client(/customers).
Chaque commande peut avoir plusieurs éléments de commande(/phaser-Order-items).
Chaque élément de commande peut être associé à un produit(/products), mais ce n’est pas obligatoire. Chaque produit a un stock(/saldos). Notez que l’entité stock est créée automatiquement lorsqu’un produit est créé avec l’API.
Chaque élément de commande peut avoir plusieurs tâches (ou étapes du processus)(/phaser-jobs).
Chaque travail doit avoir une étape de travail(/workstages).
Flux de travail d’intégration #
Voici un exemple étape par étape de la manière dont vous pourriez structurer votre intégration de votre système ERP à Skyplanner.
- Récupérer les ventes/commandes de travail de l’ERP
- Créez un client (obtenez l’identifiant du client dans la réponse)
- Créez une commande avec l’identifiant du client (obtenez l’identifiant de la commande dans la réponse)
- Récupérer les données de l’article de la commande de vente ou de travail à partir de l’ERP
- Créez un produit (obtenez l’identifiant du produit dans la réponse)
- Créer un élément de commande avec l’identifiant de la commande et d’autres données (obtenir l’identifiant de l’élément de commande dans la réponse)
- Récupérer les données des étapes du processus à partir de l’ERP
- Créez une phase de travail (obtenez l’identifiant de la phase de travail dans la réponse)
- Créer un travail avec l’identifiant de l’étape de travail et d’autres données
Conseils supplémentaires #
Lors de la suppression #
La suppression des phaser-orders, phaser-Order-items ou phaser-jobs via l’API (et à partir de l’interface utilisateur) s’effectue de manière douce. Cela signifie que les données ne sont pas réellement supprimées de la base de données, mais qu’elles sont marquées comme étant archivées. En effet, l’attribut is_archive de l’entité est mis à vrai lorsqu’elle est supprimée. Il est toujours possible d’accéder aux entités archivées/supprimées à l’aide de l’API en utilisant le paramètre include_archived. Lorsque include_archived=true, une requête GET permet de récupérer l’entité même si elle est archivée.
Notez que la suppression en douceur n’est pas disponible dans tous les points de terminaison de l’API ! Vous devez donc être prudent car la suppression de clients, de personnes, etc. est permanente !
Utilisation des étapes de traitement par défaut pour votre poste de commande #
Si vous avez créé des étapes de processus par défaut pour le produit que votre article de commande fabrique, vous pouvez demander au système d’intégrer les valeurs par défaut à l’article de commande à l’aide de l’API en utilisant l’attribut get_default_steps.
Ajout d’articles à un poste de commande #
Si vous avez joint des matériaux au produit fabriqué, ils sont automatiquement joints à la ligne de commande.
Toutefois, si vous ne souhaitez pas utiliser les matériaux associés au produit (par exemple, s’il s’agit d’une commande spéciale et que vous souhaitez utiliser des matériaux différents, etc.), vous pouvez utiliser l’attribut use_custom_materials.
