Jump to content

fefevilela

Membros Pro
  • Posts

    115
  • Joined

  • Last visited

Posts posted by fefevilela

  1. Pessoal,

    Insteli o Delphi 11 e fiz a instalação normalmente da Suite ACBr. Nenhum erro foi apresentado na compilação/instalação dos componentes, porem ao executar o Delphi estou tendo o erro conforme anexo.
    Não entendi se ele está em conflito com a versão 10.4 ou se o problema é outro.

    Eu estou achando que isso tem a ver com a versão do FastReports que eu baixei através do GetIT. Essa versão é compativel com os formularios do ACBR ?

    Erro_Delphi_11.jpg

  2. Pessoal, fiz o procedimento citado pelo @Juliomar Marchetti porem o problema persiste.

    Ele instala o delphi 10.4 normalmente. Quando ele vai compilar o 11, ele está buscando o pacote no LIB27 do Fortes ao inves de buscar na pasta LIB28.

    Já verifiquei que no Fortes as instalações estão separadas em LIB27 e LIB28

    No ACBr ele gera a pasta LIB27 e instala. Tambem gera a pasta LIB28 e compila os pacotes normais do ACBr. Quando chega no pacote FORTES ele dá o erro conforme descrito abaixo onde pode ser claramente visivel que ele está apontando para o pacote errado.


    Acredito que seja algo no instalador do ACBr mesmo.

    Cleaning package cache for ACBrDFeReportRL.bpl
    Cleaning ok
    Compiling package D:\projetos\Componentes\ACBr\Pacotes\Delphi\ACBrDFe\ACBrDFeReportRL.dpk
    D:\Programas\Embarcadero\Studio\22.0\bin\dcc32.exe "D:\projetos\Componentes\ACBr\Pacotes\Delphi\ACBrDFe\ACBrDFeReportRL.dpk"
    Embarcadero Delphi for Win32 compiler version 35.0
    Copyright (c) 1983,2021 Embarcadero Technologies, Inc.
    D:\projetos\Componentes\ACBr\Fontes\ACBrDFe\ACBrDFeReportFortes.pas(48) Fatal: E2213 Bad packaged unit format: D:\projetos\Componentes\FortesReport\trunk\Binary\LibD27\frce.dcp.RLReport - Expected version: 35.0, Windows Unicode(x86) Found version: 34.0, Windows Unicode(x86)
    Compilation failure
    Erro ao compilar o pacote "ACBrDFeReportRL.dpk".
    Abortando... Ocorreram erros na compilação dos pacotes.

  3. Pessoal,

    Ao tentar instalar o ACBr no Delphi 11 Alexandria, o instalador aborta a instalação devido estar buscando o pacote do Fortes ERRADO.

    Segue o LOG da compilação


    Cleaning package cache for ACBrDFeReportRL.bpl
    Cleaning ok
    Compiling package D:\projetos\Componentes\ACBr\Pacotes\Delphi\ACBrDFe\ACBrDFeReportRL.dpk
    D:\Programas\Embarcadero\Studio\22.0\bin\dcc32.exe "D:\projetos\Componentes\ACBr\Pacotes\Delphi\ACBrDFe\ACBrDFeReportRL.dpk"
    Embarcadero Delphi for Win32 compiler version 35.0
    Copyright (c) 1983,2021 Embarcadero Technologies, Inc.
    D:\projetos\Componentes\ACBr\Fontes\ACBrDFe\ACBrDFeReportFortes.pas(48) Fatal: E2213 Bad packaged unit format: D:\projetos\Componentes\FortesReport\trunk\Binary\LibD27\frce.dcp.RLReport - Expected version: 35.0, Windows Unicode(x86) Found version: 34.0, Windows Unicode(x86)
    Compilation failure

  4. Pessoal..

    Acho que eu to ficando maluco....
    Refiz a atualização para a ultima 20793,

    gerei a NF e enviei e agora deu certo...

    segue anexo as evidencias

    O RPS vai com a aliquota dividida por 100 e 4 decimais, o xml da nfse volta com aliquota inteiro.
    O que nao entendo é como a ginfes estava reclamando que a aliquota estava indo com a formatação errada????

    observem a resposta que estava recebendo ontem na imagem erro ontem.jpg

    peço finalizarem o topico então.

    erro ONTEM.jpg

    9573UNICA-nfse.xml 9573UNICA-rps.xml

    • Like 1
  5. eu me pautei na revisao 20723 pois era a ultima que eu estava utilizando e tudo funcionava corretamente.
    Eu sei que nao foi nessa versão que foi feito alguma alteração, mas as evidencias são que  a aliquota nessa revisão gera numero inteiro e corresponde ao que a prefeitura espera.

    A partir da alteração feita, onde voce publicou a revisão feita pelo colega Willian, a coisa desandou... Estou mantendo a revisao 20723 como produção para que os processos dos clientes continuem funcionando.

    Em relação tcDec4 eu vi no codigo que ele faz isso porem quando o componente salva o xml de remessa ele ja salva com numero inteiro e depois o xml que retorna da ginfes tambem volta inteiro, inclusive o danfs mostra exatamente o numero corretamente (4,00%) então tem algo bem diferente entre ao codigo que existia na 20723 e nessa 20790.

    se voce quiser posso fazer um novo teste usando o mesmo exemplo anterior com as duas revisões e enviar os resultados novamente.

  6. 2 minutos atrás, Italo Jurisato Junior disse:

    Boa tarde Luís Fernando,

    Na sua postagem anterior cuja a alíquota é 4% a imagem do XML é do RPS ou da NFS-e?

    Se não me falha a memória o Ginfes requer que a alíquota no XML do RPS seja informada dividida por 100, mas ao gerar o XML da NFS-e ele gera sem a divisão.

    E na sua ultima postagem a alíquota informada é 1% o correto não seria 4% para a referida cidade?

    Oi Italo...
    Os testes foram diferentes.
    Na primeira mensagem era uma operação com 4% de ISS, e conforme demonstrado tanto no xml de envio quando no xml definitivo a aliquota está como "4"
     

    Nesse outro teste que fiz agora para valiar a nova revisão liberada, fiz o teste com outro pedido onde a aliquota é 1%, ao gerar o xml ele gerou conforme acima dividido por 100 e com 4 decimais. A prefeitura nao está aceitando numeros nesse formato conforme informei inicialmente.
     

    Voltei a versao 20723 e gerou corretamente.

    Não sei explicar o que está ocorrendo, porem só pude concluir até pela primeira mensagem de retorno que a aliquota tem que ser enviada no padrao 5(2), porem se observarmos a versao 20723 faz correto pois acredito que o campo é 5 caracteres "00004" que seria os 4% divididos por 100 porem em numero inteiro. acho que é essa a pegadinha da GINFES

  7. 30 minutos atrás, Victor H. Gonzales - Panda disse:

    Boa tarde, o commit: rev:r20790 contem a correção para essa questão!!
    Abraços!

    Pessoal, boa tarde.

    Desculpa intervir novamente porem a alteração não está satisfatória conforme exemplo em anexo.

    Não sei se é particularidade de Guarulhos, mas a ALIQUOTA Não pode ser dividida por 100

    ALIQUOTA ERRADA.jpg

    resposta do envio.jpg

  8. Pessoal, 
    temos problemas.
    primeiramente o GINFES de Guarulhos está reclamando que a a aliquota tem que ser enviada com 5 casas sendo 2 decimais.

    A alteração proposta pelo colega coloca 4 decimais

    Outro problema é que teoricamente a quantidade de digitos deveria ser atribuida em função do tipo3.xml onde a tcAliquota é definida certo?

    revisao 20723 está ok

     

    segue anexo imagens que demonstram como Guarulhos está recebendo as informações e estão adequadas.

    danfse_ginfes.jpg

    XML_NFSE_GINFES.jpg

  9. Olá pessoal.

    Abri esse tópico pois não achei nada a respeito.

    Supondo que uma NF-e já está cancelada na Sefaz por algum motivo (digamos que o usuario entrou pelo site e cancelou)....

    Quando tento enviar o cancelamento, a WS vai responder o cStat = 218 (NF-e já está cancelada na base de dados da SEFAZ [nRec:999999999999999] )

     Nesse caso, como eu posso pegar o XML do cancelamento para atualizar a minha base de dados?

     Agradeço qualquer informação.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.