Italo Giurizzato Junior

Boa noite a todos, Esta disponível diversas correções para que seja possível gerar, assinar e validar os modelos: CT-e e CTeOS na versão 3.00

Boa noite Heronim, Estou ficando sem ideias. Por favor atualize os fontes e realize novos testes.

Boa tarde Rick, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Shirley, Tanto os MOC quanto os Schemas foram disponibilizados hoje nos Portais do CT-e e MDF-e. E já faz 10 dias que os componentes ACBrCTe e ACBrMDFe já estão preparados para a versão 3.0 Encontram-se disponíveis no repositório os novos Schemas.

Luis, Muito obrigado, aqui é assim: a gente risca, belisca e prega fogo.

Boa tarde a todos, Fiquei sabendo e obtive os Manuais tanto do CT-e quanto do MDF-e referente versão 3.00 no dia 11 de agosto, é pessoal não é só o CT-e o MDF-e também ganhará uma nova versão que também será 3.00 No dia 29 de agosto já se encontrava disponível no repositório os fontes do CT-e e MDF-e visando atender a nova versão. Quem tem o costume de atualizar os fontes diariamente já faz 10 dias que estão usando os componentes aptos a emitir na nova versão. Com certeza será necessário fazer os ajustes finos nos componentes. Com a disponibilização dos Schemas agora fica muito mais fácil dar inicio aos testes. Baixei os schemas e já disponibilizei eles no repositório. Schemas do CT-e: ...\Exemplos\ACBrDFe\Schemas\CTe (schemas da versão 2.00 e 3.00) Schemas do MDF-e: ...\Exemplos\ACBrDFe\Schemas\MDFe (schemas da versão 1.00 e 3.00) Em bambos os documentos temos a propriedade de configuração chamada VersaoDF é de se esperar que se atribuirmos o valor ve300 o XML será gerado segundo essa versão, concordam? No caso do CT-e foi incluída a propriedade ModeloDF que aceita os valores: moCTe e moCTeOS. Se o valor for moCTe será gerado o XML do CT-e que conhecemos, mas se o valor for moCTeOS será gerado um novo XML chamado de CT-e Outros Serviços. Não vou explicar o que vem a ser esse novo modelo de Documento Fiscal Eletrônico, peço a todos que leiam a versão 3.00 do Manual do CT-e.

Boa tarde Marcos, Tentou usar o botão [Gerar e Enviar Lote] ?

Boa tarde Walney, A NFS-e não é padronizada nem a nível Estadual muito menos a nível Nacional. O ACBrMonitor Plus não emite NFS-e. Se você não programa em Delphi terá que usar o programa disponibilizado pela prefeitura ou emitir a nota via site da própria prefeitura.

Boa tarde Reinaldo, Você esta com todos os fontes de todas as pastas atualizados e compilados?

Boa tarde, Cuidado o XML NFS-e não é uma reimpressão do XML RPS. O RPS se refere ao Recibo Provisório de Serviço e NFS-e se refere a Nota Fiscal de Serviço Eletrônica. Você não informou o Report que esta usando, se é Fast ou Fortes.

Boa tarde, Se você deseja salvar no banco de dados o XML do RPS deve ler o XMLAssinado se vazio leia o XMLOriginal. Lembre-se que dependendo do provedor o XML do RPS é assinado ou não.

Heronim, Por favor atualize mais uma vez e faça mais um teste. Anexe os resultados. Se o erro persistir vamos deixar para amanhã.

Heronim, O erro chato: <mensagens>Linha: 1, Mensagem: cvc-complex-type.2.4.a: Foi detectado um conteudo invalido comecando com o elemento 'Id'. Era esperado um dos '{"http://www.el.com.br/nfse/xsd/el-nfse.xsd":Id}'.</mensagens> <mensagens>EL55 - Arquivo Invalido - Verifique a extrutura do arquivo se esta nos padroes solicitados!.</mensagens> Antes era a TAG LoteRps e agora é o Id. Antes o conteúdo estava sendo gerado com 2 dígitos sendo que o correto é ter no mínimo 13 e no máximo 35 se não me falha a memória. Fiz uma alteração para gerar com 15 dígitos, mas por um descuido ficou todos zerados. Vamos ver se agora vai funcionar. A mensagem não esta muito claro, mas acredito que o problema seja o conteúdo que esta errado. Por favor atualize e faça novos testes.

Boa noite Felipe, A solução é simples, mostre ao seu cliente o Manual do CT-e, que define que o campo vComp só é permitido 2 casas decimais. Depois mostre o Manual do DACTE e peça para que ele leia em voz alta o conteúdo do item 1.1 que reproduzo abaixo: 1.1 Campos do DACTE O conteúdo dos campos do DACTE deverá ter a sua origem nas respectivas TAG XML do CT-e, quando conhecidos no momento da solicitação de autorização de uso. Não poderão ser impressas informações que não constem do arquivo da CT-e.

Heronim, Dois persistentes em pleno feriado, vamos lá, por favor atualize e teste.

Heronim, Vamos lá, infelizmente na tentativa e erro, por favor atualize e teste novamente.

Boa noite Rafael, O Terceiro parâmetro do método DistribuicaoDFe se refere ao último NSU, qual é o valor que você esta passando?

Boa noite Marcos, Com certeza o problema é na SEFAZ-AM.

Boa tarde Heronim, Por favor tenha paciência, mas vamos que vamos, atualize os fontes e faça novos testes.

Bom dia Heronim, Favor atualizar os fontes e realizar novos testes.

Boa noite Tiago, Verifica se no nome do destinatário (caso informado) não possui o E comercial "&".

Boa noite, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde a todos, Por favor abram a unit ACBrNFe e procure pela function: GetURLQRCode. Inclua o código IBGE a UF que esta gerando a rejeição como foi feito com essas outras 3 UF. if (CUF in [35, 41, 50]) then begin sdhEmi_HEX := LowerCase(sdhEmi_HEX); sdigVal_HEX := LowerCase(sdigVal_HEX); end; por exemplo: if (CUF in [29, 35, 41, 50]) then Compile os fontes do componente e depois a aplicação e façam novos testes.

Boa tarde Marcos, Muito obrigado pela correção, já esta no repositório.

Boa tarde Rick, Já enviei a correção para o repositório, muito obrigado.