Italo Giurizzato Junior

Boa tarde Joemil, Também tive esse erro nos meus testes. Até onde sei o erro 401 significa: "Embora o padrão HTTP especifique "unauthorized", semanticamente, essa resposta significa "unauthenticated". Ou seja, o cliente deve se autenticar para obter a resposta solicitada." Acredito que para que você possa enviar o RPS para o webservice se faz necessário solicitar junto ao provedor a sua liberação, o provedor deve ter uma lista de pessoas físicas e jurídicas que tem a permissão de consumir o webservice.

Boa tarde Lucas, Por favor não fique criando varias postagens referente ao mesmo assunto. Já respondi a sua outra postagem onde você anexou os arquivos Cidades.ini e GovBR.ini Respondendo a sua pergunta, depende, tem provedor que devemos alterar somente o Cidades.ini e outros temos que alterar também o INI do provedor. Vou fechar este tópico.

Boa tarde Lucas, Pelo que vi no site da prefeitura ainda consta o provedor 4R. Mas pela URL que você tem não é o provedor GovBr e sim o Pronimv2.

Boa tarde Marcos, Favor atualizar os fontes e faça novos testes.

Bom dia Eliezer, Se você utiliza o DANFSE feito em Fortes Report o layout é único para todos os provedores. Mas nada impede de você criar um novo componente para impressão do DANFSE com um layout especifico para a cidade de São Paulo. Hoje temos ACBrNFSeDANFSeRLRetrato que é o padrão, você pode criar o EliezerDANFSeRLRetratoSP com esse nome acredito que você não vai precisar reinstalar ele toda vez que você reinstalar a suíte ACBr. Desta forma a sua aplicação vai ter os componentes: ACBrNFSe, ACBrNFSeDANFSeRLRetrato e EliezerDANFSeRLRetratoSP. Na propriedade DANFSE do componente ACBrNFSe é possível em tempo de execução, hora ligar com o ACBrNFSeDANFSeRLRetrato, hora ligar com o EliezerDANFSeRLRetratoSP.

Bom dia Marcos, Primeiramente peço desculpas pela demora em analisar a sua contribuição. Segundo não entendi o motivo de você implementar o método para ler o XML versão 1.00, pois a unit (ACBrGNREGuiasRetorno) onde ele foi implementado se refere a leitura do retorno. Até onde sei na versão 1 do GNRE o retorno da Guia esta no formato TXT e não XML, por outro lado na versão 2 do GNRE o retorno da Guia esta no formato XML.

Bom dia João, Muito obrigado pela colaboração, vou incluir na minha lista de tarefas.

Sandro, Analisando a rotina que monta a string da assinatura para ser convertida, a sequencia: 000000000021803 de 15 dígitos se refere ao valor do serviço: sValorServico := Poem_Zeros( OnlyNumber( FormatFloat('#0.00', (NFSe.Servico.Valores.ValorServicos - NFSe.Servico.Valores.ValorDeducoes) ) ), 15); O componente esta calculando o valor R$ 218,03 e o provedor esta calculando R$ 218,02 Se o valor da dedução é zero o problema realmente esta no calculo do Valor do serviço (campo ValorServicos).

Bom dia Joemil, Favor atualizar os fontes e faça novos testes.

Bom dia Fellipe, Já enviei para o repositório.

Bom dia Deivid, Já enviei para o repositório com uma pequena alteração. O novo parâmetro que você anexou coloquei ele por ultimo para não gerar efeito colateral com os outros desenvolvedores que utilizam o pagina.

Bom dia Danny, A alteração que você fez vai afetar todas as cidades que se utilizam desse provedor. Favor verificar se essa alteração é para somente a cidade de Cerquilho/SP ou se é valida para todas as cidades atendidas pelo provedor 4R.

Bom dia Sandro, Primeiramente é preciso comparar o conteúdo da assinatura antes de ser convertido gerado pelo componente com o apresentado pela mensagem de rejeição, pode ser apenas um caractere que esteja errado.

Bom dia Igor, Os últimos testes que fiz ocorrem um erro acusando que encontrou o fim dos dados, não compreendi o motivo, esta muito complicado encontrar um solução para o problema.

Mas esta errado, o correto é da forma que eu coloquei.

Bom dia, O campo ExigibilidadeISS é do tipo TnfseExigibilidadeISS e os valores são: TnfseExigibilidadeISS = ( exiExigivel, exiNaoIncidencia, exiIsencao, exiExportacao, exiImunidade, exiSuspensaDecisaoJudicial, exiSuspensaProcessoAdministrativo, exiISSFixo ); No XML os valores vão ser 1, 2, 3, 4, 5, 6 , 7 ou 8 dependo do valor acima informado no campo ExigibilidadeISS. Exemplo: Servico.ExigibilidadeISS := exiExigivel;

Bom dia a todos, Tem alguns provedores mudando e só vão aceitar o envio segundo o protocolo TLS versão 1.2 Favor verificar se o problema não é esse. Em SSLType mude para LT_TLSv1_2

Bom dia Joemil, Muito estranho o componente esta gerando o XML de forma errada, vou verificar.

Bom dia Danny, Muito obrigado pela colaboração, vou incluir na minha lista de tarefas.

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

Bom dia Brajan, Favor atualizar os fontes, note que fiz uma alteração no arquivo Natal.ini Com a alteração que fiz o que tudo indica, agora tanto a assinatura do RPS quanto do Lote estão validas.

Bom dia a todos, No meu entendimento o MDF-e tem que ser emitido no dia ou na véspera da viagem, pois nesse meio tempo pode ocorrer a troca do caminhão e ou a troca do motorista. Outra coisa, emite o MDF-e hoje mas a respectiva carga só vai ser transportada semana que vem e se nesse meio tempo surgir uma outra carga para ser transportada com urgência e a empresa só tem um caminhão, como é que fica? Vamos imaginar que a NF-e foi emitida e o MDF-e também, o transporta vai se dá dentro de uma semana, depois de 3 dias ocorre a desistência da compra por parte do cliente. Como você vai fazer para cancelar o MDF-e depois de 3 dias sendo que o prazo para cancelar o MDF-e é de 24 horas após a data e hora de sua autorização?

Olá Pessoal, Foi publicado a NT 2020/005 que contem alterações no layout do XML da NF-e e alterações de regras de validação. O prazo previsto para a implementação das mudanças é: 01/07/2021 - Ambiente de Homologação 01/09/2021 - Ambiente de Produção No que se refere ao layout do XML vão ser acrescentados os campos: cBarra e cBarraTrib para informar o código de barra que são diferentes do GTIN. O campo tpViaTransp vai passar a ter novos valores; No detalhamento do ICMS vamos passar a ter novos campos: vICMSSTDeson e motDesICMSST. Com relação ao Fundo de Combate a Pobreza teremos os novos campos: pFCPDif, vFCPDif e vFCPefet. Consta também de forma errônea que a placa do veículo vai passar a ser opcional, mas o correto é a UF por conta da placa Mercosul. Essas são algumas das novidades, para mais informações convido a todos a lerem a NT que se encontra disponível em nossa biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/NFeNFCe/NT/2020/ Observação: Como vai ocorrer alteração no layout do XML da NF-e vai ser necessário atualizar os fontes do componente ACBrNFe bem como os Schemas independente se você vai usar esses campos na sua aplicação.