Ir para conteúdo
  • Cadastre-se

Gabriel Bonzanini

Membros
  • Total de ítens

    125
  • Registro em

  • Última visita

  • Days Won

    1

Tudo que Gabriel Bonzanini postou

  1. Bom dia pessoal. Verifiquei que a cidade de Sombrio/SC não está presente no arquivo Cidades.ini. Se quiserem/puderem adicioná-la, já estamos usando em produção e está funcionando perfeitamente. [4217709] Nome=Sombrio UF=SC Provedor=Betha Abraço.
  2. Boa tarde pessoal. Estou tendo o mesmo problema, tanto no envio de NF-e quanto no envio de NFS-e (Betha). Às vezes a nota é aprovada (ou o servidor avisa que ainda está sendo processada), e às vezes recebo esta mensagem. Aparentemente é algo que envolve o sistema operacional e seus componentes, pois acontece em alguns computadores e em outros não. Alguém tem alguma ideia de que 'identificador' seria esse? A mensagem é muito genérica, sem nenhum dado que possa ser aproveitado para um possível ajuste, tendo como agravante que ocorre apenas às vezes, tornando praticamente impossível debugar. Abraço.
  3. Boa tarde Italo. Perfeito, muito obrigado pela atenção. E parabéns pelo ótimo trabalho que vêm sendo realizado por vocês, com muito capricho, organização e comprometimento. Grande abraço.
  4. Obrigado Agnaldo. Vou deixar registrada a solução aqui para que outros usuários possam utilizá-la. Resumidamente, devem ser preenchidas duas propriedades do ACBrDanfe antes da impressão do mesmo: NFeCancelada e ProtocoloNFe. Deixo também uma sugestão à equipe de desenvolvimento: a remoção da propriedade AtualizarXMLCancelado, já que aparentemente não surte nenhum efeito e pode causar confusão nos usuários. Abraço. Ah, um detalhe: pelo que entendi, como a propriedade é do componente de impressão e não de cada NF-e em particular, acredito que será um problema imprimir várias notas de uma só vez, estou certo? Abraço.
  5. Obrigado pelo retorno Sérgio. Imaginei que pudesse ser algo nesse sentido, mas a questão é: como mostrar a tarja de cancelamento na danfe, sendo que o cstat da nota fica como 100 e não como 101? Abraço.
  6. Bom dia amigos. Verifiquei que, ao cancelar uma nota fiscal eletrônica, o xml da mesma não está sendo atualizado e consequentemente o danfe não imprime a tarja de cancelamento. Reparei que na função NotaFiscal.GravarXML da unit ACBrNFeNotasFiscais há um teste que faz com que o xml modificado não seja salvo: if EstaVazio(FXMLOriginal) then GerarXML; Obs: estou com a propriedade Geral.AtualizarXMLCancelado = True Abraço, Gabriel.
  7. Boa tarde. Ao atualizar os fontes hoje pela manhã, passei a ter um problema na validação do xml. Descobri que o problema se encontra na linha 132 da unit pnfsNFSeW_ABRASFv1.pas: if ((VersaoNFSe = ve100) and not (FProvedor <> proISSNet)) or (FProvedor = proNFSeBrasil) then Utilizando o provedor Betha, nesta condição o componente gera a tag 'CpfCnpj' e a tag 'Cnpj' internamente, o que diverge do padrão 1.00 que deve ser diretamente a tag 'Cnpj'. Acredito que o problema esteja mais especificamente aqui: not (FProvedor <> proISSNet) // o mesmo que (FProvedor = proISSNet) Abraço, aguardo retorno.
  8. Show de bola. Muito obrigado pelas informações.
  9. 3Soft Sistemas, Não estava por dentro dessa questão... Poderia me explicar a diferença entre os dois repositórios, ou me apontar algum material/tópico para leitura sobre o tema? Abraço.
  10. Obrigado pelo retorno 3Soft Sistemas. Estou com a versão atualizada, mas a classe TprocEvento_DetEvento ainda não possui a propriedade 'xCorrecao', apenas 'xJust'. Abraço.
  11. Boa tarde. Verifiquei que no método ACBrNFe.DistribuicaoDFe e para o tipo de evento de retorno teCCe (Carta de Correção eletrônica), a tag WebServices.DistribuicaoDFe.RetDistDFeInt.docZip.procEvento.DetEvento.xJust estará sempre vazia, visto que pra este tipo de evento a justificativa da correção fica em uma tag chamada xCorrecao. Adicionando a seguinte condição, pude obter o conteúdo desejado. if(FdocZip.Items[i].FprocEvento.FtpEvento = teCCe) Then FdocZip.Items[i].FprocEvento.detEvento.FxJust := oLeitorInfZip.rCampo(tcStr, 'xCorrecao') else FdocZip.Items[i].FprocEvento.detEvento.FxJust := oLeitorInfZip.rCampo(tcStr, 'xJust'); Em anexo, a unit com a alteração e um arquivo xml deste tipo de evento, onde a correção é 'Quantidade de volumes corretos 7'. Não sei se irão preferir criar a property xCorrecao na classe, mas acredito que não seja necessário, já que a xJust nunca seria utilizada neste caso. Abraço, aguardo retorno, Gabriel. pcnRetDistDFeInt.pas 1101104315099046200300013055001000117594164569486401-procEventoNFe.xml
  12. Bom dia. Estamos homologando a emissão de boletos e remessa bancária do Banrisul no padrão CNAB 240 para um de nossos clientes. A crítica retornada pelo banco foi a seguinte: - posição 109, segmento P, informar 'A' ou 'N'; Verifiquei que o componente está enviando o conteúdo 'S' quando há o aceite, no procedimento TACBrBanrisul.GerarRegistroTransacao240, através do seguinte código: case Aceite of atSim: aAceite := 'S'; atNao: aAceite := 'N'; end; Em anexo a unit atualizada, com a troca de 'S' por 'A'. Obrigado, aguardo retorno. Gabriel. ACBrBancoBanrisul.pas
  13. Juliomar, obrigado pelo retorno. Fiz o teste, mas a mensagem continua retornando apenas o primeiro caracter. Parece ser problema no tipo de dado da variável mesmo, e já vi o mesmo ocorrer em outro tópico (apesar de não ser a questão central): 'Requisição não enviada. 12157 - E' - Este 'E' é a letra inicial da mensagem correta. É o mesmo que ocorreu comigo, e a solução foi alterar o tipo de dado da variável Buffer. Apenas gostaria de ver se isso confere, e se pode ser alterado no projeto principal para que não tenha que lembrar de alterar toda vez que sincronizá-lo. Abraço, Gabriel.
  14. Algum moderador poderia verificar isto? É uma correção pontual, acredito que vá ajudar.
  15. Para quem quiser ver a mensagem de erro corretamente, e não apenas a primeira letra:
  16. Bom dia. Verifiquei uma falha na função TACBrHTTPReqResp.GetWinInetError, da unit ACBrHTTPReqResp. Estou utilizando Delphi 2010 e Windows 7. A mensagem de erro retornada apresenta apenas o primeiro caracter, devido ao tipo PAnsiChar da variável Buffer. Alterando para PChar funciona corretamente. Poderiam verificar se isto terá algum impacto em outros ambientes, e se poderia ser alterado para as próximas versões? Muito obrigado, Gabriel. ACBrHTTPReqResp.pas
  17. Boa tarde. Estou fazendo a homologação do arquivo de remessa do banco Sicredi, com 240 posições, e verifiquei algumas correções necessárias: Nas linhas 1460 e 1506, o sistema utiliza o multiplicador '3' ao invés de '2', como se houvesse um terceiro registro além de P e Q, ocasionando falha na geração do código sequencial. Na linha 1331, o componente está enviando o dígito verificador da agência, quando deveria enviar sempre um espaço em branco. Fiz o teste preenchendo a propriedade 'AgenciaDigito' com esse espaço em branco (tentando assim evitar a alteração no componente), mas nesse caso o código de barras não pôde ser gerado corretamente na impressão do boleto. Em anexo, a unit com as correções e o arquivo com as críticas mencionadas, dentre outras que devem ser ignoradas pois foram corrigidas em nosso próprio software. Aguardo um parecer de um dos administradores. Abraço, Gabriel. ACBrBancoSicredi.pas protocol_14000673221.pdf
  18. Muito obrigado Juliomar. Parabéns pra toda a equipe de vocês, os componentes são fantásticos, facilitam o trabalho de muita gente. Como faço pra marcar o tópico como resolvido? (Se houver necessidade, claro) Abraço!
  19. As linhas adicionadas são 287 (PDF) e 295 (HTML). Obrigado pela atenção. ACBrBoletoFCFR.pas ACBrBoletoFCFR.pas
  20. Alguém saberia dizer qual seria o passo correto a seguir para ter esta alteração implementada? Obrigado.
  21. Primeiramente, obrigado pela atenção Juliomar. Adicionando a linha mencionada, o componente se comporta conforme a necessidade. É a primeira vez que preciso alterar algum componente do ACBr, visto a qualidade do projeto, então não sei exatamente como proceder. Fico na dúvida se a solução é aceitável, pois é um reaproveitamento de uma property utilizada também para controlar a visibilidade do diálogo de impressão. De qualquer forma, não me importaria de implementar uma property específica para este fim, assim evitaria de ter que alterar o código fonte do componente toda vez que for atualizar o projeto. Abraço, Gabriel.
  22. Boa tarde pessoal. Estou implementando uma rotina para envio de faturas comerciais em massa, por e-mail. Para tal, utilizo os componentes TACBrBoleto e TACBrBoletoFCFR. Ao executar o procedimento TACBrBoleto.EnviarEmail, o componente mostra a tela de setup da exportação do PDF, o que não é de meu interesse. Reparei que existe a propriedade 'MostrarSetup', mas a finalidade dela parece estar restrita apenas ao diálogo de impressão, e não ao de exportação. Debugando o programa, cheguei ao procedimento TACBrBoletoFCFR.Imprimir, no qual o TDataModule responsável pela impressão é criado em tempo de execução (DmBoleto). Isto impede qualquer alteração dos dados nele contidos fora do contexto do procedimento (no código do aplicativo): procedure TACBrBoletoFCFR.Imprimir; var DmBoleto: TdmACBrBoletoFCFR; begin inherited Imprimir; // Verifica se a lista de boletos está vazia DmBoleto := TdmACBrBoletoFCFR.Create(Self); ... Logo após, a propriedade 'MostrarSetup' é aplicada nas opções de impressão do report: frxReport.PrintOptions.ShowDialog := MostrarSetup; E, finalmente, o momento da exportação do arquivo: frxPDFExport.FileName := NomeArquivo; {Esta é a linha que está resolvendo o impasse, por enquanto} DmBoleto.frxPDFExport.ShowDialog := MostrarSetup; frxReport.Export(DmBoleto.frxPDFExport); Gostaria de saber dos colegas se há alguma outra forma de contornar isto. Caso não haja, como proceder para aplicar esta solução no projeto? É interessante criar outra propriedade específica para este fim? Desde já agradeço a atenção, Gabriel.
×
×
  • 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...