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.