bandeau_edess


Bienvenue, Invité
Nom d'utilisateur: Mot de passe: Se souvenir de moi

SUJET: Logique relationnelle des trois types de messages

Logique relationnelle des trois types de messages 11 Fév 2016 16:03 #87

  • François ROUGERIE
  • Offline
à creuser : DELIVERY serait en fait le "bon de livraison" par lequel le prestataire signale qu'il a livré une des prestations prévues par la commande

le bon de livraison doit alors être accepté par le donneur d'ordres (notion de "service fait"), et, suivant les termes du contrat, le prestataire peut alors émettre une facture partielle ou globale
L'administrateur à désactivé l'accès en écriture pour le public.

Logique relationnelle des trois types de messages 11 Fév 2016 15:54 #86

  • François ROUGERIE
  • Offline
Il faudrait pouvoir raisonner sur un exemple. DELIVERY décrit la réalisation d'une ou plusieurs prestations dans le cadre d'une commande passée par le donneur d'ordre à un prestataire.

Exemple à soumettre lors de l'atelier du 19/2 :

Le CDxx (financeur / donneur d'ordre) a commandé au prestataire SADyy une prestation de ménage à domicile de une heure 2 fois par semaine pendant 6 mois chez Monsieur MICHU => référence d'un bon de commande dans le SI du donneur d'ordre.

A un rythme variable (idéalement par mobile après l'exécution d'une heure de ménage, ou bien chaque semaine, ou chaque mois ??) le SADyy envoie un message DELIVERY, avec la référence du bon de commande du donneur d'ordre et la liste des prestations élémentaires réalisées.

Ce serait alors au SI du donneur d'ordre de collecter via les messages DELIVERY les prestations effectivement réalisées dans le cadre du bon de commande, pour à la fois vérifier que le plan d'aide est bien effectué, et pour accepter ensuite une/des factures.
L'administrateur à désactivé l'accès en écriture pour le public.

Logique relationnelle des trois types de messages 06 Fév 2016 11:05 #82

  • Philippe AMELINE
  • Offline
La logique du message Order, telle que nous en sommes convenus lors de l'atelier du 15/01/2016, est de véhiculer tout ou partie d'un plan d'aide, sous forme d'une liste de prestations.

Chaque prestation est donc dotée d'un identifiant unique : CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / LineID

De ce que je comprends de l'enchainement des messages, une prestation sera effectuée en une ou plusieurs fois, donnant lieu à (autant de/un certain nombre de) lignes de facture.

On pourrait donc imaginer que les diverses lignes du message Delivery permettent d'exprimer à quelles prestations les actions signalées correspondent... mais dans Delivery, je ne vois qu'un identifiant CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / AssociatedCIDDLDocumentLineDocument / LineID
Cet identifiant devrait plutôt contenir l'identifiant de l'acte déclaré comme réalisé... mais alors comment le rattacher à sa prestation ?

Le problème me semble se poser de façon identique pour les factures qui, on pourrait l'imaginer, devraient pouvoir indiquer qu'une ligne de facture correspond à un ensemble d'actes réalisés pour une prestation (donc 1 ID de prestation issu d'Order et 1...n ID d'actes issus de Delivery). Mais je ne vois aucune balise susceptible de contenir ce type d'information (à nouveau, il n'y a qu'un LineID).
L'administrateur à désactivé l'accès en écriture pour le public.
Propulsé par Forum Kunena