Francisco IBS

Estranho gerei algo como imagino que vc tentou e deu certo enviando para SC? 42180572378391000193554000000006601538804287-nfe-Proc(NFe.660).xml

Bom Dia... Tente criar 1 "detPag" para cada "dup" que vc criou, deve validar.

Pois então, algum problema tinha, mais hj de manhã estava funcionando td corretamente como o esperado. Testes feitos apenas para SC.

Seguindo a dica de @vinicius keller parou de ocorrer o erro em nDup mais não validou dando outra rejeição, então entrei em contato com CAF que retornaram o seguinte: Boa Tarde... Estou tentando validar uma Nota no Layout 4.0 e estou recebendo o seguinte rejeição: 857 - Rejeicao: Numero da parcela invalido ou nao informado Pelo que da a entender essa tag nDup - Número da Parcela, seria a sequencia da parcela para o documento? É um erro na estrutura do XML ou algo do WS? Resposta Prezado Francisco O erro é devido ao fato da SVRS ainda não ter implantado a Nota Técnica 218.002 na versão 1.50, a previsão é para a implantação em homologação entrar amanha (16/05), é para produção deve ser estendido o prazo para 28/05. Favor aguardar a implantação para efetuar novo teste em homologação. Então o negócio é esperar pra testarmos amanhã.

Testes feitos em SC 04/05/2018 as 08:00 ainda não estava com o WS Homologação atualizado, se mantem o retorno de rejeição 867.

Obrigado pelo retorno Daniel, agora então ficamos na mão do SEFAZ.

Boa Tarde @José Carlos Buss saberia me informar se compilando em 64bits lhe resolveu o problema, se sim qual o tamanho do arquivo/quantidade de itens que chegou a testar? @Daniel Simoes vc comentou anteriormente que não é possível fazer fazer isso da forma atual que o ACBr trata/processa o arquivo para assinar, certo? Pensam em fazer alguma alteração, ou devido a questão do tamanho do arquivo irão aguardar que o estado altere a rotina? Poderias sugerir alguma outra forma de fazer isso?

O integrador estava no projeto apenas não estava associado, associei e passou a funcionar, fica a dica e a sugestão para ajuste no svn.

Alguém está conseguindo usar o exemplo delphi? O erro reportado pelo EvandroMira tbm ocorreu aqui e fui testar as funções da aba MFE e os 4 botões estão me gerando um acesso violento(talvez devido ao primeiro erro).

Obrigado Tulio, estava com o mesmo problema e já tinha baixado do git e do SVN umas 5 vezes deletando td e recarregando e não tinha dado certo, fazendo o Uninstall do pacote funcionou.

Bom Dia... Desculpe a demora, mas precisei testar novamente a rotina já que parou de funcionar, creio que alguma nota técnica ou atualização no WS possa ter corrigido a "falha" que deixava não enviar a tag "vPag", quando testei isso devíamos estar na "Nota Técnica 2016.002 - v1.30". Não utilizando as finalidades 3 e 4(Ajuste e Devolução) parece que é obrigado informar o valor do pagamento que é o que da a entender na NT. Não querendo incomodar mais @BigWings ou @Italo Jurisato Junior saberiam algo mais sobre isso? Dou o exemplo de uma nota de transferência não "existe" valor de pagamento e a finalidade da NFe pra esse caso não se encaixa no 3 ou 4, como tratar isso? Sei que não é culpa do ACBr mais questiono já que isso já esta em produção, como estão fazendo com esses casos? Transferencia.xml

Bom Dia... Você realizou a alteração que passei no inicio do post?

Note que o problema que comentei é no caso de vc estar utilizando "tPag = 90= Sem pagamento", vc postou um xml com vários tipos e formas de pagamento, não tem nada haver com a situação reportada no tópico.

Tarde Jairo, a questão é que vc precisa mudar a unit "pcnNFeW" no procedimento "TNFeW.Gerarpag". Se observar o comentário do Guimaraes ele resolvou o problema da mesma forma que eu. Pelo que deu a entender vc postou uma parte do código do seu sistema e o problema esta no tratamento que o componente estava fazendo, só ir na Unit e no procedimento, adicionar o if que irá resolver. PS: A unit com a alteração esta em anexo, fiz o update no dia da postagem para ver se não estava com o fonte desatualizado.

Bom Dia... Estou realizando alguns testes na NFe 4.0 e ao tentar utilizar "tPag = 90= Sem pagamento" não informando assim valor dos pagamentos estava tendo o retorno: 865 - Rejeicao: Total dos pagamentos menor que o valor total da nota A estrutura no XML fica assim: <pag> <detPag> <tPag>90</tPag> <vPag>0.00</vPag> </detPag> </pag> Fiz uma alteração na "pcnNFeW" no procedimento "TNFeW.Gerarpag" alterando a programação de: Gerador.wCampo(tcStr, 'YA02', 'tPag', 02, 02, 1, FormaPagamentoToStr(nfe.pag.tPag), DSC_TPAG); Gerador.wCampo(tcDe2, 'YA03', 'vPag', 01, 15, 1, nfe.pag.vPag, DSC_VPAG); Para: Gerador.wCampo(tcStr, 'YA02', 'tPag', 02, 02, 1, FormaPagamentoToStr(nfe.pag.tPag), DSC_TPAG); if (NFe.pag.tPag <> fpSemPagamento) then Gerador.wCampo(tcDe2, 'YA03', 'vPag', 01, 15, 1, nfe.pag.vPag, DSC_VPAG); Assim gerando um novo XML que validou. Nova estrutura do XML ficou: <pag> <detPag> <tPag>90</tPag> </detPag> </pag> Alteram no SVN? pcnNFeW.pas

Obrigado Italo assunto encerrado podemos fechar o tópico.

Entendi a confusão agora. Ficou assim por que é o valor padrão do objeto, como ele não conseguiu ler o retorno ele acaba soltando as mensagens com as variáveis no valor padrão, nulo e no caso do ambiente ali 1... Mais pode observar na imagem a cima das mensagens em branco com o ambiente 1, que o retorno do WS esta correto com o "<tpAmb>2</tpAmb>". Note que depois que fiz a alteração no fonte o retorno veio o esperado(última imagem). Minha dúvida é se mais alguém teve o mesmo problema, mais alguém estaria realizando os testes com a versão 4.0 ?

Desculpe Juliomar ou eu não lhe entendi ou me expressei mau, mais não estou utilizando nada em produção é tudo homologação já que produção só entra em vigor 02/10/17(Se não adiarem novamente). Você conseguiu fazer um enviar a Confirmação do manifesto utilizando a versão 4.0 da NFe pelo exemplo do ACBr? Pelo que consegui identificar o retorno na versão 4.0 é diferente e precisaríamos alterar o fonte, não?

Bom Dia... Estou testando as rotinas para utilizar a NFe 4.0 e ao usar o recurso de manifesto no Exemplo do ACBr o botão "Manif. Dest. - Conf. Operação" não tive sucesso ao utilizar a configuração da NFe 4.0. Voltei a configuração para 3.10 realizando a mesma rotina e funcionou. Pelo que identifiquei na Unit "ACBrNFeWebServices" na função "TNFeEnvEvento.TratarResposta" o retorno(FPRetornoWS) é diferente, em vez de "nfeRecepcaoEventoResult" vem "nfeRecepcaoEventoNFResult". O código original na rotina "TNFeEnvEvento.TratarResposta" é: FPRetWS := SeparaDadosArray(['nfeRecepcaoEventoResult', 'nfeResultMsg'],FPRetornoWS ); Fiz a alteração para ficar: FPRetWS := SeparaDadosArray(['nfeRecepcaoEventoResult', 'nfeResultMsg', 'nfeRecepcaoEventoNFResult'],FPRetornoWS ); E passei a ter o mesmo retorno(o retorno esperado) que quando utilizado a configuração para 3.10. Imagem 1 com a configuração para 3.10. Imagem 2 com as mensagens de retorno. Imagem 3 com a configuração para 4.0. Imagem 4 com as mensagens de retorno. Imagem 5 com as mensagens de retorno depois da alteração no fonte. Como não achei mais ninguém comentando o retorno gostaria de saber se estou fazendo/configurando algo errado ou será necessária a alteração no fonte?

Interessante, esse era o erro apresentado, as vezes eu estava olhando no final do log mais o erro estava antes, vou verificar aqui, obrigado novamente.

Entendo perfeitamente, vou ver se consigo reproduzir ele no ECFTeste e retorno com os resultados. Obrigado pela atenção.

Desculpe, o modelo é o 4200 TH - FI. Bem complicado gerar o erro no teste, até estava pensando em por a mesma sequencia de comandos do nosso sistema do fechamento ao pedido de status e numero de ecf que gera o retorno com as letras no lugar do indice mais teria que por no mesmo PC do cliente pois nas maquinas aqui da empresa, de desenvolvimento, não consegui gerar o mesmo erro. Bem, agradeço a ajuda, pensei que os logs ali poderiam ajudar a alguem me apontar o que eu estaria fazendo de errado, mesmo assim obrigado.

Boa Tarde... Estou com um retorno em apenas um cliente que não consegui entender o por que da diferença, esse cliente tem pelo menos 4 maquinas todas com Bematech 4200 e apenas em uma das máquinas ocorreu o retorno: Communication error 6: Identificador inválido Na minha aplicação solicito diversas vezes o status da ecf e não ocorre o problema(na rotina), ele ocorre apenas "quando finalizo o cupom" e peço o status. Um dos logs esta com o ControlePorta True e o outro não, testei das 2 formas e não resolveu a questão, a solução atual foi colocar um Sleep de 200 milissegundos antes de chamar o status da ecf depois do fechamento, mais gostaria de uma ajuda ou dica caso possível para entender o porque o retorno vem diferente. -- 08/09 11:32:15:353 -- Ativando a porta: COM3 -- 08/09 11:32:15:399 -- 08/09 11:32:15:399 TX -> [SOH][228][26][NUL][4][NUL]8|0|b -- 08/09 11:32:15:415 RX <- [ACK] -- 08/09 11:32:15:415 Status TX -> [ENQ][NUL] -- 08/09 11:32:15:446 Resposta: SEQ:228 CMD:26 EXT:0 CAT:0 RET:[SOH][NUL][NUL][NUL] TBR:31 BRS:"08092016|1|000113300|338266173|" CHK:104 -- 08/09 11:32:15:446 RX <- [SOH][228][26][NUL][NUL][SOH][NUL][NUL][NUL][31][NUL]08092016|1|000113300|338266173|h -- 08/09 11:32:15:446 -- Desativando a porta: COM3 Na primeira linha ele traz um "b" no final e na ultima linha traz um "h". No log com o sleep ele não gera esse "b" e nem com o "h". -- 08/09 11:34:12:899 RX <- [SOH]C[26][NUL][NUL][SOH][NUL][NUL][NUL][STX][NUL]0|[FF] -- 08/09 11:34:12:899 -- 08/09 11:34:12:899 TX -> [SOH]D[26][NUL][4][NUL]8|0|[194] -- 08/09 11:34:12:930 RX <- [ACK] -- 08/09 11:34:12:930 Status TX -> [ENQ][NUL] -- 08/09 11:34:12:946 Resposta: SEQ:68 CMD:26 EXT:0 CAT:0 RET:[SOH][NUL][NUL][NUL] TBR:31 BRS:"08092016|1|000113300|338266173|" CHK:200 -- 08/09 11:34:12:946 RX <- [SOH]D[26][NUL][NUL][SOH][NUL][NUL][NUL][31][NUL]08092016|1|000113300|338266173|[200] ACBrLog Com Erro.txt ACBrLog Sem Erro.txt