cancel
Showing results for 
Search instead for 
Did you mean: 

B2B Versão 2.0

Former Member
0 Kudos

Senhores, alguém sabe dizer se preciso mesmo configurar o cenário do B2B para nova versão? Pois pelo que vi, não há nenhuma mudança que exija essa configuração. Estou errado?

Obrigado

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Henrique,

Fizemos a configuração do 006 aqui no cliente (a configuração da 005a já funcionava). Quando fomos testar, enviamos tanto uma NFe 1.x quanto uma NFe 2.0. Ambos os cenários se comportaram de forma idêntica, para as NFes (nfeProc). Conversando com a área responsável aqui do cliente, iremos manter apenas a configuração da 006, desativando a configuração da 005a. Podemos fazer isto, ou há a possibilidade de haver alguma diferença que não detectamos nos testes?

Abs.

Andre Monteiro

henrique_pinto
Active Contributor
0 Kudos

André,

vc manteve 2 communication channels, certo? (a configuracao comm channel x sender agreement é necessariamente 1:1).

Nesse caso, vc configurou o mesmo email nos 2?

Abs,

Henrique.

Former Member
0 Kudos

Olá Henrique,

O teste que o André comentou foi o seguinte: aqui no cliente já tinha a configuração de recebimento de email do fornecedor na versão 1.10, o que eu fiz foi enviar para o mesmo email configurado uma nota na versão 1.10 e uma nota na versão 2.00, e as duas foram carregadas no monitor do GRC. Depois, fiz a configuração do cenário 006, utilizei o mesmo email que estava utilizando na versão 005a, mas modifiquei a senha no 005a para não ativar esse cenário, e fiz a mesma coisa para a versão 006, mandei uma nota de cada versão e as duas foram carregadas no monitor do GRC. Como isso acontenceu acreditamos que não precisamos deixar ativo os dois cenários (005a e 006) em produção, e nem precisaremos criar dois emails, um para cada versão. A nossa dúvida é se alguma coisa vai mudar, e a partir de alguma data a versão 006 só vai carregar XML na versão 2.00 mesmo.

Abrs,

Cris.

henrique_pinto
Active Contributor
0 Kudos

Entao, resumindo, vc criou 2 communication channels pro mesmo email, mas só vai deixar 1 ativo de cada vez, é isso?

Se for, até dá certo sim.

O problema é garantir que com certeza vc nao terá os 2 ativos ao mesmo tempo.

Só que a dúvida era justamente como fazer para os 2 cenarios (005a e 006) estarem ativos ao mesmo tempo E com o mesmo email. Assim nao entendi a relevancia do cenario descrito por vocês.

Abs,

Henrique.

Former Member
0 Kudos

Oi Henrique,

Acho que não expliquei direito, mas o caso é o seguinte, tanto a configuração 005a como a configuração 006 receberam os dois XML (versão 1.10 e 2.00). Ou seja, eu só vou deixar a configuração ativa do cenário da 006 com um communication channel, com um email, e nesse email vou receber os dois tipos de XML (1.10 e 2.00) porque está carregando os dois no monitor do GRC, mas só o cenário 006 vai estar ativo entendeu?

É essa a nossa dúvida, porque está carregando os dois XML se eles são de versões diferentes, mas eu fiz teste e carregou, a minha dúvida é se isso vai parar de funcionar mais pra frente.

Abrs,

Cris.

henrique_pinto
Active Contributor
0 Kudos

Oi Cris,

entendi agora.

De fato, essa "feature" de a interface 006 tb processar XMLs no layout 1.10 nao era prevista.

Como no PI 7.0 nao há validacao de XSD, o mapping funciona provavelmente pq os nomes e namespace das tags permanecem os mesmos. Se vc migrar pro PI 7.1, é possível que isso já falhe.

Ainda, se o mapping eventualmente falhar para algum campo, note que isso nunca vai ser "corrigido" pelo suporte da SAP, pois é um miss use da mesma interface para processar XMLs parecidos mas nao 100% compativeis.

E finalmente, se vocês implementarem o NFE 10.0, que processa NFes de entrada, daí isso morre de vez, pois o proxy de entrada é mudado radicalmente, e passa a ler todos os campos. Com ctz vc teria exception no mapping nesse caso. Mas até o 10.0 sair e vocês estarem em projeto, o layout 1.10 já vai ter sido descontinuado, entao nao vai ser um problema crítico.

Abs,

Henrique.

Former Member
0 Kudos

Oi Cristina,

Para receber as duas versões do XML no mesmo e-mail, você realizou alguma customização, por exemplo, a customização de criar um SWCV e realizar modificações nos Interfaces Mapping (conforme sugestão do Henrique) ?

Lembro que quando fiz os primeiros testes, os XMLs das duas versões até apareciam no Monitor, porém não realizava a consulta na Sefaz (para validação do Status) para as duas versões do XML, apenas para a versão do cenário transferido.

Só consegui atingir isso realizando as customizações nos Interfaces Mappings e no Interface Determination.

Abs.,

Cristian.

former_member182114
Active Contributor
0 Kudos

Oi Pessoal,

Não faz sentido estar funcionando. Como uma interface que espera 006 irá processar 005A?

Os códigos "do outro lado" esperam campos preenchidos conforme 006 e não 005A, por isso deve-se fazer o roteamento previamente antes de chamar as interfaces NFB2B e CFB2B conforme a namespace do XML entrante.

Atenciosamente, Fernando Da Ró

henrique_pinto
Active Contributor
0 Kudos

Fernando,

nao testei, mas talvez funcione pq o mapping do cenario NFB2B é bem simples, e no PI, o mapping funciona se ele é capaz de achar a tag com nome E namespace iguais ao esperado pelo mapping, abaixo da estrutura. Ele nao vai validar se o valor do atributo versao está de acordo com o XSD, desde que o campo que ele espera esteja debaixo do nfeProc/NFe/infNFe/etc... Só achei estranho que o mapping falhe pro CNPJ de destinatário (a estrutura do campo nao mudou de um layout pro outro).

E o check de status pode sim funcionar para ambos, pois conforme já falamos, você pode consultar o status de uma NFe da versao 1.10 ou 2.00 através do serviço nfeConsulta2 (versao 2.00 da interface de consulta de status de nfe). Como o unico campo que é de fato mapeado do GRC para o PI para consumir este serviço é a chave de acesso, vai tudo ok.

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Bom dia,

A parte da consulta sim, funfa sem problemas pois é a partir da chave de acesso.

O que não estava entendendo como pode ser possível é passar um XML 1.10 por um canal preparado para 2.00, que chama um proxy 2.00. O pepino que estava vendo era na verdade chegar no ABAP Proxy, mas olhei agora e vi que chega string, então sim, se o PI conseguir fazer o ABAP também fará, porém ficará com a informação errônea que aquele layout é 2.0 pois é atribuido conforme a interface que recebe.

Atenciosamente, Fernando Da Ró

henrique_pinto
Active Contributor
0 Kudos

Isso! No NFE 1.0, o XML vai como string, dentro de uma interface cujo message type é do namespace common, e que portanto independe de versao do layout da NFe.

Como falado, no 10.0 isso vai mudar, entao provavelmente vai deixar de funcionar.

Abs,

Henrique.

henrique_pinto
Active Contributor
0 Kudos

Vc vai ter que reconfigurar nao só o B2B, mas como todos os cenarios do XI.

Os cenarios NTB2B/CTB2B que vc tem hoje sao para o namespace 005a, vc precisa tb para o cenario 006.

Abs,

Henrique.

Former Member
0 Kudos

Henrique, os cenários já estão configurados e funcionando, a minha dúvida é que tanto a função B2B incoming da 006, quanto da 005a chamam a mesma função: /XNFE/RECEIVE_INCOMING_B2B.

Por isso não vejo razão de ter 2 channels apontando para o mesmo diretório de notas. Só quero confirmar que, se eu ativar o b2b incoming da 006 e desabilitar o da 005, as notas da 005 seguirão entrando normalmente.

Grato

henrique_pinto
Active Contributor
0 Kudos

Nao, vc precisa dos 2 proxies ativos pois cada um é baseado num XML diferente.

E na verdade, na real, vc precisaria de 2 comm channels diferentes (i.e. 2 emails diferentes) para cada versao de XML.

Na verdade, isso é um ponto que eu já estava pensando em analisar e propor uma solucao no SDN.

Vou evoluir a idéia, mas hj é de fato um problema.

Abs,

Henrique.

Former Member
0 Kudos

Henrique,

Você conseguiu evoluir a idéia em relação ao cenário B2B de Incoming ? ou em caso de precisarmos ter as duas versões funcionando, será preciso além dos 2 communication channels diferentes , 2 e-mails diferentes tb (sendo 1 cc e 1 e-mail para cada versão) ?

Obrigado.

Abraços,

Cristian.

henrique_pinto
Active Contributor
0 Kudos

Oi Cristian,

confesse que nao tive tempo de escrever nada.

Mas na verdade, a ideia era fazer algo bem similar ao que está proposto no artigo sobre B2B incoming que já havia escrito há um tempo atras, para poder receber num mesmo endereço de email tanto os XMLs de NFe quanto de cancelamento.

A ideia era seguir na mesma linha, manter uma unica interface de origem e testar/propor algumas conditions a mais no interface determination para determinar a interface de destino correta.

Algo do tipo:

if <NFe> EX and versao = 1.10, interface destino = NFE 005a
if <cancNFe> EX and versao = 1.07, interface destino = CANC 005a
if <NFe> EX and versao = 2.00, interface destino = NFE 006
if <cancNFe> EX and versao = 2.00, interface destino = CANC 006

Nao sei se essas condicoes funcionam exatamente do jeito q estao, teria q testar e evoluir a ideia a partir daí.

Abs,

Henrique.

Former Member
0 Kudos

Oi Henrique,

Tentei seguir a linha que você sugeriu, porém sem sucesso.

Tentei abrir o Interface Determination do namespace 006 para incluir as interfaces relacionadas ao nampespace 005a e criar as regras, inclui uma nova linha selecionando a interface na coluna Inbound Interface, porém ao tentar selecionar o Interface Mapping não aparece as interfaces do namespace 005a.

Você teria mais alguma sugestão ?

Obrigado.

Abs.,

Cristian.

henrique_pinto
Active Contributor
0 Kudos

Vc criou um interface mapping na mao, com interface de destino NFE 005a e origem NFE ou CANC 006, da mesma maneira que proposto no artigo para a origem CANC 005a?

Esses interface mappings alternativos nao existem por default, tem que ser criados similarmente ao que foi feito no caso proposto no artigo.

No caso, vc pode modificar os interface mappings NFE e CANC do namespace 006 pra ter interface de origem = NFE 005a, ou pode criar do zero mesmo. De qq maneira, vc vai ter q fazer no seu SWCV Z (similarmente ao proposto no artigo).

Abs,

Henrique.