B2B Mail - XML para transportadora

[Former Member]

Bom dia Srs,

Mais uma vez preciso da ajuda dos mestres...rs

De acordo com o ajuste SINIEF nº 8, de 9.07.2010 u2013 DOU 13.07.2010, a clausula 7 diz o seguinte:

I u2013 o § 7º do caput da cláusula sétima :

u201C§ 7º O emitente da NF-e deverá, obrigatoriamente, encaminhar ou disponibilizar download do arquivo da NF-e e seu respectivo Protocolo de Autorização de Uso ao destinatário e ao transportador contratado, imediatamente após o recebimento da autorização de uso da NF-e.u201D;

Podemos dar várias interpretações para este ponto. Há quem diga que, apenas disponibilizar o XML para a transportadora qdo solicitado, já é o bastante; Pelo simples fato de deixar armazenado o xml através de um canal de comunicação direta.

Mas o que me intriga, é a seguinte frase: "imediatamente após o recebimento da autorização de uso da NF-e."

Não quero gerar mais discussão, pois já existem outras threads para esta questão.

O problema é que diante desta intrigante frase, a empresa quer enviar o XML para a transportadora, da mesma maneira que é efetuado para o cliente via B2B, no ato da aprovação.

Temos configurado a solução proposta pelo Henrique, para o envio do email via B2B Sender Mail.

Minha questão é: Gostaria de entender melhor, o funcionamento desta solução. Principalmente, em que ponto o email do cliente é chamado e emito o XML para o cliente. Esta explicação foi solicitada pelos responsáveis da empresa e não consegui entender a lógica deste processo para explicar para eles.

Agradeceria imensamente, se pudessem dar um explicação rápida sobre o B2B Sender Mail.

Grato,

Ricardo

[henrique_pinto]

Ricardo,

a funcionalidade B2B standard do GRC é executada logo após a aprovacao da NFe (ou cancelamento) pela SEFAZ. Neste caso, caso o CNPJ do cliente esteja configurado e flagado como ativo na /XNFE/TB2B (via SPRO), a interface assincrona NTB2B (ou CTB2B) será startada e enviada ao PI.

No PI, segundo o desenho standard, você deveria entao ter um conditional routing baseado no CNPJ do recebedor (campo das interfaces NTB2B/CTB2B) e configurar todos os seus clientes como Parties e colocar os dados de comunicacao (e.g. email) em um canal de comunicacao dessa party, no Integration Directory do PI.

Diante do grande trabalho manual/de manutencao que esse approach exige, propus uma alternativa onde nao é necessário manter uma party/canal de comunicacao para cada cliente no PI, mas apenas party/canal genericos e dinamicamente, em tempo de execucao, chamar uma RFC Z que poderia ler o dado de comunicacao (e.g. email) a partir do, por exemplo, cadastro do cliente. O campo chave seria o CNPJ, ou seja, a RFC Z identifica o cliente pelo CNPJ (campo tax code 1), lê o email (previamente gravado em um campo pre-determinado) e retorna o email para o PI, que entao usa esse dado dinamico como destinatario do e-mail enviado pela interface B2B.

Note que o ponto em que o processo é chamado nao muda, continua como no standard, apenas propus uma mudança na maneira de como obter os dados de comunicacao (dinamicamente em vez de "hard coded").

Nesse sentido, como complemento da solucao B2B proposta nesse artigo, propus algumas modificacoes para poder enviar o email ao transportador neste wiki: NFE Outbound B2B - sending the XML to the carrier (dynamic configuration). Existem algumas ressalvas, por exemplo: nao funciona pro XML de cancelamento*, só funciona se o B2B já estiver ativo para o destinatário da nota etc. (todas estao descritas no wiki). Ainda, a RFC Z proposta acima tem que ser estendida para poder ler o email do cadastro de fornecedores (a transportadora está no ERP como um vendor de serviços), a partir do CNPJ da transportadora, conforme detalhado no wiki.

Abs,

Henrique.

• A lei hoje só exige o envio p/ a transportadora do XML da NFe, nao o de cancelamento, entao isso nao seria de fato um problema.

[Former Member]

Henrique,

Fico imensamente grato por sua pronta resposta.

Realmente é de grande ajuda e tenho certeza que sua explicação ajudará outros companheiros em dúvidas.

Parabéns pelo excelente trabalho,

Grato,

Ricardo

[Former Member]

Henrique,

Estou montando uma apresentação sobre a forma de como o B2B se comunica.

E com base em suas informações descritas, consegui rastreá-los; Porém sugiram dúvidas:

1- Assim que o processo de criação da invoice no ERP é finalizado com status 100, a nota é enviada para o GRC, via RFC.

1º Dúvida: Esta RFC é efetuada com o ZNFE_READ_EMAIL ou was_rfc_rcv?

*ERP Possui a função ZNFE_READ_EMAIL (SE37)

*GRC Possui a função ZNFE_READ_EMAIL (Integration Builder - Imported Objects)

3- Com a conexão estabelecida, o GRC pega as informações da NFE na tabela: /XNFE/NFEHD.

*Os campos de informações importantes, seriam: ID,versnum, versium,TPEMIS e CNPJ_DEST.

4- Com estas informações, o GRC executa a função: /XNFE/RESEND2_B2B (SE37).

5- Esta função chama a tabela /XNFE/TB2B, que consulta os CNPJs B2B cadastrados na SPRO.Em seguida, comparam com status da nota com status 100.

6- Com o CNPJ em mãos, o GRC consegue identificar o email do destinatário, acrescentá-lo ao campo do XML e enviá-lo ao SEFAZ.

2º Dúvida: Sei que todos os processos de criação e verificação, estão atrelados ao Vendor Master (XK03), Custumer Master (XD03) e SPRO.

--> Continuação

Edited by: Ricardo - Basis on Aug 9, 2010 4:02 PM

[Former Member]

O que não consegui entender, é: Em que momento o GRC verifica e identifica o email do fornecedor no campo do XML?

Seria no item 5, mencionado acima?

Em resumo e só para conhecimento, já temos um cenário criado e funcionando perfeitamente:

1- Component Version (SCV_NFE , 1.0 of sap.com),

2- External Definition (NTB2B_NFeToB2BReceiverMail): com 4 elements (CNPJrec, procNFEStr, eMail e NumNFE),

3- Message mappings (MM_NTB2B_WebAS_Outbound_B2B_NFe): faz a ponte entre o source e o target message, via Interface Mapping NTB2B_procNFe_TO_procNFe,

4- Imported Archives (NTB2B_NFeToB2BReceiverConverter): onde possui o CLASS e o JAVA importados,

5- Message Interfaces (NTB2B_procNFe_OB): onde o contexto dos objetos CNPJrec e procNFEStr,foram criados,

6- Por fim, temos um Communication Channel (NFeXML_Mail_Receiver_CC): que se encarrega de entregar o XML para o destinatário.

Peço à todos que me corrijam se houver alguma informação infundada, nas observadas acima e acrescente alguma outra que venha ser relevante ao processo B2B.

Mais uma vez, muito obrigado pela atenção.

Ricardo,

[henrique_pinto]

Ricardo,

você está misturando tudo.

- O B2B nao é de maneira alguma estartado pelo ERP, o GRC o faz automaticamente qdo volta a aprovacao. Nao existe isso de o "ERP enviar o XML para o GRC". O ERP nunca tem o XML.

- WAS_RFC_RCV x ZNFE_READ_EMAIL: Vc estah confundindo communication channel com a RFC em si. Nao entendi sua pergunta.

- processo com o : isso é uma customizacao específica de vocês, nao é sugerido no artigo em questao a utilizacao do mesmo. Se vocês utilizam esse campo pra passar o email, entao a sua UDF no message mapping tem que ser modificada de acordo para ler esse campo.

etc. etc. etc.

Abs,

Henrique.

[Former Member]

Henrique, obrigado por sua pronta resposta!

- O B2B nao é de maneira alguma estartado pelo ERP, o GRC o faz automaticamente qdo volta a aprovacao. Nao existe isso de o "ERP enviar o XML para o GRC". O ERP nunca tem o XML.

R.: Sei disto.. Sei que o ERP não possui XML, talvez não tenha me expressado direito. É justamente este ponto onde está minha dúvida.

2º Dúvida: Sei que todos os processos de criação e verificação, estão atrelados ao Vendor Master (XK03), Custumer Master (XD03) e SPRO. O que não consegui entender é, em que momento o GRC verifica e identifica o email do fornecedor.

Como dito anteriormente, hoje já possuimos uma solução implementada e funciona perfeitamente. Como não estive aqui na implementação, estou tentando entender melhor este processo!

Grato,

[henrique_pinto]

O que está proposto no artigo é que, depois de aprovada, o GRC dispara a interface NTB2B (de acordo com as definicoes da /XNFE/TB2B), mandando o XML ao PI, juntamente com a informacao do CNPJ do recebedor.

No PI, a ideia é chamar a RFC ZNFE_READ_MAIL, atraves do canal de comunicacao WAS_RFC_RCV, lá no ERP, e essa RFC que contem o condigo que deve avaliar nos cadastros qual o email, a partir do CNPJ.

Abs,

Henrique.