Delphi in Delphi

Já editei e removi a palavra Trial, que dificultou o entendimento da informação que quiz passar.

O XE6 não veio com o Fast Embarcadero Edition, depois da compra ele pode ser baixado separadamente sem custo. Uma pena isso, pois dificulta alguns testes de atualização dos programadores. Para quem comprou pode realizar o download aqui: http://cc.embarcadero.com/item/29816

O arquivo "ACBrInstall.exe" deve estar na revisão 6107 ou inferior, realize uma atualização dele para a revisão 6694 ( ou mais rescente). Isso ocorre porque a instalação do XE6 não estava incluído na lista de versões do Delphi. Procure sempre manter a Acbr atualizada.

Realmente, o problema relatado não acontece utilizando o instalador da ACBR, ontem não utilizei porque ainda não estava corrigido, mas tudo parece normal agora. Obrigado.

Prezados, alguém já tentou realizar a instalação da acbr no XE6 Trial? Aqui alguns componentes funcionam normalmente, porem a Acbr é a única que da erro de Resource, o pacote compila normalmente, porém ao instalar recebo a mensagem "Resource ACBR not found.". ---- Atualizando 18:59 ----- O problema aconteceu porque o bitmap não está contido no arquivo AcbrComum.res, realizei o teste, e sempre quando dou um build no XE6 o arquivo de resource do pacote está vindo sem o arquivo da tela de sobre do componente. (AcbrReg.pas) {$IFDEF DELPHI9_UP} initialization //Estou comentando aqui para instalar o pacote ACBrComum ===> AddSplash; {$ENDIF} Aqui também resolveu dar um Build, reverter o arquivo .Res do pacote e tentar instalar em seguida. (Assim a imagem permanece).

Obrigado Juliomar, como não tinha mais Delphi aqui em minha máquina, foi testado no Trial do Xe5, obrigado. pcnNFeW.pas

Prezados, a pedido de um amigo que utiliza a ferramenta fui verificar um determinado problema, então desculpe-me se estiver enganado quanto a informação que vou postar sobre a Acbr. Ao realizar um teste de envio da NF-e 3.10 em Homologação, tive problemas quanto ao campo "dhSaiEnt" (Data e Hora de Saída da Mercadoria/Produto). Quando este campo fica em branco, está sendo apresentado um erro de data inválida retornado pela Sefaz. Segundo o manual da versão 3.10 da NF-e (NT2013.005) este campo não é obrigatório, agora analisando o código nós vemos: Gerador.wCampo(tcDat, 'B10', 'dSaiEnt', 10, 10, 0, nfe.ide.dSaiEnt, DSC_DSAIENT); A função wCampo com o tipo "tcDat" já faz a verificação se a data é "null" e então manda em branco para o XML. Porém com a alteração deste campo para o formato "AAAA-MM-DDThh:mm:ssTZD" (se versão maior ou igual a 3) a linha passou a ser: Gerador.wCampo(tcStr, 'B10', 'dhSaiEnt', 25, 25, 0, DateTimeTodh(nfe.ide.dSaiEnt) + GetUTC(CodigoParaUF(nfe.ide.cUF), nfe.ide.dSaiEnt), DSC_DSAIENT); Repare que o tipo é "tcStr", e este não mais faz o decode da data para verificar se trata-se de uma data "null". Então temos ai o problema se a data não for preenchida, mesmo assim ela será informada no XML (30/12/1899), mas ocorre porque este formato de data não funciona com o tipo "tcDat". Como eu não sei o formato de alteração dos arquivos e regras da Acbr, não realizei uma correção efetiva para isso, apenas validei a data antes da chamada do "wCampo" de 'dhSaiEnt'. if (not DateTimeIsNull(NFe.Ide.dSaiEnt) then É fato que este campo em algumas UF se faz obrigatório, porém em outras não.

Obrigado. Segue em anexo o arquivo com a correção proposta. ACBrSintegra.pas

Prezados, fui contratado para realizar uma análise de alguns problemas de software em uma determinada empresa, e durante algumas verificações, ví que é possível que exista uma pequena falha na classe TRegistro55 (eles usam a ACBR): property UF: string read FUF write FUF; property UFFavorecida: string read FUF write FUF; No caso a segunda linha deveria estar da seguinte forma: property UFFavorecida: string read FUFFavorecida write FUFFavorecida; Porém ainda tenho dúvidas quanto a esta informação, por exemplo se houver alguma regra que estes campos tem que ser equivalentes e eu não teria essa informação, porém testanto no validador ele deixou normalmente as UF diferentes.

Prezado, verificando mais afundo o que foi argumentado por mim em tópicos anteriores, diante a apresentação do exemplo da ACBRNfe e ainda o código de envio utilizado pela dpec no procedimento executar, fica evidente o "Envio" das informações, é claro, o arquivo DPEC é gerado antes, mas ele não deixa de executar a transmissão, e como apresentado a situação problema no post anterior fica claro que existe a situação em que o envio não se faz necessário. Quanto ao procedimento LoadFromFile, eu devo estar enganado, porém só pude ver a existência do mesmo para o XML da nota fiscal eletrônica, em nenhum momento consegui visualizar um LoadFromFile para carregar o retorno da DPEC do site da sefaz, as classes que eu procurei foram: TWebServicesBase TNFeEnvDPEC TRetDPEC Sendo que a TRetDPEC traz a possibilidade da leitura do arquivo da seguinte forma, então pergunto será essa a forma mencionada ? var RetDPEC: TRetDPEC; begin RetDPEC := TRetDPEC.Create; try RetDPEC.Leitor.Arquivo := XMLRet; RetDPEC.LerXml; TACBrNFe( FACBrNFe ).SetStatus( stIdle ); // verAplic := RetDPEC.verAplic; // cStat := RetDPEC.cStat; // xMotivo := RetDPEC.xMotivo; // ID := RetDPEC.ID; // TpAmb := RetDPEC.TpAmb; // DhRegDPEC := RetDPEC.DhRegDPEC; // nRegDPEC := RetDPEC.nRegDPEC; // NFeChave := RetDPEC.chNFe; // FMsg := RetDPEC.xMotivo; finally RetDPEC.Free; end; Desde já agradeço a compreensão e paciência depositada, nas minhas dúvidas.

Realmente devo admitir minha confusão, não consegui visualizar a utilização da seguinte situação, e gostaria que se possível me passasse mais detalhes de como utilizar ela no ACBrNFe. Internet do usuário deixa de funcionar. Usuário gera dpec e armazena em um pendrive junto ao seu certificado. Usuário se dirige a um local com internet Usuário carrega o xml da dpec no site da sefaz. Usuário realiza o download do xml autorizado do site da sefaz. Usuário se dirige a sua empresa. Usuário carrega o xml no sistema. Sistema verifica validade do arquivo carregado além de seu status. Sistema imprimir o danfe em modo contigência tipo de emissão 4 junto ao número da autorização.

Verificando com mais cuidado, também reparei que não existe a possibilidade de carregar o XML autorizado pelo site da SEFEZ diretamente para o componente e então analisar o retorno, sendo necessário abrir o xml e ler as tags, sendo que pela acbr é muito mais simples fazer isso se houvesse uma função LoadDPECRetFromFile ou coisa do tipo. No exemplo da ACBR somente é viável realizar a consulta via o webservice. Logo o exemplo não atende a situação de contingência por falha na internet.

Opa Régys, tudo bem ? então olhei sim o código, também verifiquei que ele tenta realizar o envio correto ? var vAux : String; begin if not(InputQuery('WebServices DPEC', 'Numero da Nota', vAux)) then exit; ACBrNFe1.NotasFiscais.Clear; GerarNFe(vAux); ACBrNFe1.NotasFiscais.SaveToFile(); if ACBrNFe1.WebServices.EnviarDPEC.Executar then begin //protocolo de envio ao DPEC e impressão do DANFE ACBrNFe1.DANFE.ProtocoloNFe:=ACBrNFe1.WebServices.EnviarDPEC.nRegDPEC+' '+ DateTimeToStr(ACBrNFe1.WebServices.EnviarDPEC.DhRegDPEC); ACBrNFe1.NotasFiscais.Imprimir; ShowMessage(DateTimeToStr(ACBrNFe1.WebServices.EnviarDPEC.DhRegDPEC)); ShowMessage(ACBrNFe1.WebServices.EnviarDPEC.nRegDPEC); end; MemoResp.Lines.Text := UTF8Encode(ACBrNFe1.WebServices.EnviarDPEC.RetWS); memoRespWS.Lines.Text := UTF8Encode(ACBrNFe1.WebServices.EnviarDPEC.RetornoWS); LoadXML(MemoResp, WBResposta); ACBrNFe1.NotasFiscais.Clear; end; Porém existe uma rotina no software do meu cliente que realiza uma analise da melhor contingência a ser utilizada dentre avaliação da internet e demais itens, então é interessante que não ocorra o envio sendo que o software já sabe que não é possível realizar esta tarefa.

Prezado, sei que a informação abaixo não responde sua pergunta em si, mas pode ser útil para resolver seu problema: Realize o envio do evento de cancelamento normalmente Obtem o XML de retorno: var XML:string; begin XML := ACBRNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML; end; Com o xml em mãos, você armazena da forma que achar melhor, seja em arquivo,banco de dados e etc.. Para obter o status você pode usar "ACBRNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat" Vale lembrar que na nota técnica do cancelamento é pedido para armazenar o xml autorizando o cancelamento, o mesmo não pude confirmar para a carta de correção esta necessidade.

Prezados, me corrijam se eu estiver errado, mas a DPEC é o único método que não onera ao enviar a nota por contingência por falha na internet no cliente. E a única forma de fazer isso é obtendo o XML de envio assinado e então carregar no site da sefaz pelo smartphone ou qualquer outro método que torne possível seu upload pelo site da sefaz. Sendo a informação acima coerente se concluí que é importante que a classe da ACBR responsável por gerar e enviar a DPEC tenha uma rotina para obter o XML da DPEC assinado, gostaria de saber se existe alguma forma "oficial" de fazer isso, visto que não encontrei método parecido dentro da classe "TNFeEnvDPEC" ? No momento como alternativa estou herdando a classe citada acima, e visto que o procedimento que gera o xml e assina tanto como o objeto repositor estão na cláusula PROTECTED foi possível fazer isso. Segue exemplo para quem tiver alguma dúvida do procedimento informado: uses ACBrNFeWebServices, pcnEnvDPEC; type TXMLNFeEnvDPEC = class( TNFeEnvDPEC ) public function ObtemXmlDPECEnv: string; end; implementation { TFixNFeEnvDPEC } function TXMLNFeEnvDPEC.ObtemXmlDPECEnv: string; begin LoadMsgEntrada; Result := FDadosMsg; end;   Exemplo de uso: var XML:string; begin XML := TXMLNFeEnvDPEC( ACBRNFe1.WebServices.EnviarDPEC ).ObtemXmlDPECEnv; end; É obvio que para utilizar o exemplo acima é necessário que os dados da nota fiscal estejam carregados no componente ACBRNfe, via suas funções ou LoadFromFile para o XML.

NOVAS ALTERAÇÕES Desde o último post neste tópico estive trabalhando na conversão da versão do DANFE Fast em VCL para a nova versão do Fast para firemonkey, é claro que a conversão não implica somente no arquivo do relatório, mas também de um pacote novo para o firemonkey além de outros detalhes importantes. Características do FastReport para o Firemonkey É multiplataforma Não tem gerador de PDF. Não conta com componente para código de barras. Baseado na informação acima, foi necessário utilizar uma solução para o código de barras, que é mais complexo que o EAN13, então levou mais tempo, a solução encontrada foi um componente de um site francês (http://sourceforge.net/projects/openbarcodes/) onde utiliza-se uma fonte ".ttf" na pasta font do windows, e então uma biblioteca para gerar a codificação para a fonte entender qual informação irá ser exibida, ou seja não basta informar o valor numérico. O problema é que a biblioteca estava escrita em visual basic, no site (http://grandzebu.net/informatique/codbar-en/code128.htm) existe duas bibliotecas para Pascal, mas todas elas estavam gerando o retorno incorreto, então reescrevi a biblioteca baseado no código original em VB. No processo final para instalação do pacote, basta instalar a fonte Code128.ttf que depois instalar o pacote do danfe FRFMX, a qualidade do código de barra ficou muito boa. Quando ao gerador de PDF ainda não procurei uma solução, e acredito que opensource para firemonkey ainda não tenha. Gostaria que alguém do fórum verifica-se as modificações para subir logo para o subversion, porque se não as revisões vão ficando muito afastadas da versão que eu estava alterando. Revisão destes arquivos alterados: 4645 Revisão Atual da ACBR: 4668 O Arquivo abaixo conta com: Todas os arquivos do primeiro Post que originou este tópico. As bibliotecas criadas. Os arquivos EVENTOSFMX.fr3 e DANFEFMX.fr3 para a versão do Fast para Firemonkey O demo atualizado com o Danfe funcionando postado também neste tópico anteriormente A fonte utilizada na criação do código de barras. ACBRFMX.zip (e88ad1b649d759c2c6d1a3bbf9ebe723) A versão do Fast para Firemonkey utilizada foi a de demonstração disponibilizada pelo site deles, você pode fazer o Download aqui O Resultado final do Danfe ainda precisa de pequenos acertos de alinhamento , mas está funcional.

A fim de facilitar nos testes que estou fazendo, e também para quem for analisar estou postando o exemplo da ACBrNFe convertido "parcialmente" para o Firemonkey, alguns recursos podem não existir ou terem que ser adaptados: TWebBrowser não existe. TTreeView foi adaptado Dialogs TRadioGroup não existe foi trocado por TListBox Danfe não existe, mas agora o FastReport existe para o FMX e com suporte ao OSX então é possível de ser implementado. segue o exemplo: ACBrNFE Firemonkey DEMO.zip

Esta solução funcionou aqui tbm. Acredito que essa alteração fica salva no Token.

Sim, teoricamente quando se adiciona na uses a unit "Forms" por exemplo, o Delphi deveria entender se é para usar a do Firemonkey ou VCL, se não me engano na primeira versão do Delphi XE2 isso acontecia, agora no XE3 por exemplo isso não acontece, você precisa identificar com "VCL." ou "FMX.". Mas alguns recursos mudam ,como a chamadas de diálogos. {$IFDEF FMX} MessageDlg(Msg, TMsgDlgType.mtInformation, [TMsgDlgBtn.mbOK],0); {$ELSE} MessageDlg(Msg ,mtInformation ,[mbOk],0); {$ENDIF} Ou Por Exemplo function GetAppExeName:string; begin {$IFDEF FMX} Result := ParamStr(0); {$ELSE} Result := Application.ExeName; {$ENDIF} end;

Prezados, sou novo no fórum, e estou prestando um serviço pra uma determinada empresa, onde ela está realizando um mini projeto de emissão de NFE no firemonkey, ela anteriormente veio utilizando a VCL + ACBRNFe. A questão é que no Delphi XE3 ao inserir um componente da ACBR no firemonkey ele nem mesmo compila, então resolvi fazer uma adaptação para que o ACBR funciona-se no FMX. Avaliando o projeto ele não tem nenhum impedimento para funcionar no firemonkey, visto que nada ou quase nada utiliza interface. O único problema que eu pude visualiza foi em relação a biblioteca ACBRCAPICOM_TLB.PAS onde é utilizado o OleServer.pas que somente existe na VCL. Mas analisando esta biblioteca pode-se verificar que ela somente faz uso das API do Windows, que também podem ser acessadas do firemonkey, escrevi um arquivo chamado FMX.OleServer.Pas e FMX.OleConsts.Pas para fazer a substituição trocando o bloco de código uses Vcl.OleConst, Vcl.Controls; Por uses FMX.OleConst, FMX.Controls, FMX.Types; E no final do arquivo initialization GroupDescendentsWith(TOleServer, Vcl.Controls.TControl); Por initialization GroupDescendentsWith(TOleServer, FMX.Types.TControl); O segundo problema é que tanto no Delphi XE2 e no Delphi XE3 não existe conditional compilation para determinar se o projeto é proveniente do Firemonkey ou VCL, então a solução encontrada por mim seria utilizar a Conditional Defines disponibilizada nas opções dos projetos, desta forma seria possível o mesmo componente ser utilizado para VCL e Firemonkey sem grandes dificuldades, é claro que deve ser de bom censo de todos que utilizam o componente sem o código fonte, que as DCU compiladas para o FMX não serão utilizadas na VCL e vice-versa. Os demais arquivos alterados foram: ACBrCAPICOM_TLB.pas ACBrDFeUtil.pas ACBrMSXML2_TLB.pas ACBrNFe.pas ACBrNFeDANFEClass.pas ACBrNFeNotasFiscais.pas ACBrNFeWebServices.pas FMX.OleServer.pas FMX.OleConst.pas Os seguintes itens foram testados em Delphi XE3 no Windows 8 x64 no ambiente de Homologação: Pedido de Seleção do Certificado Pela Capicom no repositório do Windows. Pedido de Status do Servidor Envio de Nota Fiscal Vale lembrar que este recurso é somente para o Windows! Editado em 17/01/2013 - Correção na função GetAppExeName ACBrNFeUtil.pas Editado em 17/01/2013 15:30 - Unit PCN forçando uso da VCL no FMX (Corrigido) pcnNFe.pas ACBrCAPICOM_TLB.pas ACBrDFeUtil.pas ACBrMSXML2_TLB.pas ACBrNFe.pas ACBrNFeDANFEClass.pas ACBrNFeNotasFiscais.pas ACBrNFeWebServices.pas FMX.OleServer.pas FMX.OleConst.pas ACBrNFeUtil.pas pcnNFe.pas