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,
Ao atualiza o ACBr passou a ocorrer um problema ao ler o arquivo de retorno do banco Sicoob 240, pois não está identificando a conta bancária se a mesma possuir mais que 7 dígitos.
Verifiquei e isso se deve à linha 504 do arquivo ACBrBancoBancoob.pas, conforme abaixo:
Cedente.Conta := PadLeft(IntToStr(StrToIntDef(Cedente.Conta,0)), 7, '0');
Aqui está sendo truncando o número da conta em 7 dígitos e no meu caso a conta possui 8 (sem o dígito verificado).
Antes esta linha não estava causando problemas pois ela estava mais no início do código.Portanto, no meu caso apenas alterei de 7 para 10 no PadLeft (acima de 10 ocorre exception).
Cedente.Conta := PadLeft(IntToStr(StrToIntDef(Cedente.Conta,0)), 10, '0');
Na verdade não sei se essa linha é realmente necessária, pois pelo que entendi o objetivo dela seria apenas remover os zeros á esquerda.
Fonte em anexo.
-
1
-
-
Olá José, obrigado pelo retorno.
Pelo que verifiquei as correções estão OK.
Novamente obrigado.
-
Olá José, obrigado pelo retorno.
Pelo que verifiquei as correções estão OK.
Novamente obrigado.
-
Boa tarde, alguma posição sobre as correções?
-
Boa tarde, alguma posição sobre as correções?
-
Em 15/03/2018 at 12:59, José M. S. Junior disse:
Boa tarde, será atualizado com as correções. Obrigado!
Olá José,
Por gentileza, existe alguma previsão para estas alterações serem avaliadas e "comitadas"?
Pergunto apenas para me agendar aqui.Obrigado.
-
Em 16/03/2018 at 08:19, José M. S. Junior disse:
Bom dia,
Como sabemos, boa parte da implementação das Units de Bancos são contribuições de diversas pessoas e nesses pontos realmente não seguem um padrão, muitas vezes também por que o layout dos bancos também não seguem um padrão...
Nestes casos acima também acho que está correto o ajuste. Vamos considerar a analise para os devidos ajustes. Obrigado.
Olá José,
Por gentileza, existe alguma previsão para estas alterações serem avaliadas e "comitadas"?
Pergunto apenas para me agendar aqui.Obrigado.
-
-
Olá pessoal,
Por gentileza, alguém consegue me explicar o motivo do seguinte código abaixo estar presente nas units do ACBrBoleto? (ACBrBancoAmazonia, ACBrBancoBradesco, ACBrBancoBrasil, ACBrBancoCaixa, ACBrBancoHSBC, ACBrUniprime)
// Quando o numero documento vier em branco if Trim(NumeroDocumento) = '' then NumeroDocumento := NossoNumero;
ou
// prevenir quando o seunumero não vem informado no arquivo, altera para NossoNumero do banco wSeuNumero := StringReplace(SeuNumero, '0','',[rfReplaceAll]); if (AnsiSameText(wSeuNumero, EmptyStr)) then begin SeuNumero := NossoNumero; NumeroDocumento := NossoNumero end;
Isso é alguma prática definida nos manuais?
Toda vez eu tenho que remover estes trechos de código dos fontes porque, no meu ponto de vista, não tem sentido.
São dois campos diferentes: NossoNumero é uma numeração do banco, que pode ser diferente de NumeroDocumento, o qual corresponde a uma numeração interna da empresa, justamente para ser controlada pelo ERP do jeito que cada empresa quiser.Minha sugestão é que cada um controle NumeroDocumento e SeuNumero em seu próprio ERP do jeito que preferir, quem quiser igualar o NumeroDocumento ao NossoNumero, que faça em seus próprios fontes.
Do jeito que está agora, este tratamento está sendo imposto, mascarando o valor real que vem no arquivo de retorno.
Sem falar que está sendo implementado em apenas algumas units. Ou seja, nem é uma prática padrão.Fontes em anexo.
PS: Na unit ACBrbancoBrasil, aproveitei e substituí DataMoraJuros por DataMulta na função GerarRegistroTransacao400 (na função GerarRegistroTransacao240 já estava correto).
PS: Estão indo junto as alterações que enviei no tópico Correção na Comparação de Datas (TDatetime) com Null pois ainda não foram comitadas.Concordam?
-
1
-
-
Olá, aproveitei que atualizei meus fontes para repassar essas correções.
Ainda existiam algumas comparações de TDateTime com Null, como por exemplo:
if Data <> Null then
Esta condição sempre será verdadeira pois TDateTime é float e não pode nem receber Null.
Portanto, alterei as comparações para:if Data > 0 then
Fontes em anexo.
-
3
-
-
Bom dia,
Eu também estava com este problema e, lendo este tópico, resolvi assinando a nota antes de validar (antes apenas gerava, validava e transmitia).
Contudo ficou uma dúvida: antes de saber desta solução, para testar as possibilidades eu apenas removi a chamada ao método Validar e fui direto para a transmissão da nota e transmitiu normal.
Isso confere? -
Obrigado André! Vou acompanhar e responder por lá então.
-
Boa tarde,
Atualizei o ACBr hoje e passou a ocorrer erro na validação da NF-e (ainda no layout 3.10), mais precisamente na chamada da função ACBrNFe1.NotasFiscais.Validar:
CitarFalha na validação dos dados da nota: 9011
Não foi possível carregar o arquivo.
Err: -1072896763, Lin: 1, Pos: 11 - A name contained an invalid character.Eu estava com o código desatualizado há um bom tempo, portanto além de atualizar e reinstalar todo o ACBr, atualizei os arquivos da pasta Schemas.
E utilizo Capicom ainda.Será que falta atualizar alguma coisa?
-
Olá,
Segue em anexo logo do Santander atualizado em preto e branco.
Foi rejeitado no processo de homologação com o atual, que inclusive não corresponde à imagem do logo colorido.
Obrigado.
-
18 horas atrás, Juliomar Marchetti disse:
o Banco não irá aceitar e rejeitará todos os boletos seus.
Você se refere ao processo de homologação, certo? Ou o próprio caixa do banco iria recusar?
Digo porque na prática homologamos o layout padrão e o arquivo de remessa. -
Boa tarde pessoal,
Um cliente está me questionando sobre imprimir boleto diretamente em impressora portátil de 80mm, acredito que sejam essas impressoras Leopardo A7.
Testei os layouts disponíveis no ACBrBoleto e não obtive sucesso.
Esta necessidade já ocorreu por aqui? Existe alguma alternativa atualmente através do ACBr (utilizo a impressão do Fortes)?Pesquisando aqui no fórum vi que em outro post a pessoa adaptou o relatório em Fast, porém foi questionado se o layout é homologado e se respeita tamanhos mínimos exigidos.
Neste caso, desculpe pela pergunta, mas o qual seria o problema em utilizar um layout com tamanho não homologado? -
Obrigado a todos pelas orientações!
-
Em 27/10/2017 at 18:53, BigWings disse:
Creio não ser possível, você deve ter rejeição de duplicidade de NFe em uma delas. Caso faça a consulta do protocolo após esse erro é possível que o XML seja atualizado com o protocolo incorreto, entretanto.
Marcar a configuração "ValidarDigest" do componente impede que um XML seja atualizado com um protocolo de outro XML após a consulta.
Bom dia, obrigado pela dica @BigWings, eu não conhecia esta propriedade. Se não houver alguma contra indicação, vou deixar ela sempre marcada.
Em 28/10/2017 at 10:05, Kiko Fernandes disse:Bom dia!
Este controle terá que ser feito pelo teu sistema.
Vou sugerir duas formas que vc poderá usar para controlar isto:
1 - Só gerar o número da nota após o operador clicar no botão enviar.
- Neste caso o operador não sabe que número de nota está gerando, até o momento em que clica no botão enviar.
- Ao clicar no botão enviar, você gera o número da nota e já muda a sequencia de forma que o outro terminal pegaria o próximo numero.
- Após isto fica gravado no teu banco de dados a informação da nota. (Caso ela não seja transmitido, dê um problema e se desista dela, você terá que mostrar o controle de notas não transmitida e dar a opção para o usuário usar este número novamente ou inutilizar o número se outros terminais já avançaram na emissão de outras notas)
- O contra deste processo é que algumas empresas necessitam informar a numeração da nota em campos de observação (dados adicionais) e como isto deve ser feito antes de enviar a nota, este procedimento dificultaria para o operador que ainda não saberia que número de nota ele tem.2 - Ao iniciar a nota gerar o número.
- Desta forma ao abrir o formulário da emissão da nota, vc pode gerar o número para este terminal e se o outro terminal clicar no formulário de emissão também já receberá o próximo número.
- Da mesma forma que o anterior, vc terá que controlar as notas que foram transmitidas e as que ficaram pendentes de transmissão, caso tenha ocorrido algum problema.
- A vantagem desta é que ao iniciar o form de emissão o operador já saberá o número da nota, porém se desistir dela tem que se ter os cuidados necessários.Já para NFCe com vários terminais emitindo o sugerido é que cada terminal siga uma sequência dentro do seu controle serial.
Exemplo:
Terminal 1 - Serie 1
Terminal 2 - Serie 2Obrigado pelas orientações @Kiko Fernandes! Vou tentar seguir estas práticas.
Só pra vocês entenderem o que ocorreu: o computador A e B transmitiram "ao mesmo tempo", a nota do computador A autorizou, mas o retorno foi recebido pelo computador B. Por consequência, a nota do computador B salvou e o computador A recebeu o retorno de duplicidade (que deveria ser do computador B). Foi um caso isolado, mas deu um bom trabalho pra corrigira situação.
Além das boas práticas sugeridas acima, vocês acham que se a a propriedade "ValidarDigest" estivesse marcada, este caso teria sido evitado?
-
Boa tarde,
Supondo que dois computadores da mesma empresa tentem transmitir uma NF-e ao mesmo tempo (duas notas diferentes, e em virtude disso a chave de acesso gerada seja a mesma entre os dois, existe a possibilidade de um computador obter o retorno do outro computador e vice versa?
Se sim, existe alguma maneira de prevenir esta situação, algum código, protocolo que possa ser validado?
Obrigado.
-
Olá, verifiquei que na revision 12732, de 26/12/2016, foi incluída a seguinte linha na unit do banco Santander, na função LerRetorno240:
Vencimento := StrToDateDef(Copy(Linha, 70, 8), 0);Contudo, este código não deve obter a data corretamente pois o valor extraído vem sem as barras "/".
Neste sentido sugiro o seguinte código:
Vencimento := StringToDateTimeDef(Copy(Linha, 70, 2)+'/'+ Copy(Linha, 72, 2)+'/'+ Copy(Linha, 74, 4), 0, 'dd/mm/yyyy' );PS: Não estou anexando o fonte pois tenho alterações aqui no arquivo local.
-
Em 30/06/2016 at 10:04, K2 SOFTWARE disse:
Bom dia Régys.
Vou fazer uns testes e qualquer coisa te falo.
Obrigado.
Boa tarde, deu certo dessa forma?
@Régys Silveira, somente informando estes 3 campos não irá rejeitar? Mesmo sem partilha?
Estou com um caso similar, em que a contabilidade de um cliente exige que, independente de ter partilha, o FCP deve ser declarado na nota, porém eu só conheço o campo Det.Imposto.ICMSUFDest.vFCPUFDest.
Saberia me informar se já existe outro campo para informar o FCP separado do grupo da partilha?Obrigado.
-
Olá Juliana,
Entendo. Foi hoje para homologação, estou aguardando o resultado.
-
Bom dia,
Fiz um pequeno ajuste na remessa 240 do Santander, pois obtive rejeição em processo de homologação.
Caso Valor Mora Juros for maior que zero, Data Mora Juros não pode ser '00000000'. Portanto, neste caso defini a data do vencimento.
O que acham?
-
Bom dia,
No campo Data da Multa (segmento R), a fim de evitar a data 30/12/1899 no arquivo de remessa, fiz um pequeno ajuste para aparecer '00000000' no lugar.
Utilizei a mesma variável utilizada na Data de Mora Juros (segmento P), pois pelo que venho acompanhando Data da Multa e Data de Mora Juros são consideradas a mesma. Correto?-
1
-
Possível correção na identificação dos campos vBCFCP, pFCP e vFCP
em NFe/NFCe - Nota Fiscal Eletrônica
Postado
Bom dia,
Um cliente me questionou por que o campo vBCFCP não estava sendo informado nas notas fiscais.
Analisando a Nota Técnica 2016.002, na página 23, verifiquei que o campo vBCFCP não está presente somente na CST 00, que era o caso dele. Já nas demais CSTs, este campo aparece.
Dúvida resolvida.
Contudo, durante minha investigação eu acabei parando nos fontes do ACBr e identifiquei uma possível correção no carquivo ACBr\Fontes\ACBrDFe\ACBrNFe\PCNNFe\pcnNFeW, que coloquei em anexo.
Só não soube explicar se isso está tendo algum efeito, pois se estivesse, já teria sido detectado.
Enfim, segue para análise.
pcnNFeW.pas