Painel de líderes

Bom dia, eu tenho clientes com gmail, yahoo e terra, hotmail nunca consegui fazer funcionar. yahoo: SMTP: smtp.mail.yahoo.com - Porta: 465 - SSL(x) - TLS(x) terra: SMTP: smtp.terra.coom.br - Porta: 587 - SSL( ) - TLS( ) gmail: SMTP: smtp.gmail.com - Porta: 465 - SSL(x) - TLS(x) Para quem não está conseguindo enviar email pelo GMAIL basta acessar o link abaixo e entrar na sua conta do Google: https://www.google.com/settings/security/lesssecureapps E marcar a opção: Ativar. De um tempo até você receber um email do Google dizendo que a segurança foi desabilitada. Sds, Ricardo.

Bom dia, No campo Data da Multa (segmento R), a fim de evitar a data 30/12/1899 no arquivo de remessa, fiz um pequeno ajuste para aparecer '00000000' no lugar. Utilizei a mesma variável utilizada na Data de Mora Juros (segmento P), pois pelo que venho acompanhando Data da Multa e Data de Mora Juros são consideradas a mesma. Correto? ACBrBancoSantander.pas

Sefaz MT normalizada

Conforme solicitação do Sr. Henrique Leonardo @hleorj, estou criando um novo post referente a melhoria e alterações no método "FormarCEP" sobre post 1 e post 2, onde solicitei para alterar o método para preencher com zeros a direito ao invés de zeros a esquerda. Em meus clientes ocorre o seguinte: como a maioria das pequenas cidades possui apenas 1 CEP e nos casos em que os 3 últimos dígitos é "000", eles estavam acostumados a digitar por exemplo "89140" e o método FormatarCEP formatava para "89140-000". Quando migrei os fontes para o trunk2, este método passou a formatar os zeros a esquerda, ficando "00089-140". Em Dezembro de 2015 solicitei a alteração e o @Daniel Simoes alterou para formatar os zeros a direita, conforme post 1. Porém, essa semana atualizei os fontes e novamente foi alterado para formatar zeros a esquerda, por causa da impressão do DANF-e da NF-e que trata o campo CEP como integer e ocorria problemas com CEPs iniciados com zero, conforme post 2. Sugestão 1) Para tentar contribuir sem comprometer outras funcionalidades, sugeri a principio uma alteração na unit "ACBrValidador.pas", onde existem 2 métodos "FormtarCEP": o primeiro recebe um parâmetro string e o segundo um parâmetro integer. No método que recebe o parâmetro string, sugeri para formatar zeros a direita e no outro método que recebe o parâmetro como integer, formatar zeros a esquerda. Dessa forma não acontece o erro do post 2, porém, ao implementar um teste ( TDD ) que atenda a minha necessidade, a execução falhou no teste "FormatarMenosDeOitoDigitos". Os métodos "FormtarCEP" da unit "ACBrValidador.pas" ficariam da seguinte forma: function FormatarCEP(const AValue: String): String; Var S : String ; begin S := PadRight( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a direita } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; function FormatarCEP(const AValue: Integer): String; Var S : String ; begin S := PadLeft( OnlyNumber(IntToStr(AValue)), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; Sugestão 2) Uma outra sugestão, seria criar um parâmetro no método "FormatarCEP" da unit "ACBrValidador.pas" para forçar o preenchimento dos zeros a direita, mas que por padrão, caso o parâmetro não seja informado, o valor seja False. A alteração ficaria da seguinte forma: function FormatarCEP(const AValue: String; PreencheZerosADireita: boolean = False): String; Var S : String ; begin if PreencheZerosADireita then S := PadRight( OnlyNumber(AValue), 8, '0') { Prenche zeros a direita } else S := PadLeft( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; e o teste na unit "ACBrValidadorTest.pas" ficaria assim: procedure TTestCaseACBrValidadorCEP.FormatarString; var ACep: String; begin ACep := '89140'; CheckEquals('89140-000', ACBrValidador.FormatarCEP(ACep, True)); end; Dessa forma, atenderia todos os testes (incluindo o teste que implementei). Segue em anexo os arquivos referente a segunda sugestão de alteração. ACBrValidador.pas acbrvalidadortest.pas

Não me agrada modificar a assinatura dos métodos existentes... a não ser que seja realmente necessário... Nesse caso, preferi um código que seja capaz de detectar como o CEP deve ser alinhado, de acordo com o seu tamanho... function FormatarCEP(const AValue: String): String; Var S : String ; begin S := OnlyNumber(AValue); if Length(S) < 5 then S := PadLeft( S, 5, '0'); // "9876" -> "09876" if Length(S) = 5 then S := PadRight( S, 8, '0') // "09876" -> "09876-000"; "18270" -> "18270-000" else S := PadLeft( S, 8, '0') ; // "9876000" -> "09876-000" Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; (Já está no SVN)

Todas acima da versão delphi 2009!

para Hotmail utilize smtp-mail.outlook.com Porta 587 TLS= marcado

Maiko, Se você gera um código aleatório para o documento a ser emitido, código este que vai compor a chave esta correto. Mas procure salvar esse código aleatório juntamente com os demais dados do documento no banco de dados. Por exemplo temos o nMDF que é o numero do MDF-e e o cMDF que é o código aleatório do MDF-e, ambos vão fazer parte da chave do MDF-e. Pois bem na tabela que entre outras coisas temos o numero do MDF-e crie mais um campo para armazenar o código aleatório. Isso deve ser feito antes de alimentar o componente com os dados, desta forma quando você for alimentar o componente para emitir o MDF-e, você vai atribuir a nMDF e a cMDF informações lidas do banco de dados. Caso seja necessário gerar novamente o XML de um MDF-e a chave deste novo será igual ao do antigo. Quando devemos gerar novamente o XML? Por exemplo quando o digníssimo usuário fez o favor de deletar o mesmo.

Bom dia, estou retornando de férias, eu havia feito uma alteração no fonte "ACBrNFSeWebServices.pas" na rotina "procedure TNFSeGerarNFSe.DefinirDadosMsg;" que havia resolvido o problema, atualizei os fontes do ACBr2 agora mas não estou conseguindo testar, pois parece que o servidor de homologação está fora do ar. Alteração: (em vermelho) procedure TNFSeGerarNFSe.DefinirDadosMsg; ... if (FPDadosMsg <> '') and (FDadosEnvelope <> '') then begin DefinirSignatureNode(''); //Duarte case FProvedor of proPublica: TagGrupo := 'Rps></GerarNfseEnvio' end; //Duarte // case FProvedor of // proSP: AssinarXML(FPDadosMsg, FPrefixo3 + TagGrupo, '', // 'Falha ao Assinar - Gerar NFS-e: '); // else FPDadosMsg := TNFSeGerarNFSe(Self).FNotasFiscais.AssinarLote(FPDadosMsg, FPrefixo3 + TagGrupo, FPrefixo3 + TagElemento, FPConfiguracoesNFSe.Geral.ConfigAssinar.LoteGerar, xSignatureNode, xDSIGNSLote, xIdSignature); // end; ... end;

Juliana Tamizou, enviei uma mensagem em pvt pra você, com boletos e remessa que gerei em meu aplicativo homologado. Por favor, poderia analisar?

Desinstale o Fortes que você usa atualmente, exclua do library path as linhas relacionadas a qualquer versão do Fortes e leia este tópico:

Vamos lá, Isso é uma coisa nova, você precisa entrar em contato com o pessoal da Software Express, eles vão lhe enviar um módulo a ser instalado no SITEF e 2 manuais, um como configurar o SITEF e outro que tem o descritivo destes campos. Só funciona com tudo isso configurado corretamente. NFCeSAT.CNPJCredenciadora = CNPJ da credenciadora do cartão (campo para NFC-e) NFCeSAT.Bandeira = Descrição da Bandeira do Cartão NFCeSAT.Autorizacao = Número de autorização da transação NFCeSAT.CodCredenciadora = Código da credenciadora do cartão (campo para o SAT)

Boa tarde Vinícius, Você pode fazer assim no método de transmissão: function TransmitirNFCe; var bNotaJaTransmitida : Boolean; ... begin ... if (ACBrNFe1.Enviar(iLoteId, False, False)) then if not ConsultaChaveNFCe(sChaveNFCEe) then end; Boa tarde Vinícius, Eu faço dessa forma tento 3 vezes para garantir a transmissão. Caso contrário não consegua transmitir emito em OFFLINE e depois será transmitida por outro método. Quando o problema de Internet ou servidor da sefaz voltar em fim. Espero ter te ajudado! E dá uma curtida ai! Valeu! procedure TransmitirNFCe (sChaveNFCEe : string); var bNotaJaTransmitida : Boolean; iTentativas : Integer; ... begin ... repeat bNotaJaTransmitida := false; ACBrNFe1.Enviar(iLoteId, False, False); bNotaJaTransmitida := ConsultaChaveNFCe(sChaveNFCEe); if bNotaJaTransmitida then Exit; until (iTentativas > 3); if (not bNotaJaTransmitida) then begin // Código para gerar nota em OFFLINE para depois transmitir. .... end; ... end;

Bom dia, 1) Eu estava com o mesmo problema, avalieis os novos fontes do Trunk2 e fiz as correções necessárias para que a assinatura seja realizada conforme determinado pelo provedor Pública. O que acontecia é que para assinar o XML a tag GerarNfseEnvio precisa estar no conteúdo assinado, sendo que estava assinando apenas o conteúdo da tag Rps. 2) Também alterei o provedor da cidade de Caçador/SC que agora utiliza Pública e não é mais Betha Alterações: - ACBrDFeSSL.pas: Precisei colocar o método "AdicionarSignatureElement" como público, para poder incluir a tag de assinatura no local correto, e fazer a assinatura na geração da NFS-e (TACBrNFSe.Gerar) - ACBrNFSeWebServices.pas: Faço a chamada do método indicado acima, para incluir a tag de assinatura - pnfsConversao.pas: Precisei incluir a natureza de operação 9, que é utilizada na cidade de Caçador/SC -Cidade.ini: Mudança no provedor de Caçador/SC; Inclusão dos parâmetros: NomeURL_H e NomeURL_P, para o provedor Pública, pois é necessário já que esse provedore atende as cidades de Itajaí/SC e Caçador/SC - Publica.ini: Precisei alterar as propriedades RpsGerar=0 LoteGerar=1, para que a assinatura fosse realizada corretamente. Adicionei a URL para cidade de Caçador/SC Fiz os testes com os métodos: TACBrNFSe.Gerar e TACBrNFSe.Enviar, funcionaram corretamente após as alterações Seguem arquivos em anexo com as alterações necessárias para integração com o provedor Publica Publica.rar

CEST é uma coisa NCM é outra, são finalidades totalmente diferentes, com certeza vai sim continuar existindo.

o CEST é uma Tag do produto, correto ? Então... [Produto001] .... CEST=1234567

Dimom fiz uma atualização no software base do equipamento e o erro parou

Este "1", é porque no meu caso, eu imprimi um cancelamento. Por isso que ficou (110111) Quando for uma carta de correção, ficará (110110).

Maravilha !!! Funcionou corretamente. Só uma correção caso outras pessoas leia este post. DANFERaveCB.PathPDF + '110110' + Chave + nSeqEvento + 'evento.pdf' tinha um "1" no lugar do "0" - Mas fácil de resolver.

Eu estava tendo o mesmo problema de foco. Tive que criar uma procedure à parte para resolver o problema, chamando essa procedure no evento OnRestauraFoco do componente ACBrTEFD. Segue o código da procedure: procedure RestauraFoco; var Form: TForm; Habilitado: Boolean; begin try Form := nil; //Verifica se já existe um form ativo na tela. if Assigned(Screen.ActiveForm) then Form := Screen.ActiveForm //Do contrário, pega o último form criado else if Assigned(Screen.Forms[Screen.FormCOunt - 1]) then Form := Screen.Forms[Screen.FormCOunt - 1]; if Assigned(Form) then begin //Verifica o estado da propriedade 'Enabled' do form Habilitado := Form.Enabled; //Habilita o form para permitir que o foco seja setado para o mesmo Form.Enabled := TRUE; //Envia o Form em questão para a frente da tela SetForeGroundWindow(Form.Handle); //Seta o foco da aplicação para o form if Form.CanFocus then Form.SetFocus; Form.Refresh; //Retorna a propriedade 'Enabled' para o estado anterior Form.Enabled := Habilitado; end; except end; end; Obs.: Eu uso a procedure no início do evento OnExibeMsg também, pra garantir que a aplicação terá foco no momento em que a mensagem for exibida.