Italo Giurizzato Junior

Bom dia Igor, Noto que você ainda esta usando o componente antigo. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não esta 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/

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

Boa tarde, O jeito vai ser entrar em contato com o provedor e expor o problema. Lembre-se o componente apenas gera e envia o XML do Rps para o webservice do provedor. Os arquivo *-soap.xml se referem ao XML que foi enviado para o webservice ou o que foi retornado por ele, O arquivo 341077-lista-nfse-sinc-soap.xml é o de retorno ele conte a lista de NFS-e. Por que lista? Simples, ao enviar um lote este pode ter até 50 Rps. Se eu envio apenas 1 Rps, no retorno é para consta apenas 1 NFS-e caso o Rps tenha sido processado com sucesso. Se eu envio 30 Rps e todos são processados com sucesso, tenho no retorno 30 NFS-e. No seu caso, você esta enviado 1 Rps e é retornar "N" NFS-e, isso esta errado. O WebService com certeza esta com algum bug muito feio.

Boa tarde, O erro 404 não significa que a URL não existe? Caso afirmativo, o que pode ter ocorrido: 1. A cidade mudou de provedor. 2. O provedor mudou a URL da cidade em questão.

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

Márcio, Maravilha, se for geral seria interessante já arrumar para todas as cidades. Se você descobrir com eles todas as cidades que eles atende seria uma mão na roda.

Boa tarde, Fiz uma pequena mudança na sua contribuição e envie para o SVN. Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Boa tarde Marcio, Já esta no SVN. Você sabe me informar se o provedor Coplan vai adotar essa nova formatação das URLs para todas as cidades atendidas por ele?

Boa tarde, Já esta no SVN.

Boa tarde Eduardo, Já enviei para o SVN. Note que foi feito um refactoring do componente.

Boa tarde Diego, Favor atualizar os fontes, reinstale o ACBr e faça novos testes. Note que foi realizado um Refactoring no componente.

Boa noite Juliomar, Sim consta no MOC do CTe essa informação.

Boa noite Marcio, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2774

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

Boa noite, Muito obrigado pela contribuição, já inclui na minha lista de tarefas. TK-2772

Boa noite Victor, Pelo que me recordo pela conversa que tivemos no Discord o problema foi sanado, isso confere?

Boa noite Juninho, Chegou a estudar o programa exemplo do componente ACBrNFSeX? Veja: // Provedores que permitem informar mais de 1 serviço: // Agili, AssessorPublico, EL, EloTech, Equiplano, fintelISS, Governa, // Infisc, IPM, ISSDSF, Simple, SmarAPD, WebFisco with Servico.ItemServico.New do begin Descricao := 'Desc. do Serv. 1'; ItemListaServico := '09.01'; (...) // Provedor IPM { define se o tributo é no municipio do prestador ou não } TribMunPrestador := snNao; { codigo do municipio que ocorreu a prestação de serviço } CodMunPrestacao := edtCodCidade.Text; { codigo da situação tributária: 0 até 15 } SituacaoTributaria := 0; // <===== informe o código correto aqui end;

Boa noite Jarbas, Porque você esta gerando o XML do Lote e tentando importar pelo site? Até onde sei a cidade em questão se utiliza do provedor SilTecnologia que possui WebService.

Boa noite Widson, Se mesmo gerando o XML com os campos e seus valores o webservice continua a recusar, não vejo outra saída entrar em contato com o provedor e expor o problema.

Boa tarde, Ao enviar o lote o numero dele esta sendo alterado ou esta usando sempre o mesmo numero de lote? O problema pode ser esse. Ou realmente existe um BUG muito feio no webservice do provedor.

Boa tarde Jarbas, Ficarei aguardando um retorno para ajustar corretamente o tamanho do campo.

Boa tarde Tiago, Foi feita uma correção no provedor IPM visando esse erro de UTF-8, favor atualizar os fontes e faça novos testes.

Boa tarde Leandro, A SEFAZ só aceita uma requisição com tamanho máximo de 512 Kbytes. Regra: B01 - Tamanho do XML de Dados superior a 512 Kbytes - vai ocorrer a rejeição 214.

Boa tarde, Segundo a NT 2020/001 versão 1.04 o grupo prodPred possui ocorrências (0-1) ou seja é um grupo opcional e caso ele venha ser incluído no XML a quantidade máxima de ocorrências dele é de 1. Portanto esse grupo só pode constar no máximo uma única vez.

Olá pessoal, O componente ACBrPagFor passou por um Refactoring. A motivação para esse Refactoring é tornar o componente mais fácil e prático no que se refere a implementar novos bancos bem como realizar manutenção no código sem correr o risco de gerar um efeito colateral nos bancos já implementados. Antes tínhamos apenas uma unit responsável por gerar o arquivo txt de remessa para todos os bancos. Isso gerava riscos na implementação e manutenção dos bancos existentes. Agora temos uma unit que gera o arquivo segundo o layout estabelecido pela Febraban e units separadas para cada banco. Assim, podemos alterar a procedure do registro ou do segmento que não segue a risca o layout da Febraban de um banco específico sem afetar outros. Desta forma dezenas de IF e CASE utilizados para identificar o banco em questão e gerar o txt corretamente, agora não existem mais. Desta forma temos um código muito mais limpo de ser lido e compreendido. Além disso foram removidas as propriedades de configuração: CNPJ e VersaoLayout que se encontravam em Configuracoes.Geral, pois estavam sem nenhuma utilidade. Agora no lugar delas temos as propriedades de configuração: Empresa e UsarDadosConfig. Novas Propriedades de Configuração: Propriedade Tipo Valor Padrão Descrição Empresa Grupo Dados da Empresa TipoInscricao TTipoInscricao tiIsento Determina o tipo de Inscrição da Empresa que pode ser: tiIsento, tiCPF, tiCNPJ, tiPISPASEP ou tiOutros. NumeroInscricao string Numero da Inscrição da Empresa conforme o tipo. Convenio string Numero do Convenio da Empresa estabelecido com o Banco. Nome string Razão Social da Empresa. Conta Grupo Dados da Conta AgenciaCodigo Integer 0 Numero da Agencia que a Empresa tem Conta. AgenciaDV string Digito Verificador da Agencia. ContaNumero Int64 0 Numero da Conta. ContaDV string Digito Verificado da Conta DV string Digito Verificado geral utilizado por alguns bancos. TipoConta Integer 0 Tipo de Conta, utilizado por alguns bancos. Endereco Grupo Dados do Endereço Logradouro string Nome do Logradouro do Endereço da Empresa. Numero string Numero ou código do Logradouro (veja a "obs." abaixo) Complemento string Complemento do Endereço. Cidade string Nome da Cidade. CEP Integer CEP do Endereço da Empresa. Estado string Sigla do Estado. UsarDadosConfig Boolean False Se True o componente vai utilizar as informações de configuração para serem utilizadas ao gerar o arquivo de remessa, caso contrario o desenvolvedor terá que alimentar diretamente os campos do componente. Observação: o tipo do campo Numero do logradouro do Endereço foi alterado de Integer para string pois a cidade de Bauru utiliza o formato xx-yy onde xx se refere ao numero da quadra em que a rua se encontra e o yy o numero do imóvel. Pasta dos fontes: Outro ponto importante é a localização das Units que compõe o componente: Pasta Descrição ACBrPagFor Pasta raiz dos fontes do componente. Bancos Pasta que contem as units dos bancos: (PagFor.NomeBanco.GravarTxtRemessa, PagFor.NomeBanco.LerTxtRetorno, PagFor.NomeBanco.Provider). Base Pasta que contem as units de classes, conversão e parâmetros. Provider Pasta que contem as units bases de geração e leitura do arquivo txt bem como a interface com as units de cada banco. Modelos Pasta que contem as units que podemos utilizada como modelo para quando for implementar um novo banco: (PagFor.Modelo.GravarTxtRemessa, PagFor.Modelo.LerTxtRetorno, PagFor.Modelo.Provider). Situação atual: Hoje o componente já conta com os seguintes bancos implementados: BancoCECRED, Banco do Brasil, Bradesco, HSBC, Itaú, Safra, Santander e Sicredi. Desafios a frente: Implementar e testar novos bancos melhorar a leitura do arquivo de retorno e extrair as ocorrências para que sejam apresentadas de forma clara e objetiva para que o desenvolvedor possa realizar os ajustes necessários Para que isso ocorra, contamos com a colaboração de todos.