Valdir Dill

Bom dia, Fontes atualizados, testados e tudo funcionando. Show. Obrigado!

41191013971229000115550010000000841244429685-nfe.xml

Mudei para fpLimiteCaracteresLinha := 95; Verifiquei que nas rotinas ele copia 95 caracteres, mas na impressão isso não muda. Creio que tenha alguma coisa a ver com o TRLMemo lá no relatório.

Boa noite, Na impressão das informações adicionais, ao que parece, o Acbr está com alguma coisa errada no alinhamento. do texto. Notem que no print anexo, onde destaco a última linha, o texto "17/2015" que é jogado para a linha seguinte, teria espaço de sobra para imprimir na linha anterior. Isso por si só não seria um grande problema. Mas ocorre que esse espaço em branco que poderia ser utilizado, dependendo da nota, acaba gerando uma segunda página do Danfe desnecessariamente. Obs.: Não há nenhum um enter ou ";" após o "nacional n°". Imagino que a causa possa ser o tamanho do memo que abriga esse campo no Danfe seja menor do que o quadro físico no Danfe. Ou qual poderia ser a causa disso? Obrigado.

Boa tarde, Corrigido na 18034. Obrigado.

Boa tarde, É só você localizar esse arquivo novo na pasta dos fontes e adicionar esse path no library do Delphi. Abraços.

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