BigWings

Como está fazendo para transmitir? O validador da SEFAZ-RS acusa vários erros de schema. Resultado da Validação do Schema e de Regras de Negócio: Parser XML: Nenhum erro encontrado Tipo de Mensagem: NF-e sem assinatura digital Schema [exibindo os 5 primeiros erros] The element 'ide' in namespace 'http://www.portalfiscal.inf.br/nfe' has invalid child element 'indPag' in namespace 'http://www.portalfiscal.inf.br/nfe'. List of possible elements expected: 'mod' in namespace 'http://www.portalfiscal.inf.br/nfe'. Caminho: NFe[1]/infNFe/ide/indPag The 'http://www.portalfiscal.inf.br/nfe:CNPJ' element is invalid - The value '' is invalid according to its datatype 'http://www.portalfiscal.inf.br/nfe:TCnpj' - The Pattern constraint failed. Caminho: NFe[1]/infNFe/dest/CNPJ/ The element 'dest' in namespace 'http://www.portalfiscal.inf.br/nfe' has invalid child element 'idEstrangeiro' in namespace 'http://www.portalfiscal.inf.br/nfe'. List of possible elements expected: 'xNome, enderDest, indIEDest' in namespace 'http://www.portalfiscal.inf.br/nfe'. Caminho: NFe[1]/infNFe/dest/idEstrangeiro/ The 'http://www.portalfiscal.inf.br/nfe:NVE' element is invalid - The value '' is invalid according to its datatype 'String' - The Pattern constraint failed. Caminho: NFe[1]/infNFe/det[1]/prod/NVE The 'http://www.portalfiscal.inf.br/nfe:pCredSN' element is invalid - The value '2,5' is invalid according to its datatype 'http://www.portalfiscal.inf.br/nfe:TDec_0302a04' - The Pattern constraint failed. Caminho: NFe[1]/infNFe/det[1]/imposto/ICMS/ICMSSN101/pCredSN https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx

Anexe o manual do layout com essa extensão.

Para o CTe-OS o tomador deve ser informado no grupo toma. with ACBrCTe1.Conhecimentos.Items[0].CTe.toma do begin ... end; Veja se está informando corretamente.

Então debugue sua aplicação e verifique se está adicionando as chaves da NFe ao manifesto no grupo infDoc. Veja que o ACBr não vai incluir CTe nesse grupo caso tpEmit seja 3.

Que eu saiba foi feita adequação ao novo layout que teve tags e grupos e foram removidos ou transferidos para o MDFe, então não é possível.

A mensagem completa indica o erro: Falha na validação dos dados do Manifesto: 70 Element '{http://www.portalfiscal.inf.br/mdfe}infDoc' cannot be empty according to the DTD/Schema. Não foi gerado nenhum documento no grupo infDoc. Foi feita uma correção recentemente sobre isso: Você está com os fontes atualizados?

É um problema mesmo já que está usando a versão 2.00 do CTe. No layout da 2.00 a tag era denominada chave, na 3.00 é chCTe. O ACBrMonitorPLUS está alimentando apenas a chCTe, portanto só funcionará para CTe 3.00. Recomendo que já faça a troca, já que o CTe 2.00 será desativado no dia 04/12/2017, ou seja, em menos de dois meses. Para funcionar no CTe 2.00 vai ser necessário aplicar a alteração anexo e recompilar o ACBrMonitorPLUS. DoACBrCTeUnit.rar

Isso é incompatibilidade com a sua versão do FastReport. Você precisa do FastReport 5.x acima.

Não deve ter diferença entre os estados, a resposta do WebService é padrão... O que muda é o método de envio, no método síncrono não precisa consultar o recibo, por exemplo. Há tempos eu só uso o método síncrono, já que todos os estados que atendo aceitam esse método. Tem outra forma de acessar o cStat após a consulta do recibo: ACBrNFe1.WebServices.Recibo.NFeRetorno.protNFe.Items[0].cStat Dividi o tópico e movi para o fórum ACBrNFe já que não se tratava do ACBrMonitorPLUS.

Analisando melhor, parece que o método de consulta de recibo realmente não faz o tratamento do cStat do protNFe. Se você precisa realmente usar a consulta de recibo explicitamente, minha sugestão é que use o método de Consulta de NFe após o retorno 104 da consulta de recibo. Lembrando que no envio assíncrono esse retorno já é tratado.

Se você está usando o método de consulta de recibo apenas, o ACBr não retornará exceção caso o cStat seja 104. Já no método Enviar o cStat de retorno é tratado, pelo método TratarRespostaFinal da unit ACBrNFeWebservices.pas. Você deve conseguir obter o cStat de rejeição acessando ACBrNFe1.WebServices.Recibo.NFeRetorno.cStat.

Mande gravar os arquivos de envio e retorno e anexe aqui.

Tente assim: [idDocAnt001001] chCTe=35171044191880000104570010002355271013594331

Só vai ser obrigatório usar TLS 1.2 também para MDFe, assim como é na NFe 4.00. Não deve haver alteração de URLs.

Não vejo porquê, já que a versão 1.00 já está desativada. E essa alteração é somente para 04/2018.

O tópico é referente a erro na emissão, por favor, abra um novo tópico e especifique a UF do emitente que está testando.

Sim, usando TLS 1.2.

Ou troca o CFOP, ou troca a finalidade da NFe.

O CFOP usado na NFe não é considerade um "CFOP de devolução de mercadoria" portanto não se deve usar a finNFe = 4. Para que se possa usar a finalidade devolução, o CFOP deve estar na lista do anexo XIII.01 do MOC.

Com o valor zerado a tag não deveria ter sido gerada. Pelo que li nos fonte, isso não deveria acontecer, foi feita uma correção nesse sentido há 6 meses: Então, você está com os fontes atualizados?

Que eu saiba apenas o PR exige o cadastro da software house e da aplicação para emissão da NFCe. Nos demais estados não é necessário.

Desde o Trunk2 essa configuração está em ACBrNFe1.Configuracoes.Arquivos.PathSalvar.

Caso haja a tag FCP ou FCP-ST no XML, o valor deve ser entre maior que 0 e menor ou igual a 2%. Poste o XML para analisarmos.

Algo no webservice de MG está fora do padrão... Fiz algumas tentativas aqui da configuração do SoapAction mas sempre tenho o retorno: <soap:Text xml:lang="en">Message part {http://www.portalfiscal.inf.br/nfe/wsdl/NfeConsulta4}nfeDadosMsg was not recognized. (Does it exist in service WSDL?)</soap:Text>

Use os arquivos em anexo e tente novamente. ACBrNFeServicos.ini ACBrNFeServicos.res