Italo Giurizzato Junior

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.

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

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.

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

Bom dia Ramalho, A alteração proposta pelo BigWings já se encontra no repositório.

Danillo, Esse XML foi gerado na sua maquina ou foi enviado para você da maquina do seu cliente? Você chegou a abrir ele com algum aplicativo? Ele nem abre no navegador, só depois que eu converti ele para UTF-8 que consegui abrir no navegador.

Boa tarde Danillo, O problema é que esse XML não esta no formato UTF-8 e sim no UCS-2 Little Endian.

Boa tarde Jean, Se você esta recebendo a rejeição 611 significa que o MDF-e não esta sendo Encerrado depois que toda a carga do caminhão é entregue.

Bom dia Fernando, Quanto ao nome do PDF é utiliza o numero do protocolo de serviço que é retornado ao solicitar o PDF, mas o local onde vai ser salvo é configurável sim, basta definir o caminho na propriedade de configuração: PathDownload.

Bom dia Dangelo, Em vez de configurar o componente para usar o libCapicom, porque não configura com o libWinCrypt?

Bom dia ALA, Qual é a primeira rejeição que aparece? "Numero de Lote RPS já registrado" No meu entendimento esse provedor requer que a cada envio de Lote, o mesmo possua um numero diferente do anterior. A melhor maneira de se fazer isso é ter um controle de numero de lote, que ao meu ver deve ser sequencial. Posso usar o numero do RPS como sendo o numero do Lote? Não. Pois o Lote poderá ter até 50 RPS. A tua aplicação precisa ter um controle de numero (sequencial) de RPS e outro controle de numero (sequencial) de Lote.

Bom dia ALA, Você chegou a abrir o arquivo GovDigital.ini ? Nele contem as URLs de produção e de homologação. [URL_P] RecepcaoLoteRPS=https://ws.govdigital.com.br/ws/%NomeURL_P% [URL_H] RecepcaoLoteRPS=https://homolog.govdigital.com.br/ws/%NomeURL_H% Segundo o nosso amigo Luiz a URL da cidade São Roque/SP que hoje é: https://ws.govdigital.com.br/ws/saoRoque?wsdl passaria a ser: https://ws.nfe-cidades.com.br/ws/saoRoque?wsdl Coloquei em negrito e na cor vermelha para destacar a diferença entre elas. O que você acha que devemos fazer a partir do dia 30/04/2020 para que continuemos a emitir NFS-e para as cidades atendidas por esse provedor? Dica, olhe para as URLS que coloquei acima que se encontram no arquivo INI do provedor. Você concorda que elas deveriam passar a ser: [URL_P] RecepcaoLoteRPS=https://ws.nfe-cidades.com.br/ws/%NomeURL_P% [URL_H] RecepcaoLoteRPS=https://homolog.nfe-cidades.com.br/ws/%NomeURL_H% Como foi discutido anteriormente, seria muito trabalhoso mudar o nome do provedor, sendo que basta abrir o arquivo INI dele e fazer as devidas alterações nas URLs. Se todas as cidades atendidas pelo provedor GovDigital seguirem a mesma formatação da URL como era antes, basta fazer o que foi mostrado acima e seja feliz.

Boa tarde Windel, Pelo os exemplos esse provedor segue a versão 2 do layout da ABRASF, para implementar ele esta faltando os Schemas para que possamos validar o Lote de RPS antes do seu envio, bem com a URL de produção, uma vez que a URL de homologação parece ser a mesma para todas as cidades atendidas por esse provedor.

Boa tarde Rodrigo, Encontrei essa explicação para o erro HTTP 415. https://www.checkupdown.com/status/E415_pt.html