cancel
Showing results for 
Search instead for 
Did you mean: 

Conselhos sobre NFe B2B melhores práticas

Former Member
0 Kudos

Olá amigos,

Estou à procura de "melhores práticas" informações práticas para a manipulação de entrada e saída NFe comunicações B2B com parceiros de negócios em PI. Que adaptadores são comuns? E-mail, FTP, HTTP? Como você lida com ambientes de teste?

Não vamos definir uma configuração PI separado para cada parceiro único, de entrada e saída?

Talvez com e-mail que pode ter uma configuração dinâmica compartilhada por todos os parceiros B2B?

Muito obrigado,

-Aaron

(Sinto muito por meu português ruim)

Accepted Solutions (1)

Accepted Solutions (1)

henrique_pinto
Active Contributor
0 Kudos

Olá Aaron,

o mais comum é o email, de longe (o que, de maneira alguma quer dizer que seja o melhor - pelo contrário). Provavelmente pela simplicidade de configuração e adoção - qualquer cliente e/ou fornecedor, por menor que seja, podem enviar/receber e-mails. Os problemas são inúmeros e óbvios: praticamente nenhuma garantia de entrega (low reliability), baixa segurança, incompatibilidade entre as inumeras maneiras de se mandar dados por email (como attachment, como texto, com/sem base64, etc.)...

Para evoluir além do e-mail, porém, é necessário maturidade dos dois lados.

Não adianta só a empresa destinatária ter vontade de receber de uma maneira mais segura sem ter fornecedores que sejam capazes de fazê-lo. Da mesma maneira, um fornecedor com vontade de estabelecer uma integração mais confiável/segura precisa q seus clientes sejam capazes e estejam dispostos a fazê-lo também. Infelizmente, no final, isso se configura como custo pros dois lados e daí acabam indo no "mais barato" (e.g. email)...

São raras as empresas que se preocuparam com desenvolver algo mais seguro. Tipicamente, o que vi foi empresas que desenvolveram web services para receber isso de maneira mais segura/confiável, e daí os fornecedores tem que se adaptar. Porém, como inevitavelmente existirão fornecedores menores que não conseguirão se adequar, a empresa acaba não escapando de ter que manter os 2 canais (e-mail e WebService, por exemplo), aumentando ainda mais o custo de manutenção.

Com relação a testes, tipicamente as empresas oferecem um e-mail único para recepção de XMLs produtivos; poucas oferecem um email de testes. As que já trabalham com web services aí sim já acabaram disponibilizando WSs de teste e produção (em alguns casos, dev, qa e produção, porém geralmente o dev acabam nao dando acesso externo aos fornecedores, só no QA e PRD).

Former Member
0 Kudos

Obrigado Henrique, que é exatamente o tipo de informação que eu procurar.

1) Existem redes de terceiros que tentam lidar com essa comunicação? Por exemplo, como Ariba modelo de rede de fornecedores (desculpe se você não está familiarizado). Enviamos um tipo de mensagem a eles. Eles frente para os fornecedores através de seus serviços de web padrão. Da mesma forma, eles agregam todas as mensagens voltar e nós obtê-lo de que um canal para todos os fornecedores?

2) Outra pergunta, qual é a pena ou reparação quando não devidamente receber ou enviar um desses com um parceiro B2B? Dizer algo sobre eles mudaram seu formato e-mail e ele parou como erro no PI. O contingência O negócio tem enquanto a equipe técnica desenvolve uma mudança no sistema?

henrique_pinto
Active Contributor
0 Kudos

1) Existem sim algumas soluções de mercado com esse propósito. P.ex. Crossgate, que foi recentemente adquirida pela SAP; Neogrid, uma solução de mercado de menor porte, etc.

2) Não há claro uma "multa" a ser aplicada caso a empresa não compartilhe, mesmo pq não está claro nem o modelo de compartilhamento. Na prática, se a empresa questioná-lo e pedir alguma informação, daí você precisa passar. O que você não pode dizer é "não tenho como atender sua demanda". Uma maneira contingencial seria alguém fazer o envio manual, e.g. fazer download manual de um XML (ou de um período, em um .zip, pelo monitor de download em massa) e daí enviar via e-mail pessoal para o destinatário, ou disponibilizar para download em algum site.

rhviana
Active Contributor
0 Kudos

Aaron,

Essa definição depende muito do time de segurança do cliente, muitos alegam que comunicação via e-mail não é algo seguro e tals.

Já tive situações que o cliente não queria via e-mail o recebimento, nesse caso tive que desenvolver um webservice utilizando HTTPS (SSL).

Já teve outra situação que o cliente não queria que o e-mail, o arquivo XML, fosse comsumido direto do e-mail, então o servidor tinha uma rotina de leitura dos arquivos XML em anexo, jogava para uma pasta local e o PI lia essa pasta e continuava o processo.

O impostante é você expor para cliente as opções que podem ser feitas, se ele não se interessar, como Henrique falou acima, sugere a contratação de empresas para fazer esse tipo de procedimento para os cenários inbound e outbound - Já passei por 3 clientes que tinham a NeoGrid fazendo o papel de leitor e emissor de XML.

Bom acho que é isso.

Valeu

Former Member
0 Kudos

Muito bom, muito obrigado pelo conselho.

O processo de XML B2B parece que vai ser propenso a erros e mudança constante.

É este também a sua experiência?

rhviana
Active Contributor
0 Kudos

Aaron,

Pelo contrario se eu entendi a sua pergunta.

O XML B2B não tem muitas mudanças, uma vez colocou em funcionamento dificilmente vai ocorrer mudanças.

O que ocorreu entre o GRC 1.0 e o GRC 10.0 foi uma mudança técnica no XML, antes ele vinha como uma string e agora vem o XML aberto, com isso você precisou adaptadar o seu b2b.

Valeu

Answers (0)