Italo Giurizzato Junior

Boa tarde Felipe, Você poderia anexar a alteração que você fez para a cidade de Porto Belo para que possamos atualizar o arquivo INI e enviar para o SVN?

Boa tarde Joemil, A cidade de Juazeiro/BA trocou de provedor? Pois no arquivo ACBrNFSeXServicos.ini consta que o provedor é MetropolisWeb e não Sudoeste.

Boa tarde Gabriel, Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Boa tarde Robson, Tem provedor que o RPS só é processado de madrugada. Como o provedor disponibiliza 3 modos de envio: Envio em Lote modo Assíncrono, Envio em Lote modo Síncrono e Envio Unitário, experimenta enviar outro Rps no modo Síncrono e outro no modo unitário. Nesses 2 últimos o processamento é para ser imediato, ou seja, não entra em uma fila de processamento.

Bom dia John, No que se refere ao Padrão Nacional da NFS-e temos o seguinte: 1. Se o prestador for MEI independente da Cidade ter aderido ao projeto ou não, deverá obrigatoriamente emitir as suas notas no Padrão Nacional a partir de 01/09/2023. 2. Se o prestador não for MEI, temos as duas situações abaixo: 2.1 Se a Cidade aderiu 100% ao projeto o prestador vai emitir as suas notas no Padrão Nacional a partir da data estabelecida pela prefeitura. 2.2 Se a cidade aderiu somete ao pacote de compartilhamento de dados, o prestador vai continuar a emitir as suas notas como emite hoje. Quem adere ao projeto é a Cidade e não o Prestador de Serviço.

Bom dia a todos, Me parece que MG ainda esta usando o namespace e o soapaction da versão 3 na versão 4. Os caras não aprende, fizeram um copia e cola e esqueceram de fazer os ajustes necessários.

Bom dia Diron e Marcos, Vocês tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Bom dia Márcio, Muito obrigado pela colaboração. Já esta no SVN. Detalhe importante os seus fontes estão muitos desatualizados, ainda ele não contempla a versão 4.00 do CT-e.

Bom dia Souza, A cidade de Guarulhos/SP se utiliza do provedor Ginfes, este provedor trabalha com a versão 1 do layout da ABRASF. Todos os provedores que trabalha com essa versão só tem um serviço para recepcionar o RPS implementado em seus webservices: EnvioLoteRps Esse serviço trabalha no modo assíncrono. Reforço o que o Diego lhe orientou, utilize o modo de envio meAutomatico, pois com esse modo o componente sabe qual é o modo que ele deve usar em função do provedor.

Bom dia @Datacaixa, O retorno: ACBrNFSeX.NotasFiscais.Count = 1 ACBrNFSeX.WebService.Emite.Sucesso = True; ACBrNFSeX.WebService.Emite.Erros.Count = 2 Esta muito estranho. O NotasFiscais.Count ser igual a 1 é compreensivo, pois o componente esta carregado com os dados do Rps que foi enviado. Por outro lado o valor True no Emite.Sucesso esta errado, uma vez que na unit temos a seguinte linha: Response.Sucesso := (Response.Erros.Count = 0); E o valor correto de Emite.Erros.Count deveria ser 1, uma vez que no XML de retorno que você anexou temos apenas um erro reportado pelo webservice. Você chegou a fazer um teste com o programa exemplo para ver se aparece a ou as mensagens de erro?

Bom dia Gladston, O problema é que essa consulta não deve ser assinada conforme consta no manual deles, mas também não explicam como anexar o certificado nessa consulta. Assim fica complicado resolver o problema.

Bom dia @C4Dev, Substitua a unit pela que esta em anexo, reinstale o ACBr, recompile a aplicação e faça novos testes. NFSeBrasil.Provider.pas

Bom dia Leandro, Eu realmente não sei se o problema pode ser a questão do BOM (com ou sem), mas com certeza deve ter alguma diferença.

Bom dia Leandro, O que tudo indica é que o webservice do provedor (ISSFortaleza) está gerando o XML de retorno com uma codificação diferente de UTF-8, mas esta incluindo no inicio do arquivo a linha de encoding sendo UTF-8. Muitos provedores comentem esse tipo de erro. Sugiro você entrar em contato com a prefeitura uma vez que o provedor é próprio dela e relatar o problema.

Boa tarde Bill, Já esta no SVN.

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

Everson, Analisando as suas alterações não entendi o motivo da alteração na unit Provider do provedor. Na unit ACBrNFSeXProviderBase o ConsultaSitLote já recebe o valor False e ele só é alterado para True na unit ACBrNFSeProviderABRASFv1, só que o provedor em questão se utiliza da unit ACBrNFSeProviderABRASFv2. No programa exemplo na procedure ChecarResposta temos as seguintes condições para apresentar o resultado do ConsultarSituacao: if ACBrNFSeX1.Configuracoes.Geral.ConsultaLoteAposEnvio and ((Emite.Protocolo <> '') or (Emite.NumeroLote <> '')) then begin if ACBrNFSeX1.Provider.ConfigGeral.ConsultaSitLote then begin with ConsultaSituacao do begin (...) Você não esta alterando o valor do ConsultaSitLote diretamente na sua aplicação?

Marcio, Você poderia anexar as units que você alterou?

Diego, Já esta no SVN.

Boa tarde Túlio, Já esta no SVN.

Boa tarde Igor, Após o envio do lote de Rps no modo assíncrono, você esta consultando a situação do lote e por fim consultando o Lote? Pois no modo assíncrono ao enviar o que temos como resposta é o numero do protocolo. Leia atentamente o tópico abaixo.

Boa tarde Diego, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4072

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

Boa tarde Marcio, Já inclui na minha lista de tarefas. TK-4071

Boa tarde, Fazendo uma pequena retificação a orientação do nosso amigo @Juliomar Marchetti. Se tratando do MDF-e temos os eventos de cancelamento e encerramento. Se enviar o evento de encerramento significa que a carga foi transportada e entregue. Se enviar o evento de cancelamento significa que a carga não foi transportada. Então neste caso o evento correto é o de cancelamento. Temos também a questão do prazo para o cancelamento, veja a regra abaixo: O que tudo indica o prazo para o cancelamento de um MDF-e é de 24 horas após a data/hora de autorização do mesmo. Para cancelar esse MDF-e vai ser necessário solicitar ao Fisco o cancelamento extemporâneo. É ai que entra o Contador conforme o Juliomar mencionou.