arieldll

Estivemos verificando nos fontes atualizados. Este tópico está resolvido.

Seria possível incluir as seguintes cidades no ACBr: Provedor Betha: São joão do Oeste/SC - IBGE 4216255 Provedor GINFES: Pouso Alegre/MG - IBGE 3152501 Atenciosamente, Ariel.

Boa tarde Senhores. Estamos realizando a integração com o webservice de Documentos Fiscais Eletrônicos, porém, algumas vezes estou recebendo a seguinte mensagem: "Rejeição: Consumo Indevido (Deve ser utilizado ultNSU nas solicitações subsequentes. Tente após 1 hora)" - Tanto no ambiente de homologação como de produção. Para o cliente obter todos os documentos fiscais, estou realizando o seguinte trecho de código: FNSU := FNota.WebServices.DistribuicaoDFe.retDistDFeInt.ultNSU; if (StrToInt64(Trim(FNSU)) <> 0) and (FNSU <> FNota.WebServices.DistribuicaoDFe.retDistDFeInt.maxNSU) then begin FNota.DistribuicaoDFe(UF, EmpresaCNPJ, FNSU, ''); end; Por ora temos a integração pelo webservice de consulta das NFe, e lá existe um parâmetro dizendo que o webservice estaria retornando mais documentos ou se este seria o último "lote". Tem algo parecido neste? Alguém saberia como posso contornar esse problema de consumo indevido? Agradeço desde já, Atenciosamente, Ariel.

Bom dia Senhores. O grande problema é que a capicom não conseguiu assinar um a assinatura válida para o algoritmo rsa-sha1 (que consta no manual do provedor de SP). A única alternativa que encontramos foi utilizar recursos nativos da própria assinatura do windows via C#. Cheguei a entrar em contato com desenvolvedores em outros países através do fórum da Embarcadero, porém ninguém sabia me informar como fazer isso com delphi. Atenciosamente, Ariel.

Eduardo, ainda não precisei utilizar esse provedor de Salvador. Desculpe mas só preciso entender uma coisa, essa dll já está inclusa no projeto? Se sim, poderia me dizer qual é o nome dela/localização? Ela também funciona referenciando a assinatura por uma tag igual a CAPICOM? Obrigado. Atenciosamente, Ariel.

Boa tarde eduardo. Neste caso, então acredito também ser melhor incorporada ao ACBr a dll desenvolvida. Atenciosamente, Ariel.

Bom dia Senhores. Csoft, não tenho profundos conhecimentos para lhe dizer a diferença entre a capicom e a openssl, e quais seriam as vantagens e desvantagens ao utilizá-las. Eduardo, não sei se entendi vossa dúvida, mas na questão de fonte (código fonte), ele está anexo ao projeto na primeira página deste tópico. O que realmente me preocupa em seguir com a dll é que todos os desenvolvedores deverão importá-la em seu delphi (o que na minha opinião se torna muito burocrático). Já o executável, não seria necessário, pois, bastaria uma chamada para ele. Mas claro, não omitir o código fonte de ninguém, ou seja, ele continuaria disponível para a comunidade. Nosso único motivo de ter criado esta nova dll de assinatura, foi porque a capicom assina uma tag junto, então, não era possível assinar apenas uma string. Eduardo, por favor, poderia me explicar melhor essa parte do replace no campo ID? Acabei não entendendo. Atenciosamente, Ariel.

Boa noite Senhores. Desculpem a demora em responder. Vamos por partes. Caros, vos digo: Tricon.paulo, o exemplo que utilizamos para teste é o mesmo que está disponível no programa exemplo nos fontes do componente. Csoft, não realizamos testes usando openssl, apenas utilizamos a CAPICOM. Daniel, A solução está funcional, porém, deveriam ser realizados mais alguns testes. A princípio estava tudo certo e já poderia ser enviado para o respositório. Eu estava pensando que como ninguém se manifestou sobre a assinatura para não precisar utilizar outra DLL que não seja a CAPICOM, se não seria melhor escrever um executável em C# que possa assinar e passar de alguma forma na comunicação dos processos ou pelo shell, para não ser necessário todos instalarem a DLL que desenvolvi toda vez, pois, isso além de trabalhoso, me parece difícil de mantê-la. Neste caso, ficaria a critério do projeto aceitar ou não essa sugestão de ter um .exe compilado juntamente com o projeto, porém inerentemente ficaria muito mais fácil dos membros aderirem ao provedor de São Paulo, e também, ficaria mais organizado. Há de se estudar essa possibilidade na minha opinião. Atenciosamente, Ariel.

Boa tarde. Você vai ter que verificar quais dados estão indo para a prefeitura, e se não resolver o problema entrar em contato diretamente com a prefeitura, informando o erro e enviando o xml para eles, então lhes dirão qual é o problema. Atenciosamente, Ariel

Bom dia. É lido quando é retornado o valor do número da NFSe no xml de retorno após o envio. Anexo o exemplos.zip, retirado do repositório oficial da prefeitura. Observe os arquivos RetornoEnvioRPS.txt e RetornoEnvioLoteRPS.txt Atenciosamente, Ariel. exemplos.zip

Desculpe, mas não entendi o que você quis dizer com "propriedade do webservice". Você quis dizer de algo ser retornado no XML? Atenciosamente, Ariel.

Boa tarde. A questão do número da NFSe é gerado pelo webservice ao autorizar o RPS. Esse número é recebido ao enviar o RPS para a prefeitura, e depois disso, tem uma função que o Ítalo adicionou (se não me engano), que após 20 ou 30 segundos faz uma consulta na NFSe para receber o xml da situação dela, aí sim ela é devidamente autorizada. Se você está utilizando um certificado de uma empresa com o cnpj de outra, é muito provável que não vá funcionar, pois, até onde conheço, cada empresa vai ter um cadastro na prefeitura, então o certificado de cada será diferente. Atenciosamente, Ariel.

Boa tarde. O que acontece é que os únicos eventos que precisam de uma assinatura especial são os de envio e de cancelamento, o de consulta é assinado na mesma forma que os outros provedores, por isso não foi preciso desenvolver uma nova rotina de assinatura para esse procedimento. Aliás, não sei o porquê disso, mas depois de ser gerada a assinatura da hash rsa-sha1 da string, a prefeitura pede que o documento também seja assinado com a capicom através da tag <signature>, como todos os outros documentos digitais. Estou sem os fontes comigo agora, mas se não me engano NotaUtil.AssinaturaSP pede a senha do certificado e a string que será assinada, retornando o valor rsa-sha1 da assinatura. Atenciosamente, Ariel.

Boa tarde Senhores. Felipe, conseguiu testar e homologar os fontes? Atenciosamente, Ariel.

Neste caso, o número é recebido após a autorização do lote. Aí é crítico, porque não tem nem valor para um protocolo ou similares. Referente aos erros, verifique como estão sendo geradas as informações no componente, pois como disse no post anterior, há algo realmente estranho que está fazendo assinar o RPS, quando na verdade não poderia fazer isso, pois está configurado para justamente não fazer isso. Atenciosamente, Ariel.

Quem retorna isso é o próprio webservice da prefeitura. Nada a princípio está fixo. A única coisa é que o número do lote não é gerado se ele não é autorizado e não será nem ao menos disponibilizado o número dele. Então verifiquei se o lote está vindo em branco ou nulo, e se estiver, então é retornado zero, tal qual na homologação. E também, para não fugir da lógica dos outros provedores, que em sua maioria retornam um valor inteiro para o número do lote. Detalhe: Não é como nos outros provedores que você gera o número do lote e envia, nesse é ao contrário. Você recebe o número do lote após ser autorizado, e não recebe também número de protocolo (em qualquer evento). Atenciosamente, Ariel.

Na realidade ele deveria informar que há caracteres inválidos, e não que há informações faltando, mas tudo bem. Quando eu estava implementando cheguei a ter os problemas com {"<", ">"}, o qual algumas informações do cliente tinham esses caracteres, falhando na hora de validar. Mas se você conseguiu enviar e não teve problemas, já é um importante passo. Só atento que se você está emitindo os documentos como ambiente de homologação através do envio de lote, o retorno sempre será lote 0. Editado: Felipe, na realidade, fui ver o que estava ocorrendo nessa linha, e ele não poderia entrar no if que está lá(linha 857), porque não é assinado o RPS em si, e sim são todos os RPS que são assinados quando o documento XML é assinado, junto com todos os outros dados. A assinatura do RPS é feita pela tag <Assinatura>, a qual a dll que desenvolvi deve assinar, então ele não poderia em hipótese alguma estar entrando naquele if. Isso deveria estar configurado na Unit do Provedor de São Paulo como sendo falso, então deveria cair sempre no else. A configuração que disse, está no arquivo ACBRProvedorSP.pas na função TProvedorSP.GetConfigCidade no trecho: ConfigCidade.AssinaRPS := False; ConfigCidade.AssinaLote := True; Realmente estranho. Caso você consiga homologar os fontes e verificar que tudo está correto(funcionando envio, consulta, cancelamento e impressão do DANFSe), então creio que a implementação já possa ser disponibilizada no repositório oficial. Atenciosamente, Ariel.

Bom dia Senhores. Caro Felipe, verifique se todos os campos obrigatórios estão sendo passados pela demo. Os espaços que você citou não devem existir nas assinaturas. Atenciosamente, Ariel.

Desculpe, mas ainda não entendi uma coisa: Você está testando com a versão dos meus fontes ou está reescrevendo as alterações? Passe o xml completo no ponto em que está acontecendo o erro para que eu possa analisa-lo. Atenciosamente, Ariel.

Fora implementado o PedidoEnvioLoteRPS, o qual você pode enviar 1 ou vários RPS. Se você está tentando utilizar o PedidoEnvioRPS, terá que implementar ele, mas não vejo necessidade neste caso. Não sei se entendi bem o que anda acontecendo, mas é muito estranho estar gerando esse xml, pois o de envio de lote RPS para o provedor SP é algo como: <PedidoEnvioLoteRPS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.prefeitura.sp.gov.br/nfe"> <Cabecalho Versao="1" xmlns=""> <CPFCNPJRemetente> <CNPJ>04642554000143</CNPJ> </CPFCNPJRemetente> <transacao>false</transacao> <dtInicio>2007-01-20</dtInicio> <dtFim>2007-01-20</dtFim> <QtdRPS>2</QtdRPS> <ValorTotalServicos>2000</ValorTotalServicos> <ValorTotalDeducoes>200</ValorTotalDeducoes> </Cabecalho> <RPS xmlns=""> <Assinatura>ro6Og7L5BMPpYZKXfSSITNe8U9C4a95P9dIspX8R0Okg1CRsA87N08Llaq+q6IVOGLhjGMkAELBIkQ8T0BGR3czgtJAuOcgMlOmGZlgziWAg3Kww3pFD+rYxE+DRgL2M5QXTaZEYwVNj0lZyJpt1nS9LHUqO7PB+ivYRk+ewUVA=</Assinatura> <ChaveRPS> <InscricaoPrestador>31000000</InscricaoPrestador> <SerieRPS>LLLLL</SerieRPS> <NumeroRPS>1</NumeroRPS> </ChaveRPS> . . . . </PedidoEnvioLoteRPS> Atenciosamente, Ariel

Continua normal, o que foi alterado são as funções que geram os xmls dentro do componente. Como você vai passar os dados, será de mesma forma que os outros provedores, apenas o que vai mudar talvez, são pequenos detalhes em alguns campos. Não foram inutilizadas as rotinas, mas é que elas simplesmente não se encaixam nesse tipo de xml, então quase todas as rotinas de leitura e escrita de xmls tiveram que ser novamente criadas especialmente para esse provedor, mas as dos outros provedores foram mantidas e não alteradas. Você está utilizando as schemas que foram dispostas no meu primeiro envio da implementação? Se não for com esses, não vai funcionar de jeito algum, pois o padrão é totalmente diferente. Apenas utilize a função "Enviar", deve funcionar. Qualquer coisa, poste o trecho do código do método de envio que você está fazendo. Atenciosamente, Ariel.

Caros, bom dia. Referente a dll, não consegui fazer o delphi importar o assembly gerado pela dll se não fosse com o deploy. Se vocês souberem como fazer isso de uma forma mais funcional e elegante, por favor, compartilhem. FAlmeida, pelo que entendi o padrão que você citou é o ABRASF, o qual o provedor de NFSe de São Paulo infelizmente não se adequa, pois, tem um layout próprio, e que em minha implementação, na hora em que o xml é gerado nesse ponto, há uma função personalizada especialmente para o provedor de SP. Seguem anexos os exemplos oficiais dos xmls disponibilizados pela prefeitura de São Paulo. Não entendi sua última pergunta sobre incompatibilidade, poderia ser mais claro? Atenciosamente, Ariel. exemplos.zip

Boa tarde Senhores. Caro Cabongue, é este processo mesmo que deve ser feito. Também devem ser copiados todos os arquivos .tlb para as pastas que vocês estiverem utilizando. Atenciosamente, Ariel.

Você já tentou com outro certificado? Caso não tenha tentado ainda, tente com outro. Nós testamos com um certificado emitido pela Serasa, e aparentemente não tivemos problemas. Essa DLL foi compilada para o .net framework 2.0. Esqueci de pedir, mas qual versão do windows você está utilizando? Atenciosamente, Ariel.

O que está ocorrendo na realidade, é que a instância "coll" está sendo criada, mas ela é do tipo null, ou seja, nula, pois o certificado não está sendo encontrado para gerar uma instância do objeto do tipo X509Certificate2Collection. Neste trecho: X509Certificate2Collection coll = store.Certificates.Find(X509FindType.FindBySerialNumber, serial, true); Verifique o que está indo como parâmetro para a função que invoca a dll, nos parâmetros "serial" e "original". O serial deve ser o mesmo que está carregado no ACBRNFSe, e o original uma string contendo um conjunto de caracteres que são a assinatura em si. Caso não consiga descobrir o que pode ser o problema, pegue um serial que você tenha certeza que esteja instalado, e alimente manualmente a dll para saber se há retorno ou não. Atenciosamente, Ariel.