RobertoSchuster
-
Total de ítens
65 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por RobertoSchuster
-
-
-
Bom dia,
Verifiquei que somente o nome do Sacador/Avalista está sendo exibido nos boletos (FortesReport) e não encontrei nenhum tópico falando a respeito.
Portanto, realizei uma pequena adaptação na disposição das informações do Pagador, a fim de permitir que os dados de endereço do Sacador/Avalista sejam exibidos também, mantendo o mesmo espaço.
Segue em anexo para análise e, se possível, commit.
-
Olá Juliana,
Te agradeço pela ajuda.
Não realizei nenhuma alteração inicialmente justamente porque esta parte é bem delicada mesmo, envolvendo outros manuais e afetando todos os outros tipos de convênio.
-
1
-
-
Olá Juliana, obrigado pelo retorno.
Entendo, porém o estranho é que meu cliente já utilizava estas configurações em outro software e estava emitindo boletos sem registro (carteira 18), com o nosso número no formato que mencionei.
Encontrei algo no manual em anexo, pág 8:
Citar Para número de convênio de 6 posições (de 10.000 a 999.999), informar o nosso número com
11 posições mais o DV, sendo as 6 primeiras posições o número do convênio, as 5 posições
seguintes um número sequencial para controle e mais o DV.
Exemplo: CONVÊNIOS DE 010.000 ATÉ 999.999
123456123451
CCCCCCSSSSSD
Onde: C = Convênio S = Sequencial D = dígito verificador
-
Olá,
Estou enfrentando problemas para gerar boletos do Bando do Brasil, utilizando carteira 18 e convênio de 6 posições.
À primeira vista, o NossoNumero está sendo gerado com 17 dígitos em vez de 11.NossoNumero (nº sequencial): 1
Convênio: 123456
NossoNumero completo esperado: '12345600001' (11 dígitos)
NossoNumero completo obtido: '00000000000000001' (17 dígitos)Passos para reprodução do problema:
1. Criar um Titulo na lista (Titulo := ACBrBoleto.CriarTituloNaLista)
2. Popular os dados do boleto, sendo que Titulo.NossoNumero recebe o número sequencial (Titulo.NossoNumero := '1')Neste momento ocorre:
a. Chamada à função SetNossoNumero()
b. SetNossoNumero() chama CalcularTamMaximoNossoNumero('18', '1')
c. CalcularTamMaximoNossoNumero('18', '1') resulta em 11 dígitos
d. Então Titulo.NossoNumero (fNossoNumero) recebe '00000000001'
3. Exibir o boleto (ACBrBoleto.Imprimir)Neste momento ocorre:
a. Chamada à função MontarCampoNossoNumero(Titulo) // Aqui Titulo.NossoNumero ainda é igual a '00000000001'
b. MontarCampoNossoNumero(Titulo) chama FormataNossoNumero(Titulo) // Aqui Titulo.NossoNumero ainda é igual a '00000000001'
c. FormataNossoNumero(Titulo) chama CalcularTamMaximoNossoNumero('18', '00000000001')
d. CalcularTamMaximoNossoNumero('18', '00000000001') resulta em 17 dígitos, pois entra no primeiro if
e. Então FormataNossoNumero(Titulo) resulta em '00000000000000001', com 17 dígitos
f. A partir daí o nosso número passa a ter 17 dígitos....Será que estou preenchendo de forma incorreta as propriedades ou preenchendo em uma ordem incorreta?
Obrigado.
-
Entendo perfeitamente @Juliomar Marchetti. Falha minha.
-
1
-
-
Bom dia pessoal, agradeço pela atenção ao post.
Pelo que entendi, acredito que o @Roberto Borchardt esteja com um problema similar ao meu.
Estou na revision 10745, de 28 de dezembro de 2015, verifiquei várias vezes no log do SVN e não encontrei nenhum commit que me chamasse a atenção sobre este problema. Logo, só terei como confirmar se o problema persiste quando eu atualizar o ACBr, na semana que vem. O que posso afirmar é que por enquanto isso acontece (não sei se ocorria antes pois eu usava o Rave).
-
Bom dia,
Hoje assisti ao novo vídeo da Tecnospeed, que fala sobre a partilha do ICMS e principalmente sobre a diferença no preenchimento das tags quando a empresa for do Simples Nacional. Pelo que entendi, a única diferença é que a tag vICMSUFRemet fica zerada, conforme destacado na imagem abaixo.
No entanto, independente desta peculiaridade do Simples, fui refazer o cálculo todo para confirmar se os outros valores fechariam. E não fecharam.
Eis a dúvida: até então, para obter o DIFAL eu faria 19% - 12% = 7%, que seria aplicado à base de cálculo: R$ 1000,00 x 7% = R$ 70,00. Então 40% destes R$ 70,00 iriam para a UF de destino e 60% para a UF de origem (zerado quando for Simples Nacional). E 40% de R$ 70,00 corresponde a R$ 28,00 e não os R$ 20,00 preenchidos no exemplo da Tecnospeed. Pelo que pude perceber, apesar de terem preenchido 19% na tag pICMSUFDest, a partilha foi realizada utilizando 17%, ficando: 17% - 12% = 5%, que aplicado à base de calculo fica: R$ 1000,00 x 5% = R$ 50,00. Então 40% de R$ 50,00 são os R$ 20,00 que aparecem na imagem abaixo.
O que vocês acham?
Abaixo segue o print do vídeo da Tecnospeed:
-
1
-
-
-
Boa tarde, o problema apareceu novamente.
Conforme o print abaixo, o que está em amarelo não aparece no DANFE, embora apareça no XML. Para testar criei o texto no notepad, sendo cada linha uma letra, para localizar mais facilmente o que estava faltando. Observar que também não foi gerada outra página.
Tags no XML:
<infAdic> <infCpl>Trib aprox R$ 183,30 Federal, R$ 163,10 Estadual | Fonte: IBPT | ca7gi3;AAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAA;BBBBBBB BBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBB;CCCCCCCC CCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCC;DDDDDDDDD DDDDDDDDDDDDD DDDDDDDDDDDDDDDDDDDDDD;EEEEEEEEEE EEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEE;FF FFFFFFFFF FFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFF;GGG GGGGGGGGG GGGGGGGGGGGG GGGGGGGGGGGGGGGGGGG;HHHH HHHHHHHHH HHHHHHHHHHHH HHHHHHHHHHHHHHHHHH;IIIII IIIIIIIII IIIIIIIIIIII IIIIIIIIIIIIIIIII;JJJJJJ JJJJJJJJJ JJJJJJJJJJJJ JJJJJJJJJJJJJJJJ;KKKKKKK KKKKKKKKK KKKKKKKKKKKK KKKKKKKKKKKKKKK;LLLLLLLL LLLLLLLLL LLLLLLLLLLLL LLLLLLLLLLLLLL;MMMMMMMMM MMMMMMMMM MMMMMMMMMMMM MMMMMMMMMMMMM;NNNNNNNNNN NNNNNNNNN NNNNNNNNNNNN NNNNNNNNNNNN;OOOOOOOOOOO OOOOOOOOO OOOOOOOOOOOO OOOOOOOOOOO;PPPPPPPPPPPP PPPPPPPPP PPPPPPPPPPPP PPPPPPPPPP;QQQQQQQQQQQQQ QQQQQQQQQ QQQQQQQQQQQQ QQQQQQQQQ;RRRRRRRRRRRRRR RRRRRRRRR RRRRRRRRRRRR RRRRRRRR;SSSSSSSSSSSSSSS SSSSSSSSS SSSSSSSSSSSS SSSSSSS;TTTTTTTTTTTTTTTT TTTTTTTTT TTTTTTTTTTTT TTTTTT</infCpl> </infAdic> -
Boa tarde @Juliomar Marchetti,
Peço desculpas pelo post, foi falha em meus testes. Testei novamente aqui e está imprimindo conforme o seu PDF.
Provavelmente no meu teste anterior eu não me dei conta que a continuação das informações complementares aparecem acima do painel de informações complementares, abaixo dos itens na mesma página. E que após estourar este espaço ele transfere tudo para a outra página.
-
Boa tarde,
Precisei incluir o tratamento para as ocorrências 31 e 38 na unit do HSBC.
- 31-Liquidação normal em Cheque/Compensação/Banco Correspondente
- 38-Liquidação de título não registrado - em dinheiro
Segue em anexo para análise e, se possível, inclusão ao SVN.
-
1
-
Olá,
Percebi que no DANFE em Fortes o campo Informações Complementares está cortando o texto. Antes no Rave, era gerada uma nova página contendo o restante do conteúdo caso atingisse o limite na primeira página.
Existe alguma alternativa neste caso para o Fortes? Alguma propriedade que estou esquecendo?
Obrigado.
-
Boa tarde,
Realizei uma pequena alteração na unit do Santander, pois se DataBaixa não for definida, ela fica com aquela data 30/12/1899. Desta forma, DaysBetween(Vencimento, DataBaixa) retorna toda essa diferença de dias entre 30/12/1899 e a data do vencimento, sendo ainda truncado em 2 dígitos.
Foi tratado para informar zeros '00' caso DataBaixa seja menor que Vencimento.
-
Boa tarde,
Estou passando por uma situação similar.
Poderia informar se a remessa é de 240 ou 400 posições? A qual posição você se refere no arquivo?
-
6 minutos atrás, Cantu disse:
Só pra constar, atualizei minha planilha de forma que não some o FCP no ICMDest, conforme v 1.60 da NT 2015.003:
http://blog.firebase.com.br/preenchimento-do-xml-de-nf-e-referente-a-partilha-do-icms/
Bom dia Cantu, baixei sua planilha novamente, porém continua na versão 1.0, somando o FCP. Confere?
Att,
-
5 minutos atrás, nazarenoneto disse:
Então fica assim???
Total do Produto: 1.000,00BC ICMS: 1.000,00
BC ICMS UF Dest: 1.000,00
É como estou considerando (obviamente incluindo o frete, seguro, desconto, etc).
-
Bom dia pessoal,
Desculpem a pergunta, mas fiquei com uma dúvida de última hora: o campo do ICMS normal (vICMS) não sofre nenhuma alteração, correto?
Eu já havia adotado a forma de cálculo apresentado na planilha do Cantu, mas os últimos os exemplos de cálculo informados aqui me deixaram com esta dúvida.
Att,
Roberto.
-
Boa tarde,
Na revision #10438, somente na unit ACBrNFeDANFeRLRetrato.pas, foi incluída a função AplicaParametros, que basicamente formata as alturas e posições das linhas e painéis de acordo com um valor padrão definido nas propriedades do componente (ex: fAltLinhaComum, etc).
Porém a chamada da função foi inserida no final da função InitDados, resultando na desformatação do quadro de volumes, pois o mesmo tem seu tamanho definido na função Transporte.
Penso que é arriscado reformatar todo o DANFe no final do processo de carregamento (InitDados) pois tudo o que tiver sua altura definida dinamicamente, como é o caso dos volumes, será "resetado".Inicialmente apenas movi a chamada da função AplicaParametros para antes da chamada das funções a seguir:
AplicaParametros; // Aplica os parâmetros escolhidos DadosAdicionais; Header; Emitente; Destinatario; Imposto; Itens; ISSQN; Transporte; AddFaturaReal; AddFatura; Observacoes
-
Boa tarde Italo,
Obrigado pelos esclarecimentos.
-
Na verdade ela está, pois há alguns anos era emitida a NF-e.
Portanto sempre realizamos os testes com o nosso certificado mesmo, em função da facilidade.
-
Bom dia Italo,
Na verdade eu utilizava o certificado da nossa empresa mesmo (A3).
O correto é utilizar um certificado do cliente?
-
Bom dia,
Trabalho em uma Software House e, há algum tempo passei a receber a rejeição 481 - Código Regime Tributário do emitente diverge do cadastro na SEFAZ, em virtude dos testes que realizava. Ou seja, antes eu emitia notas em homologação para testar as CSTs do regime normal bem como do Simples nacional, tudo com o mesmo emitente / certificado.
Neste sentido, visto que estou impossibilitado de realizar os testes como antes, gostaria de saber qual a solução adotada neste caso, se é necessário criar uma nova empresa, ou se é possível apenas comprar algum outro "tipo" de certificado, ou se a empresa precisa incluir alguma nova função junto à contabilidade, ou se é apenas algum parâmetro que deve ser informado de forma diferente, enfim, acredito que não sou só eu com esta dificuldade.. Como vocês estão fazendo para realizar os testes?
Obrigado.
-
Olá Juliana, obrigado pelo retorno.
Na verdade, antes de sair verificando com todos os bancos, eu pensei em perguntar como o pessoal aqui do fórum está tratando este tipo de ocorrência (toRetornoTituloPagoEmCheque): se paga o boleto ou não. Se for permitido, é claro.
Caso o comportamento padrão seja a liquidação e exista esta exceção em alguns bancos, eu iria sugerir a criação de outro tipo de ocorrência para diferenciar, algo como toRetornoTituloPagoEmChequePendente. Mas se o comportamento padrão for o contrário, em que o boleto não deve ser liquidado ainda, eu estava equivocado e já tratei na minha aplicação.
Att.
-
1
-
Para número de convênio de 6 posições (de 10.000 a 999.999), informar o nosso número com
Melhoria Remessa 400 Sicredi: Carnê e Parcelas
em ACBrBoleto
Postado
Boa tarde,
Realizei uma pequena melhoria nas units ACBrBancoSicredi.pas e ACBrBoleto.pas para fins preventivos, uma vez que me deparei com erros de homologação em função disso.
Verifiquei que a propriedade TACBrTitulo.TipoImpressão não é explicitamente inicializada, portanto inicia com o valor tipCarne, em vez de tipNormal. Isso impacta lá na geração da remessa (CNAB 400), pois as propriedades Parcela e TotalParcelas iniciam com zero. Logo, conforme imagem abaixo, Número de Parcelas não deve ser zero se Tipo de Impressão for carnê (B) e deve ser zero (ou em branco) se Tipo de Impressão for normal (A).
ACBrBoleto.pas
ACBrBancoSicredi.pas