Pedro Peixoto

Boa tarde pessoal. Caso resolvido! Após testarmos o emulador e verificar que todos os comandos estavam sendo enviados corretamente resolvemos mandar a impressora para intervenção e acabou que eles vão dar baixa na impressora.

Daniel, não estou com a impressora real na minha máquina para testar e acho que seria interessante instalar pelo menos o emulador para debugar a função de sangria. Vi ontem em um tópico onde você disse que utiliza o emulador da Urano que utiliza o protocolo FiscNet. Tentei configurar este emulador com o VSPE e ele não funciona de primeira igual ao Sweda Connect SIM. Como você fez a configuração da porta serial virtual para funcionar o emulador da Urano? Eu criei um new devide do tipo Connector como COM1 e utilizando o ECFTeste sempre hora consegue conectar hora não.

Boa tarde, este log se refere a seguinte rotina: procedure TForm1.Sangria1Click(Sender: TObject); Var CNF, FPG, cValor : String ; Valor : Double ; begin CNF := 'SANGRIA' ; FPG := 'DINHEIRO' ; cValor := '0' ; if not InputQuery('Sangria', 'Entre com o Valor da Sangria', cValor ) then exit ; Valor := StrToFloatDef(cValor,-1) ; if Valor <= 0 then exit ; if not InputQuery('Sangria', 'Entre com a Descrição do Comprovante Não Fiscal', CNF ) then exit ; if not InputQuery('Sangria', 'Entre com a Descrição da Forrma de Pagamento', FPG ) then exit ; ACBrECF1.Sangria( Valor, 'TESTE DE SANGRIA', CNF, FPG ) ; mResp.Lines.Add( 'Sangria: '+ FloatToStr(Valor)+' '+ CNF +' '+FPG ); AtualizaMemos ; end; Se não entendi errado quando eu chamo a método Sangria do Objeto ACBrECF1, internamente ele executa várias rotinas certo? Neste caso então eu teria que implementar uma outra rotina de sangria para contornar isto? Obrigado pela atenção!

Bom dia Pessoal, Estamos com um ECF que aceita Suprimento e não aceita Sangria. Pensamos que fosse o PDV mas utilizando o Demo do ACBr também deu errado. Segue o LOG após executar o comando de sangria no ECFTeste. -- 29/03 09:54:34:145 AbreNaoFiscal( ,, ) -- 29/03 09:54:34:145 TX -> {69;AbreCupomNaoFiscal;;23} -- 29/03 09:54:35:034 RX <- {69;0;;6} -- 29/03 09:54:35:034 NumCupom -- 29/03 09:54:35:034 TX -> {70;LeInteiro;NomeInteiro="COO";31} -- 29/03 09:54:35:144 RX <- {70;0;ValorInteiro=287;22} -- 29/03 09:54:35:144 RegistraItemNaoFiscal( 0 , 1 , ) -- 29/03 09:54:35:159 TX -> {71;EmiteItemNaoFiscal;CodNaoFiscal=0 Valor=1;45} -- 29/03 09:54:35:721 RX <- {71;0;;6} -- 29/03 09:54:35:721 Subtotal -- 29/03 09:54:35:721 TX -> {72;LeMoeda;NomeDadoMonetario="TotalDocLiquido";47} -- 29/03 09:54:35:846 RX <- {72;0;ValorMoeda=1,0000;23} -- 29/03 09:54:35:846 EfetuaPagamentoNaoFiscal( -2 , 1 , , 0 ) -- 29/03 09:54:35:846 TX -> {73;PagaCupom;CodMeioPagamento=-2 Valor=1;41} -- 29/03 09:54:35:877 RX <- {73;8000;NomeErro="ErroCMDForaDeSequencia" Circunstancia="Cupom nao fiscal de saida nao permite pagamento.";107} -- 29/03 09:54:35:877 ----------------- ERRO ----------------- Erro retornado pela Impressora: FiscNET: ZPM - ZPM/1FIT LOGGER Erro: 8000 - ErroCMDForaDeSequencia Cupom nao fiscal de saida nao permite pagamento. ---------------------------------------- -- 29/03 09:54:35:877 FechaNaoFiscal( TESTE DE SANGRIA ) -- 29/03 09:54:35:877 TX -> {74;EncerraDocumento;TextoPromocional="MD-5:DE08EB94AAFC19B10F0275BC991A7FCD\x0AEaglePDV 2015.005\x0ATESTE DE SANGRIA";118} -- 29/03 09:54:37:000 RX <- {74;0;;6} Será que esta impressora tem que ir para intervenção para resolver isto?

Boa noite pessoal, Recentemente precisamos fazer algumas adaptações nas nossas soluções para poder suportar o nono dígito e gostaria de compartilhar com vocês uma em especial que usa um recurso muito bacana do Firebird de casamento de padrão por expressão regular. Antes de passar o trecho de código vale apenas ressaltar que esta alteração não procede para telefones fixos. Em 25 de Agosto de 2013 passou a valer o nono dígito para os números móveis dos DDDs 11, 12, 13, 14, 15, 16, 17, 18, 19 Em 27 de Outubro de 2013 os números dos DDDs 21, 22, 24, 27, 28 Até 31 de dezembro de 2014 para os Códigos Nacionais 91, 92, 93, 94, 95, 96, 97, 98, 99 Em 31 de maio de 2015 para os Códigos Nacionais 81, 82, 83, 84, 85, 86, 87, 88, 89 Em 11 de outubro de 2015 Códigos Nacionais 31, 32, 33, 34, 35, 37, 38, 71, 73, 74, 75, 77, 79 Até 31 de dezembro de 2016 para os Códigos Nacionais 41, 42, 43, 44, 45, 46, 47, 48, 49, 51, 53, 54, 55, 61,62, 63, 64, 65, 66, 67, 68, 69 Fizemos um tratamento a nível de trigger que verifica se o número de telefone já pode receber o nono dígito caso o usuário esqueça de informar e atualiza os antigos como segue abaixo: IF (NEW.PESSOA_TELEFONE SIMILAR TO '(11|12|13|14|15|16|17|18|19|21|22|24|27|28|91|92|93|94|95|96|97|98|99|81|82|83|84|85|86|87|88|89|31|32|33|34|35|37|38|71|73|74|75|77|79)[6-9]{1}[0-9]{7}') THEN BEGIN NEW.PESSOA_TELEFONE = SUBSTRING(NEW.PESSOA_TELEFONE FROM 1 FOR 2) || '9' || SUBSTRING(NEW.PESSOA_TELEFONE FROM 3 FOR 8); END Com uma única expressão conseguimos verificar se o número de telefone pode receber o nono dígito como segue: 1) (11|12|13|14|15|16|17|18|19|21|22|24|27|28|91|92|93|94|95|96|97|98|99|81|82|83|84|85|86|87|88|89|31|32|33|34|35|37|38|71|73|74|75|77|79) verifica os dois primeiros digitos são DDDs que já estão valendo o nono dígito 2) [6-9]{1} verifica somente números de telefones não fixos 3) [0-9]{7} verifica se o resto do numero de telefone e digito Esperamos que seja útil.

Ítalo, Regys e Juliomar, mesmo acessando a propriedade XML não estou conseguindo. Neste caso como você disse ele teria que atualizar o XML. Quando mando imprimir o DANFE PDF ele não mostra o protocolo de autorização que também não tem no XML. Tem alguma rotina em específico que eu possa DEBUGAR para em que momento atualiza o XML? Quem sabe consigo ver alguma coisa?

Só para situar, estou usando a revisão 10158; Eu estou usando a propriedade XMLOriginal em vez de XML porque assim que gero e assino o XML e mando consultar e acesso esta propriedade ela está retorando o XML sem assinar. O Juliomar falou sobre as propriedades de salvar. Lembro que em revisões antigas tinha uma propriedade AtualizarXMLCancelado e foi removida. Estou carregando as configurações da seguinte maneira atualmente: {Geral} with ACBrNFe.Configuracoes.Geral do begin ExibirErroSchema := True; FormatoAlerta := 'TAG:%TAGNIVEL% ID:%ID%/%TAG%(%DESCRICAO%) - %MSG%.'; FormaEmissao := teNormal; ModeloDF := moNFe; VersaoDF := ve310; //IdCSC := edtIdToken.Text; //CSC := edtToken.Text; Salvar := getBoolean('conf_salvar_xml'); end; {Web Services} with ACBrNFe.Configuracoes.WebServices do begin UF := getString('conf_webservices_uf'); Ambiente := StrToTpAmb(ok, getString('conf_webservices_ambiente')); Visualizar := False; Salvar := False; AjustaAguardaConsultaRet := False; AguardarConsultaRet := 0; Tentativas := 5; IntervaloTentativas := 1000; end; {Arquivos} with ACBrNFe.Configuracoes.Arquivos do begin Salvar := getBoolean('conf_salvar_xml'); SepararPorMes := False; AdicionarLiteral := False; EmissaoPathNFe := False; SalvarEvento := getBoolean('conf_salvar_xml'); SepararPorCNPJ := False; SepararPorModelo := False; pathSalvar := Self.pathSalvar; PathSchemas := Self.PathSchemas; PathNFe := Self.pathSalvar; //PathCan := Self.pathSalvar; removido //PathCCe := Self.pathSalvar; removido PathInu := Self.pathSalvar; PathEvento := Self.pathSalvar; end; No caso das propriedades do WebServices o salvar está como False. Será que nesta propriedade que tenho que setar True para que faça como fazia no trunk1?

Bom dia e obrigado pela atenção em responder a nossa dúvida Estou fazendo exatamente assim: ACBrNFe.NotasFiscais.Clear; ACBrNFe.NotasFiscais.LoadFromString(XML); //XML Assinado ACBrNFe.Consultar; Result := ACBrNFe.NotasFiscais.Items[0].XMLOriginal; O que está acontecendo é que o XML retornado por esta função está somente com a assinatura e não "atualizou". O que será que estou fazendo de errado?

Bom dia a todos Migramos para o trunk 2 a mais ou menos uns três meses notamos muitas diferenças para melhor na mudança, principalmente na organização do código e diretórios. Fazemos o possível para atualizar os fontes diariamente (sem medo) pois na maioria das vezes conseguimos identificar o que mudou lendo os fontes. Um problema que surgiu recentemente estamos precisando de auxílio é o seguinte: Antes quando por algum motivo um XML de NFe não era recuperado após a transmissão fazíamos o seguinte: 1) Alimenta o componente com os dados do documento gerando o XML 2) ACBrNFe.NotasFiscais.Validar; 3) ACBrNFe.NotasFiscais.Assinar; 4) ACBrNFe.Consultar; Se não me engano o XML era atualizado e pronto! Problema Resolvido! Em testes não estamos conseguindo mais fazer isto. Houve alguma mudança neste processo? Ou agora não pode "Atualizar o XML" como anteriormente. Tentei fazer o Download do XML transmitido, utilizar os métodos XMLAssinato, XMLOriginal e não conseguimos ver uma maneira de obter o XML perdido automaticamente a não ser baixar manualmente no site da sefaz e guardar ele no banco de dados. Quem já passou por isto e puder me dar uma dica agradeço!

Bom dia, assim que conseguir entro em contato de novo.

Estou usando a versão que é baixada via svn ainda! Vou ter que pedir suporte com o pessoal do fortes então sobre o delphi 2007. Mas e você olhar nos outros pacotes de impressão de NF-e, Boleto, etc está sendo citado a {$IFDEF VER180} RLibWinD2007vcl, vcljpg,{$ENDIF}. Só não queria ter código diferente dos oficiais. Se você puder criar então nos pacotes a directiva {$IFDEF VER180} FortesReportCE_Win32_D2007_vcl, vcljpg, {$ENDIF} // D2007 eu consigo trabalhar o fortes para compilar com delphi 2007.

Bom dia De acordo com o caso http://www.projetoacbr.com.br/forum/topic/22800-instalação-do-fortes-report-com-o-trunk2/?page=2 onde o Juliomar fez a troca do nome do pacote do Fortes para delphi 2010 "FortesReportCE_Win32_D2010_vcl" sugiro que seja feito o mesmo para delphi 2007 de acordo com o exemplo abaixo: {$IFDEF VER150} FortesReportCE_Win32_D7_vcl, vcljpg, {$ENDIF} // D7 {$IFDEF VER180} RLibWinD2007vcl, vcljpg,{$ENDIF} // D2007 {$IFDEF VER200} RLibWinD2009, vclimg, {$ENDIF} // D2009 {$IFDEF VER210} FortesReportCE_Win32_D2010_vcl, vclimg, {$ENDIF} // D2010 Segue em anexo o arquivo para avaliação ACBr_MDFeDamdfeRL.dpk

Obrigado Juliana.

Prezados boa noite Executando testes de liberação de versão identificamos o seguinte erro ao processar retorno na função LerRetorno240 ' ' is not a valid integer value Segue em anexo a correção. Sempre que vou converter um tipo costumo utilizar a conversão com valor padrão para evitar possíveis dores de cabeça. ACBrBancoCaixa.pas ACBrBancoCaixa.pas

Juliomar, boa noite Atualizei meus fontes para a revisão 8615 vi que foi modificado os pacotes para o delphi 2007. Reinstalei o ACBR e deu certinho. Muito obrigado e espero que seja útil mais pessoas estas alterações.