Italo Giurizzato Junior

Boa tarde Rafael, Muito obrigado pela colaboração, vamos analisar e caso esteja tudo OK, enviaremos para o repositório.

Bom dia Leandro, Primeiramente quero agradecer pela contribuição. Segundo, os seus fontes estão desatualizados. Terceiro tinha muito mais alterações a serem feitas para deixar a rotina que gera o XML para o modal ferroviário ficar em conformidade com o manual segundo a versão vigente. Aproveitei e fiz todas as alterações necessárias. Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e faça novos testes.

Bom dia, Desculpe, eu tinha me confundido com a outra alteração. Muito obrigado pela contribuição, já esta no repositório.

Boa noite ALA, Tentou usar o método Enviar em vez do Gerar?

Boa noite Eduardo, Tente desta forma: xChave := ACBrCTe1.Conhecimentos.Items[ x ].NumID; Onde x varia de zero até a quantidade -1 de CT-e ADD ao componente.

Boa noite, Com o programa exemplo ocorre o mesmo problema? Se não ocorre, veja a rotina que configura o componente no programa exemplo. Tem uma linha que verifica se foi informado o certificado ou não e seta uma propriedade para que ele não carregue o certificado.

Boa tarde, Se não me falha a memória esse tipo de afastamento já foi incluído. Você esta com todos os fontes atualizados?

Boa tarde Keli, Muito obrigado pela colaboração, já enviei para o repositório.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia ALA, Tente com esse arquivo: GovDigital.ini Fiz um teste usando o programa exemplo configurado para Pedro Leopoldo e não ocorreu erro de conexão, tanto em ambiente de homologação quanto o de produção usando as novas URLs. Sendo assim as novas URLs já estão ativas. Quanto a sua pergunta se basta apenas atualizar o arquivo INI no seus clientes a resposta é SIM.

Bom dia a todos, Pela mensagem de erro de validação o problema é que não foi informado o numero do protocolo de autorização do MDF-e que estava sendo solicitado o seu encerramento. Veja: Element '{http://www.portalfiscal.inf.br/mdfe}nProt': '' is not a valid value of the atomic type Simplificando a mensagem: Elemento nProt com valor '' (string vazia) não é valido.

Bom dia, Quanto ao horário de emissão em relação ao de autorização, se não me falha a memória existe uma tolerância de 5 minutos. Neste caso o relógio do computador esta adiantado em 10 segundos em relação ao do servidor do webservice, portanto esta dentro da tolerância de 5 minutos. A sua aplicação não tem nenhuma rotina que dispara automaticamente o envio da nota com outro numero caso o envio anterior não tenha sido realizado com sucesso? Com certeza após o envio e obter o protocolo de autorização a sua aplicação atualiza o registro dessa nota no banco de dados como enviada e protocolada.

Boa tarde Edu, Você ainda esta usando o Capicom? A recomendação de configuração é: Com SSLType configurado para LT_TLSv1_2

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá pessoal, Alguns já notaram que dependendo do DF-e - Documento Fiscal Eletrônico, o modo de envio é assíncrono e ou síncrono. Quais DF-e podem ser enviados em determinado modo e quais são as condições? NF-e: como normalmente enviamos um lote com até 50 notas o modo de envio é assíncrono e funciona para todas as UF. Podemos enviar NF-e em modo síncrono, mas neste caso só é permitido o envio de apenas 1 nota. O modo de envio síncrono não esta disponível para as UF: SP, BA e GO. NFC-e: como normalmente enviamos 1 nota por vez o modo de envio é síncrono, mas caso seja necessário enviar 2 ou mais notas obrigatoriamente o modo de envio deverá ser assíncrono. CT-e: como normalmente enviamos um lote com até 50 conhecimentos o modo de envio é assíncrono e funciona para todas as UF. Podemos enviar CT-e em modo síncrono, mas neste caso só é permitido o envio de apenas 1 conhecimento. O modo de envio síncrono não esta disponível para as UF: MG, PR e SP. CT-e OS: como só é possível o envio de 1 por vez o modo de envio é síncrono para todas as UF. MDF-e: pode ser assíncrono ou síncrono para todas as UF, uma vez que, quem recepciona é sempre a SVRS. Detalhe o envio é sempre unitário, ou seja, só podemos enviar somente um manifesto por vez. BP-e e BP-e TM é síncrono para todas as UF e só podemos enviar 1 bilhete por vez.

Bom dia ALA, Esta correto a alteração, o problema de atualizar antes é as empresas pararem de emitir caso essas novas URLs ainda não estiverem ativas. Favor entrar em contato com o provedor para saber se as novas URLs vão passar a valer a partir do dia 30/04/2020 ou se a partir dessa data as URLs antigas não vão ser mais validas.

Luiz, Fazendo uma verificação no arquivo Cidades.ini detectei que as cidades: Itajubá, Teixeira de Freitas, Pelotas, São Roque, Coronel Fabriciano Estão com outros provedores. Se possível for, gostaria da confirmação de que as cidades acimas agora são atendidas pelo NFe-Cidades (GovDigital). Caso afirmativo precisamos fazer as devidas correções no arquivo Cidades.ini

Boa tarde Edevair, Todos os eventos não importa qual, é gerado 3 XML. *-ped-eve.xml ===> Pedido de Evento, esse XML é enviado para SEFAZ. *-eve.xml ===> Retorno da SEFAZ contendo o protocolo de autorização do evento, caso este tenha sido aceito pela SEFAZ. *-procEventoNFe.xml ===> É gerado pelo componente, ele contem os outros dois acima. É este ultimo que devemos carregar juntamente com o XML da nota para poder imprimir o DAEvento um Documento Auxiliar do Evento, gerar o PDF através do método ImprimirPDF e inclusive enviar o Evento por e-mail através do método EnviarEmailEvento. No programa exemplo do ACBrNFe temos um botão para cada uma dessas funcionalidades. Com relação a salvar o XML em disco, é preciso verificar a configuração do componente. Os dois primeiros arquivos só são salvos se a propriedade Configuracoes.Geral.Salvar estiver com o valor True, já o terceiro só se Configurações.Arquivos.Salvar estiver com o valor True. Outra coisa os XMLs dos eventos não são salvos na mesma pasta que são salvos os XMLs das NF-e. É criado uma pasta chamada Evento e dentro desta uma pasta com o nome do tipo de evento e dentro desta os XMLs.

Fernando, Já esta no repositório as alterações que fiz para que seja possível escolher um nome para o PDF. Por favor atualize os fontes reinstale a suíte ACBr e faça novos testes. O método Enviar agora possui um parâmetro, veja: function Enviar(const ANomePDF: String = '' ) : Boolean; Ele só vai ter utilizada quando for enviado o pedido para obter o PDF da Operação do Transporte. Se não for informado nada o nome do PDF vai ser como é hoje ou seja, o numero do protocolo de pedido, caso contrario vai ser salvo com o nome informado. Exemplo: ACBrCIOT.Enviar("NomeQueEuEscolhi"); O PDF vai ser salvo na pasta definida em PathDownLoad com o nome: NomeQueEuEscolhi.pdf

Boa tarde ALA, ACBrDef ???? Não conheço. Por favor informe em qual unit ocorre o problema e a linha dela.

Boa tarde Luiz, Legal, ele traz uma relação de todas as cidades atendidas pelo provedor. Seria interessante verificar quais dessas cidades não estão no arquivo Cidades.ini e inclui-las.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Fernando, Estou preparando uma alteração no componente que vai permitir que você informe um nome para PDF. Até o final desta semana estarei enviando para o repositório.

Boa tarde Sergio, Você esta com figurando o componente desta forma: E o valor de SSLType é TL_TLSv1_2 ?

Boa tarde Eduardo, Favor anexar o XML inteiro gerado pelo componente e o fragmento de código referente ao ICMS.