Italo Giurizzato Junior

Bom dia Pedro, Muito obrigado pela colaboração, já esta no SVN.

Bom dia Joffas, Já foi divulgado as URLs de homologação e de produção?

Bom dia, A partir do dia 02/03/2022 se não prorrogar novamente, o webservice que atende a cidade de Sorocaba vai ser trocado. O provedor continua o mesmo, mas vão deixar de usar o layout próprio do provedor DSF e vão passar a usar o layout da ABRASF versão 2.03 Não sei lhe informar se o ambiente de homologação do novo webservice já esta ativo, mas não custa nada tentar. Veja como esta no arquivo ACBrNFSeXServicos.ini [3552205] ; Atualizado em 01/02/2022 Nome=Sorocaba UF=SP ; Remover essa linha e descomentar as 4 linhas abaixo após o dia 02/03/2022 ; Provedor=DSF ; Versao=2.03 ; ProRecepcionar= ; HomRecepcionar=https://homol.issdigitalsod.com.br/notafiscal-abrasfv203-ws/NotaFiscalSoap ; Remover essa linha e as 7 linhas abaixo após o dia 02/03/2022 Provedor=ISSDSF ; ProRecepcionar=https://www.issdigitalsod.com.br/WsNFe2/LoteRps.jws HomRecepcionar= ; ProNameSpace=http://proces.wsnfe2.dsfnet.com.br HomNameSpace=http://proces.wsnfe2.dsfnet.com.br Para testar deixa desta forma: [3552205] ; Atualizado em 01/02/2022 Nome=Sorocaba UF=SP Provedor=DSF Versao=2.03 ProRecepcionar= HomRecepcionar=https://homol.issdigitalsod.com.br/notafiscal-abrasfv203-ws/NotaFiscalSoap Salve o arquivo; Execute o Compila_RES; Reinstale o ACBr; E inicie os testes.

Bom dia, É necessário verificar como esta sendo gerado os registros dos seguimentos A e B e fazer as alterações para que quando se tratar de PIX sejam gerados do forma diferente.

Bom dia Ângelo, A cidade de Mogi das Cruzes se utiliza do provedor SmarAPD - layout da ABRASF versão 2.03 O método Emitir em se modo de envio automático se utiliza do envio de lote no modo síncrono, neste caso não costuma retornar o numero do protocolo. O numero do protocolo somente é retornado no envio de lote no modo assíncrono.

EDIT: As alterações abaixo já se encontram no SVN desde o dia 23/02/2022. Olá Pessoal, Como sempre queremos facilitar pra vocês ao máximo o uso de nossos componentes e a manutenção de seu código. Sendo assim, achamos apropriado fazer algumas alterações no componente ACBrNFSeX. O componente antigo, ACBrNFSe, não será alterado visto que não estamos fazendo melhorias nele, apenas manutenção de erros e falhas. Para saber mais sobre como migrar do ACBrNFSe para o ACBrNFSeX, veja esse link. Vamos detalhar abaixo as mudanças e as motivações. Anteriormente, no componente tínhamos as seguintes propriedades: XML, XMLOriginal, XMLAssinado e XMLNFSe. Essas propriedades foram criadas seguindo o modelo do componente antigo e podiam ser lidas através da lista de notas, como por exemplo no código: Elas tinham a seguinte função no componente antigo: XML: o XML da NFS-e retornado pelo WebService; XMLNFSe: o XML da NFS-e retornado pelo WebService; XMLOriginal: o XML do RPS sem assinatura; XMLAssinado: o XML do RPS (que pode estar assinado ou não dependendo do provedor); Agora pense um pouco sobre o que viu. Temos duas propriedades que contem o XML da NFS-e e duas que contem o XML do RPS. Não temos necessidade dessa redundância, principalmente porque o componente novo, ACBRNFSeX, está muito mais funcional na questão de separação de comportamento dos provedores. Sendo assim, as propriedades XMLAssinado e XMLNFSe acabaram ficando sem utilidade. Estávamos na situação de que ao tentar ler as mesmas é retornado uma string vazia. Já na propriedade XMLOriginal era retornado o XML do Rps (assinado ou não conforme o provedor). Por firm, na propriedade XML era retornado o XML da NFS-e. Estamos fazendo as seguintes alterações no ACBrNFSeX: As propriedades XMLAssinado e XMLNFSe foram removidas. Elas não continham nenhuma informação. A propriedade XML foi renomeada para XmlNfse, deixando mais claro o objetivo. A propriedade XMLOriginal foi renomeada para XmlRps, dando mais clareza ao que ela contêm. Assim ao invés de 4 propriedades com nomes talvez confusos e dados redundantes, agora temos 2 funcionais. Para aqueles que desejam guardar o XML do Rps e ou da NFS-e no banco de dados basta ler as propriedades mencionadas acima podem usar um código semelhante ao abaixo XMLReciboRPS := ACBrNFSeX1.NotasFiscais.Items[ i ].XmlRps; XMLNotaServico := ACBrNFSeX1.NotasFiscais.Items[ i ].XmlNfse; Onde "i" é o índice da nota na lista, que pode variar de zero até a quantidade de documentos menos 1. Observações: Se o valor da propriedade de configuração: Configuracoes.Arquivos.Salvar for True os valores de XmlRps e XmlNfse serão salvos em disco; O conteúdo de XmlRps será salvo na pasta Recibos e o de XmlNfse na pasta Notas;

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

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

Boa tarde a todos, Analisando o código do componente ACBrPagFor, na Unit ACBrPagForGravarTxt notei que para o banco Itaú consta uma alteração para gerar os campos referente ao PIX no SegmentoB. Para os demais bancos não tem nada. @suporteatinfoabra a unit que indiquei acima e veja como foi feito para o banco Itaú. - Procedure: GeraSegmentoB, tente fazer algo semelhante para o banco Sicred.

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

Bom dia, Já esta no SVN.

Bom dia Pedro, Já esta no SVN.

Bom dia Maiquel, Já esta no SVN.

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

Bom dia Marcos, Já esta no SVN.

Bom dia Ângelo, Para não misturar os assuntos lhe peço para criar um tópico para cada problema. Já inclui na minha lista de tarefas para analisar o problema inicial que é da leitura do XML. TK-2398 Me diz uma coisa o XML a ser lido foi retornado pelo webservice ou baixado do site do provedor? Qual é o provedor?

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

Boa tarde Jonathas, Já inclui na minha lista de tarefas. TK-2394

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

Rogério, Já inclui na minha lista de tarefas. TK-2392

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

Boa tarde, É no CIGA.Provider Por favor anexe a unit alterada para que possamos avaliar e enviar para o SVN.

Boa tarde, Muito obrigado pelos arquivos, já inclui na minha lista de tarefas.TK-2391

Boa tarde Pessoal, Para quem ainda não sabe como configurar o componente quando a SEFAZ-Autorizadora entra em contingência, vejam a dica no link abaixo:

Segundo o Manual da ABRASF - layout da versão 1 o agrupamento <Pedido> é sim um elemento dentro do agrupamento de <Confirmacao>. O provedor que esta gerando o XML de retorno de cancelamento de forma errada, ou seja, não esta seguindo o que esta escrito no manual. Alias o retorno do cancelamento esta totalmente diferente do previsto no manual. Como vai ser dificil eles concertarem a porcaria que fizeram, o jeito vai ser reescrever a procedure TratarRetornoCancelaNFSe que esta na unit ACBrNFSeXProviderABRASFv1 na unit Provider do provedor.