Marcos Antônio Kempf perguntou há 8 anos
Boa tarde!
Jorge Campos,
Como você é um ícone do SPED, um especialista em todos os módulos do SPED e também um conhecedor dos atalhos para levar solicitações para os coordenadores dos projetos SPED, venho através deste tópico pedir a tua ajuda.
O assunto é a utilização do arquivo XML da NF-e para B2B.
Um dos propósitos da NF-e é incentivar o B2B.
Em março de 2013 até foi publicado uma nota técnica sobre este assunto (Nota Técnica 2013.002 Distribuição de Documentos com Autorização de Uso pela SEFAZ (Incentivo ao B2B))
As tags que existem atualmente para o B2B são:
xPed – número do Pedido de Compra (tamanho C 15)
nItemPed – Item do Pedido de Compra (tamanho N 6) (sequência do item na Ordem de Compra e não o código de material do Cliente)
Este formato até pode funcionar nos segmentos onde os produtos são mais constantes.Porém no segmento calçadista, que é de moda, a rotação dos produtos e de matérias primas é muito grande e rápida e pela dinâmica exigida a tag nItemPed não se adequa.
Este formato não é seguro pois qualquer alteração de itens da Ordem de Compra por parte do cliente ou fornecedor poderá desalinhar os passos seguintes. Em vez de informar a sequência do item da Ordem de Compra, por que não informar o próprio código do produto do cliente, e assim, eliminar completamente a margem de erro.
Por não ter uma tag específica para informar o código do material do Cliente, veja a gambiarra que o setor foi obrigado a fazer: informar na tag da descrição do item uma subtag seguida do código do produto do cliente.
Veja um exemplo real:
CRAVO BOA0083 GRAFITE cProdCliente:”001413949” TIPO:P SEM LAUDO ACAB: GALVANICOQA:NORMAL BA:ONIN 00XX SEM ESC VE:EPEP EMB:CAIXA
Eu digo gambiarra, mas também sou usuário desta gambiarra e até funciona bem. Porém, tanto para o fornecedor, como para o cliente, não é fácil de implementar em seus sistemas e também não é fácil exigir que 500 fornecedores seus implementem este formato.
Sendo assim, quero dar as seguintes sugestões:
1) Na tag nItemPed alterar o tamanho de 6 para 50 e alterar o tipo de Numérico para Caracter.
Assim as empresas que querem usar o item sequencial da Ordem de Compra poderão continuar usando. E, as empresas que precisam do código do produto que foi informado na Ordem de Compra, poderão combinar com o seu fornecedor para nesta tag informar o código do produto do Cliente. Ou seja, esta tag teria função dupla.
2) Ou, criar uma tag nova (cProdCliente por exemplo) para esta finalidade.
Acredito que esta simples alteração não afetaria em nada as regras do projeto da NF-e e por outro lado alavancaria muito o B2B em milhares de empresas.
Jorge,
É possível o senhor fazer este favor e encaminhar esta solicitação para a pessoa certa lá no projeto da NF-e?
Muito obrigado.
Atenciosamente,
Marcos Antônio Kempf
Analista de Sistemas.
Marcos Antônio Kempf respondeu há 8 anos
Realmente com a criação das tags “xPed” e “nItemPed” melhorou bastante.
A minha sugestão é para melhorar mais ainda e até simplificar:
– na tag “nItemPed” aumentar o seu tamanho de 6 para 50, tornando-se uma tag multiuso, podendo informar o número sequencial do item da ordem de Compra, ou, informar o código do produto do cliente.
– Ou, criar uma tag específica para o código do produto do cliente (cProdPed por exemplo). Esta opção me parece a ideal pois deixaria as tags mais organizadas.
Com isso os participantes do B2B podem optar por qual tag utilizar:
– o número sequencial do item da ordem de Compra (nItemPed) ou
– o código do produto do Cliente (cProdPed).
Certamente se já existisse esta possibilidade a Marisa e Renner também estariam usando.
Criar uma tag a mais no arquivo XML da NF-e não é problema, ainda mais quando não tem necessidade de validação.
Vejam o exemplo do valor do ICMS.
Para definir o valor do ICMS para cada item da NF-e, existem mais de 40 tags. Cada CST tem um grupo de tags (cst, base, valor, % reduzido). Ou seja, tags super específicas.
A NF-e é um projeto que deu certo. Está funcionando muito além da expectativa inicial.
Acredito, que a NF-e juntamente com o CT-e formam hoje o maior sistema de EDI do mundo, 100% padrão e o seu uso é obrigatório.
Este maior sistema de EDI do mundo criou as tags “xPed” e “nItemPed” para permitir e incentivar o B2B.
Se o maior sistema de EDI do mundo tem também o propósito de proporcionar o B2B, por que não sugerir melhorias para o projeto?
Quem sabe sugerir mais campos.
Quem sabe uma parceria entre projeto NF-e e GS1.
Extrair o código do produto do cliente da tag “infAdProd” em qualquer posição não tem mistério. Eu também uso esta técnica, até porque muitos fornecedores do segmento calçadista, por falta de campo específico, estão informando nesta tag misturando várias informações. A dificuldade não está no meu lado. A intenção é simplificar para o fornecedor.
Muitos materiais não tem EAN por terem vida curta. É totalmente diferente de uma coca-cola. Sem EAN não tem DEPARA por EAN.
Sendo assim, independente da tag que preencher, “nItemPed”, “infAdProd” ou um campo específico, o fornecedor precisa ter em seu sistema um controle de relacionamento com a Ordem de Compra do cliente. Com DEPARA ou não, ele precisa preencher corretamente.
No meu entender, se o objetivo é automação, o campo específico para o código do produto do cliente é o mais indicado, pois é mais simples, mais organizado, menos margem de erro e mais fácil de implementar nos 2 lados. E, se precisar aparecer no DANFE, então é só informar na tag “infAdProd” também. Também gosto de máximas, principalmente o da organização: um lugar para cada coisa, e cada coisa no seu lugar.
LEIA AQUI = no texto acima o publicador removeu as TAGS, agora com *:
Desde a versão 3.X contamos com o trio *xPed*, *nItemPed* e *infAdProd*
Na *infAdProd* é que se permite ao emissor/fornecedor que ele coloque o código do comprador, entre outras informações complementares que houverem.
Alguns dirão: epa,epa,epa mas preciso de uma TAG específica!
Acredito que não, explico:
Avançamos, e muito na 3.x, antes tínhamos essas informações todas nas informações complementares, sequer era por item faturado.
Agora ao importar o XML emitido pelo meu fornecedor posso contar com o pedido e o número do item da minha ordem de compra preenchido no item faturado por ele, então SABEREI (por query na minha base no momento da importação) qual código interno espero encontrar e, se encontrar este meu código/texto dentro da TAG *infAdProd* significa que a informação BATE, tenho uma chave de verificação adicional! Pronto, não preciso me preocupar em que parte ou com que label esta informação foi descrita pelo meu fornecedor dentro da TAG *infAdProd* do item faturado por ele, só preciso encontrá-la lá.
E nada disso é customização de software do lado do emissor, são TAGs já existentes e os softwares de faturamento já os contemplam (pelo menos aqueles que seguem a manual da SEFAZ).
Fazer DEPARA sempre é dor de cabeça e quem deveria estar no compromisso de fazê-lo é o COMPRADOR e não o fornecedor, afinal você conhece o seu estoque, já para o seu fornecedor esse código não significa nada. A única forma de garantir DEPARA efetivo seria contar com um cadastro nacional de produtos (lacuna que a GS1 Brasil tenta preencher aqui no país).
De toda forma a NF-e é só uma parte do B2B, antes dele devem vir a sua ORDEM de COMPRA e o DESCRITIVO DA CARGA do fornecedor. Os volumes entregues por ele não estão abertos na NF-e (com a informação do seu conteúdo), então importar a NF-e serve para uma pré validação das suas OCs, para a totalização e para uma autorização do recebimento, mas não para a conferência do físico.
Vale lembrar que varejo de moda já faz esta solicitação à industria de calçados, confecções e acessórios a um bom tempo e que você Marcos, já deve estar emitindo NF-es para eles.
Vamos a DOIS exemplos, com graus de integração diferentes para importar NF-e:
SIMPLES, que eu prefiro: Marisa = cobra *xPed* e *nItemPed* = você fatura seus itens despachados colocando os dados das ordens de compra da Marisa;
MAIS COMPLEXO, desse eu fujo quando posso (depende do cliente): Renner = cobra *xPed*, *nItemPed* e *infAdProd* = você fatura seus itens colocando os dados das ordens de compra da Renner e é obrigado a administrar INTERNAMENTE o DEPARA do seu cliente Renner.
O modelo da Marisa é o mais fácil de implementar, de carga interna de trabalho menor.
Quanto à precisão sou obrigado a reconhecer que o da Renner, de 3 chaves, é mais robusto, mas do ponto de vista prático você ainda têm que contar com o faturamento correto por parte do emissor, ele pode errar tanto o *infAdProd* quanto o *xPed* ou no *nItemPed*
Eu costumo aplicar a máxima: o que faço na minha expedição cobro no meu recebimento. Procuro tocar o EDI com as TAGs que já existem. Dá pra tocar a automação com assertividade só *xPed* e *nItemPed* ? Claro que dá!, com elas dá pra fazer o DEPARA via machine learning (via código/armazenamento por repetição) e não obrigando comprador e vendedores a armazenarem códigos que não são deles. Se, sob a supervisão de um humano o primeiro DEPARA daquele fornecedor armazenar o seu código (da sua OC alcançado por pedido e item seus) e o código dele (código de produto dele da NF-e) as próximas transações já estarão resolvidas. Você passou o DEPARA para o seu lado a partir das primeiras OC e NF-es trocadas. Se houver tag EAN preenchido melhor ainda.
Já imaginou se todos os seus clientes pedirem pra você faturar com o código deles? Pois é, se não quero isso na minha expedição também não cobro o meu código interno nas minhas compras . Quando o mercado for robusto o suficiente, como acontece com supermercados e afins, dá pra amarrar no GTIN (antigo EAN) eliminando a necessidade de buscar pelo código do comprador na *infAdProd*, as compras, que ocorrem ANTES da emissão da NF-E, deveriam ser SEMPRE pelo código do fornecedor (o EAN, agora chamado de GTIN), e num cenário misto (de quem têm e de quem não têm o GTIN) o jeito é ir tocando com as informações possíveis. Dá pra ir mesclando, até porque você não contará tão cedo 100% das emissões dos seus fornecedores com o seu código de comprador e também não terá tão cedo 100% dos seus fornecedores com o GTIN. A vantagem de quem estiver trabalhando com GTIN é poder contar com o SSCC (barras do volume/unidade logística), e aí sim você terá ferramenta para, além de importar o XML da NF-e, tocar a automação no seu recebimento físico (conferência).
Desde a versão 3.X contamos com o trio , e
Na é que se permite ao emissor/fornecedor que ele coloque o código do comprador, entre outras informações complementares que houverem.
Alguns dirão: epa,epa,epa mas preciso de uma TAG específica!
Acredito que não, explico:
Avançamos, e muito na 3.x, antes tínhamos essas informações todas nas informações complementares, sequer era por item faturado.
Agora ao importar o XML emitido pelo meu fornecedor posso contar com o pedido e o número do item da minha ordem de compra preenchido no item faturado por ele, então SABEREI (por query na minha base no momento da importação) qual código interno espero encontrar e, se encontrar este meu código/texto dentro da TAG significa que a informação BATE, tenho uma chave de verificação adicional! Pronto, não preciso me preocupar em que parte ou com que label esta informação foi descrita pelo meu fornecedor dentro da TAG do item faturado por ele, só preciso encontrá-la lá.
E nada disso é customização de software do lado do emissor, são TAGs já existentes e os softwares de faturamento já os contemplam (pelo menos aqueles que seguem a manual da SEFAZ).
Fazer DEPARA sempre é dor de cabeça e quem deveria estar no compromisso de fazê-lo é o COMPRADOR e não o fornecedor, afinal você conhece o seu estoque, já para o seu fornecedor esse código não significa nada. A única forma de garantir DEPARA efetivo seria contar com um cadastro nacional de produtos (lacuna que a GS1 Brasil tenta preencher aqui no país).
De toda forma a NF-e é só uma parte do B2B, antes dele devem vir a sua ORDEM de COMPRA e o DESCRITIVO DA CARGA do fornecedor. Os volumes entregues por ele não estão abertos na NF-e (com a informação do seu conteúdo), então importar a NF-e serve para uma pré validação das suas OCs, para a totalização e para uma autorização do recebimento, mas não para a conferência do físico.
Vale lembrar que varejo de moda já faz esta solicitação à industria de calçados, confecções e acessórios a um bom tempo e que você Marcos, já deve estar emitindo NF-es para eles.
Vamos a DOIS exemplos, com graus de integração diferentes para importar NF-e:
SIMPLES, que eu prefiro: Marisa = cobra e = você fatura seus itens despachados colocando os dados das ordens de compra da Marisa;
MAIS COMPLEXO, desse eu fujo quando posso (depende do cliente): Renner = cobra , e = você fatura seus itens colocando os dados das ordens de compra da Renner e é obrigado a administrar INTERNAMENTE o DEPARA do seu cliente Renner.
O modelo da Marisa é o mais fácil de implementar, de carga interna de trabalho menor.
Quanto à precisão sou obrigado a reconhecer que o da Renner, de 3 chaves, é mais robusto, mas do ponto de vista prático você ainda têm que contar com o faturamento correto por parte do emissor, ele pode errar tanto o quanto o ou no
Eu costumo aplicar a máxima: o que faço na minha expedição cobro no meu recebimento. Procuro tocar o EDI com as TAGs que já existem. Dá pra tocar a automação com assertividade só e ? Claro que dá!, com elas dá pra fazer o DEPARA via machine learning (via código/armazenamento por repetição) e não obrigando comprador e vendedores a armazenarem códigos que não são deles. Se, sob a supervisão de um humano o primeiro DEPARA daquele fornecedor armazenar o seu código (da sua OC alcançado por pedido e item seus) e o código dele (código de produto dele da NF-e) as próximas transações já estarão resolvidas. Você passou o DEPARA para o seu lado a partir das primeiras OC e NF-es trocadas. Se houver tag EAN preenchido melhor ainda.
Já imaginou se todos os seus clientes pedirem pra você faturar com o código deles? Pois é, se não quero isso na minha expedição também não cobro o meu código interno nas minhas compras . Quando o mercado for robusto o suficiente, como acontece com supermercados e afins, dá pra amarrar no GTIN (antigo EAN) eliminando a necessidade de buscar pelo código do comprador na , as compras, que ocorrem ANTES da emissão da NF-E, deveriam ser SEMPRE pelo código do fornecedor (o EAN, agora chamado de GTIN), e num cenário misto (de quem têm e de quem não têm o GTIN) o jeito é ir tocando com as informações possíveis. Dá pra ir mesclando, até porque você não contará tão cedo 100% das emissões dos seus fornecedores com o seu código de comprador e também não terá tão cedo 100% dos seus fornecedores com o GTIN. A vantagem de quem estiver trabalhando com GTIN é poder contar com o SSCC (barras do volume/unidade logística), e aí sim você terá ferramenta para, além de importar o XML da NF-e, tocar a automação no seu recebimento físico (conferência).