Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un
format d'échange pour transférer des factures, des bl etc...
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs
pour edi/xml, voir des entreprises qui font la conversion. Je me pose
donc la question de passer ou non par un convertisseur.
Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un format d'échange pour transférer des factures, des bl etc...
Juste une question : c'est du format texte ou binaire ?
Je n'ai pas trouvé de réponse claire dans les 5 minutes que je viens de consacrer au sujet !-)
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs pour edi/xml, voir des entreprises qui font la conversion. Je me pose donc la question de passer ou non par un convertisseur.
Mmm... Ca peut être tentant dans la mesure où il ya de bons outils pour gérer du XML en Python, mais ça fait quand même un niveau d'indirection supplémentaire.
Si c'est un format texte, il existe quand même quelques générateurs de parseur en Python, cf http://wiki.python.org/moin/LanguageParsing
Si c'est un format binaire, il y a aussi http://pyconstruct.wikispaces.com/
Après, je ne connais pas assez ni EDI ni le contexte dans lequel tu es amené à l'utiliser pour avoir le moindre avis...
Mes 2 centimes, -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
William Dode wrote:
Slt,
Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un
format d'échange pour transférer des factures, des bl etc...
Juste une question : c'est du format texte ou binaire ?
Je n'ai pas trouvé de réponse claire dans les 5 minutes que je viens de
consacrer au sujet !-)
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs
pour edi/xml, voir des entreprises qui font la conversion. Je me pose
donc la question de passer ou non par un convertisseur.
Mmm... Ca peut être tentant dans la mesure où il ya de bons outils pour
gérer du XML en Python, mais ça fait quand même un niveau d'indirection
supplémentaire.
Si c'est un format texte, il existe quand même quelques générateurs de
parseur en Python, cf
http://wiki.python.org/moin/LanguageParsing
Si c'est un format binaire, il y a aussi
http://pyconstruct.wikispaces.com/
Après, je ne connais pas assez ni EDI ni le contexte dans lequel tu es
amené à l'utiliser pour avoir le moindre avis...
Mes 2 centimes,
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un format d'échange pour transférer des factures, des bl etc...
Juste une question : c'est du format texte ou binaire ?
Je n'ai pas trouvé de réponse claire dans les 5 minutes que je viens de consacrer au sujet !-)
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs pour edi/xml, voir des entreprises qui font la conversion. Je me pose donc la question de passer ou non par un convertisseur.
Mmm... Ca peut être tentant dans la mesure où il ya de bons outils pour gérer du XML en Python, mais ça fait quand même un niveau d'indirection supplémentaire.
Si c'est un format texte, il existe quand même quelques générateurs de parseur en Python, cf http://wiki.python.org/moin/LanguageParsing
Si c'est un format binaire, il y a aussi http://pyconstruct.wikispaces.com/
Après, je ne connais pas assez ni EDI ni le contexte dans lequel tu es amené à l'utiliser pour avoir le moindre avis...
Mes 2 centimes, -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Michel Claveau
Bonsoir !
J'ai eu assez souvent à travailler avec des fichiers EDI. D'une manière générale, il n'y a guère de difficultés techniques.
Les problèmes principaux, c'est de récupérer les informations sur le format utilisé (il y en a plusieurs centaines), de trouver la (bonne) source des informations, d'obtenir un droit d'accès à ces informations, etc.
Finalement, c'est un petit boulot habituel de gestion.
Ah oui, petit détail : l'utilisation de certains formats EDI est quelquefois payante, soit directement, soit via une adhésion (plus ou moins obligatoire) à une structure tierce. Le client n'étant pas toujours au courant, cela peut aussi poser des problèmes.
-- @-salutations
Michel Claveau
Bonsoir !
J'ai eu assez souvent à travailler avec des fichiers EDI.
D'une manière générale, il n'y a guère de difficultés techniques.
Les problèmes principaux, c'est de récupérer les informations sur le
format utilisé (il y en a plusieurs centaines), de trouver la (bonne)
source des informations, d'obtenir un droit d'accès à ces informations,
etc.
Finalement, c'est un petit boulot habituel de gestion.
Ah oui, petit détail : l'utilisation de certains formats EDI est
quelquefois payante, soit directement, soit via une adhésion (plus ou
moins obligatoire) à une structure tierce. Le client n'étant pas
toujours au courant, cela peut aussi poser des problèmes.
J'ai eu assez souvent à travailler avec des fichiers EDI. D'une manière générale, il n'y a guère de difficultés techniques.
Les problèmes principaux, c'est de récupérer les informations sur le format utilisé (il y en a plusieurs centaines), de trouver la (bonne) source des informations, d'obtenir un droit d'accès à ces informations, etc.
Finalement, c'est un petit boulot habituel de gestion.
Ah oui, petit détail : l'utilisation de certains formats EDI est quelquefois payante, soit directement, soit via une adhésion (plus ou moins obligatoire) à une structure tierce. Le client n'étant pas toujours au courant, cela peut aussi poser des problèmes.
-- @-salutations
Michel Claveau
William Dode
On 10-05-2006, Michel Claveau wrote:
Bonsoir !
J'ai eu assez souvent à travailler avec des fichiers EDI. D'une manière générale, il n'y a guère de difficultés techniques.
Pour répondre à bruno au dessus, c'est de l'ascii... Tu utilises un module particulier oubien c'est du maison ? Par exemple j'ai trouvé ça sans encore regarder exactement ce qu'il fait : http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/299485
Les problèmes principaux, c'est de récupérer les informations sur le format utilisé (il y en a plusieurs centaines), de trouver la (bonne) source des informations, d'obtenir un droit d'accès à ces informations, etc.
C'est bien ce qui me semblait. Pour ce coup j'ai plutôt un bon contact, mais je me demandais si ce que je fais poura être réutilisé, apparement pas forcément, d'où l'idée de passer par un intermédiaire qui saurait faire le tri et toujours me renvoyer le même format xml. Tu penses que ça peut valoir le coup ?
Finalement, c'est un petit boulot habituel de gestion.
Ah oui, petit détail : l'utilisation de certains formats EDI est quelquefois payante, soit directement, soit via une adhésion (plus ou moins obligatoire) à une structure tierce. Le client n'étant pas toujours au courant, cela peut aussi poser des problèmes.
Bon à savoir. Déjà mon client en question il ferme boutique s'il ne se plie pas à l'edi !
-- William Dodé - http://flibuste.net
On 10-05-2006, Michel Claveau wrote:
Bonsoir !
J'ai eu assez souvent à travailler avec des fichiers EDI.
D'une manière générale, il n'y a guère de difficultés techniques.
Pour répondre à bruno au dessus, c'est de l'ascii...
Tu utilises un module particulier oubien c'est du maison ?
Par exemple j'ai trouvé ça sans encore regarder exactement ce qu'il fait
: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/299485
Les problèmes principaux, c'est de récupérer les informations sur le
format utilisé (il y en a plusieurs centaines), de trouver la (bonne)
source des informations, d'obtenir un droit d'accès à ces informations,
etc.
C'est bien ce qui me semblait. Pour ce coup j'ai plutôt un bon contact,
mais je me demandais si ce que je fais poura être réutilisé, apparement
pas forcément, d'où l'idée de passer par un intermédiaire qui saurait
faire le tri et toujours me renvoyer le même format xml. Tu penses que
ça peut valoir le coup ?
Finalement, c'est un petit boulot habituel de gestion.
Ah oui, petit détail : l'utilisation de certains formats EDI est
quelquefois payante, soit directement, soit via une adhésion (plus ou
moins obligatoire) à une structure tierce. Le client n'étant pas
toujours au courant, cela peut aussi poser des problèmes.
Bon à savoir. Déjà mon client en question il ferme boutique s'il ne se
plie pas à l'edi !
J'ai eu assez souvent à travailler avec des fichiers EDI. D'une manière générale, il n'y a guère de difficultés techniques.
Pour répondre à bruno au dessus, c'est de l'ascii... Tu utilises un module particulier oubien c'est du maison ? Par exemple j'ai trouvé ça sans encore regarder exactement ce qu'il fait : http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/299485
Les problèmes principaux, c'est de récupérer les informations sur le format utilisé (il y en a plusieurs centaines), de trouver la (bonne) source des informations, d'obtenir un droit d'accès à ces informations, etc.
C'est bien ce qui me semblait. Pour ce coup j'ai plutôt un bon contact, mais je me demandais si ce que je fais poura être réutilisé, apparement pas forcément, d'où l'idée de passer par un intermédiaire qui saurait faire le tri et toujours me renvoyer le même format xml. Tu penses que ça peut valoir le coup ?
Finalement, c'est un petit boulot habituel de gestion.
Ah oui, petit détail : l'utilisation de certains formats EDI est quelquefois payante, soit directement, soit via une adhésion (plus ou moins obligatoire) à une structure tierce. Le client n'étant pas toujours au courant, cela peut aussi poser des problèmes.
Bon à savoir. Déjà mon client en question il ferme boutique s'il ne se plie pas à l'edi !
-- William Dodé - http://flibuste.net
Gerard Flanagan
William Dode wrote:
Slt,
Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un format d'échange pour transférer des factures, des bl etc...
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs pour edi/xml, voir des entreprises qui font la conversion. Je me pose
suggere google: UBL EDI
(UBL: Universal Business Language)
Gerard
William Dode wrote:
Slt,
Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un
format d'échange pour transférer des factures, des bl etc...
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs
pour edi/xml, voir des entreprises qui font la conversion. Je me pose
Un peu HS mais je ne conçoit pas de ne pas utiliser python pour ça...
Est-ce que quelqu'un s'est déjà froté à des "messages EDI", c'est un format d'échange pour transférer des factures, des bl etc...
J'ai trouvé quelques scripts sur le net, mais aussi des convertisseurs pour edi/xml, voir des entreprises qui font la conversion. Je me pose
suggere google: UBL EDI
(UBL: Universal Business Language)
Gerard
Méta-MCI
Bonsoir !
UBL a des prétentions universalistes. Mais, son support de XML, et son orientation très nord-américaine ne compensent pas son inadaptation à EdiFact, qui reste le groupe de formats EDI le plus important, du moins en Europe.
En gros, dans ce domaine, on a les utilisateurs EdiFact (européens et asiatiques), qui travaillent depuis des années avec des formats qui fonctionnent, et des "méthodologistes", (essentiellement nord-américains, menés pas Cefact-Onu), qui voudraient tout transformer ebXML. AMHA, c'est surtout pour tenter de récupérer le marché des utilisateurs.
Ceci dit, en pratique, la plupart des cas que j'ai rencontrés se rangent en trois catégories : - ceux qui utilisent un sous-ensemble d'un format connu (Edifact ou autre) - ceux dont les partenaires ont définis un format "maison" - la dernière catégorie passe par un prestataire externe qui traduit les messages d'un format vers un autre.
Donc, je n'ai jamais rencontré quelqu'un qui utilise complètement, et directement, un vrai format EDI
Toutefois, ma situation n'est pas généralisable.
@-salutations -- Michel Claveau
Bonsoir !
UBL a des prétentions universalistes. Mais, son support de XML, et son
orientation très nord-américaine ne compensent pas son inadaptation à
EdiFact, qui reste le groupe de formats EDI le plus important, du moins en
Europe.
En gros, dans ce domaine, on a les utilisateurs EdiFact (européens et
asiatiques), qui travaillent depuis des années avec des formats qui
fonctionnent, et des "méthodologistes", (essentiellement nord-américains,
menés pas Cefact-Onu), qui voudraient tout transformer ebXML. AMHA, c'est
surtout pour tenter de récupérer le marché des utilisateurs.
Ceci dit, en pratique, la plupart des cas que j'ai rencontrés se rangent en
trois catégories :
- ceux qui utilisent un sous-ensemble d'un format connu (Edifact ou
autre)
- ceux dont les partenaires ont définis un format "maison"
- la dernière catégorie passe par un prestataire externe qui traduit les
messages d'un format vers un autre.
Donc, je n'ai jamais rencontré quelqu'un qui utilise complètement, et
directement, un vrai format EDI
UBL a des prétentions universalistes. Mais, son support de XML, et son orientation très nord-américaine ne compensent pas son inadaptation à EdiFact, qui reste le groupe de formats EDI le plus important, du moins en Europe.
En gros, dans ce domaine, on a les utilisateurs EdiFact (européens et asiatiques), qui travaillent depuis des années avec des formats qui fonctionnent, et des "méthodologistes", (essentiellement nord-américains, menés pas Cefact-Onu), qui voudraient tout transformer ebXML. AMHA, c'est surtout pour tenter de récupérer le marché des utilisateurs.
Ceci dit, en pratique, la plupart des cas que j'ai rencontrés se rangent en trois catégories : - ceux qui utilisent un sous-ensemble d'un format connu (Edifact ou autre) - ceux dont les partenaires ont définis un format "maison" - la dernière catégorie passe par un prestataire externe qui traduit les messages d'un format vers un autre.
Donc, je n'ai jamais rencontré quelqu'un qui utilise complètement, et directement, un vrai format EDI
Toutefois, ma situation n'est pas généralisable.
@-salutations -- Michel Claveau
Méta-MCI
'soir !
Tous mes développements, pour ce genre de choses, sont maison. Mais, de l'échange/exportation de données/fichiers, j'en fais depuis presque 30 ans, alors, on s'habitue...
Pour un prestataire qui ferait une partie du travail, ça peut être une très bonne solution, ne serait-ce que pour s'éviter les travaux de validation.
Quand à XML, il faudrait d'abord voir si les formats EDI envisagés sont en XML, ce qui n'est pas forcément le cas.
Je tiens encore à te rassurer : rien de techniquement difficile. C'est même de l'informatique simpliste. Et Python conviendra très bien. Le plus délicat étant d'obtenir les (bonnes infos), et d'avoir quelques heures.
Enfin, si l'entreprise te doit sa survie, tu vas pouvoir augmenter tes émoluments, avec leurs remerciements ;o) profites-en pour jouer au loto (faut profiter au maximum des périodes de chance).
@+
MCI
'soir !
Tous mes développements, pour ce genre de choses, sont maison.
Mais, de l'échange/exportation de données/fichiers, j'en fais depuis presque
30 ans, alors, on s'habitue...
Pour un prestataire qui ferait une partie du travail, ça peut être une très
bonne solution, ne serait-ce que pour s'éviter les travaux de validation.
Quand à XML, il faudrait d'abord voir si les formats EDI envisagés sont en
XML, ce qui n'est pas forcément le cas.
Je tiens encore à te rassurer : rien de techniquement difficile. C'est même
de l'informatique simpliste. Et Python conviendra très bien. Le plus
délicat étant d'obtenir les (bonnes infos), et d'avoir quelques heures.
Enfin, si l'entreprise te doit sa survie, tu vas pouvoir augmenter tes
émoluments, avec leurs remerciements ;o) profites-en pour jouer au loto
(faut profiter au maximum des périodes de chance).
Tous mes développements, pour ce genre de choses, sont maison. Mais, de l'échange/exportation de données/fichiers, j'en fais depuis presque 30 ans, alors, on s'habitue...
Pour un prestataire qui ferait une partie du travail, ça peut être une très bonne solution, ne serait-ce que pour s'éviter les travaux de validation.
Quand à XML, il faudrait d'abord voir si les formats EDI envisagés sont en XML, ce qui n'est pas forcément le cas.
Je tiens encore à te rassurer : rien de techniquement difficile. C'est même de l'informatique simpliste. Et Python conviendra très bien. Le plus délicat étant d'obtenir les (bonnes infos), et d'avoir quelques heures.
Enfin, si l'entreprise te doit sa survie, tu vas pouvoir augmenter tes émoluments, avec leurs remerciements ;o) profites-en pour jouer au loto (faut profiter au maximum des périodes de chance).
@+
MCI
Gerard Flanagan
Méta-MCI wrote:
Bonsoir !
UBL a des prétentions universalistes. Mais, son support de XML, et son orientation très nord-américaine ne compensent pas son inadaptation à EdiFact, qui reste le groupe de formats EDI le plus important, du moins en Europe.
En gros, dans ce domaine, on a les utilisateurs EdiFact (européens et asiatiques), qui travaillent depuis des années avec des formats qui fonctionnent, et des "méthodologistes", (essentiellement nord-américa ins, menés pas Cefact-Onu), qui voudraient tout transformer ebXML. AMHA, c'e st surtout pour tenter de récupérer le marché des utilisateurs.
Ceci dit, en pratique, la plupart des cas que j'ai rencontrés se rangen t en trois catégories : - ceux qui utilisent un sous-ensemble d'un format connu (Edifact ou autre) - ceux dont les partenaires ont définis un format "maison" - la dernière catégorie passe par un prestataire externe qui tradu it les messages d'un format vers un autre.
Donc, je n'ai jamais rencontré quelqu'un qui utilise complètement, et directement, un vrai format EDI
Toutefois, ma situation n'est pas généralisable.
Bonjour!
je ne connais pas EDI/EdiFact et je n'ai que utilise un petit sous-ensemble de UBL. UBL j'ai trouve bon parce que:
* facile (relativement) de convertir en format 'web' avec XSLT * Microsoft Excel a des utils pour XML/XMLSchema * il y a un util 'Microsoft-ien' (xsd.exe) qui, donne un XMLSchema, cree automatiquement des classes C# - ces classes sont ecrit pour etre Serialize a/Deserialize de XML facilement (c'etait pour un app 'XML over HTTP') * etre completement honnete, l'application 'est meurt avant naissance' :-(, mais j'ai eu l'intention d'utiliser Python sur le serveur/db, et donc XML aurait ete bon pour le langue commun
Gerard
Méta-MCI wrote:
Bonsoir !
UBL a des prétentions universalistes. Mais, son support de XML, et son
orientation très nord-américaine ne compensent pas son inadaptation à
EdiFact, qui reste le groupe de formats EDI le plus important, du moins en
Europe.
En gros, dans ce domaine, on a les utilisateurs EdiFact (européens et
asiatiques), qui travaillent depuis des années avec des formats qui
fonctionnent, et des "méthodologistes", (essentiellement nord-américa ins,
menés pas Cefact-Onu), qui voudraient tout transformer ebXML. AMHA, c'e st
surtout pour tenter de récupérer le marché des utilisateurs.
Ceci dit, en pratique, la plupart des cas que j'ai rencontrés se rangen t en
trois catégories :
- ceux qui utilisent un sous-ensemble d'un format connu (Edifact ou
autre)
- ceux dont les partenaires ont définis un format "maison"
- la dernière catégorie passe par un prestataire externe qui tradu it les
messages d'un format vers un autre.
Donc, je n'ai jamais rencontré quelqu'un qui utilise complètement, et
directement, un vrai format EDI
Toutefois, ma situation n'est pas généralisable.
Bonjour!
je ne connais pas EDI/EdiFact et je n'ai que utilise un petit
sous-ensemble de UBL. UBL j'ai trouve bon parce que:
* facile (relativement) de convertir en format 'web' avec XSLT
* Microsoft Excel a des utils pour XML/XMLSchema
* il y a un util 'Microsoft-ien' (xsd.exe) qui, donne un XMLSchema,
cree automatiquement des classes C# - ces classes sont ecrit pour etre
Serialize a/Deserialize de XML facilement (c'etait pour un app 'XML
over HTTP')
* etre completement honnete, l'application 'est meurt avant
naissance' :-(, mais j'ai eu l'intention d'utiliser Python sur le
serveur/db, et donc XML aurait ete bon pour le langue commun
UBL a des prétentions universalistes. Mais, son support de XML, et son orientation très nord-américaine ne compensent pas son inadaptation à EdiFact, qui reste le groupe de formats EDI le plus important, du moins en Europe.
En gros, dans ce domaine, on a les utilisateurs EdiFact (européens et asiatiques), qui travaillent depuis des années avec des formats qui fonctionnent, et des "méthodologistes", (essentiellement nord-américa ins, menés pas Cefact-Onu), qui voudraient tout transformer ebXML. AMHA, c'e st surtout pour tenter de récupérer le marché des utilisateurs.
Ceci dit, en pratique, la plupart des cas que j'ai rencontrés se rangen t en trois catégories : - ceux qui utilisent un sous-ensemble d'un format connu (Edifact ou autre) - ceux dont les partenaires ont définis un format "maison" - la dernière catégorie passe par un prestataire externe qui tradu it les messages d'un format vers un autre.
Donc, je n'ai jamais rencontré quelqu'un qui utilise complètement, et directement, un vrai format EDI
Toutefois, ma situation n'est pas généralisable.
Bonjour!
je ne connais pas EDI/EdiFact et je n'ai que utilise un petit sous-ensemble de UBL. UBL j'ai trouve bon parce que:
* facile (relativement) de convertir en format 'web' avec XSLT * Microsoft Excel a des utils pour XML/XMLSchema * il y a un util 'Microsoft-ien' (xsd.exe) qui, donne un XMLSchema, cree automatiquement des classes C# - ces classes sont ecrit pour etre Serialize a/Deserialize de XML facilement (c'etait pour un app 'XML over HTTP') * etre completement honnete, l'application 'est meurt avant naissance' :-(, mais j'ai eu l'intention d'utiliser Python sur le serveur/db, et donc XML aurait ete bon pour le langue commun
Gerard
William Dode
On 11-05-2006, Méta-MCI wrote:
'soir !
Tous mes développements, pour ce genre de choses, sont maison. Mais, de l'échange/exportation de données/fichiers, j'en fais depuis presque 30 ans, alors, on s'habitue...
Oui, c'est incroyable quand même d'avoir toujours à faire ce même genre de chose aujourd'hui.
Pour un prestataire qui ferait une partie du travail, ça peut être une très bonne solution, ne serait-ce que pour s'éviter les travaux de validation.
Quand à XML, il faudrait d'abord voir si les formats EDI envisagés sont en XML, ce qui n'est pas forcément le cas.
C'est le boulot de l'intermédiaire justement, d'où l'intérêt car il va se dépatouiller avec les différents formats edi et sortir (ou entrer) un fichier xml bien documenté...
Je tiens encore à te rassurer : rien de techniquement difficile. C'est même de l'informatique simpliste. Et Python conviendra très bien. Le plus délicat étant d'obtenir les (bonnes infos), et d'avoir quelques heures.
C'est sûrement le plus difficile comme d'hab, d'avoir les bonnes infos. C'est encore l'intérêt de l'intermédiaire... Je vais donc aller voir ce qu'il propose exactement avant de me lancer.
Enfin, si l'entreprise te doit sa survie, tu vas pouvoir augmenter tes émoluments, avec leurs remerciements ;o) profites-en pour jouer au loto (faut profiter au maximum des périodes de chance).
Voilà, je vais commencer par ça !
Merci
-- William Dodé - http://flibuste.net
On 11-05-2006, Méta-MCI wrote:
'soir !
Tous mes développements, pour ce genre de choses, sont maison.
Mais, de l'échange/exportation de données/fichiers, j'en fais depuis presque
30 ans, alors, on s'habitue...
Oui, c'est incroyable quand même d'avoir toujours à faire ce même genre
de chose aujourd'hui.
Pour un prestataire qui ferait une partie du travail, ça peut être une très
bonne solution, ne serait-ce que pour s'éviter les travaux de validation.
Quand à XML, il faudrait d'abord voir si les formats EDI envisagés sont en
XML, ce qui n'est pas forcément le cas.
C'est le boulot de l'intermédiaire justement, d'où l'intérêt car il va
se dépatouiller avec les différents formats edi et sortir (ou entrer) un
fichier xml bien documenté...
Je tiens encore à te rassurer : rien de techniquement difficile. C'est même
de l'informatique simpliste. Et Python conviendra très bien. Le plus
délicat étant d'obtenir les (bonnes infos), et d'avoir quelques heures.
C'est sûrement le plus difficile comme d'hab, d'avoir les bonnes infos.
C'est encore l'intérêt de l'intermédiaire... Je vais donc aller voir ce
qu'il propose exactement avant de me lancer.
Enfin, si l'entreprise te doit sa survie, tu vas pouvoir augmenter tes
émoluments, avec leurs remerciements ;o) profites-en pour jouer au loto
(faut profiter au maximum des périodes de chance).
Tous mes développements, pour ce genre de choses, sont maison. Mais, de l'échange/exportation de données/fichiers, j'en fais depuis presque 30 ans, alors, on s'habitue...
Oui, c'est incroyable quand même d'avoir toujours à faire ce même genre de chose aujourd'hui.
Pour un prestataire qui ferait une partie du travail, ça peut être une très bonne solution, ne serait-ce que pour s'éviter les travaux de validation.
Quand à XML, il faudrait d'abord voir si les formats EDI envisagés sont en XML, ce qui n'est pas forcément le cas.
C'est le boulot de l'intermédiaire justement, d'où l'intérêt car il va se dépatouiller avec les différents formats edi et sortir (ou entrer) un fichier xml bien documenté...
Je tiens encore à te rassurer : rien de techniquement difficile. C'est même de l'informatique simpliste. Et Python conviendra très bien. Le plus délicat étant d'obtenir les (bonnes infos), et d'avoir quelques heures.
C'est sûrement le plus difficile comme d'hab, d'avoir les bonnes infos. C'est encore l'intérêt de l'intermédiaire... Je vais donc aller voir ce qu'il propose exactement avant de me lancer.
Enfin, si l'entreprise te doit sa survie, tu vas pouvoir augmenter tes émoluments, avec leurs remerciements ;o) profites-en pour jouer au loto (faut profiter au maximum des périodes de chance).
Voilà, je vais commencer par ça !
Merci
-- William Dodé - http://flibuste.net
Méta-MCI
Bonjour !
je n'ai que utilisé un petit sous-ensemble de UBL
Finalement, on est dans le même ,cas. En pratique je n'ai jamais vu que des utilisations partielles des formats EDI. Ce qui contraste avec les discours officiels (publics ? commerciaux ?), où l'absolu est de mise.
* facile (relativement) de convertir en format 'web' avec XSLT
Sans vouloir donner l'impression de redéfinir la roue, ni de critiquer systématiquement XML, je ne demande quel est le gain réel de travailler avec XSLT, relativement à l'écriture d'une routine, en quelques heures, avec un langage tel Python (ou Ruby, ou TCL, ou simplement SQL) sur des bases de données. Mais, là, on va virer hors sujet.
@-salutations -- Michel Claveau
Bonjour !
je n'ai que utilisé un petit sous-ensemble de UBL
Finalement, on est dans le même ,cas. En pratique je n'ai jamais vu que des
utilisations partielles des formats EDI. Ce qui contraste avec les discours
officiels (publics ? commerciaux ?), où l'absolu est de mise.
* facile (relativement) de convertir en format 'web' avec XSLT
Sans vouloir donner l'impression de redéfinir la roue, ni de critiquer
systématiquement XML, je ne demande quel est le gain réel de travailler avec
XSLT, relativement à l'écriture d'une routine, en quelques heures, avec un
langage tel Python (ou Ruby, ou TCL, ou simplement SQL) sur des bases de
données.
Mais, là, on va virer hors sujet.
Finalement, on est dans le même ,cas. En pratique je n'ai jamais vu que des utilisations partielles des formats EDI. Ce qui contraste avec les discours officiels (publics ? commerciaux ?), où l'absolu est de mise.
* facile (relativement) de convertir en format 'web' avec XSLT
Sans vouloir donner l'impression de redéfinir la roue, ni de critiquer systématiquement XML, je ne demande quel est le gain réel de travailler avec XSLT, relativement à l'écriture d'une routine, en quelques heures, avec un langage tel Python (ou Ruby, ou TCL, ou simplement SQL) sur des bases de données. Mais, là, on va virer hors sujet.
@-salutations -- Michel Claveau
William Dode
On 13-05-2006, Méta-MCI wrote:
Bonjour !
je n'ai que utilisé un petit sous-ensemble de UBL
Finalement, on est dans le même ,cas. En pratique je n'ai jamais vu que des utilisations partielles des formats EDI. Ce qui contraste avec les discours officiels (publics ? commerciaux ?), où l'absolu est de mise.
* facile (relativement) de convertir en format 'web' avec XSLT
Sans vouloir donner l'impression de redéfinir la roue, ni de critiquer systématiquement XML, je ne demande quel est le gain réel de travailler avec XSLT, relativement à l'écriture d'une routine, en quelques heures, avec un langage tel Python (ou Ruby, ou TCL, ou simplement SQL) sur des bases de données.
L'intérêt de l'xml c'est uniquement le parsing, l'extraction et l'exportation des données qui est santard... C'est déjà pas mal je trouve mais Pour le reste ça ne change rien amha.
-- William Dodé - http://flibuste.net
On 13-05-2006, Méta-MCI wrote:
Bonjour !
je n'ai que utilisé un petit sous-ensemble de UBL
Finalement, on est dans le même ,cas. En pratique je n'ai jamais vu que des
utilisations partielles des formats EDI. Ce qui contraste avec les discours
officiels (publics ? commerciaux ?), où l'absolu est de mise.
* facile (relativement) de convertir en format 'web' avec XSLT
Sans vouloir donner l'impression de redéfinir la roue, ni de critiquer
systématiquement XML, je ne demande quel est le gain réel de travailler avec
XSLT, relativement à l'écriture d'une routine, en quelques heures, avec un
langage tel Python (ou Ruby, ou TCL, ou simplement SQL) sur des bases de
données.
L'intérêt de l'xml c'est uniquement le parsing, l'extraction et
l'exportation des données qui est santard... C'est déjà pas mal je
trouve mais Pour le reste ça ne change rien amha.
Finalement, on est dans le même ,cas. En pratique je n'ai jamais vu que des utilisations partielles des formats EDI. Ce qui contraste avec les discours officiels (publics ? commerciaux ?), où l'absolu est de mise.
* facile (relativement) de convertir en format 'web' avec XSLT
Sans vouloir donner l'impression de redéfinir la roue, ni de critiquer systématiquement XML, je ne demande quel est le gain réel de travailler avec XSLT, relativement à l'écriture d'une routine, en quelques heures, avec un langage tel Python (ou Ruby, ou TCL, ou simplement SQL) sur des bases de données.
L'intérêt de l'xml c'est uniquement le parsing, l'extraction et l'exportation des données qui est santard... C'est déjà pas mal je trouve mais Pour le reste ça ne change rien amha.
