Italo Giurizzato Junior

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

Boa tarde @Nelson Santos, Já esta no SVN.

Olá Pessoal, Foi feito alguns ajustes na unit que gera o arquivo com os dados do RPS a ser enviado para o webservice do provedor. O componente estava pegando o conteúdo do campo: NFSe.Tomador.IdentificacaoTomador.Tipo como sendo o local da prestação do serviço, sendo que esse campo não tem nada haver, sendo assim foi criado um novo campo: NFSe.Servico.LocalPrestacao que aceita os valores: lpMunicipio, lpForaMunicipio. Os dados do endereço do local da prestação estava pegando do tomador, exemplo: NFSe.Tomador.Endereco.Endereco, agora vai pegar de: NFSe.Servico.Endereco.Endereco. Em sua aplicação você vai ter que incluir o trecho abaixo para alimentar todos os dados referente ao local da prestação do serviço: Servico.Endereco.Bairro := 'Bairro onde o serviço foi prestado'; Servico.Endereco.CEP := 'cep do local da prestação do serviço'; Servico.Endereco.xMunicipio := 'município do local da prestação do serviço'; Servico.Endereco.Complemento := 'complemento do local da prestação do serviço'; Servico.Endereco.Endereco := 'endereço do local da prestação do serviço'; Servico.Endereco.Numero := 'numero do local da prestação do serviço'; Servico.Endereco.xPais := 'pais do local da prestação do serviço'; Servico.Endereco.UF := 'UF do local da prestação do serviço'; Fica ai a dica.

Bom dia @Nelson Santos, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5713

Bom dia @Diego Reckziegel, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5712

Bom dia @vinizioWOW, E como eles identificam que se trata de um teste e não uma averbação pra valer?

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

Boa tarde @Kaikson, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes. O ID da confirmação do cancelamento vai ser armazenado em: ACBrNFSeX.NotasFiscais.Items[0].NFSe.NfseCancelamento.ID;

Olá Pessoal, Na verdade a cidade de Campinas/SP não esta trocando de provedor. A prefeitura já a algum tempo adquiriu o sistema de recepção de NFS-e do provedor ISSDSF, com isso o referido provedor deixou de realizar manutenções no sistema bem como deixou de ser o responsável pelo seu funcionamento. Com o passar do tempo alguns provedores costumam fazer algumas alterações e para evitar que tanto a prefeitura de Campinas/SP como o provedor ISSDSF venham fazer alguma alteração e com isso gerar um efeito colateral, decidimos em criar um novo provedor para Campinas/SP chamado ISSCampinas. Desta forma se o provedor ISSDSF vier a fazer alguma alteração não vai afetar Campinas/SP e vice-versa. Recomendo que o quanto antes vocês atualizem todos os fontes de todas as pastas e reinstalem o ACBr. Observações Importantes: 1. O programa exemplo em Delphi foi alterado para exemplificar o uso do provedor ISSCampinas. 2. Dentro da pasta: ...\Exemplos\ACBrDFe\Schemas\NFSe temos agora a pasta ISSCampinas\1.00 que contem os schemas do provedor ISSCampinas. Caso tenham algum problema favor criar um tópico no fórum relatando o que esta ocorrendo. Abaixo segue o tópico de como configurar corretamente os schemas.

Bom dia @MarceloPeron, O manual deixa claro que só pode constar no Documento Auxiliar (no caso o DACTE) informações que estejam no XML do CT-e. Checando tanto o manual referente ao layout do XML bem como o manual do DACTE não encontrei nada referente a PIX. Mas eu acho que você pode fazer o seguinte: Existe no XML um grupo opcional chamado ObsCont (que é uma lista). Esse grupo possui um atributo chamado xCampo e um elemento chamado xTexto. Na sua aplicação incluir o bloco abaixo: with compl.ObsCont.New do begin xCampo := 'ChavePIX'; xTexto := 'Incluir aqui a chave PIX a ser usada para gear o QR-Code'; end; Desta forma você pode gerar o QR-Code do PIX com base no conteúdo do elemento xTexto.

Boa tarde Kaikson, Já inclui na minha lista de tarefas. TK-5702

Boa tarde Kaikson, Qual é a cidade/provedor?

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

Bom dia Alex, Já esta no SVN.

Boa tarde Adhelmar, Antes o Validar checava se o XML estava assinado ou não, caso não estivesse assinava antes de validar. Agora ele não faz mais isso, dai a necessidade de executar o método Assinar antes do Validar conforme o Juliomar lhe passou.

Boa tarde @Jhoni Conzatti, Eu enviei duas correções, sendo que a primeira resolvia a questão da leitura do XML (*-ProcInutNFe.xml) e a outra a leitura da tag xJust. Vamos fazer a checagem: Você tem fontes do ACBr 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. Por fim repita os testes.

Boa tarde Mateus, O único serviço que usava o modo assíncrono era o de recepção do MDF-e, todos os demais sempre funcionaram no modo síncrono e eles independem de configuração ou passagem de parâmetro para que funcionem no modo síncrono. Repito somente o método Enviar que possui 3 parâmetros conforme apresentado abaixo, sendo o terceiro responsável por determinar se o envio é síncrono ou assíncrono: // Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DAMDFE // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. // Obs: no modo Síncrono só podemos enviar UM MDF-e por vez. ACBrMDFe1.Enviar(StrToInt(vNumLote), True, True); Caso não tenha feito, favor atualizar todos os fontes de todas as pastas e reinstale o ACBr. Eu fiz uma alteração fazendo com que o envio do RPS a partir de agora só seja feito em modo síncrono independente do valor do terceiro parâmetro. O Encerramento é um evento e para que o mesmo seja enviado usamos o método EnviarEvento cuja sintaxe é: function EnviarEvento(idLote: Int64): Boolean; Como você pode ver ele tem apenas um parâmetro que é o numero do lote. Abaixo temos a lista de serviços disponibilizados pela SEFAZ que consta na versão 1 do manual do MDF-e de 13/06/2012 Isso demonstra claramente que somente o serviço Recepção do MDF-e era assíncrono, todos os demais serviços eram e são até hoje síncrono.

Boa tarde André, Complementando o que o Juliomar já lhe passou: Lines.Add('Chave : ' + ACBrMDFe1.Manifestos[0].MDFe.procMDFe.chMDFe); Lines.Add('Protocolo: ' + ACBrMDFe1.Manifestos[0].MDFe.procMDFe.nProt);

Adhelmar, Como assim remover o método Validar? É ele que garante que o XML foi gerado segunda a estrutura esperada pela SEFAZ. Estamos aqui para lhe ajudar da melhor forma possível, mas infelizmente você não esta respondendo as nossas perguntas. Se você realmente deseja a nossa ajuda, favor responder as nossas perguntas.

Adhelmar, Erro de Schema é uma informação muito vaga. O que realmente esta ocorrendo? Esta ocorrendo erro de validação do XML e consequentemente não esta sendo enviado? Precisamos saber com exatidão o erro que esta ocorrendo. Quem esta gerando o XML (o componente ou a sua aplicação)?

Bom dia Alex, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-5693

Bom dia Kaikson, O ERP esta enviando as notas para o ambiente de produção? Se sim, entre em contato com a prefeitura/provedor para saber o porque não aparece.

Bom dia Adhelmar, Esse erro não deveria ocorrer, todo caso faça o seguinte: Você tem fontes do ACBr 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. Por fim repita os testes.

Gabriel, Não precisa isso. Atualize todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes. Veja a alteração que eu fiz no arquivo ACBrNFSeXServicos.ini para a referida cidade.

Boa tarde Alex, Já esta no SVN.