Gerar Proxy 'Z' no Software Component SAPBO SLL-NFE 10.0

[matheusog]

Olá pessoal!

É o seguinte, meu cliente tem um portal de notas todo 'Z' para B2B com fornecedores, por isso desde que migramos para o SP 15 o mesmo não vinha utilizando a solução standard de inbound, apenas uma solução Z armazenando os XML no KPRO e relacionando com a tabela /XNFE/XMLIN.

Com a subida do SP 16, tornou-se obrigatório o uso das tabelas /XNFE/INNFEHD, por isso o processo de disparo de eventos de manifestação do destinatário parou.

Devido à obrigatoriedade do SVC, subiram o SP em produção para o 16, s desde então o processo de manifesto destinatário parou de vez..

Eu estou estudando uma solução para por trás do 'Z', "standarizar" o processo para não ter mais o problema em UPDATES futuros do GRC, assim como tivemos no SP 16, porém por agora eu precisava de uma solução alternativa para não para o processo de PRD.

Eu criei uma cópia 'Z' do SI "EVENT_OPPRG_OperationProgressResponse_IB", e fiz todas as devidas configurações e alterações para que o processo de evento de manifestação do destinatário caia nesse proxy.

O problema é que eu não consigo gerar o proxy para implementar uma solução 'Z' nele, copiando a lógica standard, só que não olhando a tabela /XNFE/INNFEHD para que a tabela consiga receber o retorno de sucesso ou erro da SEFAZ.

Vocês fazem ideia do como posso gerar o proxy nesse SFWC (SAPBO SLL-NFE 10.0), ou alguma  outra sugestão de solução temporária?

O erro retornado ao tentar gerar o proxy é o seguinte:

Proxy-Generierung für Namensraum http://sap.com/xi/NFE/006 in diesem System nicht zugelassen

Nº mensagem SPRX225

Tradutor:

Geração Proxy para http://sap.com/xi/NFE/006 namespace neste sistema não é permitido

Att,

Matheus Goulart

[rhviana · Accepted solution]

Matheus boa tarde,

Na realidade você deve criar um Produto e o SWCV na SLD e colocar como dependencia o SAP BO NFE.

Nessa minha wiki explico como faz isso:

SAP GRC NFE 10.0 - Outbound B2B ( XML + Corpo de texto) dinâmico - Português (Portuguese) - SCN Wiki

Att,
Viana

[matheusog]

Valeu pela ajuda pessoal.

Isso saiu do meu colo, mas vou passar pra consultoria que está vendo a solução corretiva.

Eu agora estou trabalhando para deixar a solução standard.

Abrs!

[rhviana]

Show cara, qualquer coisa posta ai.

Abras

[former_member182503]

Matheus,

Esse portal de B2B de entrada não pode utilizar o standard?

Exemplo: gravar os arquivos recebidos dos parceiros em um diretório e você implementar a interface NFB2B como file to proxy ou algo assim?

Se a questão é fazer a chamada do proxy do evento, chame diretamente o proxy EVENT_nfeRecepcaoEvento_OB (conforme função /XNFE/008_EV_BATCH_OUT) e crie um Implicit Enhancement Point no proxy de entrada EVENT_nfeRecepcaoEventoResponse_IB (/XNFE/II_008_EVENT_NFE_REC_IB~EVENT_NFE_RECEPCAO_EVENTO_RESP) para tratar o retorno de acordo com a sua lógica.

[]'s

JN

[Former Member]

Não sei se entendi. Mas porque simplesmente não usa a interface standard?

Qual motivo de você gravar direto nas tabelas?

Abraço

Eduardo Chagas

[matheusog]

É que os processos dele eram boa parte em 'Z', eles apenas consumiam as funções que disparavam as interfaces standard para consumo do serviço, e funcionava.

O que aconteceu foi que fizeram upgrade para o SP 16, e aí o serviço de manifesto parou de funcionar em parte, devido à uma obrigatoriedade (nova validação) de ter registros na /XNFE/INNFEHD para as notas manifestadas, e o cliente não alimentava as tabelas de inbound para todas as notas de entrada, por isso em alguns casos o retorno do serviço de evento de manifesto ficam parados no GRC com erro no proxy, justamente porque é disparado uma EXCEPTION no proxy por não ter dados no INNFEHD.

Nós estamos "standarizando" o processo deles, porém por enquanto muitas notas estão sem retorno de evento de manifesto por travarem no proxy do GRC.