| |||||||||
CI-9(HF8), Mappage du numéro d'article de l'avis d'expédition avancé (DESADV.DELVRY06) entraînant des erreurs lors du traitement de l'IDoc
Le client a installé CI9 HF8. Lors des tests unitaires initiaux, il a été découvert que lors du traitement de l'IDoc traduit de l'avis d'expédition avancé entrant, l'IDoc échouera dans SAP en raison de l'erreur ci-dessous.
"le numéro d'article est plus long que la longueur définie"
La zone en question est /DELVRY06/IDOC/E1EDL20/E1EDL24/KDMAT.
La valeur est renseignée via un appel RFC à SAP et n'est donc pas basée sur le mappage de cxml entrant.
Veuillez donner des conseils sur les prochaines étapes.
En vérifiant ce problème, nous pouvons comprendre qu'Ariba ne mappe pas ce champ (KDMAT/numéro d'article client) dans les cartes PI standard.
Le champ KDMAT n'est pas envoyé lorsque les bons de commande sont enregistrés et que le numéro d'article client n'est pas non plus renseigné depuis SAP Business Network lors de la création d'un avis d'expédition.
Fondamentalement, les informations de zone KDMAT sont extraites de la table KNMT gérée dans SAP ECC.
Nous avons essayé de répliquer ce problème avec une commande d'achat avec le numéro d'article et le numéro d'article client. Nous avons pu constater que KDMAT est prélevé de la table ECC - KNMT et renseigné dans l'IDoc DESADV.
Table KNMT :










Concernant les contraintes de longueur, nous avons suggéré aux clients de gérer KDMAT en fonction des limitations ECC et de vérifier ce problème du côté ECC.
![]() | Mappage du numéro d'article de l'avis d'expédition avancé (DESADV.DELVRY06) à l'origine d'erreurs lors du traitement de IDOC.docx | 575,20 Ko |
SAP Business Network for Procurement & Supply Chain