carlosmarian
-
Total de ítens
235 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por carlosmarian
-
-
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,82Isso não deve gerar problemas durante a Homologação do PAF-ECF né?
-
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+
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++
-
Os comandos implementados estão de acordo com o manual, inclusive eu fiz testes em uma Daruma FS700 dentro do PD da Daruma e aqui na empresa também.
É, 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+
-
Experimente algo bem simples:
ACBrECF1.IgnorarTagsFormatacao := True;
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+
-
Acabei de enviar uma possível correção... por favor atualize e teste...
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á,
só pra esclarecer: as duas alterações acima são necessárias?
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.
-
Olá,
Após atualizarmos os componentes, estava gerando erro ao tentar exportar o arquivo. Este erro estava sendo proveniente do Registro D195. No código estava faltando a inicialização do FRegistroD195 para a geração correta. Arquivo em anexo para análise.
Att,
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.
Nota Legal DF
em Dúvidas Gerais sobre o ACBr
Postado
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