roger.perezin

Boa tarde @João Batista de Oliveira Pode postar o arquivo Soap do envio, acredito que o erro esteja aí.

Boa tarde @Italo Jurisato Junior Seguem arquivos para análise. Nossa alterações: - A alteração no arquivo ACBrDFeHttpWinApi.pas não tem a ver diretamente com a implementação do novo provedor. Simplesmente facilitou no processo de desenvolvimento/debug. - Criamos um novo provedor que chamamos proDSFSJC (já que esta implementação da DSF é exclusiva pra São José dos Campos). Para tanto alteramos o arquivo Cidades.ini para que o arquivo de inicialização de SJC passe a ser o DSFSJC.ini. - Criamos o arquivo DSFSJC.ini baseado no arquivo GINFES.ini e nele alteramos os namespaces, as urls de acesso e as configurações necessárias. A mais curiosa é a inclusão de uma seção CDATA na montagem dos xmls de envio. Esta seção é necessária e foi incluída por indicação do próprio pessoal da DSF (sem ela o arquivo não é entendido pelo webservice deles). Eu não sei exatamente o que ela faz, talvez alguém com mais experiência nisso possa esclarecer este ponto. - Aí então fizemos as alterações necessárias nos próprios fontes do ACBr (criamos o enumerado proDSFSJC, e os devidos tratamentos de envios e respostas). Algumas considerações/explicações: - Nós utilizamos os seguintes métodos (somente estes foram testados e validados) : * RecepcionarLoteRpsV3 * ConsultarSituacaoLoteRpsV3 * ConsultarLoteRpsV3 * ConsultarNfsePorRpsV3 * CancelarNfseEnvio - A implementação da DSF foi bem curiosa. Pelo que entendi a ideia era causar o mínimo impacto nas aplicações dos contribuintes e para isso eles mantiveram a estrutura de xmls do GINFES. Mas a lógica de implementação e o conteúdo dos arquivos de resultados (e às vezes mesmo a estrutura deles) não são os mesmos. Exemplos: * O retorno do método ConsultarLoteRpsV3 não traz a identificação de cada um dos rps no lote. Ou seja, não é possível saber a situação de cada um deles após o envio do lote neste método. * Para saber da situação de uma determinada nota, deve-se chamar o método ConsultarSituacaoLoteRpsV3 para garantir que o lote foi processado e em seguida chamar ConsultarNfsePorRpsV3 para saber da situação da nota em si. * Apesar da estrutura do xml de envio do método CancelarNfseEnvio ser igual à do Ginfes, o arquivo de retorno é totalmente diferente e exigiu uma implementação nova de tratamento de retorno nos fontes do ACBr. Além dos arquivos fonte alterados e dos novos arquivos .ini estou anexando os arquivos .xds que nos foram repassados pela DSF. Fico à disposição para quaisquer dúvidas. ACBrDFeHttpWinApi.pas ACBrNFSeDANFSeFR.pas ACBrNFSeWebServices.pas Cidades.ini DSFSJC.ini nfse.xsd pnfsCancNfseResposta.pas pnfsConversao.pas pnfsNFSeG.pas pnfsNFSeW_ABRASFv1.pas xmldsig-core-schema20020212.xsd

Bom dia a todos A mudança realizada em São José dos Campos não é tão simples de ser resolvida. Foi feito um "híbrido" da implementação GINFEs com a implementação da DSF que roda em outras cidades (Abrasf). Sendo assim, a simples criação de um novo .ini não vai resolver. Fizemos aqui a implementação de um novo provedor (que chamamos de proDSFSJC) nos fontes do ACBr que posso compartilhar com a comunidade. @Italo Jurisato Junior, como faço pra subir as alterações?

Bom dia Italo Segue unit alterada. A alteração está na linha 2911. ACBrNFSeWebServices.pas

Correção: O novo código deve ser: if (FProvedor in [proCTA]) or ((FProvedor in [ProNotaBlu, proSP]) and (RetEnvLote.InfRec.ListaChaveNFeRPS.Count > i)) then Desculpem pelo erro. Abraços

Explicando a situação: Enviamos uma nota para a prefeitura de São Paulo que foi devidamente aprovada. No entanto, por algum problema de comunicação o retorno da operação não foi recebido, e portanto a nota ficou como se não tivesse sido enviada no nosso sistema. Ao tentar reenviar a nota ocorre a exceção: "Argument out of range". Este é o arquivo de retorno neste caso: <RetornoEnvioLoteRPS xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.prefeitura.sp.gov.br/nfe"> <Cabecalho Versao="1" xmlns=""> <Sucesso>true</Sucesso> <InformacoesLote> <NumeroLote>517474301</NumeroLote> <InscricaoPrestador>12345678</InscricaoPrestador> <CPFCNPJRemetente> <CNPJ>012345678901234</CNPJ> </CPFCNPJRemetente> <DataEnvioLote>2019-07-23T14:48:02</DataEnvioLote> <QtdNotasProcessadas>1</QtdNotasProcessadas> <TempoProcessamento>0</TempoProcessamento> <ValorTotalServicos>1572</ValorTotalServicos> </InformacoesLote> </Cabecalho> <Alerta xmlns=""> <Codigo>224</Codigo> <Descricao>RPS ja convertido na NFS-e 00015999. RPS nao sera processado.</Descricao> <ChaveRPS> <InscricaoPrestador>32171544</InscricaoPrestador> <SerieRPS>001</SerieRPS> <NumeroRPS>67550</NumeroRPS> </ChaveRPS> </Alerta> </RetornoEnvioLoteRPS> Depois de investigarmos, descobrimos o seguinte: O arquivo de retorno neste caso não traz as tags <ChaveNFeRPS> e <ChaveRPS> que deveriam trazer os dados da(s) notas(s) aprovada(s) e consequentemente o componente não pode preencher o campo FRetEnvLote.InfRec.ListaChaveNFeRPS. Note que apesar disso, a tag <QtdNotasProcessadas> retorna 1. Na sequência, o componente tenta recuperar o número da nota, o seu código de verificação e o número do lote através do seguinte código [unit ACBrNFSeWebServices, linha 2910 - revisão 17357] : if (FProvedor in [proCTA]) or ((FProvedor in [ProNotaBlu, proSP]) and (RetEnvLote.InfRec.InformacoesLote.QtdNotasProcessadas > 0)) then begin FNotasFiscais.Items[i].NFSe.Numero := RetEnvLote.InfRec.ListaChaveNFeRPS[I].ChaveNFeRPS.Numero; FNotasFiscais.Items[i].NFSe.CodigoVerificacao := RetEnvLote.InfRec.ListaChaveNFeRPS[I].ChaveNFeRPS.CodigoVerificacao; FNotasFiscais.Items[i].NFSe.NumeroLote := RetEnvLote.InfRec.NumeroLote; end; end; Como a quantidade de notas processadas é maio que zero, ele tenta acessar RetEnvLote.InfRec.ListaChaveNFeRPS - que não foi preenchida como vimos anteriormente. Para evitar o problema, substituímos a linha if (FProvedor in [proCTA]) or ((FProvedor in [ProNotaBlu, proSP]) and (RetEnvLote.InfRec.InformacoesLote.QtdNotasProcessadas > 0)) then por if (FProvedor in [proCTA]) or ((FProvedor in [ProNotaBlu, proSP]) and (RetEnvLote.InfRec.ListaChaveNFeRPS.Count >= i)) then Saudaçoes!

Eu realmente não tinha me atentado a esse requisito. Infelizmente não poderemos colaborar com o projeto nesse momento. Peço desculpas e agradeço a atenção.

Aos administradores e moderadores: O colega Rodrigo Traleski me alertou para uma questão em que não tinha pensado: Qual a versão mínima do Delphi deve ser suportada pelas classes/componentes? Exemplo: temos por padrão utilizar generics nos nossos projetos, mas essa funcionalidade só está disponível a partir do Delphi XE (se não me engano). Isso seria aceitável?

Olá Isaque, temos sim a intenção de doar esse código, até como forma de retribuição ao que já usufruímos do ACBr. Gostaríamos de já iniciar o desenvolvimento (programado para esta semana ainda) respeitando os padrões necessários. Existe algum manual de práticas a serem adotadas? Se não existe, há alguém com quem possa manter contato sobre estas questões e possíveis dúvidas durante o desenvolvimento? Tenho estudado o código do TACBrNFe/TACBrCTe e acho que o desenvolvimento da classe/componente deve levar algo em torno de 4 semanas. Abraço Roger Olá Edson.pol Nossos clientes também estavam esperando uma nova prorrogação, mas pelo jeito dessa vez não vai acontecer. Como o prazo é curto, agradecemos a oferta de ajuda no desenvolvimento, mas preferimos manter o projeto completamente "in house". Por outro lado, abriremos o código para testes assim que possível, e nesta fase toda a ajuda será muito bem-vinda. Abraço Roger

Boa tarde a todos. Atualmente trabalho numa empresa desenvolvedora de software em São Paulo e estou participando do desenvolvimento de uma aplicação que tem a finalidade de atender às exigências de um novo sistema do SPED: a e-Financeira. Trata-se de um projeto que estabelece um conjunto de arquivos digitais referentes a cadastro, abertura e fechamento anuais e auxiliares, e pelo módulo de operações financeiras. Em resumo, aplica-se a todo tipo de instituições financeiras (bancos, previdência privada, seguradoras, etc), e a entrega destes arquivos passa a ser obrigatória a partir de maio de 2016 (com informações do movimento de 2015). Para mais detalhes consulte http://sped.rfb.gov.br/pagina/show/1499 Nossa ideia é desenvolver as classes necessárias para o envio e consulta das informações (similares às classes de NF-e) e incorporar esse código ao projeto ACBr. A minha pergunta é a seguinte: Existe interesse de mais alguém da comunidade ACBr neste projeto?