BigWings

Se está falando da codificação do arquivo de saída, por padrão ele é gravado em UTF-8, você pode alterar para ANSI nas configurações gerais do ACBrMonitorPLUS.

Remova o separador de milhar.

A SEFAZ provavelmente ainda não atualizou as regras no webservice de acordo com a NT 2016.002 v. 1.50. As datas previstas são 02/05/2018 em homologação e 16/05/2018 em produção. Entre em contato com a SEFAZ e reporte o problema, ou aguarde regularizarem.

Provavelmente está recusando por causa do desconto que está sendo aplicado. Verificar se na remessa foi informado que é aceito pagamento parcial do boleto.

Simples: faça esse tratamento na sua aplicação, e não no código do ACBr. Não dá pra saber se algum documento de estrangeiro possa conter caracteres não numéricos, traços, barras, etc... o que causaria rejeição caso isso seja aplicado no componente.

Repita o número do lote na seção de medicamento. [Medicamento001001] nLote=a100 cProdANVISA=1111111111111 vPMC=13.31 Tem um problema no código do monitor que faz com que o grupo seja ignorado caso essa tag não seja informada.

Certificados tem hora para expiração e não apenas data. Na minha opinião a implementação original é mais correta já que leva também a hora em consideração.

Do ACBrNFe-change-log.txt:

O enumerado está declarado na unit pcnConversao.pas: TpcnIndicadorPagamento = (ipVista, ipPrazo, ipOutras, ipNenhum); Você pode ter arquivos antigos em algum lugar que o compilador está encontrando em vez do correto. Anexe o log do ACBrInstall_Trunk2.

Já verificou se é aceito pela prefeitura a emissão de NFCe de serviços? Geralmente é exigida a NFSe. A mensagem é clara: o valor do vServ deve ser a soma dos vProd dos itens. Informe o valor sem deduzir o desconto.

Isso deve ser possível pelo método ACBrNFe.WebServices.Enviar.Executar. Estude o método ACBrNFe.Enviar e os passos que ele executa.

As tags vBCSTRet, vICMSSTRet, vBCSTDest, vICMSSTDest são parte do grupo ICMSST (Grupo de repasse do ICMS-ST), para os CST 41 e 60 (NFe 4.00). Caso você informe valor em alguma delas o componente entende que está querendo gerar esse grupo e não o de tributação normal. Essa abordagem causou alguns problemas tratados em outros tópicos, então é uma área sensível... Que saiba não há tag para se informar base de cálculo de ICMS-ST, em operações normais com CST 60... qual foi exatamente a tag que você preencheu pra gerar o erro de validação?

O mesmo problema ocorre com o demo do ACBr? Informe o passo a passo para reprodução.

Aparentemente está exigindo TLS 1.2 apenas em homologação, por enquanto.

O próprio emitente não pode fazer download da NFe pelo serviço de DistribuicaoDFe. O sistema entende que por ele ser o emitente, já tem o XML. Apenas o destinatário, transportador ou terceiros identificados no grupo autXML podem fazer o download.

Nada demais na aba certificado, apenas configurei SSLLib como libOpenSSL e informei caminho do pfx e senha.

Enviei um ajuste para o repositório para não gerar a tag indPag caso não seja informado. Favor atualizar os fontes.

Tem no grupo de pagamentos, que está causando o erro.

Provavelmente a SEFAZ-RS ainda não atualizou os Schemas referentes a NT 2016.002 v. 1.50. Informe pag.indPag := ipNenhum para não gerar a tag. Essa foi removida na NFe 4.00. A nova tag está no grupo de pagamentos.

Você não pode informar o grupo de duplicatas caso não tenha pelo menos uma forma de pagamento do tipo 14-Duplicata mercantil, vai cair na rejeição. Isso vale até a SEFAZ implantar no webservice as regras da NT 2016.002 v. 1.50.

A suspeita óbvia: verificou a validade do certificado?

Essa validação existe desde a implantação da NFe 4.00 a partir da NT 2016.002 v. 1.40. Faça uma busca no fórum e veja a quantidade de posts sobre o assunto. Ela só foi removida na NT 2016.002 v. 1.50, a vigorar a partir de 02/05/2018 (homologação) e 16/05/2018 (produção). Estranho, já que essa validação é obrigatório na NFe 4.00. Tem um XML autorizado com o grupo de duplicatas e sem informar o tPag = 14?

Sim, como dito. Qual UF?

OpenSSL é o único que deve funcionar, a tabela dos SO compatíveis com TLS 1.2 se refere a compatibilidade nativa com o protocolo. Fiz testes no Windows Server 2003 e Windows XP com OpenSSL e funcionou, apenas copiando as DLLs da pasta ACBr\DLLs\OpenSSL\1.0.2.13 para o diretório da aplicação. Não sei dizer quanto a atualização do Windows, entretanto.