cancel
Showing results for 
Search instead for 
Did you mean: 

Opinião - NF-e Entradas - XML com CNPJ destinatário desconhecido

bruno_renzo
Active Contributor
0 Kudos

Olá Pessoal, tudo bem?

Preciso aqui de uma opinião de todos aqueles que já usam o NF-e de entradas.

Como vocês sabem, o sistema possui uma tabela onde se configura todos os CNPJs próprios para que os XMLs que estão chegando possam ser validados se realmente foram emitidos contra a empresa de vocês.

Desde o começo, caso chegue um XML cujo CNPJ destinatário não tem um CNPJ correspondente nesta tabela, este era rejeitado na camada PI, nem aparecendo no monitor de entradas.

Porém, houve uma mudança de comportamento do sistema a partir do SP09 (se não me engano) e que permanece até o SP13. Quando chega um XML cujo CNPJ destinatário não tem um CNPJ correspondente na tabela de CNPJs próprios, a NF-e aparece no monitor fiscal com status de "Processo empresarial não encontrado", com o ícone de raio.

Recebemos o feedback que isto tem confundido os usuários, pois teoricamente se a Nota não foi emitida contra a empresa de vocês, mas foi enviada por engano, não há o que se fazer com essa NF-e.

Nós queremos para o SP14 voltar o comportamento anterior de barrar direto na camada PI, pois se houve algum esquecimento na hora de configurar a tabela (não deveria acontecer de jeito nenhum em produção), basta arrumar o customizing e o admin PI restartar as mensagens.

O que vocês acham? É melhor deixar entrar NF-es que não foram emitidas contra o CNPJ próprio e confundir os usuários, ou barrar direto na camada PI?

Abraços

Accepted Solutions (0)

Answers (6)

Answers (6)

Former Member
0 Kudos

Senhores,

Como a dúvida é mais voltada a deixar entrar ou não um XML no GRC no qual o CNPJ destinatário é desconhecido, não se poderia fazer uma tabela no qual cada cliente decide tal destino do XML?
Por exemplo, um flag no GRC do tipo "receber XML com CNPJ de destinatário desconhecido".

Neste caso, se um cliente optar em receber o XML com CNPJ de destinatário desconhecido, ele marca tal flag. Já o cliente que quisesse que todos os XML com CNPJ de destinário desconhecido fossem barrados no PI, bastava apenas ele desmarcar tal flag.

Se for possível isto, acho interessante que o cliente decida de acordo com a sua necessidade.

Abraços,

Bruno Duarte

eduardohartmann
Contributor
0 Kudos

Concordo com o ponto colocado pela Karen anteriormente (http://scn.sap.com/message/13938006#13938006) e a opção via parâmetro seria boa tb. Assim cada um escolhe o que quer ou não visualizar e/ou tratar.

Abraço,

Eduardo Hartmann

RafaelVieira
Active Participant
0 Kudos

Ok, mas esta opção via parâmetro teria que ser feita, em todo caso, no GRC, porque não tem como deixar isso aberto pra escolha no PI.

Então, permitindo o recebimento do XML ou via parâmetro, o PI irá transferir o XML pro GRC da mesma forma.

david_medeiros
Participant
0 Kudos

Prezados,

Eu entendo a dificuldade dos usuários em confundir-se com este tipo de problema, porém não acho viável efetuar o tratamento direto no PI para resolver isto, pois como disse o nosso caro amigo Lucas em Post anterior "O PI é só um sistema de mensageria, e a configuração de processos é aplicação". Porém uma solução simples que adotei em outros clientes foi criar um filtro no monitor das Notas Fiscais com o STATUS "21" (NF-e sem atribuição de processo empresarial) sendo assim o usuário jamais vai se confundir com este tipo de problema já que o mesmo encontra-se em um filtro/aba à parte.

Abraços.

henrique_pinto
Active Contributor
0 Kudos

Em processo triangular (em teoria, nunca localizado), nao seria o caso de vc receber o XML de um terceiro?

Former Member
0 Kudos

Bom dia!!!

Entendo que deve-se manter o recebimento e arquivamento do XML mesmo sendo CNPJ de terceiro. No caso acho que seria bom ter um processo de SIGNAUT3 (para diferenciar) com os mesmos passos do SIGNAUTH.

Isso porque:

- no caso de uma transportadora que use o SAP NF-e... ela precisa receber o XML da NF-e (o qual ela não é o destinatário da NF-e) conforme Ajuste SINIEF 17/2010,

“§ 7º Deverá, obrigatoriamente, ser encaminhado ou disponibilizado download do arquivo da NF-e e seu respectivo Protocolo de Autorização de Uso:

I - ao destinatário da mercadoria, pelo emitente da NF-e imediatamente após o recebimento da autorização de uso da NF-e;

II - ao transportador contratado, pelo tomador do serviço antes do início da prestação correspondente.”.

- outro argumento é específico da empresa, recebemos e armazenamos XML de venda a ordem para efetuar a automação da nota fiscal de remessa por conta e ordem de terceiros. Considerando que esta NF-e é copia da emitida pelo adquiriente originário, esta é uma forma de garantir que a NF é valida e a emissão conforme a legislaçao vigente.


Abraço

Karen Rodrigues

former_member182114
Active Contributor
0 Kudos

Bom dia Bruno,

Pensando pelo ponto de vista administração do B2B e não apenas do usuário e seu InBox acredito que é útil todas os XML's enviados entrarem no aplicativo. Para que quem pode decidir se é lixo ou não o faça na interface do aplicativo.

Será que alguém está erroneamente nos enviando XML's?

Será que dos que me estão enviando parte estou descartando?

Aí para colocar a cereja, um botão para Finalizar processo.

@Eduardo, Para este cenário você teria como tratar na BAdI de determinação de processo e setar um SIGHAUT2 (fazendo um filtro mais complexo pelos dados da emissora)? Pergunto pois não testei...

Atenciosamente, Fernando Da Rós

Former Member
0 Kudos

Pois é Fernando.... já forcei na badi mas não passa. Não sei se é porque neste caso não tem CNPJ do destinatário que o sistema não atribui o processo. Nunca paramos pra debugar.

Pensando mais a respeito... se for esse o motivo seria interessante na badi de determinação de processo você poder modificar o CNPJ (destinatário) e assim pode atribuir não só o SIGNAUTH mas o FLEXPR01 e assim para quem tiver interesse automatizar a entrada via desenvolvimento próprio.

Quanto a receber o XML erroneamente de outras empresas... eu acho melhor cair no SAP NF-e e então o usuário decidir o que fazer: rejeitar, finalizar, etc. e ter a opção de fazer a atualização em massa; digo selecionar varias notas e atribuir a ação!

Abraço

Eduardo Chagas

former_member182114
Active Contributor
0 Kudos

Hmm... Aí já é uma melhoria mais forte, determinar além do processo, sistema destino e tudo mais....

Bem... Vamos aguardar outras opiniões sobre o que o Bruno está precisando por agora. XML's sem a configuração no sistema devem entrar ou não?

Atenciosamente, Fernando Da Rós

former_member182114
Active Contributor
0 Kudos

Pessoal ajudem opinando o que acham. A decisão deste ponto está em andamento.

Queremos saber a opinião de vocês.

Desde já agradeço.

Atenciosamente, Fernando Da Rós

Former Member
0 Kudos

Fernando, Bruno,

Na minha opinião, o PI não deve barrar as mensagens. O PI é só um sistema de mensageria, e a configuração de processos é aplicação. Se fizermos uma analogia com o modelo OSI de comunicação, o PI seria a camada de transporte, e o NF-e a aplicação.  Se o PI recebeu a mensagem com sucesso e é válida, cabe a aplicação decidir o que é para ser feito.

Abs,

Former Member
0 Kudos

Oi Bruno

Acho que deve se manter a questão de receber e armazenar o XML. Exemplo simples.. XML de importação onde o destinatário da nota é o fornecedor.

Abraço

Eduardo Chagas

Former Member
0 Kudos

O que eu acho que pode fazer é habilitar o usuário a rejeitar o XML (manualmente via monitor ou badi) bem como deixar atribuir o SIGNAUTH ou outro processo específico mesmo quando não valida o destinatário.

Abraço

bruno_renzo
Active Contributor
0 Kudos

Eduardo Chagas wrote:

XML de importação onde o destinatário da nota é o fornecedor.

Mas neste caso a legislação obriga vocês a manterem o XML? Como o usuário sabe que aquele foi um processo de importação para vocês e não para outra empresa?

Tem algum outro exemplo?

Abs

Former Member
0 Kudos

A obrigação para armazenar é a mesma. Identificamos que a empresa é nossa pelo emitente no caso.

Abraço