Francisco IBS

Blz @BigWings, pelo que entendi no seu primeiro post: A sugestão seria jogar um 0,01 no valor desconto para que ele seja inserido no XML, certo? R: Alguem do ACBr sabe ou tem algum contato/colaborador que chegou a confirmar se essa validação esta correta(por algum contato com alguma das SEFAZ), já que isso seria um paliativo certo? PS: Particularmente achei mais bonito por o campo como obrigatório no fonte indo 0,00, sei que vou ter que dar manutenção nisso caso ocorra alguma alteração na unit, mas preferi assim. Ao menos até desvendarmos o como isso vai ficar.

Bem ai que esta o problema já que a nota técnica vai de contra a isso, então não da de saber se é um erro deles ou um erro na NT. Como traz a NT 1.60 não obriga nenhum dos campos do "Grupo Fatura", a Regra "Y01-20" meio que vai de contra ao que esta na descriminação do campo... Agora ficamos nessa de se o Estagiário lá só seguio ao pé da letra o que estava descrito na regra ou se esqueceram de alterar a descrição do campo.

Desculpe Wallas, estava testando aqui e tinha alterado o fonte colocando obrigatório o campo, justamente por não ter desconto e quando informado 0 no valor ele não gerava no XML. "Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC);" Então creio que terá que ser tratado diferente esse campo, para mesmo que for 0 ir no XML.

Bom Dia... Realizei uns testes hj pela manha no ambiente de homologação de SC e obtive a rejeição: "905 - Rejeicao: Campos do grupo Fatura nao informados" Indo no site do SEFAZ notei que foi disponibilizado um novo pacote de SCHEMAS onde alteram a TAG vDesc, fica a dica pra quem encontrar o mesmo problema e o pedido para atualizaram no SVN. Esquemas XML NF-e - Pacote de Liberação No. 9 (Novo leiaute da NF-e, NT 2016.002 v.1.60 - b) http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=CoNA9VIgZ3E=

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.