Painel de líderes

corrigido depois de tentar diversas vezes calibrar o sensor limpei o mesmo e calibrei e funcionou perfeitamente desde ja grato a todos obs : solução calibrar o sensor desligando a impressora apertando botão de feed e ligando esperando ela calibrar

Cross Compile de Linux para Win64 Acessar pasta dos fontes do FPC cd /usr/share/fpcsrc/3.0.4 Compilar FPC em Win64 (em modo "root") make all OS_TARGET=win64 CPU_TARGET=x86_64 Instalar novas DCUs e Compilador no Linux (em modo "root") make crossinstall OS_TARGET=win64 CPU_TARGET=x86_64 INSTALL_PREFIX=/usr Editar /etc/fpc.cfg (em modo "root") Incluir antes da sessão "Linking" a linha -Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/* Criar Link Simbólico para o compilador Win64 em /usr/bin (em modo "root") ln -s /usr/lib/fpc/3.0.4/ppcrossx64 /usr/bin/ppcrossx64 Configure o seu projeto, criando um novo Build Mode (em modo normal) Acesse Project Options -> Compiler Options -> Config and Target Target OS -> Win64 Target CPU -> x86_64

Cross Compile de Linux para Win32 Baixe o Lazarus do Site oficial: https://www.lazarus-ide.org/ Exemplo de arquivos a serem baixados: lazarus-2.0.2-0.x86_64.rpm, fpc-3.0.4-1.x86_64.rpm, fpc-src-3.0.4-1.x86_64.rpm Instalar FPC e FPCSRC (em modo "root") rpm -U fpc* Instalar Lazarus (em modo "root") rpm -U lazarus* Testar a instalação do Lazarus (em modo normal) startlazarus Feche o Lazarus e acesse a pasta dos fontes do FPC cd /usr/share/fpcsrc/3.0.4 Compilar FPC em Win32 (em modo "root") make all OS_TARGET=win32 CPU_TARGET=i386 Instalar novas DCUs e Compilador no Linux (em modo "root") make crossinstall OS_TARGET=win32 CPU_TARGET=i386 INSTALL_PREFIX=/usr Editar /etc/fpc.cfg (em modo "root") Incluir antes da sessão "Linking" a linha -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/* Criar Link Simbólico para o compilador Win32 em /usr/bin (em modo "root") ln -s /usr/lib/fpc/3.0.4/ppcross386 /usr/bin/ppcross386 Configure o seu projeto, criando um novo Build Mode (em modo normal) Acesse Project Options -> Compiler Options -> Config and Target Target OS -> Win32 Target CPU -> i386 Se ocorrer erros na recompilação da IDE, e tiver dificuldades de descobrir o problema. Selecione em Mensagens, para não efetuar nenhum filtro Botão direito em Mensagems -> Filter non Urgent Messages -> Filter None Observe as mensagens, geralmente é acusada a falta de alguma Biblioteca compartilhada... No caso de dúvidas, por favor crie um novo tópico em: https://www.projetoacbr.com.br/forum/forum/12-object-pascal-delphi-lazarus/

Boa tarde, Realizei as outras alterações (praticamente refiz) do leiaute do DAMDFe, contudo tenho apenas como testar o modal rodoviário. (Caso alguém trabalhe com outros modais, e queira testar, ou disponibilizar XMLs de outros modais para que eu faça o teste de impressão, só informar). DAMDFe_3a.fr3

Faça alguns testes utilizando :

Funcionou. Muito obrigado José Junior.

Erro Interno: 12002, parece ser instabilidade no servidor SEFAZ. Experimente aumentar o timeout

Boa tarde Gumercino, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia. Se for destacar o ICMS, então é necessário observar o seguinte: Caso o CSOSN seja csosn201 ( 201 - Tributada pelo Simples Nacional com permissão de crédito e com cobrança do ICMS por substituição tributária ), neste caso, use o CSOSN900, isso porque, como o destinatário vai utilizar o produto no ativo imobilizado e não a sua comercialização, o imposto será recolhido na origem, ou seja, substituição tributária para frente, desta forma, realize todo o cálculo normalmente. O CSOSN101 não permite o destaque o ICMS e ICMS ST, seria o CSOSN201, mas, como o destinatário não é contribuinte do ICMS, o destaque fica por conta do CSOSN900.

Atualizai e funcionou corretamente. Muito obrigado.

Bom dia. Eu acredito que não foi um problema no componente e sim um possível problema de configuração, rede, etc. Tenho clientes que geram mais de 8 mil notas /dia e isso não ocorre. Faça uma análise mais detalhada. Para obter o XML, gere novamente e mande assinar, logo depois realize uma consulta para obter o protocolo de envio. Caso contrário, que eu saiba, ainda não existe um WS para download do XML da NFC-e. Abraços

hmm acho que enviei o arquivo incorreto. Vou verificar.

A 16º Firebird Developers Day - (FDD) ocorrerá no dia 3 de Agosto, em Piracicaba - SP. Este evento é o maior evento sobre banco de dados Firebird no mundo (em número de participantes). Uma chance que os desenvolvedores brasileiros tem de se aprofundar nos mais variados assuntos relacionados ao SGBDR, trocar experiências e ter contato direto com especialistas do Brasil e do exterior. O Projeto ACBr estará presente! Conheça pessoalmente as vantagens de ser membro do SAC ACBr. Saiba os preços de aquisição e renovação da sua licença Delphi. Compre ingressos para o Dia do ACBr com preço promocional! Visite nosso Stand na Firebird Developers Day para receber um cupom de desconto exclusivo!

Boa tarde. Criei esse nova classe para gerar boleto e Remessa (c400) Unicred/SC, onde aqui no estado usa como base o Bradesco, modificando em alguns pontos. Unit nova: ACBrBancoUnicredSC Modifiquei: ACBrBoleto.pas em alguns lugares. ACBrBancoUnicredSC.pas ACBrBoleto.pas Manual_CNAB_400_UniCred.pdf

A função HexToAscii da unit pcnAuxiliar apresenta um erro de conversão ao tentar converter uma string inválida. '$ 2' is not a valid integer value Este erro ocorre na impressão de notas com caracteres inválidos na tag infCpl. Segue possível correção para análise. pcnAuxiliar.pas

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Boa tarde, Obrigada pela contribuição, adicionada para validação. Att.

Obrigado Juliana. Eles utilizam o CONAM que já está implementado em outras localidades. Irei realizar os ajustes necessários.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde. Ainda não tivemos retorno após os últimos comentários, porém é ótimo que você queira ajudar com seu conhecimento também, certamente estão sempre surgindo casos onde o conhecimento contábil é muito útil. Att,

Qual o seu ambiente de trabalho atual ? Observe as danfe´s que : caso tenha, utilizado alguma danfe da pasta Obsoletos , não estamos dando suporte as elas. Utilize o demo na pasta para sanar algumas duvidas.

Boa tarde Carlos! Também estou enfrentando esse problema a alguns dias. Caso encontre uma solução ou alguém tenha alguma dica será de grande ajuda! Att

Pessoal boa tarde sou Contador, e tenho um cliente está obrigado a entregar o LCDPR, não sei como que funciona aqui no fórum mas se eu puder ajudar em alguma coisa estou aqui, lembrando que eu não sou programador, mas no que eu puder ajudar contém comigo.

Eu segui os seus passos e resolveu o problema. Muito obrigado @fernandesdouglas.

A libxml2.dll que não entende o regex da forma como vem nos schemas oficiais. Se você configurar SSLXmlSignLib como xsMsXML, para usar a depreciada msxml5.dll, deve validar com o schema oficial. Não sei dizer se os schemas oficiais estão fora de algum padrão ou é limitação da libxml2. Em todo caso estou enviando o Schema alterado para o repositório.

Boa tarde Se utiliza OpenSSL descomente a linha ( {$DEFINE USE_MINGW} ) e utilize as dll da pasta (C:\ACBr\DLLs\XMLSec\MinGW)

Faça a correção dos dados e envie novamente ao eSocial

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Christiano, Tente da seguinte forma: BPe (tPag := TFormaPagamento.fpDinheiro)

Boa tarde André, Verifique se o CNPJ ou CPF que se encontra no XML (grupo infCIOT) é o responsável pela geração do CIOT.

Certo... não tinha ficado claro pra mim que já estava reportando a solução. Mas veja que a tag hSaiEnt é de layout antigo do XML, ela nem é mais usada. A mensagem de rejeição se refere a tag dEmi (no XML ela é gerada como dhEmi = data e hora de emissão). Outra coisa, somar +1 num campo do tipo TDateTime você está acrescentando 1 dia. O limite para NFCe é 5 minutos entre a data de emissão e a data de recebimento pelo webservice.

Entendi! Obrigado, vou analisar!

Para conseguir emitir o idDest tem que ser = 1 como informado pelo @BigWings

Bom dia, Foi realizado compatibilizações nas classes de respostas, com as respostas da lib. Lembrando que precisa atualizar o Projeto ACBrLib também.

Bom dia Asterix, Muito obrigado pela colaboração, vamos analisar e estando tudo OK, enviaremos para o repositório.

Boa tarde Tiago, O emitente é uma pessoa física ou jurídica? A principio se for pessoa jurídica não é necessário ser feito nada, pois todos estão habilitados a emitir o MDF-e. Já se for pessoa física, como a Graça colocou se faz necessário uma solicitação para habilitar a emissão.

Lembro que este fórum é voltado a desenvolvedores. Se você não é desenvolvedor sugiro que entre em contato com o suporte da sua aplicação.

Experimente substituir na sua pasta de schemas com o arquivo em anexo. tiposGeralMDFe_v3.00.xsd

Acabei de enviar ao SVN uma correção nesse código. Revisão 17332. Todo o código da alternação de cores agora fica apenas no rlbItensBeforePrint. Isso deve facilitar verificações futuras. Fiz alguns testes aqui e parece ok. Mas, por favor, queira atualizar, testar e reportar caso encontre algum problema. Mais uma vez, obrigado pelas sugestões.

Bom dia Danilo, Ainda não foi incluído e mesmo que tivesse ainda não iria funcionar pois o ambiente de homologação só vai estar liberado no dia 22/07/2019 para recepcionar CT-e com a string do QR-Code.

Olá, desculpe a demora, esse é o trecho que faz a carga do XML para o ACBR. impNotaXML.NotasFiscais.Clear; if FileExists(sCaminhoXML) then Result := impNotaXML.NotasFiscais.LoadFromFile(sCaminhoXML) else Result := False; Sempre fiz desta forma, e sempre funcionou perfeitamente, mas em apenas 1 cliente, começou a dar problemas, mas tendo em vista de que, mesmo nesse cliente sempre funcionou, plantei a ideia de que pode ser algo no pc dele, ou que ele instalou, ou algo assim, ele disse que ia mandar formatar, e depois reinstalaremos o sistema lá, não faço ideia de que algo no windows possa interferir nisso, mas como não tenho nem aonde olhar mais, vamos esperar ele formatar, primeiro. Grato!

Resolveu meu problema.... Agradeço muito.

Devido ao campo infMDFeTransp001001 e seus subsequentes estava ocasionando esse erro Após retirar tudo foi solucionado Obrigado a todos e desculpe nao remover o tópico pois não encontrei nenhuma opção para tal

Seria ótimo

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17330. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa tarde. Desculpe a demora e responder. Só agora a tarde consegui entrar aqui. O CSOSN a ser utilizado é o 101, ou seja, é a correlação com a CST 10 da empresa normal. No teu caso, sendo indústria e o destino é outra unidade da federação, há que se ficar atento às regras da legislação destino. Pelo relato e as rejeições não é possível fazer uma análise mais profunda, isso seria possível olhando o .xml, mas, pelo código 600 me parece que há inconsistência na somatória da BC-ICMS dos itens com o total informado na BC-ICMS da nota. Se tiver o .xml fica mais fácil. No caso do CFOP deve ser utilizado o 6107 mesmo.

Boa tarde, @Italo Jurisato Junior Eu fiz uma alteração confome essa postagem, que estava ocorrendo na Ginfes: Após isso consegui obter o retorno da prefeitura, no caso realmente não é permitido cancelar somente realizar a substituição: O prazo limite para realizar essa solicitacao por meio do sistema de NFS-e encerrou-se (vide Portaria 47 de dez/2017). Agradeço a atenção!

Meu arquivo estava realmente desatualizado. Baixei novamente e inclui nele o QR-Code. Neste arquivo apenas inclui a informação do QR-Code, pois foi a minha necessidade imediata para disponibilizar para os clientes. Estou verificando as demais alterações para alterar os outros modelos. DAMDFe_Retrato.fr3

Bom dia a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.10 que trata sobre novas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Criação/Alteração de regras de validação referentes a CST e Código de Benefício Fiscal, corrigindo algumas regras da versão anterior. • Criação de regra de validação correspondente rejeição 927, para informar os números dos itens em ordem sequencial. • Define que a regra de validação referente ao valor máximo da base de cálculo é por modelo de DF-e. Datas previstas para entrada em vigor: 22/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Alterações na aplicação do desenvolvedor: Por conta da regra H02-10, a aplicação ao atribuir o numero do item ao campo: Prod.nItem, este tem que ser um numero sequencial, consecutivo e iniciado por 1. Para quem utiliza o ACBrMonitor, não precisa se preocupar, pois o mesmo utiliza um numero sequencial, consecutivo e iniciado por 1 para o numero do item. Novas Regras de Validação: Criada a Regra de Validação H02-10, com o objetivo de informar os números do item em ordem sequencial. Criadas regras de validação a Tributo - ICMS:  Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado código de benefício fiscal para CST sem benefício fiscal (campo cBenef) [nItem: nnn] Se informado CST e informado código de benefício fiscal: - Verificar se CST possui código de benefício fiscal, conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF e por modelo de DF-e. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e. Regras que tiveram seu (Campo-Seq) alterado bem como a sua redação: Regra N07-10 agora é N12-97. Rejeição 929: Informado CST de diferimento sem as informações de diferimento [nItem: nnn] Nova Redação: Não informados campos de valores do CST 51 (Diferimento): - modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSOp (id: N16a), pDif (id: N16b), vICMSDif (id: N16c), vICMS (id: N17). Observações: Implementação a critério da UF. Regra N12-84 agora é N12-85. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal (campo: cBenef) [nItem: nnn] Nova redação: Se informado CST e não informado código de benefício fiscal: - Verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF, por modelo de DF-e e por CST. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e Regra N12-88 agora é N12-94. Rejeição 931: Informado código de benefício fiscal (campo: cBenef) incompatível com CST e UF [nItem: nnn] Nova Redação: Se informado CST e informado código de benefício fiscal: - Verificar código de benefício fiscal está vigente e corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF. Observação1: Tabela de código de benefício fiscal (cBenef) publicada no Portal Nacional da NF-e. Nota: Para itens sem benefício fiscal, a UF poderá exigir a informação da literal “SEM CBENEF” para alguns CST, vide tabela publicada no Portal Nacional da NF-e.

Bom dia @jeaanca eu sigo esses passos quando ocorre esses tipos de erros e sempre resolve. 1º Encerre sua aplicação. 2° Vá em executar, digite, certlm.msc, para abrir a interface de certificados. 3° Remova todos os certificados de "Autoridade de Certificação de Raiz Confiáveis". 4° Faça o download desse arquivo ( https://s3-sa-east-1.amazonaws.com/shared-www.validcertificadora.com.br/InstaladorCadeias_1.0.2.0.exe ) 5° Execute como Administrador o InstaladorCadeias_1.0.2.0.exe. 6º Clique em Instalar, e aguarde até que o processo seja finalizado. 7° Teste novamente a comunicação com a SEFAZ. Caso ainda não funcione, vá em opções da internet, na aba avançadas, desabilite as configurações: - Avisar quando houver incompatibilidade de endereços de certificado. - Verificar revogação de certificados do servidor. - Verificar se há certificados revogados do fornecedor. Salve, reinicie a máquina, e teste novamente.