on 09-24-2014 1:28 PM
Pessoal,
De acordo com a KBA 2057942 - [3.10] Guideline for NF-e... existe uma recomendação expressa para que não se utilize a solução Coupled:
MPORTANT: Field “RFC Exec” must not be left blank. If you use the option 3, you’ll need to schedule a job for program J_BNFECALLRFC.
Qual será o impacto se não for usada a opção 3 e continuar neste momento ainda se utilizando da solução sem decouple. Haverá problemas na numeração? ou ela simplesmente não ocorrerá e teremos que obrigatoriamente implentar o decouple?
Oi Sergio,
A utilização do CALLRFC <> de branco é necessária para que a solução de contingência com SVC funcione.
Se vocês não usam o SVC, ainda que não-recomendável, não vejo maiores problemas - além dos já conhecidos (probabilidade de gaps de numeração, etc.). Alguém sabe de mais uma restrição/impacto?
Aí vem a pergunta: qual o impacto de alterar o callrfc para 3 (numeração automática via job)?
Se vc tem informações que são lidas em memória na criação da NF, estas precisariam ser tratadas diferentemente, talvez ler de tabelas (z ou standard)... mais algum ponto?
Abs,
Eduardo Hartmann
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Oi Pessoal,
Tem um segundo impacto que já vi em projetos além do SVC. Alguns campos do mapeamento da NF-e 3.10 não são preenchidos corretamente sem o decouple. Isso ocorre porque o mapeamento lê algumas informações de estruturas que não estão populadas quando o processo é coupled. Já vi esse erro ocorrendo com o mapeamento de impostos principalmente.
att,
Renan Correa
Cheguei a constatar esse erro quando implantei a NF-e 3.10, dava erro sem Decouple e funcionava com Decouple. Mas ao aplicar a Nota abaixo resolveu:
2026778 - [3.10] NF-e rejected with error code 255.
Acho que pode até ser que continue tudo funcionando mesmo sem Decouple na 3.10.
Abç.,
Baroni
Pessoal,
Acho que o maior problema de não usar o Decouple, independente de SVC ou não, é a Autorização de NF-e's na SEFAZ sem que o DOCNUM sequer exista no SAP.
Exemplo: A nota está sendo faturada e enviada ao GRC, o GRC recebe e envia a SEFAZ dando tudo certo, STATUS = 100. E em seguida ocorre um DUMP no ECC e o DOCNUM não persiste no Banco de Dados.
Quando acontece isso não fica nenhum registro na J1BNFE, entretanto a nota consta no GRC e na SEFAZ, e normalmente se descobre depois de um certo tempo, então, imagina o que acontece;
Abraços.
Baroni
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Mais um... só pra reforçar... rsrsrs
No inicio era uma forte recomendação.. mas existem notas antigas que deixam claro que o CALLRFC deve ter valor.
Pelo visto você teve sorte e nunca passou por problemas mas o decouple tem como objetivo evitar entre outros problemas...
- gap de numeração
- demora nas tarefas de atualização
- bloqueio de documentos na atulização do status no ERP pela mensageria
- erro de validação da NF-e no SAP NF-e
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.
Eduardo,
Neste cliente, estas falhas estão bem minimizadas, poucas ocorrências.
Mas sei da importancia, pois no cliente anterior ocorriam todas estas quase que diariamente.rsrsrs
Então não é um impeditivo continuar com o sistema coupled , com a 3.10 implantada.
Pois a intenção é implantar o decoupled assim que a 3.10 estiver instalada e estável.
Abcs
User | Count |
---|---|
15 | |
3 | |
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.