BigWings

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.

Pela regra de validação N23d-10, o cálculo do vFCPST deve se a multiplicação entre o vBCFCPST e pFCPST, descontando o valor o vFCP. Assim: <vFCP>0.80</vFCP> [...] <vBCFCPST>86.59</vBCFCPST> <pFCPST>2.0000</pFCPST> <vFCPST>3.72</vFCPST> O valor correto do vFCPST deveria ser 86.59 * (2/100) - 0.80 = 0,93. Aqui o vFCPST seria 0,00.

Tópico dividido e movido por se tratar de assunto específico.

Sempre fiz pelo Windows Update, nunca tentei a instalação off-line.

Acredito que não pois depende de uma tabela externa.

Você precisa atualizar o IE no PC e inserir as chaves no registro para o TWebBrowser emular a versão mais nova.

Na aba certificado do demo você deve definir uma configuração CryptLib diferente de cryCapicom, já que este não tem suporte a SHA256.

Tentou fazer o que diz a mensagem?

Campos opcionais vazios não são gerados no XML. E o grupo card deve ser informado dentro do grupo detPag. Pode haver no máximo um grupo card para cada detPag. Para a leitura correta do indPag você deve usar uma versão atualizada do ACBrMonitorPLUS.

Correto. São várias validações, a sua rejeição foi referente ao prefixo. Pra ser autorizado na NFe o GTIN ainda deve estar cadastrado no GS1, caso contrário você deve informar a tag cEAN e cEANTrib em branco ou com a informação SEM GTIN.

Não informar o item com erro no prefixo do GTIN eu considero uma falha, sim. Sem essa informação você precisa comparar os prefixos de todos os GTIN informados no XML com a tabela. Como disse, esse GTIN destacado parece estar correto.

Pelo que entendi é a faixa entre o prefixo inicial e o final. Assim o GTIN 94201291 seria válido, por ter 8 dígitos, caracterizando o GTIN-8, o dígito verificador confere segundo o validador https://www.gs1.org/services/check-digit-calculator#gtin e o prefixo está na faixa entre 940 e 949 (GS1 New Zealand).

A mensagem de rejeição da SEFAZ devia conter o número do item: Se não está retornando, uma alternativa nesse caso é comparar o prefixo do GTIN informado no XML com a tabela de prefixos disponível pra download no portal da NFe.

Corrigido no svn.

Tem um (longo) tópico sobre esse assunto:

Pode estar relacionado com o assunto deste tópico:

Isso é alguma instabilidade no webservice da SEFAZ-MG: Fiz teste de envio do teu XML e aconteceu como você disse, hora funcionava com a rejeição do NCM, hora retornava o seguinte XML: Arquivo: *-rec-soap.xml. <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Unmarshalling Error: Unexpected close tag </COF>; expected </COFINSOutr>. at [row,col {unknown-source}]: [1,8186] </soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope> Quando o retorno do webservice vem em formato não esperado pelo ACBr, ocorre a mensagem de exceção em branco.

Atualize os fontes.

Além do .ini desatualizado, nenhuma ideia. Tente o debug.