Ir para conteúdo
  • Cadastre-se

Cognum Informatica Ltda.

Membros Pro
  • Total de ítens

    217
  • Registro em

  • Última visita

Posts postados por Cognum Informatica Ltda.

  1. Boa Tarde,

    estamos migrando nossos executáveis de NFe do Delphi para o C#, e nessa migração, ao realizarmos um teste de emissão de NFe, recebemos o erro: Msg=Nota(s) n[195][163]o confirmadas:49101->799-Rejei[195][167][195][163]o: Valor total do ICMS Interestadual da UF de destino difere do somat[195][179]rio dos itens.

    Ao compararmos os códigos, identificamos que no Delphi existem os atributos: 

    Total.ICMSTot.vFCPUFDest

    Total.ICMSTot.vICMSUFDest

    Total.ICMSTot.vICMSUFRemet

    Esses atributos não existem na classe TotalNFe da biblioteca do C#:

    nfe2.thumb.png.4937676e8c55cbf82b22801f14dbbd62.png

     

    Vejam na imagem anexa, uma comparação entre os XMLs gerados pelo C# e pelo Delphi respectivamente:

    nfe.thumb.png.e89c35bb55d2f3c03407d856785f3f60.png

     

    Obrigado

  2. Boa tarde. @Italo Jurisato Junior

    Baixei os fontes e verifiquei que a questão do link esta correta, agora o problema abaixo:

    "Outro problema, ocorreu com uma consistencia na unit ACBrNFSeWebServices no metodo InicializarGerarDadosMsg onde gerava a seguinte mensagem:

    "O Provedor eGoverneISS  necessita que a propriedade: Configuracoes.Geral.Emitente.WebChaveAcesso seja informada";

    O eGoverneISS não utiliza esta propriedade WEBCHAVEACESSO, utiliza a propriedade Prestador.ChaveAcesso ....

    Retirei o proEgoverneISS desta consistencia e as notas fiscais no meu cliente, voltaram a funcionar normalmente. "

     Este caso ainda persiste, continua gerando a consistencia equivocadamente.

    A alteração que fiz na unit ACBrNFSeWebServices.pas ,não foi pro repositorio.

    @Fábio Eduardo

    @Cognum Informatica Ltda.

  3. Em 18/09/2020 at 13:40, Italo Jurisato Junior disse:

    Boa tarde Fabio,

    Quanto a alteração na unit ACBrNFSeWebServices precisa ser revista pois me parece que para realizar o cancelamento se faz necessário informar uma chave de Autenticação.

    Essa chave é única de cada NFS-e a ser cancelada ou é única para o contribuinte.

    Se for única de cada nota faz sentido a sua alteração.

    @Italo Jurisato Junior, a chave de autenticação que o eGoverneISS utiliza para validar a nota fiscal de serviço ou cancelar a nota fiscal de serviço é a que está na propriedade  Prestador.ChaveAcesso(classe TIdentificacaoPrestador)

    Não tem haver com a propriedade Geral.Emitente.WebChaveAcesso, que está sendo consistida na unit ACBrNFSeWebServices , eu não preencho essa propriedade no eGoverneISS.

     

    Fábio Eduardo.

     

  4. Ola, pessoal 

    Identifiquei uma alteração na tag LINK do xml de resposta  do provedor eGoverneISS, municipio de OSASCO. Até o mês de agosto/2020 a url da tag LINK iniciava com "HTTP:/" e a partir de setembro/2020 começou a ser enviada como "HTTPS://" desta forma o metodo RetirarPrefixo da unit PCNFSConversao começou  a retirar o prefixo "s:" , gravando o url do Link incorretamente.

    @Italo Jurisato Junior , fiz uma implementação no metodo RetirarPrefixo da unit PCNFSConversao estou enviando em anexo para avliação.

    Outro problema, ocorreu com uma consistencia na unit ACBrNFSeWebServices no metodo InicializarGerarDadosMsg onde gerava a seguinte mensagem:

    "O Provedor eGoverneISS  necessita que a propriedade: Configuracoes.Geral.Emitente.WebChaveAcesso seja informada";

    O eGoverneISS não utiliza esta propriedade WEBCHAVEACESSO, utiliza a propriedade Prestador.ChaveAcesso ....

    Retirei o proEgoverneISS desta consistencia e as notas fiscais no meu cliente, voltaram a funcionar normalmente.

    Fábio Eduardo.


     

    ACBrNFSeWebServices.pas pnfsConversao.pas

  5. Bom dia. @Italo Jurisato Junior e @julianamver 

    Eu nunca utilizei o sistema de exemplo(DEMO), mas pelo que pude ver no xml gerado está faltando alguns campos para serem informados no xml, um deles e o mais importante é o campo de CHAVE DE AUTENTICAÇÃO. Este campo funciona como um certificado digital para o site do EGoveneiss , eu não sei se no sistema de exemplo(DEMO) tem lugar para digitar esta chave.

    E tambem faltam informações em algumas tags importantes

    <rgm1:CEPPrestacaoServico />
      <rgm1:CidadePrestacaoServico />
      <rgm1:EnderecoPrestacaoServico />
      <rgm1:EstadoPrestacaoServico />

    A chave de autenticação deve ser gerada no site da prefeitura pelo emissor da nota fiscal, no site tem  as instruções de como gerar esta chave.

     

    @Fábio Eduardo de Souza

     

    • Curtir 2
  6. Italo, 

    Desculpe a demora na resposta, mas a prefeitura de Osasco e o Egoverne não disponibilizam arquivo de schemas, pesquisei entrei em contato com o suporte técnico, mas  novamente não encontrei nada.

    O que eles disponibilizam , e o suporte Egoverne me passou foi o manual onde consta alguns exemplos de xml de notas fiscais e o endereço das WSDL.

    Você lembra, quando te passei este leiaute para criação , isso foi um dos problemas , a falta dos schemas XML , que pelo visto continua não tendo, os caras são complicados demais.

    Se eu puder ajudar em mais alguma coisa me avise.

    Obrigado pela atenção.

    @Fábio Eduardo de Souza

     

     

    Manual_Emissao_NFe_WebService2_V8.pdf

  7. Ola pessoal, 

    Ontem(18/12/2018) tivemos problemas com a validação das NFse para OSASCO -  provedor EGoverniss, e analisando o site da prefeitura verifiquei que foi lançada uma nova versão do provedor.

    As principais alterações foram:

    - URLs de comunicação - Já procedi com as alterações e anexei o .INI abaixo;

    - Inclusão dos campos , que não fiz no componente:

          NumeroRecibo - Número do Recibo Provisório de Serviço que será convertido em NF-E (RPS);

          DataRecibo -  Data de emissão do Recibo Provisório de Serviço que será convertido em NF-E ;

          EqptoRecibo - Identificação do equipamento que emitiu o recibo provisório de serviço (máximo 5 caracteres)

    Estes novos campos não são campos obrigatórios na validação da NFSe hoje. São opcionais, se preenchidos serão consistidos. Estes campos foram criados para atender uma solicitação que fizemos a prefeitura de Osasco, pois não tínhamos, neste provedor, nenhuma amarração ou chave, para evitar duplicidade de notas fiscais, tivemos varios problemas com duplicidade de nota fiscal no site da prefeitura(mesmo XML ,  varias notas fiscais diferentes);

    Em anexo estou enviando o arquivo .INI já atualizado com as URLS e o manual atualizado, com os novos campos, para que assim que possível, sejam incluídos no provedor. 

    Agradeço pela atenção, me coloco a disposição para validação dos novos campos.

    @Fábio Eduardo de Souza 

    EGoverneISS.ini

    Manual_Emissao_NFe_WebService2_V8.pdf

    • Curtir 1
  8. Olá amigos, 

    Mais uma vez venho pedir auxilio a vocês. Estamos abrindo novos clientes na cidade de ITUPEVA-SP e estes irão fazer a emissão de NFSe via webservice com a prefeitura de Itupeva provedor SIAPPA.

    Verifiquei no componente  ACBR que esta prefeitura ainda não foi desenvolvida, desta forma, consegui os arquivos WSDL, e o manual de instrução da integração via WEBSERVICE onde consta um xml de exemplo.

    Sei da demanda grande de trabalho que possuem, então , assim que for possível a inclusão do provedor SIAPPA  e da prefeitura de ITUPEVA, por favor me comuniquem, fico a disposição para realizar as validações deste provedor.

    Não fiz a inclusão deste provedor no componente , pois não me sinto apto ainda, a fazer esse tipo de inserção.

    Agradeço a atenção.

    @Fábio Eduardo de Souza

     

     

    manual_e_arquivos_wsdl_webservice_pre_nfs_e.rar

    • Curtir 1
  9. Boa tarde , a todos

    Estou com alguns clientes emitindo notas fiscais de serviço eletronicas(NFSe) pelo provedor GINFES, em JUNDIAI e PAULINIA  estado de SP, e venho notando que desde a introdução da versão 4.0 da NFe com os novos protocolos de envio, os RPS estão demorando para serem processados pelo GINFES;

    Envio o RPS pelo metodo :

    ACBr.Enviar(solicitacao) ; 

    em seguida eu  faço uma consulta pra saber o CSTAT (situação)deste RPS, se foi processado ; 

                if  acbr.WebServices.ConsLote.Protocolo <> '' then begin
                   if acbr.WebServices.ConsultaSituacao(acbr.WebServices.ConsLote.Protocolo,IntToSTR(solicitacao)) then begin
                      cstat                := StrToInt(acbr.WebServices.ConsSitLoteRPS.Situacao);
                   end;
    Neste momento o webservice esta me retornando cstat 2 - em processamento, quando isso ocorre eu solicito ao usuario que  aguarde e repita o processo..... estranhamente isso se repete, as vezes, por mais de 10 tentativas, quando não gera o erro de TIMEOUT.....

    Tem alguem no grupo passando pelo mesmo problema de lentidão no processamento do webservice que eu??? Estou utilizando os métodos de consulta errados?

    Aguardo.

    @Fábio Eduardo de Souza

     

     

  10. Italo, bom dia 

    Rapaz ainda não tenho o conhecimento suficiente do projeto para incluir um provedor novo. Ainda conto com a boa vontade e a disponibilidade de vcs moderadores. Me disponho ajudar no contato com o pessoal da CECAM e nos testes para homologação do provedor e possiveis acertos assim como fizemos com o EGoverniss. Mais que isso ainda não me sinto confortável.

    @Fábio Eduardo de Souza

     

  11. Boa tarde, 

    Apo´s atualização dos componentes ACBR para NFSe, comecei ater problemas na validação das NFSes para o municipio de OSASCO provedor EgoverneISS. 

    Analisando a mensagem de erro e as alterações feitas no componente ACBR, encontrei uma consistência na propriedade Configuracoes.Geral.Emitente.WebChaveAcesso  que não faz sentido para o provedor EGoverneISS pois o mesmo não utiliza está propriedade. a propriedade utilizada pelo EGoverneISS é a FNotasFiscais.Items[0].NFSe.Prestador.ChaveAcesso.

    Desta forma, fiz uma alteração, desconsiderando a consistencia abaixo qdo o provedor for proEGoverneIss. 

    procedure TNFSeWebService.InicializarGerarDadosMsg;
    begin

    ....

         // Agili, Agiliv2, CTA, Governa, proEGoverneISS
        ChaveAcessoPrefeitura := FPConfiguracoesNFSe.Geral.Emitente.WebChaveAcesso;
        if (ChaveAcessoPrefeitura = '') and
    antes        (Provedor in [proAgili, proAgiliv2, proCTA, proGoverna, proEgoverneISS]) then

    depois:       (Provedor in [proAgili, proAgiliv2, proCTA, proGoverna]) then

          GerarException(ACBrStr('O provedor ' + FPConfiguracoesNFSe.Geral.xProvedor +
            ' necessita que a propriedade: Configuracoes.Geral.Emitente.WebChaveAcesso seja informada.'));

    em anexo estou enviando a UNIT para que vcs avaliem minha alteração.

    Obrigado.

    E estou a disposição

    @Fábio Eduardo de Souza 

    ACBrNFSeWebServices.pas

  12. Boa tarde, @Italo Jurisato Junior 

    Há algum tempo venho tendo várias reclamações de que ao validar uma nota fiscal de serviço (NFSe) na Prefeitura de Jundiaí , provedor GINFES,  estava retornando uma mensagem em branco, apenas uma caixa de texto com um simbolo de alerta mas sem mensagem. Após o usuário tentar enviar a NFSe novamente o processamento era realizado com sucesso.  

    Analisando os XMLs verifiquei que nos casos onde a nota fiscal retornava com a mensagem em branco, a situação do lote era 2 (Não Processado) veja o xmls de resposta :

    <?xml version="1.0" encoding="UTF-8"?>

    -<ns3:ConsultarSituacaoLoteRpsResposta xmlns:ns3="http://www.ginfes.com.br/servico_consultar_situacao_lote_rps_resposta_v03.xsd" xmlns:ns2="http://www.ginfes.com.br/tipos_v03.xsd">

    <ns3:NumeroLote>11689</ns3:NumeroLote>

    <ns3:Situacao>2</ns3:Situacao>

    </ns3:ConsultarSituacaoLoteRpsResposta>

    Percebi que, na minha aplicação, ao executar a consulta da situação do lote  pelo método "WebServices.ConsultaSituacao" , o retorno era uma mensagem em branco, analisando o fonte do ACBR, verifiquei que o metodo  TNFSeConsultarSituacaoLoteRPS.Executar: Boolean da unit ACBrNFSeWebServices não está tratando a resposta para situação 2 dos retorno do GINFES.

    Veja o trecho do código onde ele não trata a mensagem para situação 2 (inicio na linha 3639 unit ACBrNFSeWebServices) 

     if (FProvedor in [proEquiplano, proEL ]) then
        cSituacao := '2'  // Não Processado, lote com erro
      else
        Coincidência := '1'; // Lote Não Recebido

      // Lote processado ?    Situaçao 5 usado para sucesso no provedor CONAM
      if (FSituacao = cSituacao) or (FSituacao = '3') or (FSituacao = '4') or
         (FSituacao = '5') or (FSituacao = 'Erro')
    then
        Result := TratarRespostaFinal;

    Em meus teste Italo, como eu utilizo somente o código da situação não utilizo a msg , eu inclui no primeiro IF acima o provedor proGINFES, e desta forma, não geraou a tela de mensagem em branco e  consegui recuperar a Situação 2 na minha aplicação . Não analisei mais afundo o código para saber se estava retornando alguma mensagem depois que alterei.

    Desculpem, ter colocado trechos de código no tópico, sei que isso não é legal, mas foi a forma que achei para explicar o caso e o caminho para a solução. Qualquer duvida, me passem que eu respondo, sei que minhas explicações são péssimas.

    Coincidencia ou não está situação 2 começou a ser gerada com muita mais frequencia depois que entrou no ar a versão 4.0 da NFe, o rpocessamento da NFSe na prefeitura está mais lento.

    Mais uma vez desculpem pelo post bagunçado, e reitero minha disponibilidade para qualquer esclarecimento sobre meus testes.

    @Fábio Eduardo de Souza

  13. Pessoal, Boa tarde

     

    Desde ontem as 11:30 estou tendo problemas com meus clientes, e só consegui resolver com a opção LT_TLSv1_2 e com atualização do windows. 

    Cuidado com as atualizações , no caso do WIN 7  tem atualizações que ele considera como não importantes, forçando o usuario ou técnico a marcar as atualizações e ai atualizar.

    Agora, no windows 10, em alguns casos, ele mostra que "Todas as atualizações foram feitas", mas tem uma "Opção Avançada" no update onde é necessário ativar o recurso para "Baixar atualizações".

    Então, se estiverem com problemas de validação da NFe mesmo após as atualizações do Windows, procurem pois deve ter mais updates a serem feitos.

    Outro ponto,que gostaria de colocar aqui, caso estejam utilizando/validando CTe, as regras são as mesmas que da validação do NFe,  ok?

    Sem mais

     

    @Fábio Eduardo de Souza

    • Obrigado 1
  14. Boa tarde @wagner_fix 

    acbr.Configuracoes.WebServices.Tentativas = 2
    acbr.Configuracoes.WebServices.IntervaloTentativas = 60
    acbr.Configuracoes.WebServices.AguardarConsultaRet  = 60 
    acbr.Configuracoes.WebServices.AjustaAguardaConsultaRet = true 

    Estou utilizando esta configuração.

    Abraço.

    Fábio.

     

     

    • Curtir 1
  15. Bom dia a todos...

    Obrigado pelos retornos, por fim eu acabei, depois de ver um video do DANIEL aqui no forum sobre os protocolos de comunicação, resolvi alterar minhas configurações e o problema do travamento parou de ocorrer. Abaixo está o meu erro e a forma com que eu corrigi:

    ERRO : 

             acbr.Configuracoes.Geral.SSLLib                          := TSSLLib(libCapicom);
             acbr.Configuracoes.Geral.SSLCryptLib                 := TSSLCryptLib(cryCapicom);
             acbr.Configuracoes.Geral.SSLHttpLib                  := TSSLHttpLib(httpWinInet);
             acbr.Configuracoes.Geral.SSLXmlSignLib           := TSSLXmlSignLib(xsMsXmlCapicom);
             acbr.SSL.SSLType                                                     := TSSLType(LT_all);
     

    CORRETO:

             acbr.Configuracoes.Geral.SSLLib                          := TSSLLib(libWinCrypt);
             acbr.Configuracoes.Geral.SSLCryptLib                 := TSSLCryptLib(cryWinCrypt);
             acbr.Configuracoes.Geral.SSLHttpLib                  := TSSLHttpLib(httpWinHttp);
             acbr.Configuracoes.Geral.SSLXmlSignLib           := TSSLXmlSignLib(xsMsXml);
             acbr.SSL.SSLType                                                     := TSSLType(LT_TLSv1_2);
     

    Como o certificado era TOKEN A3, eu ainda estava utilizando as configurações de CAPICOM . Depois que adotei o metodo WINCrypt e o SSLTYPE como LT_TLSv1_2 as notas não travaram mais.

    Obrigado a todos pela ajuda e desculpem-me pelo erro.

    @Fábio Eduardo de Souza

     

    • Curtir 1
  16. Boa noite @Italo Jurisato Junio

    Devido a presepada do SEFAZ no tocante as versõa 1.60 da NFe 4.00 , só hj consegui realizar alguns testes referentes ao travamento ao emitir NFes na sequencia, fiz o teste da seguinte maneira, desabilitei todos os antivirus, Spyware e firewall da maquina que emite as notas e emiti a primeira nota fiscal sem nenhum problema, na hora que enviei a segunda nota fiscal o sistema travou.

    Estou trabalhando com certificado token (Alladin), desconectei o certificado da máquina , deu um erro do certificado de INATIVO/INOPERANTE  e destravou a máquina , da a impressão que algum processo da primeira nota fiscal não está sendo encerrado, e quando retiro o certificado o processo é interrompido. 

    Fizemos o teste em outra máquina no meu cliente, instalando o certificado e o problema também ocorreu. Até onde consegui identificar nos fontes do ACBR, o certificado é utilizado apenas com leitura para carregar as informações pertinentes a ele, ele não fica "EM PROCESSO" ou "CARREGADO" certo? Ou estou enganado??

    Poderiam me ajudar a entender se este travamento teria origem em algum processo no certificado que não consegui identificar?

     

    @Fábio Eduardo de Souza 

     

  17. Pessoal, 

     

    Passei pelos mesmos problemas de  "Falha no Schema XML" servidor 'SP', no meu caso o problema começou no começo da semana passada qdo baixei os schemas que sairam no dia 02/07/2018. 

    As notas validavam perfeitamento no homologação mas na produção dava o erro 225-"Falha no Schema XML". Não havia me atentado a mensagem do sefaz sobre a prorrogação do prazo de entrada versão 1.60 no ambiente de produção, e achei estranho alguns clientes funcionarem perfeitamente com a versão 4.0(produção) e estes que estavamos atualizando não validavam em produção. Hoje ao me deparar com a mensagem do sefaz , recuperei os schemas dos clientes que estavam validando a versão 4.0 em produção (anteriores ao que baixei na data de 02/07/2018)  , atualizei meus clientes que estavam com problema de Falha e pra minha surpresa TODAS AS NOTAS VALIDARAM EM PRODUÇÂO.

    Os esquemas que foram disponibilizados no dia 02/07/2018 já estão com as validações da 1.60 que ainda não está em produção. Acredito que essa putaria gerada pelo sefaz só ira acabar no dia 23/07/2018 com as atualizações dos ambientes.

    Ainda não testei o novo recurso criado pelo  @André Ferreira de Moraes , pois acabei de ver.  

    @Fábio Eduardo de Souza 

    Obs.: se alguém quiser realizar os testes com os esquemas que estou utilizando e que está validando em produção, segue em anexo, no campo vDesc estou preenchendo vom 0( vDesc = 0). 

     

    SchemasNFe.zip

    • Curtir 1
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...