Posso ligar o digital product passport ao meu sistema ERP ou de inventário?

O acoplamento só se torna concreto quando a norma técnica existe

Uma ligação direta entre o passaporte digital do produto e um sistema ERP ou de inventário não é atualmente possível, porque as especificações técnicas para isso ainda não foram estabelecidas. O ESPR (Regulamento (UE) 2024/1781) estabelece a base nos artigos 10 e 11: o passaporte deve ser interoperável, baseado em normas abertas e legível por máquina. Isto significa que a troca automatizada com sistemas empresariais é, em última análise, o ponto de partida, não uma exceção. Mas a forma como essa troca se desenrola na prática — qual formato de ficheiro, qual interface, que direitos de acesso — só resultará de atos delegados por grupo de produtos. Para ferro e aço, esse ato ainda não existe.

Para o quê isto se aplica e para o quê não se aplica

Trata-se de saber se os sistemas poderão em breve obter automaticamente dados do passaporte ou neles escrever. Isto afeta a configuração técnica do próprio passaporte, tal como descrita no regulamento: como é estruturado, quem pode aceder-lhe e em que forma os dados ficam disponíveis. Não se trata de saber se um pacote ERP específico é adequado, nem de uma API ou formato de dados concretos — essas escolhas ainda não foram feitas. Também não se trata da obrigação em si de ter um passaporte; esse é um assunto separado que será preenchido por grupo de produtos. O que aqui se descreve é unicamente o princípio de o passaporte ser legível por máquina e interoperável — a forma como esse princípio se torna concreto para ferro e aço está ainda em aberto.

Ainda nenhuma data fixa, ainda nenhuma norma técnica fixa

Ainda não existe uma data em que uma norma técnica de acoplamento para ferro e aço entrará em vigor, porque essa norma faz parte do ato delegado que ainda tem de ser publicado. De acordo com o plano de trabalho do ESPR para o período 2025-2030, espera-se o primeiro ato delegado em 2026, com obrigações que terão depois um período de transição de dezoito meses. Enquanto esse ato não existir, é certo que o passaporte deve ser interoperável e legível por máquina (artigos 10 e 11), mas não como isso será tecnicamente implementado. Até então, o passaporte funciona na prática como um documento a ser consultado por um ser humano através do código QR na portadora de dados, não como um fluxo de dados automatizado para um sistema externo.

O que isto significa para a abordagem

Para quem já está a pensar numa ligação com seu próprio sistema, a sequência é a seguinte. Primeiro: não há necessidade de construir nada agora, porque não existe uma norma para a qual construir. Segundo: colocar os seus próprios dados de produtos em ordem é já útil agora, independentemente da forma técnica final — um conjunto claro e consistente de dados por produto (origem, composição, certificados) é a base sobre a qual qualquer mecanismo de acoplamento futuro se apoiará. Terceiro: assim que o ato delegado para ferro e aço for publicado, nele ficará claro qual formato e qual forma de acesso se aplicam, e só então se pode conceber uma ligação concreta. Quarto: até lá, o passaporte permanece consultável através do código QR que se encontra no produto, o que para a maioria das transações diárias no comércio de aço e transformação de metais já é suficiente — a ligação com um sistema ERP é então um ganho de eficiência para mais tarde, não uma condição para poder trabalhar agora com o passaporte.

Onde isto resulta: artigos 10 e 11 do ESPR

O Artigo 10 do ESPR (Regulamento (UE) 2024/1781) descreve os requisitos aos quais o passaporte do produto digital deve estar em conformidade, incluindo a interoperabilidade e o uso de normas abertas. O Artigo 11 aborda o design técnico e o funcionamento do passaporte, como os registros, o acesso aos dados e a forma como o passaporte funciona. Ambos os artigos contêm o princípio de que o passaporte deve ser adequado para processamento automatizado, mas a sua implementação — a especificação técnica real por grupo de produtos — é deixada a cargo de atos delegados que ainda devem aparecer. Para a formulação precisa, o texto oficial do regulamento é vinculativo.

Se agora já quer preparar-se com antecedência, o melhor é manter os seus próprios dados de produtos já estruturados e completos, de modo que, quando a norma técnica aparecer, se alinhem sem muitas dificuldades com o que for estabelecido. Esta página será atualizada assim que o ato delegado para ferro e aço for publicado e os detalhes técnicos forem conhecidos.

Base para isto

O regulamento propriamente dito encontra-se na EUR-Lex. Fazemos referências por cada afirmação; não precisa acreditar em nós.

O que deve fazer concretamente

O que se espera de si

Os dados devem ser legíveis por máquina e transferíveis

O artigo 10 do ESPR (Regulamento (UE) 2024/1781) estabelece que os dados no passaporte do produto digital estejam disponíveis em formato estruturado e legível por máquina. Este é imediatamente o ponto de partida para a integração com um sistema próprio: dados que são legíveis por máquina são, em princípio, também adequados para fluir automaticamente para dentro ou para fora de um sistema ERP ou de inventário. Para uma empresa de 10 a 100 funcionários, isto significa principalmente que a pergunta "isto pode ser integrado" não é, em primeiro lugar, uma questão jurídica, mas uma questão técnica: que formato o passaporte utiliza e o software próprio consegue ler ou escrever esse formato. Veja também a página sobre em qual formato devo fornecer os dados para o passaporte de produto.

O passaporte deve estar em conformidade com uma estrutura técnica uniforme

O artigo 11 do ESPR aborda o design técnico e o funcionamento do passaporte, e remete para as especificações técnicas que a Comissão desenvolverá ainda mais. Na prática da integração, isto significa que não é possível fornecer ou recuperar simplesmente "um ficheiro próprio": existe uma estrutura padronizada subjacente, provavelmente baseada em sistemas de identificação existentes. Quem já trabalha com um sistema de codificação de artigos, faria bem em verificar como se alinha com a forma como os códigos de identificação únicos serão atribuídos no futuro — veja como atribuo a cada produto um código de identificação único". Um sistema ERP que já funciona com códigos de produto inequívocos e estáveis está numa posição mais favorável para a integração do que um sistema no qual os códigos variam por encomenda ou por cliente.

A integração funciona através de um suporte de dados, não através de uma ligação direta à base de dados

O artigo 11 também descreve que o passaporte é acessível através de um suporte de dados no produto. Este é um ponto importante para a expectativa que uma empresa pode ter de "integração": não se trata de uma ligação direta à base de dados entre duas empresas, mas de uma cadeia em que o suporte de dados (normalmente um código QR) remete para um passaporte armazenado. A integração com um sistema ERP ou de inventário está assim em dois pontos: no fornecimento de dados do produto do próprio sistema para a entidade que compila o passaporte, e na leitura dos dados do passaporte (por exemplo, na compra de aço) no próprio sistema. Mais informações sobre esse suporte estão na página como aparece o código QR do passaporte do produto no meu aço.

Os dados devem permanecer atualizados enquanto o passaporte existir

Do artigo 10 segue-se também que os dados no passaporte devem estar corretos e atualizados enquanto o passaporte existir. Para uma integração com um sistema de inventário, isto significa que o fornecimento único geralmente não é suficiente: se as propriedades de uma partida de aço mudarem, ou se for descoberto um erro, deve existir uma forma de o comunicar ao local onde o passaporte é alojado. As empresas que integram o seu sistema ERP fariam bem em considerar também por quanto tempo essa atualidade deve ser mantida — veja quanto tempo um passaporte do produto deve permanecer disponível.

Onde corre mal na prática

Os códigos de artigos internos são confundidos com a identificação oficial do produto. Um sistema ERP identifica um produto sob um SKU interno, enquanto o passaporte requer um código de identificação diferente e único. Sem uma tabela de tradução entre ambos, a confusão surge na integração, especialmente se um código interno cobre várias partidas.

As mutações de inventário não são transmitidas aos dados do passaporte. Um sistema de inventário regista, por exemplo, que uma partida de aço foi refundida, dividida ou combinada, mas essa alteração não chega automaticamente ao passaporte. Isto é muito importante na questão de se o aço é registado por lote ou por unidade — veja registro aço por lote ou por unidade — porque a unidade de registo no sistema ERP deve estar alinhada com a unidade em que o passaporte é baseado.

Os ficheiros exportados do sistema ERP não estão em conformidade com o formato exigido. Muitos pacotes ERP exportam por padrão em Excel, CSV ou uma estrutura XML própria. Sem coordenação prévia, esse arquivo não se mostra compatível com o formato necessário para o passaporte, resultando em atrasos e trabalho manual adicional.

Assume-se que a integração funciona também sem ligação à internet. Alguns sistemas de inventário no chão de fábrica funcionam parcialmente offline, por exemplo num terminal de armazém. Isso levanta a questão de saber se o próprio passaporte também deve ser consultável sem ligação; essa é uma questão separada e independente da integração com o sistema ERP. Ver o passaporte de produto também deve funcionar sem conexão com a internet.

Os direitos de acesso entre sistemas não são regulados. Uma integração significa que dados fluem entre dois ou mais sistemas, frequentemente através de um terceiro que hospeda o passaporte. Se não ficar estabelecido quem pode ver, modificar ou transmitir que dados, surge incerteza sobre a responsabilidade por um erro — uma questão que se relaciona com o modo como os dados são protegidos em trânsito, ver como garanto que os dados no passaporte de produto são seguros.

O que pode registar

Um panorama de quais campos no sistema ERP ou de inventário correspondem a quais campos no passaporte do produto, incluindo uma tabela de tradução entre códigos de artigo internos e o código de identificação único do produto.
Uma descrição do formato de exportação que o próprio sistema utiliza, e uma comparação com o formato necessário para o passaporte.
Acordos com a parte que compila ou hospeda o passaporte sobre a frequência e modo de troca de dados: uma única vez na criação, ou continuamente quando há alterações.
Um procedimento para transmitir alterações no inventário, configuração de lote ou propriedades do produto aos dados do passaporte, incluindo quem é responsável por isso.
Um panorama de quem dentro da empresa tem acesso à integração entre o próprio sistema e o passaporte, e que direitos isso comporta.
Um acordo estabelecido sobre o que acontece com a integração e o fluxo de dados se o passaporte de um produto for modificado, revogado ou substituído.

Isto não é aconselhamento jurídico. Esta página fornece informações gerais sobre a regulamentação sobre a qual esta plataforma funciona. Não conhecemos a sua situação. Em caso de dúvida sobre o seu próprio caso, consulte um jurista ou a autoridade de supervisão competente.

Escrito com IA com base nas fontes acima, verificado por um ser humano em 2026-08-22. Há algo incorreto? Avise-nos — as correções têm prioridade.