Valdir Dill

Bom dia, Atualizei os fontes neste momento (18009). Mas as impressões do código de barras de da chave continuam desalinhados no MDFe. No print anexo dá para verificar. Obrigado.

Bom dia Que é isso @Daniel Simoes...Não tem nada do que se desculpar...vocês são 10!!! Já baixei, testes e está tudo corrigido. Obrigado!

Boa noite, Parece que era mesmo erro no Acbr. A A.V. ocorria na destruição do componente TEF. Baixei o update 17991 agora e está corrigido. Obrigado.

Boa tarde, Fiz a atualização dos fontes agora há pouco e começou a dar erro de access vilolation ao encerrar a minha aplicação. Acredito que deve ser algum componente que é destruído, sei lá. Deve ser algo relacionado com mudanças no Acbr, pois havia testado a aplicação imediatamente antes de fazer a atualização dos fontes e não havia o erro. Talvez até seja algo errado em minhas rotinas e que "antes passava" sem dar erro, mas o fato é que o problema foi disparado por alguma mudança nos fontes do Acbr. Ainda estou fazendo análises para tentar ver o ponto onde a violação acontece, mas se alguém tiver alguma dica para tentar encontrar a causa do erro, agradeço... Obrigado.

Boa tarde, Ao que tudo indica está tudo normal novamente no envio de NFe produtor rural SEFAZ-PA. Depois de 3 dias a SEFAZ-PA insistindo que o problema era no sistema emissor da nota, milagrosamente o problema se resolveu sem nenhuma alteração nossa sistema, hehe! Tópico resolvido! Obrigado.

Existe alguma forma de comprovar para a SEFAZ que o sistema está enviando o XML para o WS correto, ou seja, SVRS? O problema é que a SEFAZ-PA alega que o sistema está enviando para o WS antigo (SVAN). Aí o cliente nos cobra. Até onde verifiquei, isso não fica nada registrado nos XML, ou fica? Obrigado.

Bom dia, KKK...só para descontrair um pouco, relato o que o atendimento da SEFAZ-PA respondeu a um cliente: ligue no telefixo do Sebrae Rio Grande do Sul 51 3211-1562 para falar sobre o erro que esta acontecendo já que eles são responsaveis pelas atualizaçoes... Parece piada, mas não é, confirmei com o cliente e foi isso mesmo que orientaram. Pode? Abraços.

Bom dia, Deixa eu esclarecer um pouco a questão... Na verdade o problema não está ocorrendo a nível nacional. É apenas na SEFAZ-PA e passou a ocorrer a partir de ontem (02/09). Até então era possível emitir NFe com CPF, sem ter CNPJ vinculado e sem problema algum. O que ocorre é que a SEFAZ-PA mudou seus endereços de SVAN para SVRS e, imagino eu, que o novo servidor não está preparado para receber nota cujo certificado é apenas CPF. Estamos tendo o mesmo problema aqui com vários clientes. A SEFAZ-PA alega que é problema no nosso sistema que não atualizou os WS, mas a rotina que envia o XML de NFe de CPF é exatamente a mesma rotina que envia o XML de CNPJ e, NFe de CNPJ está enviando normal, sem nenhum erro. Então, não é no sistema e, com absoluta certeza, o problema é no WS novo deles que não está preparado para NFe vinda de CPF. Enviamos todos os XMLs para eles e estão analisando, mas...é sempre assim, se não têm 100% que o problema é lá, sempre vão dizer que o problema é no sistema emissor, rs.. Abraços...

Bom dia, Nas minhas análises concluí que o acbrValidador está fazendo algo errado ao conferir o prefixo de GTINs. Ao submetermos o código 0606529657802, o Acbr dá como prefixo inválido, mas não é. No portal nacional de notas eletrônicas, menu "Documentos -> Diversos -> Tabela Prefixo GS1" temos uma planilha com a listagem dos prefixos válidos, bem como uma planilha que demonstra como se extrai o prefixo de um código. Texto copiado da planilha/norma Como Identificar o "Prefixo GS1" O GTIN pode possuir 8, 12, 13 ou 14 algarismos, e segue abaixo uma forma prática de identificar o "Prefixo GS1": - Normalizar o tamanho do campo em 14 posições numéricas, com zeros não significativos; - Se primeiras 6 posições = Zeros ==> GTIN-8 -Prefixo GS1: posições 7 a 9 do GTIN normalizado; - Se primeiras 6 posições <> Zeros -Prefixo GS1: posições 2 a 4 do GTIN normalizado; Geração do prefixo segundo normas acima: - GTIN normlizado: 00606529657802 - posições 2 a 4 do GTIN normalizado: 060 -> prefixo válido Já o AcbrValidador gera um prefixo = 606 e, nesse caso seria um prefixo inválido. Mas esse cálculo do Acbr está incorreto, na minha opinião. Sugestão para correção (.pas corrigida em anexo) Trocar a rotina: if (StrToInt(Copy(CodigoNormalizado, 1, 6)) = 0) then //gtin8 sPrefixo := copy(CodigoNormalizado, 7, 3) else if StrToInt(Copy(CodigoNormalizado, 1, 2)) = 0 then //gtin12 sPrefixo := copy(CodigoNormalizado, 3, 3) else sPrefixo := copy(CodigoNormalizado, 2, 3); Por esta: if (StrToInt(Copy(CodigoNormalizado, 1, 6)) = 0) then //gtin8 sPrefixo := copy(CodigoNormalizado, 7, 3) else sPrefixo := copy(CodigoNormalizado, 2, 3); Obrigado ACBrValidador.pas

Bom dia, Certo, vou tentar aplicar as sugestões e "fuçar" mais. Se descobrir a causa posto aqui. Obrigado!

Não tem. Apenas 1 Não.

Boa tarde, Sim, opção "Copiar Todas as DLL's (CLX, ..." marcada. É um chute, mas eu imagino que talvez fique algum rastro da instalação anterior e que conflite com a nova instalação, pois se eu criar uma nova pasta, baixar os fontes e executar a instalação aí o problema não acontece. Mas se, logo em seguida eu executar o procedimento de instalação novamente, ao entrar no Delphi, dá o erro. Obrigado.

Bom dia, Já faz algum tempo que estou com o problema que vou relatar. Sempre deixei para lá, mas agora gostaria de resolver e ver o que causa isso É o seguinte: toda vez que executo ACBrInstall_Trunk2.exe para reinstalar o Acbr, ele instala beleza, mas quando vou entrar no Delphi ocorre o erro de que não encontra alguns .bpl (print anexo). No total são 11 pacotes que ele diz que não encontra o .bpl. Mas se for lá nessa pasta, o .bpl está lá. Já tentei primeiro executar o apagarAcbr.exe, criar uma nova pasta do Acbr, instalar o Acbr com a opção de apagar os arquivos antigos, ...nada adiantou Inclusive verifiquei outros tópicos aqui no fórum com relato desse erro e orientações de solução, as quais apliquei, mas não resolveu. A única forma que consigo resolver é acessar o Delphi, eliminar todos os libraryPaths do Acbr, exelcuir todos os .bpl pelo menu "component - installPackger=" e depois baixar os fontes do Acbr novamente e fazer a instalaçao completa. Alguma sugestão? Obrigado.

Putz, passamos batidos nessa, hehe! Obrigado @BigWings. Pode fechar o tópico. Abraços.

Bom dia, Estamos tendo problema de rejeição em cancelamento de NFCe. Até o momento ocorreram dois casos nas UFs PE e BA. A rejeição: "Rejeicao 501: Prazo de Cancelamento Superior ao Previsto na Legislacao". A questão é que as tentativas de cancelamentos foram feitas, uma 40 minutos depois do envio, e a outra 4 horas depois do envio, ou seja, dentro do prazo de 24 horas. Temos notícias que a SEFAZ-MS estaria mudando o prazo de cancelamento para 30 minutos. Mas essas duas UFs (PE e BA), até onde sabemos ainda é 24 horas. Alguma sugestão do que pode estar causando essa rejeição? Obrigado.

Boa noite, A tua alteração funcionou, mas a property Tecla é do tipo integer. Então precisa mudar de: if (Produtos.Setor.Descricao <> '') or (Produtos.Tecla <> '') then Para: if (Produtos.Setor.Descricao <> '') or (Produtos.Tecla > 0) then Teste e está funcionando corretamente, ou seja, gerando apenas o CADTXT Obrigado.

Bom dia, Não entendia sua paergunta @BigWings O que ocorre é que quero gerar apenas o arquivo CADTXT.TT, mas não gerar o SETORTXT.txt. Por isso informo os dados do produto, sem informar nada dos dados do setor. Imagino que fazendo dessa forma, ou seja, não informando dados do setor, não deveria gerar o SETORTXT.txt. Por isso fiz essa sugestão. Obrigado.

Bom dia, A função procedure TACBrCargaBal.PreencherFilizola(Arquivo, Setor, Nutricional, Receita: TStringList) da ACBrCargaBal.pas está alimentando a lista de setor mesmo se não tiver sido informado setor. Sugiro alterar essa procedure (PreencherFilizola) na ACBrCargaBal.pas De: Setor.Add( RFill(Produtos.Setor.Descricao, 12) + LFIll(Produtos.Codigo, 6) + LFIll(i + 1, 4) + LFill(Produtos.Tecla, 3) ); Para: if Produtos.Setor.Descricao <> '' then Setor.Add( RFill(Produtos.Setor.Descricao, 12) + LFIll(Produtos.Codigo, 6) + LFIll(i + 1, 4) + LFill(Produtos.Tecla, 3) ); Envio unit já alterada, em anexo. Obrigado. ACBrCargaBal.pas

Bom dia, Estamos tendo a rejeição "Nota(s) não confirmadas: 189->245-Rejeicao: CNPJ/CPF Emitente nao cadastrado" na SEFZ-PA. É produtor rural, ou seja, nota com CPF. Pelo texto da rejeição está claro que o problema seria o CPF do emitente lá na SEFAZ. Mas, segundo o cliente, a SEFAZ alega que está tudo certo lá com o CPF dele e também com o sistema de recepção de notas. O curioso é que esse cliente já emitia notas normalmente com CPF. De repente começou a retornar o erro. Alguma sugestão do que pode ser a causa? Em anexo o XML de retorno e também o XML da nota com tentativa de envio. Obrigado 154000422445591-pro-rec.xml 15190400051778653200559200000001891939436018-nfe.xml

Sim, isso eu entendi. A questão é que esse não é o padrão. Todos os demais bancos (pelo menos que já analisamos) trazem o valor da tarifa na mesma linha da baixa. E pior, tenho que ter uma rotina diferente para esse banco. Mas beleza. Vamos analisar. Obrigado.

Bom dia, Em anexo. Obrigado. 96632404.CRT Bom dia, Sim, analisei. Os dados do arquivo estão dispostos nas colunas corretas, conforme prevê o manual. O problema é que na linha da liquidação (ocorrencia 06), não tem o valor da tarifa. Esse valor vai ter apenas na linha 2 (ocorrencia 28). Mas no manual não fala nada sobre uma ou duas linhas. Obrigado.

bom dia, Estou analisando o tratamento do arquivo de retorno Sicredi Minhas rotinas estão assim: - ACBrBoleto1.LerRetorno(); - for I := 0 to ACBrBoleto1.ListadeBoletos.Count - 1 do begin if ACBrBoleto1.ListadeBoletos.Objects.OcorrenciaOriginal.Tipo = toRetornoLiquidado then begin BoletoPago := true; ValorTarifa := ACBrBoleto1.ListadeBoletos.Objects.ValorDespesaCobranca; ... end; end; Essa rotina funciona muito bem para quase todos os bancos. Mas, na cobrança cnab400 Sicredi estou tendo problema porque, ao que parece, o Sicredi retorna cada boleto em duas linhas. Uma para os dados da baixa em si (ocorrencia 06) e outra linha para trazer a tarifa (ocorrencia 28). Nesse caso eu teria que fazer mais um laço para ver a tarifa? if ACBrBoleto1.ListadeBoletos.Objects.OcorrenciaOriginal.Tipo = toRetornoDebitoTarifas then begin ValorTarifa := ACBrBoleto1.ListadeBoletos.Objects.ValorDespesaCobranca; end; Ou haveria uma opção melhor para tratar isso? Outra coisa, tem como saber quais bancos fazem dessa forma, ou seja, trazem o valor da tarifa numa linha separada no arquivo retorno? Obrigado.

Bom dia, Certo. Esclarecido. Obrigado.

Bom dia, Na geração de .pdf do danfe (com Fortes Report) estou com um usuário tendo erro: 'EFCreateError(Cannot create file C:\users\...\tmp\~fr16...tmp...'. Pelo que analisei é algum problema de permissão do usuário (do Windows) em gravar arquivos nessa pasta. Analisando ainda mais a fundo, constatei que o Fortes busca esse path para salvar os arquivos temporário que gera e guarda o valor na @var TempDir da RLUtils.pas. Sim, o ideal é que o operador do Windows ter permissão para essa pasta \Temp do sistema operacional. Mas, caso queiramos definir o path da TempDir, há alguma possbilidade que o Fortes permita setá-la dinamicamente? Obrigado.

Certo, entendi Italo. Eu envio uma única NFCe em cada lote. Aí trato o retorno. Se houver autorização, também pego o protocolo (...procNFe.nProt). Pelo que entendi, no caso da NFCe o protocolo retornado pela SEFAZ não serve para nada, pelo menos não para se fazer uma consulta a posteriore. Se, por exemplo, por uma situação qualquer não tivermos a chave da nota, mas tivermos o protocolo dela, isso não adiantaria nada, pois não temos como consultar pelo protocolo, estou certo? Obrigadgo.