Ir para conteúdo
  • Cadastre-se

ubaltino

Membros
  • Total de ítens

    62
  • Registro em

  • Última visita

Tudo que ubaltino postou

  1. Boa noite. Vou tentar explicar diferente. A agência é 1970 e Dv 0. A conta é 0008541 Dv 7. No componente como esta, ele monta como 01970000085417. Para ficar com 14 dígitos, inclui um zero a esquerda. E o banco solicitou que fosse preenchido com 19700000085717. Também com 14 dígitos. Ou seja, seria muito mais claro se isso fosse dois campos separados. Evitaria essa confusão. Então para mim, apesar que no manual esta Agencia + Conta, na prática para eles é CodigoCedente, apenas um campo que pode ser formatado como eles pedirem.
  2. Bom dia. Conforme conversa ontem com José Junior, um cliente que já estava em produção com Banco Safra a mais de ano, após atualização do componente, o banco passou a reclamar do Header 400 e Trailler 400 na parte da conta + agencia. No manual, item 6.1 consta que é agencia + conta com 14 dígitos. Se informarmos no componente agencia com 4 dígitos + DV e conta com 7 Dígitos + DV isso totalizam 13 dígitos. E são necessários 14 dígitos. Nesse caso o componente esta preenchendo com ZERO a esquerda, para completar 14 dígitos. Motivo pelo qual o banco acionou nosso cliente. No componente, existe a propriedade CodigoCedente, que usamos com esses 14 dígitos, conforme o banco solicita no manual. Fiz essa alteração na Unit, que esta em anexo para avaliação e manual também, que o banco enviou hoje. Outra opção seria informar a conta com 8 dígitos + DV para o componente. Não tive tempo para testar isso. Já olhei vários tópicos aqui e sei que esse Banco é complicado. Então fica as duas sugestões aqui. Obrigado. ACBrBancoSafra.pas Layout Cobrança atualizado.pdf
  3. Aqui esta funcionando normal hoje. De GO para MG e para DF. Tava olhando seu XML de envio. Claro que seu seguimento é diferente do meu. Mas vi que no seu XML não tem a TAG PRODUTO. tipo "<c26_produto>8</c26_produto>". Não sei se pode ser isso.
  4. Acho que a versão 2.00 ainda não esta funcionando em nenhum estado. Vejam em http://www.gnre.pe.gov.br/gnre/portal/consultarTabelas.jsp
  5. Você atualizou hoje, após as 12h? Porque essa correção no ACBR foi comitada hoje pelo Italo. As linhas 111 e 112 da unit pgnreGNREW.pas, deve estar como abaixo 111 // Gerador.wGrupo('TDadosGNRE versao="1.00"'); 112 Gerador.wGrupo('TDadosGNRE'); E olhando o XML de envio, o seu esta errado <TDadosGNRE versao="2.00"> deveria estar <TDadosGNRE> Mude para a versão 1.00. Acho que ainda não tem nenhum estado funcionando na 2.00.
  6. Só para constar. Com essa atualização de agora, problema resolvido. Ou seja, a correção removeu "versao 1.0" do TDadosGNRE. Isso fez funcionou. Obrigado Italo e Marcelo.
  7. Ok. Farei o que o senhores recomendam e postarei o resultado aqui. Obrigado.
  8. Segue os XMLs. Obrigado pela atenção. 20190508103306-rec.xml 20190508103306-env-lot.xml
  9. ubaltino

    Erro no Envio para MG e DF

    Bom dia. Estou usando a versão 1.00. Atualizei o componente na 06/05/2019. Agora esta ocorrendo o erro abaixo: "cvc-complex-type.3.2.2: Attribute 'versao' is not allowed to appear in element 'TDadosGNRE'" Consultando o portal da GNRE online, acusa que todos os estados estão funcionando na versão 1.00. Alguém tem alguma sugestão sobre como solucionar isso? Obrigado.
  10. Obrigado pessoal pelos esclarecimentos. Aqui em Goiás, não sei se outras regiões passaram pelo mesmo, mas desde inicio dos anos 2.000, o governo colocou algumas empresas do seguimento de distribuição de combustíveis em regime especial. Na época elas eram obrigadas a emitir guias e fazer os pagamentos, principalmente do ST, para só depois o caminhão pode ser carregado. Em cada base, foi colocado um fiscal, para cumprir essa ordem. Como ninguém deu o grito, isso é praxe até hoje. Ou seja, toda base tem um fiscal, que fiscaliza todo o movimento em uma base. Tanto de entrada como de saída. Verifica os carregamentos, etc. Os fiscais que estão reclamando acima, são esses. Não são fiscais de barreiras. De qualquer forma, já encaminhei essa posição para os clientes, e vamos que vamos né. Aguardar mais o que o governo inventa, para o lado do contribuinte. Minhas dúvidas foram esclarecidas. Obrigado.
  11. Obrigado pela resposta. "Uma pergunta: Está sendo emitido o MDFe com os dados dos veículos e vinculado a NFe?" Não sei te responder quanto ao MDFe. Acredito que alguns sim e outros não. Por não ser obrigatório. Mas o CTe com certeza sim, porque em GO é obrigatório para fora do estado. Outro detalhe que muito não fazem o MDFe, é porque é combustível. Muitas vezes, uma NFe completa um caminhão. "Se mesmo com o MDFe estão exigindo os dados dos veículos na NFe, a única solução seria informar nas informações complementares da nota." Isto já esta sendo feito desde o inicio da NFe 4.00. Exigência dos ficais. Inclusive com a UF da placa. Pelo que estou entendendo, existe um desentendimento geral entre fiscais e a documentação que rege a NFe. Ou talvez o sistema que os fiscais estão usando em GO, esta causando um transtorno pra eles em relação a essa regra. E adivinha quem leva a culpa?
  12. Bom dia a todos. Esse erro 868 já conheço. E claro, nas notas para vendas fora do estado, não estou colocando a placa, para evitar essa rejeição. Acontece que essa semana, vários fiscais "ameaçaram", inclusive por e-mail, informando que não iam mai autorizar Danfe e XML de nota sem a placa. Isso está gerando um desgaste entre meus clientes e os ficais. E claro, um desgaste meu com o clientes. Já li esse topico todo Curiosamente, no final desse tópico, informa que conseguiu incluir a placa mesmo para nota fora do estado. Mas o tópico foi fechado logo em seguida. Pergunta: É possível incluir placas para notas interestaduais? Se sim, como? Estado = GO. Obrigado a quem puder esclarecer.
  13. Estou tendo esse mesmo erro em GO. Ambiente de Produção. Já solicitei a emissão no mesmo link acima. Recebi a confirmação que esta aprovado. Mas uma simples consulta da UF não consigo fazer. Alguém passou por isso: Detalhes do Erro: Erro Interno: 10091 Erro HTTP: 500
  14. Ok. Tudo bem. Eu não afirmei que era a causa. Disse "talvez". Mas e a questão do erro de conversão? No momento que pega a resposta de uma NFe Inutilizada usando o Delphi Seatlle? Será que é só eu que estou passando por isso?
  15. Boa tarde. Estou vendo que resolveram estender o suporte ao Delphi 7 por mais tempo. "Talvez" isto tenha a ver com esta alteração. Na unit PcnRetinutNFe na function TRetInutNFe.LerXml: Boolean; existe a linha 140 (*DR08 *)FxMotivo := Leitor.rCampo(tcStr, 'xMotivo'); FxMotivo é tipo String; e Leitor.rCampo retorna uma Variant. E ai, se o campo for tipo String, faz uma chamada em assim: tcStr : result := ReverterFiltroTextoXML(ConteudoTag); Mas ReverterFiltroTextoXML retorna um AnsiString; Dai no Delphi Seatlle o Motivo fica com erros de acentuação. Tudo bem que não é nada crítico, mas fica parecendo que somos incompetentes né. Eu acho alterando ReverterFiltroTextoXML para retornar String resolve isso.
  16. Boa tarde. O Banco solicitou que fosse preenchido com zeros as posições 210 a 212 no segmento Q. A alteração esta em anexo. Mais alguém passou por isso? ACBrBancoCaixa.pas
  17. Boa tarde. Eu tive que fazer a alteração que esta em anexo para resolver isso. Onde alterei consta meu nome comentado. ACBrBoletoFCFortesFr.pas
  18. Boa tarde Juliana. Obrigado. Quero parabenizar pelo ótimo trabalho. Baixei agora, e vi as alterações. Entretanto, ontem consegui homologar o Banco Safra, mas tive que fazer mais algumas alterações. O arquivo esta em anexo. Onde alterei cosnta meu nome comentado. A principal alteração que fiz foi no tamanho máximo do nosso número. Que estava 9 e mudei para 8. Porque na impressão do boleto, o calculo do Dv do Nosso Número esta separado. Então considerei que essa regra serve para todos os bancos do componente. Edit. Estava esquecendo. O banco pisou firme. Tive que alterar o Logo. É Mole? Esta em anexo. ACBrBancoSafra.pas 422.bmp
  19. Boa noite. Estou passando o mesmo problema com o Banco Safra. Reclamou disso.
  20. Bom dia Juliana. Se postar a correção, favor avisar quando estiver no SVN. Obrigado.
  21. Boa noite. Anexada. ACBrBancoSafra.pas
  22. Boa tarde. Na unit ACBrBancoSafra tive que fazer duas correções. Linha 398 mudei de: ACBrBoleto.Cedente.CNPJCPF + para: PadLeft(OnlyNumber(ACBrBoleto.Cedente.CNPJCPF), 14, '0') + Porque o CNPJ esta indo formatado para o Arquivo Remessa. E na linha 408 mudei de: '' + para: '0' + Porque a linha detalhe do remessa estava com 399 caracteres. Pelo que notei o erro parece ser essa posição. Ou será que estou enganado?
  23. Italo, Obrigado pelos esclarecimentos. Muito boa a observação do SEFAZ-RS. Mencionei isto porque com a NFe é da mesma forma. Se fizermos NFe em Homologação para um emissor que já esta em produção, a SEFAZ-GO sempre retorna isto. Já SEFAZ-SP isto não acontece. Acredito que deve existir um nível de integração entre as SEFAZ. Vamos colocar em produção breve. Posto aqui os resultados.
  24. Bom dia Italo. Acho que deu certo aqui. o "Acho" é porque estou fazendo testes em Homologação, e a SEFAZ do GO é ótima neste aspecto. Olha a resposta: <retConsReciMDFe versao="1.00" xmlns="http://www.portalfiscal.inf.br/mdfe"> <tpAmb>2</tpAmb> <verAplic>RS20150302092652</verAplic> <nRec>529000001498546</nRec> <cStat>104</cStat> <xMotivo>Arquivo processado</xMotivo> <cUF>52</cUF> <protMDFe versao="1.00"> <infProt Id="MDFe080320151005274210"> <tpAmb>2</tpAmb> <verAplic>RS20150302092652</verAplic> <chMDFe>52150302284585000810580010000000071000000011</chMDFe> <dhRecbto>2015-03-08T10:05:27</dhRecbto> <digVal>zxAL0I293koRNasQVtTqqIZnmik=</digVal> <cStat>203</cStat> <xMotivo>Rejeição: Emissor nao habilitado para emissao do MDF-e</xMotivo> </infProt> </protMDFe> </retConsReciMDFe> Este emissor esta emitindo em produção pelo Software Gratuito ah algum tempo. Só para esclarecer o motivo do erro que estava tendo, vai uma dica. Estava pegando a resposta pela chave. Passei a pegar pelo Recibo para saber mais detalhes. Isto ajudou muito. Agora ficou uma dúvida. Já olhei no manual e não foi esclarecida. Não sei se seria melhor criar um tópico para isto. Se deu erro no envio por algum motivo, e como não existe inutilização, qual o procedimento que os senhores estão adotando? Obrigado.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.