on 03-20-2013 1:12 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Em processo triangular (em teoria, nunca localizado), nao seria o caso de vc receber o XML de um terceiro?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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,
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.