BigWings

Se está usando OpenSSL como na imagem, isso é desnecessário. Aparentemente está tudo normal. Sua versão do ACBrMonitorPLUS é baixada ou você mesmo compila? Caso seja a baixada, experimente atualizar.

Informe o código da UF e não a sigla: NFe.DistribuicaoDFe("50","09428584000175") Cuidado com a execução deste comando. Sem passar o parâmetro UltNSU ele retorna os primeiros 50 documentos emitidos contra o CNPJ nos últimos 90 dias. Você deve armazenar o NSU também retornado por ele para ser usado nas consultas seguintes, informando o parâmetro UltNSU. Uso escessivo sem informar o UltNSU causa rejeição por consumo indevido do webservice. Está com suporte a TLS 1.2 ativado? - CAPICOM: Verificar se Windows está com todas as atualizações de segurança instaladas e a opção "Usar TLS 1.2" marcada nas opções avançadas do IE. - WinCrypt: Verificar se Windows está com todas as atualizações de segurança instaladas e a configuração SSL Type do ACBrMonitorPLUS definida como LT_TLSv1_2. - OpenSSL: Verificar se a configuração SSL Type do ACBrMonitorPLUS está definida como LT_TLSv1_2. Veja também se está usando uma versão atualizada do ACBrMonitorPLUS.

Boa tarde, Uma coisa é o Manifesto de Documentos Fiscais (MDF-e), que é um documento necessário para se fazer o transporte interestadual ou mesmo intermunicipal de carga, onde vão ser listados as chaves de NFe ou CTe que estão sendo transportados, e as informações dos veículos, condutores, seguro de carga, etc. Outra coisa é a Manifestação do Destinatário da NFe que são eventos enviados pelo destinatário de uma NFe para acusar a ciência, confirmação, desconhecimento ou não realização da operação atrelada a uma NFe. De qual deles você está falando?

O erro indica que você não configurou a propriedade SSLHttpLib. Consulte o projeto exemplo do componente na pasta ACBr\Exemplos\ACBrDFe\ACBrNFe. Leia também o tópico abaixo:

O método ACBrNFe.Enviar já faz isso. A propriedade ACBrNFe.NotasFiscais é uma coleção, você pode acrescentar quantas notas quiser até o limite de , se não me engano , 50 notas ou 500kb no XML de envio.

Verifique se o Windows tem todas as atualizações de segurança instaladas.

Considere que a SEFAZ pode ainda não ter implementado a NT 2016.002 v. 1.50, então ainda pode estar validando pela UF de origem.

Como para o CSOSN 202 não existe a tag vFCP, ela é ignorada na montagem do XML. Tente informar o valor do vFCPST sem descontar o valor do FCP normal.

Pelo meu entendimento, o preenchimento é obrigatório, de acordo com o NCM, independentemente do ramo de atividade. Provavelmente a informação se é relevante ou não vai ser propagada pelos fabricantes e pode ser importada do XML de entrada. Veja que também há o campo para informar o CNPJ do fabricante, então é uma informação que deve ser armazenada.

Sim.

Nem todos os estados estão com exigência do TLS 1.2 ativadas nos webservices. Aparentemente, SP, MS, GO e agora o CE estão exigindo, em homologação. Fiz teste com meu certificado e-CPF token A3 pessoal, conforme as configurações do seu post inicial. OpenSSL usa DLLs próprias e não depende das DLLs do Windows, por isso funciona mesmo onde não há suporte nenhum a TLS 1.2, como Windows XP e 2003. E usando arquivo .pfx você não depende dos gerenciadores de cartão e tokens, é sempre o melhor cenário usar A1 com OpenSSL.

Então é problema de ambiente. Verifique as atualizações do Windows para suporte adequado a TLS 1.2, e a instalação do certificado digital.

Erro 403 geralmente tam a ver com o certificado. Pode ser necessário fazer atualização das cadeias, reinstalar com instalador atualizado... Você consegue abrir a URL do serviço pelo navegador? https://nfeh.sefaz.ce.gov.br/nfe4/services/NFeStatusServico4?WSDL Faça o teste também não informando a senha no componente, para forçar a digitação.

A rejeição provavelmente é pela falta da tag vBCFCPUFDest (NFe 4.00). Mas optantes pelo Simples Nacional, salvo engano, estão isentos desse cálculo, o grupo ICMSUFDest não precisa ser informado.

Com esse XML também não houve a mensagem de rejeição referente ao valor do vFCPST por parte do validador da SEFAZ-RS, como aconteceu com o seu arquivo anterior: Minha sugestão é que faça a correção dos demais erros de valores incorretos, se a SEFAZ-MG continuar rejeitando pelo motivo 860, tente contato com eles pra saber o motivo. Não.

O grupo card só se aplica a pagamentos em cartão, você está gerando ele para pagamento em dinheiro (tPag = 01). Essa tag é nova, incluída na NT 2016.002. v. 1.50. Fez a atualização do ACBrMonitorPLUS como recomendado?

Esse é o XML gerado pelo ACBr? A validação indica erro no parse das tags:

Precisa aguardar a SEFAZ implementar os novos schemas e regras da NT 2016.002 v.1.50. Os prazos de implantação da mesma foram prorrogados pela NT 2016.002 v.1.51.

Tente informar a tag pag.indPag como ipNenhum.

Anexe o XML modificado.

Os layouts da ABRASF 1 e 2 possuem métodos para consulta de NFSe por faixa, onde não é necessário o número do RPS, apenas numeração da NFS-e. Quanto aos municípios que não seguem o padrão ABRASF, é necessário verificar cada um.

Faltou dizer qual o erro...

Pela regra de validação da NT 2016.002 v. 1.50, essa é a fórmula correta:

Não faz sentido multiplicar por 4... Me parece indicação de uma observação, mas não há legenda pra ela. Teve a mesma rejeição? No validador da SEFAZ-RS passou... com outros erros, mas não houve mais rejeição pelo cálculo do vFCPST.

Leia as NT que tratam do assunto: http://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=eouHsaXEtoI= http://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=5c1PwLTdrCA= Ela não é muito específica, você deve analisar o código da aplicação pra saber se está havendo loop ou a mesma requisição múltiplas vezes, como consulta de status de serviço, consulta do mesmo CTe... Se nada disso for detectado resta perguntar a SEFAZ o motivo da rejeição.