carlosmarian

Acho que o atributo "NotaLegalDF" não esta sendo persistido no arquivo de configuração no método "TACBrAAC.SalvarArquivo". ... if GravarConfigApp then begin Ini.WriteBool('PAF', 'RealizaPreVenda', fsIdentPAF.Paf.RealizaPreVenda); ... Ini.WriteBool('PAF', 'MinasLegal', fsIdentPAF.Paf.MinasLegal); //Falta tratar o atributo abaixo. Ini.WriteBool('PAF', 'NotaLegalDF', fsIdentPAF.Paf.NotaLegalDF); end; At+ ACBrAAC.pas ACBrAAC.pas

Olá, funcionou corretamente(como já era de se esperar ). Só uma sugestão, talvez formatar o valor que é apresentado na mensagem. Muito obrigado pela atenção. at+

Desculpe, talvez eu tenha entendido errado a funcionalidade aplicada a este novo atributo. Troco no cartão na minha interpretação se trata do PREMIA da Cielo ou a opção de fazer saque junto com um pagamento quando a forma de pagamento for exclusivamente cartão. Estou correto? at+

OK, vou efetuar mais alguns testes, pq inicialmente eu informei valor para este atributo mas não tive o bloqueio quando o valor ultrapassou o limite estabelecido. Obrigado pela atenção.

Olá, verifique que foi adicionado um atributo a classe "TACBrTEFD", "TrocoMaximo". Já pode ser usado este atributo? Qual seria a regra para utiliza-lo, é que não achei nada sobre isso no exemplo. Obrigado pela atenção.

Olá, tive o retorno do cliente de que a partir do momento que ele mudou para o horário de verão o sistema não tem mais conseguido transmitir os CCe. Avaliando o retorna da SEFAZ Status "578 - Rejeicao: A data do evento nao pode ser maior que a data do processamento", é possível constatar que no envio a tag "dhEvento" possui este valor "2012-10-22T17:25:29-03:00", já os dados do retorno da SEFAZ a tag "dhRegEvento" possui o seguinte valor "2012-10-22T17:25:39-02:00". No fonte pcnCCeNFe.pas método TCCeNFe.GerarXML a tag "dhEvento" é montada com valor fixo "-03:00", acredito que isso possa ser o problema. Exemplo de XML: <?xml version="1.0" encoding="UTF-8" ?> - - - 42 1 0000000000000 0000000000000000000000000000000000000000000 2012-10-22T17:25:29-03:00 110110 1 1.00 - Carta de Correcao QUANTIDADE DE VOLUME = 01 VOLUME A Carta de Correcao e disciplinada pelo paragrafo 1o-A do art. 7o do Convenio S/N, de 15 de dezembro de 1970 e pode ser utilizada para regularizacao de erro ocorrido na emissao de documento fiscal, desde que o erro nao esteja relacionado com: I - as variaveis que determinam o valor do imposto tais como: base de calculo, aliquota, diferenca de preco, quantidade, valor da operacao ou da prestacao; II - a correcao de dados cadastrais que implique mudanca do remetente ou do destinatario; III - a data de emissao ou de saida. ..... - 1 SVRS20110530105153 42 578 Rejeicao: A data do evento nao pode ser maior que a data do processamento 00000000000000000000000000000000000000000000 110110 1 2012-10-22T17:25:39-02:00 Já que é necessário ter esta informação junto com a data será que não seria melhor criar um atributo para isso? At+

Olá, Existe alguma restrição para que a impressão das informações(Observacao) no Fechamento do cupom fiscal(TACBrECF.FechaCupom) referente ao MD5 ou nro de PV, DAV e DA-OS ocorram em linhas separadas? Hj no meu caso esta imprimindo um CF referente a pré-venda assim: "MD-5:1111111111112223334445556667677888PV0000000004". Será que não poderia ser impresso cada item em uma linha separada? Exemplo: ... procedure TACBrECF.FechaCupom(Observacao: AnsiString; IndiceBMP : Integer); //função para tratar a informação adicional: function TrataEnterFinalLInha(pPrefixo, pValor : String):String; begin Result := EmptyStr; if Trim(pValor) = EmptyStr then Exit; {Limpa as possíveis quebras de linha já incluidas pelos usuários} Result := StringReplace(pValor,CR+LF,#10,[rfReplaceAll]) ; Result := StringReplace(Result,'|',#10,[rfReplaceAll]) ; Result := pPrefixo + Result + #10; end; var .... { Tirando os Acentos e trocando todos os #13+#10 e '|' por #10 } Observacao := StringReplace(Observacao,CR+LF,#10,[rfReplaceAll]) ; Observacao := StringReplace(Observacao,'|',#10,[rfReplaceAll]) ; { montar o rodape quando as informações de rodapé forem passadas } RodapePafECF := EmptyStr; //Aqui, para cada item chama rotina que trata e adiciona quebra se for necessário. // atende ao requisito do Paf-ECF RodapePafECF := RodapePafECF + TrataEnterFinalLInha('MD-5:', InfoRodapeCupom.MD5); // atende ao requisito do paf-ECF V item 2 RodapePafECF := RodapePafECF + TrataEnterFinalLInha('PV', InfoRodapeCupom.PreVenda); // atende ao requisito do paf-ECF VI item 5 RodapePafECF := RodapePafECF + TrataEnterFinalLInha('DAV', InfoRodapeCupom.Dav); // atende ao requisito do paf-ECF XLI item 1 RodapePafECF := RodapePafECF + TrataEnterFinalLInha('DAV-OS', InfoRodapeCupom.DavOs); // atende ao requisito VII-A 2-A (Cupom Mania [RJ]) if InfoRodapeCupom.CupomMania then .... InfoRodapeCupom.Clear; end; ...

Alguém já passou pela homologação e tem experiência de como este teste tem sido aplicado e validado pelo homologador? Obrigado.

Olá, este relatório não teria que ter um formato diferente? De acordo com o que esta definido no manual do PAF. Estou lendo no manual e diz que deveria(ou sugere) ser algo assim: 01/01/2012 - Dinheiro - Cupom fiscal - 12,00 01/01/2012 - Dinheiro - Cupom fiscal - 8,00 SOMA DO DIA 01/01/2012 - 20,00 02/01/2012 - Dinheiro - Cupom fiscal - 10,00 02/01/2012 - Cheque - Cupom fiscal - 8,00 SOMA DO DIA 02/01/2012 - 18,00 TOTAL DO PERÍODO SELECIONADO: DINHEIRO: 30,00 CHEQUE: 8 SOMA TOTAL: 38,00 E esta sendo gerado algo similar a isso: DATA DE ACUMULAÇÃO: 19/09/2012 Identificacao Tipo Valor R$ --------------- ------------------- ------------ NÃO É DOCUMENTO FISCAL DINHEIRO CF 784,29 ------------------------------------------------ Sub-Total 784,29 DATA DE ACUMULAÇÃO: 20/09/2012 Identificacao Tipo Valor R$ --------------- ------------------- ------------ CHEQUE CF 10,00 NÃO É DOCUMENTO FISCAL DINHEIRO CF 118,53 ------------------------------------------------ Sub-Total 128,53 TOTAL GERAL TESTE MSG Identificacao Valor R$ NÃO É DOCUMENTO FISCAL --------------------------- -------------------- CHEQUE 10,00 DINHEIRO 902,82 ------------------------------------------------ TOTAL 912,82 Isso não deve gerar problemas durante a Homologação do PAF-ECF né?

Subi na revisão 3931. Se possível, verificar se está tudo certo. Obrigado Valeu, tudo correto.

Olá, Estou efetuando os testes de pré-certificação e estou com uma dúvida. Com a adição do tratamento do "Premia", não posso mais subtotalizar os cupom antes de chamar o CTR. O problema começa aii... se eu efetuar pagamento em Dinheiro + Cartão já não funciona mais. Como a forma de pagamento cartão deve ser a última, eu deve efetuar a subtotalização antes de lançar o pagamento em dinheiro, fazendo isso gera erro ao efetuar o pagamento com cartão, já que ele vai tentar lançar um novo desconto. Fora os possíveis problemas legais que isso pode acarretar. At++

É, talvez possa ser alguma coisa na minha impressora, é uma DARUMA FS 600 e ela acabou de voltar da assistência técnica, onde atualizaram o software dela. Mas vou ter que manter a alteração que fiz no fonte, pq senão não consigo imprimir alguns documentos. at+

Hummm... Não sei, acho que o mais correto mesmo seria revisar o tratamento, pq isso pode ocasionar erro em outras funcionalidades. Até pq o negrito existe para a impressora, só teria que verificar exatamente o pq foi colocar o fsComandosImpressao[0] := #0;para impressora DARUMA. at+

Teste executado e problema resolvido. At+

Olá, algum retorno sobre isso? Estou usando Delphi 2009 e tbm não esta mais inicializando o GP. Alterei o tipo do parâmetro da rotina "ACBRUtil.RunCommand" de "AnsiString" para "String" e o GP passou a ser inicializado corretamente. at+

Olá, no log encontramos a linha abaixo o que nos levou a acreditar que a não impressão total seria algo relacionado a formatação em negrito: -- 19:26:19:275 LinhaRelatorioGerencial( "================================================[CR][LF]LAUDO NUMERO: [ESC]G[1]URB0152011[ESC]G[CR][LF]", 0 ) TX -> [FS]F[231]================================================[LF]LAUDO NUMERO: [ESC]G[1]URB9999999[ESC]G[LF][255]W 19:26:19:533 RX <- :0000000[231][CR] O trecho em negrito acima, mostra que não estava fechando corretamente o comando de negrito. Inicialmente tentamos diminuir o tamanho da string para verificar se não era algum limite da impressora, mas sem sucesso. Abaixo segue o log gerado depois da nossa alteração: -- 08:02:48:674 LinhaRelatorioGerencial( "================================================[CR][LF]LAUDO NUMERO: [ESC]G[1]xxx9992099[ESC]G0[CR][LF]================================================[CR][LF][CR][LF][ESC]G[1]EMPRESA DESENVOLVEDORA[ESC]G0[CR][LF]------------------------------------------------[CR][LF]CNPJ........: 00000000000000[CR][LF]Razao Social: xxxxxxxxxxxxxxxxxx[CR][LF]Endereco....: [CR][LF]Cidade/UF...: /[CR][LF]", 0 ) TX -> [FS]F[231]================================================[LF]LAUDO NUMERO: [ESC]G[1]xxx9992099[ESC]G0[LF]================================================[LF][LF][ESC]G[1]EMPRESA DESENVOLVEDORA[ESC]G0[LF]------------------------------------------------[LF]CNPJ........: 00000000000000[LF]Razao Social: xxxxxxxxxxxxxxxxxx[LF]Endereco....: [LF]Cidade/UF...: /[LF][255]K 08:02:49:162 RX <- :0000000[231][CR] O trecho em negrito acima mostra que com a alteração o comando de negrito passa a ser escrito de forma correta, e o relatório foi impresso corretamente.

Olá, estou homologando o PAF com a impressora DARUMA e ao executar a impressão da Identificação PAF(PafMF_RelIdentificacaoPafECF), o texto foi impresso somente até o nro do laudo. Acredito que o que pode ter levado a esta problema foi que existe uma exceção para o caracter '#0' (fsComandosImpressao[0] := #0 ; ) no create da classe(TACBrECFDaruma.create) e no evento traduzir tag(TACBrECFDaruma.TraduzirTag) a tah que identifica o fim do negrito é "#0". Com isso se alterar a tag de fim de negrito de "#0" para "'0'" a impressão ocorre sem erros. Atual: function TACBrECFDaruma.TraduzirTag(const ATag: AnsiString): AnsiString; const C_ON = #1; C_OFF = #0; Alterado: function TACBrECFDaruma.TraduzirTag(const ATag: AnsiString): AnsiString; const C_ON = #1; C_OFF = '0'; At+

Olá, Acredito que sim, a primeira(do Leonardo S Barbosa) implementa os registros D195 e D197. Só deve se atender que no fonte que ele colocou não esta a implementação de outros registros, pode estar meio desatualizado. Mas a implementação dos registros D195 e D197 estão oK. A segunda foi para complementar a 1º, gerando os registros de totalizadores(9900) para o D195 e D197 . at+

Olá, Durante o processo de implantação do CT-e usando componente ACBr tive uma pequena dificuldade para guardar o arquivo XML da inutilização. Verificando no fonte o arquivo final (com sufixo "-ProcInutCTe.xml") é gerado com um prefixo que concatena a hora atual e isso pode dificultar muito a obtenção do arquivo gerado. Sugiro a seguinte alteração(com base no que é feito na NF-e), retirar o prefixo da hora atual e deixar somente a chave. Fonte atual(ACBrCTeWebServices.pas): .. function TCTeInutilizacao.Executar: Boolean; .. if FConfiguracoes.Geral.Salvar then FConfiguracoes.Geral.Save(FormatDateTime('yyyymmddhhnnss',Now)+FCTeChave+'-ProcInutCTe.xml', FXML_ProcInutCTe); if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(FormatDateTime('yyyymmddhhnnss',Now)+FCTeChave+'-ProcInutCTe.xml', FXML_ProcInutCTe, FConfiguracoes.Arquivos.GetPathInu ); .. Alteração (ACBrCTeWebServices.pas): .. function TCTeInutilizacao.Executar: Boolean; .. if FConfiguracoes.Geral.Salvar then FConfiguracoes.Geral.Save(StringReplace(FCTeChave,'ID','',[rfIgnoreCase])+'-ProcInutCTe.xml', FXML_ProcInutCTe); if FConfiguracoes.Arquivos.Salvar then FConfiguracoes.Geral.Save(StringReplace(FCTeChave,'ID','',[rfIgnoreCase])+'-ProcInutCTe.xml', FXML_ProcInutCTe, FConfiguracoes.Arquivos.GetPathInu); .. Obrigado pela atenção.

Obrigado pela alteração no registros D195, ATENÇÃO: teria tbm que dar manutenção no fonte "ACBrSpedFiscal.pas", onde trata os totalizadores: ... procedure TACBrSPEDFiscal.WriteRegistroD001; begin ... if Bloco_D.RegistroD190Count > 0 then begin with New do begin REG_BLC := 'D190'; QTD_REG_BLC := Bloco_D.RegistroD190Count; end; end; //inicio novo trecho if Bloco_D.RegistroD195Count > 0 then begin with New do begin REG_BLC := 'D195'; QTD_REG_BLC := Bloco_D.RegistroD195Count; end; end; if Bloco_D.RegistroD197Count > 0 then begin with New do begin REG_BLC := 'D197'; QTD_REG_BLC := Bloco_D.RegistroD197Count; end; end; ////final novo trecho if Bloco_D.RegistroD300Count > 0 then begin with New do begin REG_BLC := 'D300'; QTD_REG_BLC := Bloco_D.RegistroD300Count; end; end; ... OBS: só atenção que este seu fonte esta retirando as implementações do registros D695, D696 e D697. At+

Olá. Banco : 104 :-> TACBrTipoCobranca.cobCaixaSicob no fonte "ACBrCaixaEconomicaSICOB.pas", o valor da remessa para produção esta "REMESSA-PRODUÇÃO", recebi o retorno de critica onde informa que deveria ser "REMESSA-PRODUCAO" ou "REMESSA-TESTE DV AGENCIA". Obrigado pela atenção.

Outra conversão: interface function StrToCodIndIncTributaria(var ok: boolean; const s: string): TACBrCodIndIncTributaria; function StrToIndAproCred(var ok: boolean; const s: string): TACBrIndAproCred; function StrToCodIndTipoCon(var ok: boolean; const s: string): TACBrCodIndTipoCon; implementation //Codigo indicador da incidencia tributária no período (0110) function StrToCodIndIncTributaria(var ok: boolean; const s: string): TACBrCodIndIncTributaria; begin result := StrToEnumerado(ok, s, ['1', '2', '3'], [codEscrOpIncNaoCumulativo, codEscrOpIncCumulativo, codEscrOpIncAmbos ]); end; //Código indicador de método de apropriação de créditos comuns, no caso de incidencia no regime não cumulativo(COD_INC_TRIB = 1 ou 3)(0110) function StrToIndAproCred(var ok: boolean; const s: string): TACBrIndAproCred; begin result := StrToEnumerado(ok, s, ['1', '2'], [indMetodoApropriacaoDireta, indMetodoDeRateioProporcional ]); end; //Código indicador do Tipo de Contribuição Apurada no Período(0110) function StrToCodIndTipoCon(var ok: boolean; const s: string): TACBrCodIndTipoCon; begin result := StrToEnumerado(ok, s, ['1', '2'], [codIndTipoConExclAliqBasica, codIndTipoAliqEspecificas ]); end;

Outra conversão: interface function StrToIndCredOri(var ok: boolean; const s: string): TACBrIndCredOri; function StrToBaseCalculoCredito(var ok: boolean; const s: string): TACBrBaseCalculoCredito; implementation function StrToBaseCalculoCredito(var ok: boolean; const s: string): TACBrBaseCalculoCredito; begin result := StrToEnumerado(ok, s, ['01', '02', '03', '04', '05', '06', '07', '08', '09', '10', '11', '12', '13', '14', '15', '16', '17', '18'], [bccVazio, bccAqBensRevenda, bccAqBensUtiComoInsumo, bccAqServUtiComoInsumo, bccEnergiaEletricaTermica, bccAluguelPredios, bccAluguelMaqEquipamentos, bccArmazenagemMercadoria, bccConArrendamentoMercantil, bccMaqCredDepreciacao, bccMaqCredAquisicao, bccAmortizacaoDepreciacaoImoveis, bccDevolucaoSujeita, bccOutrasOpeComDirCredito, bccAtTransporteSubcontratacao, bccAtImobCustoIncorrido, bccAtImobCustoOrcado, bccAtPresServ, bccEstoqueAberturaBens]); end; function StrToIndCredOri(var ok: boolean; const s: string): TACBrIndCredOri; begin result := StrToEnumerado(ok, s, ['0', '1'], [TACBrIndCredOri.icoOperProprias, TACBrIndCredOri.icoEvenFusaoCisao]); end;

Olá, correto Kiko Fernandes, a rotina que trata o status 101 esta logo abaixo do tratamento que hoje eu sugeri que fosse revisado. valeu por lembrar, eu esqueci de comentar que onde hoje trata só o 101, não existe a necessidade de manutenção. at+

Estava com problema para recuperar os dados de protocolo na consulta da NFe quando ela esta denegada. Acredito que o problema esta na leitura do XML(pcnRetConsSitNFe.pas) método(TRetConsSitNFe.LerXml: boolean), ele trata os status 100 e 101 quando deveria tratar 100 e 110. Hoje ele faz if FcStat in [100,101] then, mas acredito que o correto seria if FcStat in [100,110] then, fiz um teste aqui e funcionou. Acredito que esta correção poderá resolver o problema relatado no topico (viewtopic.php?f=6&t=5412&p=28066&hilit=DENEGADA#p28066). Obrigado pela atenção.