francinaldoac
-
Total de ítens
86 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por francinaldoac
-
-
Muito rápido. Obrigado.
-
1
-
-
Segue o manual, campo "Identificação do Título na Empresa", página 28.
No componente o campo "seunumero" está igual ao "numerodocumento", na verdade são campos diferentes.
-
1
-
-
Boa tarde,
No retorno da caixa econômica padrão CNAB400, na procedure TACBrCaixaEconomica.LerRetorno400, o componente está pegando o valor do campo "SeuNumero" na posição errada:
SeuNumero := copy(Linha,59,15);A posição acima é a do número do documento, na verdade deveria ser assim:
SeuNumero := copy(Linha,32,25);Fiz a correção da unit, segue em anexo.
-
1
-
-
Alguém está desenvolvendo esse projeto na ACBr?
Os prazos e o manual definitivo já foi divulgado.
-
Boa tarde!
Descobri isso hoje também quando precisei usar esse registro, a partir da versão "Versao103" o código tem que ser este:
if FBloco_0.Registro0000.COD_VER >= vlVersao103 then //trocar por FBloco_0.Registro0000.COD_VER in [vlVersao103,vlVersao104] se na versão vlVersao105 não for gerado esse registro. begin Add( LFill('E113') + LFill( COD_PART ) + LFill( COD_MOD ) + LFill( SER ) + LFill( SUB ) + LFill( NUM_DOC ) + LFill( DT_DOC ) + LFill( COD_ITEM ) + LFill( VL_AJ_ITEM,0 ) + LFill( CHV_NFE )) ; end; -
Como faço para salvar o XML do MDF-e, pois tenho o arquivo de Lote, e o da consulta da situação do MDF-e?
Obrigado!
-
Como faço para gerar o xml do MDF-e através da consulta do MDF-e.
Meu problema, após envio o arquivo XML não foi enviado com o numero do protocolo, como fazer isso através da consulta do MDF-e, ou até mesmo através da consulta do Recibo novamente, isso é possível?
Obrigado!
-
Olá,
Você conseguiu emitir a GRU Cobrança? Estou tentando fazer a emissão do mesmo e gostaria de saber se o ACBrBoleto já faz isso?
-
Bom dia,
Sobre a propriedade para identificar o layout do arquivo acho o ideal, como nosso amigo descobriu o campo 3 do registro I010 é quem faz essa identificação, fui eu que fiz as alterações para o layout 2, deixei a data "amarrada" em 01/01/2013 porque não tive tempo de implementar a propriedade, estava precisando para "ontem", quando tiver tempo vou ver se volto a esse código, mas se alguém se dispuser ficamos gratos...
Só um comentário, eles deveriam ter colocado a identificação do layout no registro "0000", primeiro registro, ao invés disso fica quase no final...
-
Boa tarde!
Eu já fiz todas as alterações necessários e já validei o arquivo, falta só um detalhe, do jeito que fiz quando o período for maior que 01/01/2013 será gerado o layout 2.00, caso contrário o componente vai gerar no layout anterior, o ideal é testar o campo "COD_VER_LC" do registro "I010", mas não tive tempo ainda para fazer isso.
-
Sim funciona, já tinha feito isso e colocado em produção na minha aplicação, acho estranho ninguém ter notado antes...
Grato.
É porque vc pegou uma IE nova, a qual mudou o cálculo, pois as IEs antigas tinha o tipo como passado o link pelo Elton, e no link que vc passou foi retirado os tipos, já subi pro SVN.
Ótimo, deve ser por causa disso, grato mais uma vez.
-
O único algorítimo de validação que eu conheço de inscrição estadual de alagoas é o do site de sintegra: http://www.sintegra.gov.br/CAD_Estados/cad_AL.html
Talvez você possa explicar o que seria a empresa tipo 2, visto que ela não se encaixa no seguinte:
X – Tipo de empresa (0-Normal, 3-Produtor Rural, 5-Substituta, 7- Micro-Empresa Ambulante, 8-Micro-Empresa)
O algorítimo de validação do site do sintegra deve estar errado para Alagoas, pois lá não existe o campo tipo de empresa, segue abaixo um link do site da fazenda de Alagoas, com a validação de sua inscrição estadual.
Mude "24BNNNNNX.14.00" para "24NNNNNNX.14.00" e faça o teste, o "B" quer dizer que o terceiro carácter só poderá ser "03578" se mudar para "N" o terceiro carácter poderá ser "0123456789", isso deve resolver, confirme se funcionou, caso não funcione me informe o IE, que irei testar.
Sim funciona, já tinha feito isso e colocado em produção na minha aplicação, acho estranho ninguém ter notado antes...
Grato.
-
O único algorítimo de validação que eu conheço de inscrição estadual de alagoas é o do site de sintegra: http://www.sintegra.gov.br/CAD_Estados/cad_AL.html
Talvez você possa explicar o que seria a empresa tipo 2, visto que ela não se encaixa no seguinte:
X – Tipo de empresa (0-Normal, 3-Produtor Rural, 5-Substituta, 7- Micro-Empresa Ambulante, 8-Micro-Empresa)
O algorítimo de validação do site do sintegra deve estar errado para Alagoas, pois lá não existe o campo tipo de empresa, segue abaixo um link do site da fazenda de Alagoas, com a validação de sua inscrição estadual.
-
Olá,
Estou gerando pela primeira vez o SPED Fiscal para o estado de Alagoas, acontece que quando vou salvar meu arquivo o componente do ACBrSPEFiscal acusa que a inscrição estadual do meu cliente não é válida:
(0-0000) ENTIDADE: A inscrição estadual "242XXXXXX" digitada é inválida!
Acontece que ele é válida sim e está OK no SINTEGRA, analisando a função que faz essa crítica a "funChecaIE" da unit ACBrSpedUtils, vi que para o estado de Alagoas temos a tabela:
if TIPO = 'AL' then Tabela_1 := '1.09.0.0.11.01. . . . 24BNNNNNX.14.00';
Quando chega no ponto do teste abaixo:if ( Posicao_1 = 'B' ) and ( Pos( Posicao_2, '03578' ) = 0 ) then Erro_3 := 1;
Indica que o terceiro caractere "B" não pode ser "2" como é o meu caso da inscrição 242... Isso foi o que entendi.
Essa tabela está correta, o teste não está errado, já que minha inscrição é válida?
Grato
-
Ola!
Estamos com problema aqui também, não precisa tirar todos os dados do transportador, apenas a placa do veículo e já é autorizado, vamos esperar que o Estado corrija o problema na validação desse campo.
-
Amigos por favor só pra eu entender. Se o erro do num_parc(decimais) foi corrigino, porque não fica atualizado no svn?
Porque não havia sido corrigido por este tópico, hoje falei com o Isaque Pinheiro em outro tópico do SPED e ele fez as correções, pode baixar que está OK.
-
Resolvido e já disponivel no SVN, o problema do G125 e G126 do SPED Fiscal
Abs
Oi Isaque, faltou modificar na procedure WriteRegistroG125 da unit ACBrEFDBloco_G_Class quando for "Versao103" para para LFill( NUM_PARC, 3 ) fazendo isso tudo OK. Grato mais uma vez.
-
Agora vai
Baixa la testa e me retorna se funcionou
Abs
Sim, funcionou, apesar de todos os valores ficarem com 4 decimais, exemplo "7,6000" ao invés de "7,6" o validador não deu erro, só aumentou um pouco o tamanho do arquivo.
Obrigado.
Aproveitando o contato, embora não seja o lugar apropriado, mas como já postei um tópico sobre o assunto e o problema ainda persiste, Isaque, tem um problema parecido no SPED Fiscal, nos campos NUM_PARC do Reg G125 e do Reg G126, o campo é numérico tamanho 3 e sem decimais, qual o "post" ativo que devo informar isso?
-
Oi pessoal,
Os campos ALIQ_PIS e ALIQ_COFINS do registro C170 segundo o manual possuem tamanho 8 com 4 decimais, esse campos estavam declarados como currency, alterei para Double, conseqüentemente tive que alterar a função de formatação na procedure WriteRegistroC170, trocando o LFill por DFill.
Na unit ACBrEPCBloco_C ficou :
fALIQ_PIS_PERC : Double; /// Alíquota do PIS (em percentual) fALIQ_COFINS_PERC : Double; /// Alíquota do COFINS (em percentual) property ALIQ_PIS_PERC : Double read FALIQ_PIS_PERC write FALIQ_PIS_PERC; property ALIQ_COFINS_PERC : Double read FALIQ_COFINS_PERC write FALIQ_COFINS_PERC;Na unit ACBrEPCBloco_C_Class, procedure WriteRegistroC170 ficou :{27} DFill( ALIQ_PIS_PERC,4,true ) + {33} DFill( ALIQ_COFINS_PERC,4,true ) +Grato.
Quando for expecificado tamanho e decimais, não pode ser Double, porque a função que recebe tipo Double, tem tamanho infinito, só podemos parametrizar decimais.
Para corrigir tem que ser o Tipo Currency e parametrizar corretamente:
LFill( ALIQ_PIS_PERC,8,4 )
LFill( ALIQ_COFINS_PERC,8,4)
Faz um teste ai
Vou ajustar e subir
Não funciona, já tinha tentado desse jeito, mesmo com esses parâmetros ele arredonda pra duas decimais, um valor como "0,5775" fica "0,58", por isso fiz com double, mas não lembrei do fato da função não limitar o tamanho da parte inteira. O problema está na propriedade "CurMascara" que no componente fica setada como "#0.00", então mesmo colocando 4 decimais a função LFill arredonda para o valor da máscara setada ali, tentei deixar o valor da propriedade em branco, mas também não funcionou. Vou pensar em outra solução e coloco aqui depois.
Grato.
-
Oi pessoal,
Os campos ALIQ_PIS e ALIQ_COFINS do registro C170 segundo o manual possuem tamanho 8 com 4 decimais, esse campos estavam declarados como currency, alterei para Double, conseqüentemente tive que alterar a função de formatação na procedure WriteRegistroC170, trocando o LFill por DFill.
Na unit ACBrEPCBloco_C ficou :
fALIQ_PIS_PERC : Double; /// Alíquota do PIS (em percentual) fALIQ_COFINS_PERC : Double; /// Alíquota do COFINS (em percentual) property ALIQ_PIS_PERC : Double read FALIQ_PIS_PERC write FALIQ_PIS_PERC; property ALIQ_COFINS_PERC : Double read FALIQ_COFINS_PERC write FALIQ_COFINS_PERC;Na unit ACBrEPCBloco_C_Class, procedure WriteRegistroC170 ficou :{27} DFill( ALIQ_PIS_PERC,4,true ) + {33} DFill( ALIQ_COFINS_PERC,4,true ) +Grato.
-
Olá,
Encontrei um erro no registro A170, o campo NUM_ITEM estava gravando valor diferente do informado, o problema estava na procedure TBloco_A.WriteRegistroA170 da unit ACBrEPCBloco_A_Class:
No código estava
LFill(NUM_ITEM)
e a função estava considerando o campo como datetime. Alterei paraLFill(NUM_ITEM, 0)
agora está OK.
Segue unit em anexo.
[]´s
Francinaldo
-
-
Oi Pessoal,
O registro G125 está gerando decimais na gravação do campo NUM_PARC, este campo é numérico de tamanho 3 sem decimais, percebi que o problema está na declaração do campo que ficou como Currency e poderia ser Integer.
Grato.
-
Olá,
Estou com dois problemas no componente do SPED PIS/COFINS:
1 - O registro 0111 está retornando o velho erro de acesso a memória quando usado, verifiquei que o objeto não está sendo criado, fiz a correção temporária, implementando o create do registro pai o 0110.
constructor TRegistro0110.Create; begin FRegistro0111 := TRegistro0111.Create; end; destructor TRegistro0110.Destroy; begin FRegistro0111.Free; inherited; end;
2 - o campo SUFRAMA do registro 0140 está gravando "000000000" mesmo quando informado em branco, verifiquei que o problema está na procedure TBloco_0.WriteRegistro0140, substitui o código LFill( SUFRAMA, 9 ) por LFill( SUFRAMA ) para resolver.
Mais uma vez parabenizo todos do ACBr por esse novo componente.
Campo ValorPago não implementado no CNAB400 da Caixa
em ACBrBoleto
Postado
Boa tarde!
No padrão CNAB400 da Caixa, o vampo "ValorPago" não foi implementado, apenas o campo "ValorRecebido", no CNAB240 os dois campos possuem funcionalidades diferentes, mas no CNAB400 deveriam ser iguais ou o campo "ValorRecebido" não ser atribuído.
O campo "ValorPago" nos dois padrões é o valor efetivo a ser baixado pelo cliente, o "ValorRecebido" no CNAB240 existe quando o banco fica com parte do valor pago pelo cliente no banco a título de taxa/remuneração.
Peço a gentileza de avaliar esse caso.
Manual_de_Leiaute_de_Arquivo_Eletronico_CNAB_400 (1).pdf