BigWings

Ela foi removida no layout 3.00a. O RJ assim como todos os estados exceto MG e PR já atualizaram os webservices e só estão aceitando o XML nessa versão. Então na geração do XML informe pICMSInterPart = 0 (mas calculando como se fosse 100%). Adendo: Também precisa renomear um arquivo de schema conforme esta orientação:

Lembre que a comparação é feita com a data e hora do webservice, então se está usando a função Now precisa ter certeza que o relógio da máquina não está adiantado...

A regra que valida a data e hora de entrega diz o seguinte: Nesse caso acredito que tenha sido informado uma data e hora futura, por isso a rejeição.

Tópico duplicado:

Fiz testes pela manhã e agora a tarde, SP aparentemente já está aceitando os schemas na versão 3.00a. MG está programado pra amanhã. Restando apenas o PR...

NFe ou CTe?

Parece que você tentou se comunicar com algum webservice e ele retornou um erro interno (não encontrou coluna ou tabela TIPO_CONTRIBUINTE no banco de dados). Mas sua postagem ficou vaga demais pra saber do que se trata.

Não precisa zerar a tag vICMSUFFim e vFCPUFFim. Apenas a pICMSInterPart que foi removida do layout, já que ela não é mais necessário porque é sempre 100%. Ou seja, informe zero mas entenda como 100.

No portal da SEFAZ-MG consta que seria implantado ontem a partir das 09:00h. http://www.sped.fazenda.mg.gov.br/spedmg/cte/ Mas não consta aviso que realmente fizeram a implantação. Fiz testes há pouco e aparentemente ainda não foi atualizado.

Na versões em FortesReport do DACTE e DAMDFE não houve muita alteração no layout de impressão, apenas a impressão do QrCode foi adicionada. E ele só será impresso caso exista no XML, então precisa verificar isso. Já para o FastReport foi feito um redesenho do layout (contribuição da @JeannyPaiva). Para testar o DACTE em FastReport você pode abrir o demo na pasta ACBr\Exemplos\ACBrDFe\ACBrCTe\Delphi DACTe FR. Não me recordo de haver novas tags no XML além do QrCode.

Access Violation nos DANFE do FastReport geralmente é a Midas.dll porque ele usa ClientDataset.

Se for registrar a MIDAS.dll tem que ver se está com a versão correta de acordo com a versão do Delphi que está usando. Você pode também declarar MidasLib no uses do seu .dpr assim não precisa registrar a dll.

Enviei correção para o repositório, rev. 17533. A forma que encontrei foi usando a var. TotalPages e ativando o DoublePass, assim como é feito no DANFE. Favor atualize os fontes e teste com o fr3 do repositório.

Informe zero para a tag pICMSInterPart. Assim ela não será gerada no XML conforme o novo layout.

Veja o tópico abaixo, parece o mesmo caso:

Veja este tópico, parece ser o mesmo caso:

Se quer baixar as tabelas, veja o componente ACBrSpedTabelas.

Esse é um problema conhecido, ainda sem solução. Se compilar outra aplicação, por exemplo o demo do ACBrNFe ocorre o mesmo erro? Anexe por favor o .log e não o .ini.

Marcou a opção de remover arquivos antigos do disco na instalação? Marcou a opção de copiar as DLLs? Anexe o log do ACBrInstall_Trunk2.exe.

Provavelmente quem implementou não viu necessidade em gerar mais de uma página. Os fontes estão abertos a quem quiser contribuir.

Nesse caso você precisa entrar em contato com o banco para saber a situação das remessas enviadas, ou orientação de como obter o retorno delas. Muito estranho... cada banco tem suas regras, o SICOOB não deveria validar um arquivo de remessa do Banco do Brasil.

Não precisa se preocupar com o formato de gravação no XML, isso o ACBr faz. Basta informar um valor TDateTime normal. Ex: infEvento.detEvento.dhEntrega := Now; infEvento.detEvento.dhEntrega := MeuDataSet.FieldByName('DATA_HORA_ENTREGA').AsDateTime; InfEvento.detEvento.dhEntrega := EncodeDate(2019, 08, 23) + EncodeTime(17, 45, 00, 000);

Provavelmente ainda não está sendo aceito pela SEFAZ a versão 3.00a. Tente configurar a propriedade GerarInfCTeSupl como fgtSomenteHomologacao ou fgtNunca.

Enviei atualização de Schemas para o repositório, favor atualizar os fontes.