Painel de líderes

Foi realmente um ótimo evento. Palestras muito interessantes e esclarecedoras. Somente tenho uma sugestão: Para dar alternativas e agilidade no almoço, trazer alguns food trucks com opções diversas para a alimentação. Abraços, Paulo

O erro é típico de versão do OpenSSL antiga, que ainda não suporta TLS1.2 Pegue (todas) as DLLs da pasta "\ACBr\DLLs\OpenSSL\1.0.2.13\x86", e copie na mesma pasta do seu .EXE

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

Parece ser um Bug no Filtro PDF do Fortes Report....mas seria complicado debruçar nos fontes do Fortes, e tentar compreender porque ele não computa o tamanho da linha corretamente, com a fonte em Arial... Acho que é mais simples aplicarmos a sua sugestão e mudar a fonte para Courier New

Boa tarde ALA, Favor atualizar todos os fontes de todas as pastas, reinstalar os componentes e faça novos testes. Note que fiz alteração no arquivo INI do provedor NFSeBrasil.

Obrigado Amarildo pela atenção, mas descobri o problema aqui, após vc ter pedido os logs. Att Claudio

Boa tarde Henrique, Se chegou a funcionar depois no dia seguinte sem alterar nada ocorre esse erro, com certeza deve ser algum problema no provedor. Favor entrar em contato com eles e expor o problema.

Sim Obrigado.

poderia por favor anexar um PDF demonstrando o problema ? Acho que seja necessário mudar o Texto para um Memo

boa tarde.. sim.. ja foi aberto um topico sobre isso

você já não está com um tópico aberto falando sobre isso?

Substitui o arquivo nfse.xsd do Schemas pelo do fonte do ACBr, está enviando as notas. Obrigado pelo suporte!

Tente ajustar a página de código no componente... para 852 ou 860

@Italo Jurisato Junior como sempre muito obrigado pela resposta e me mostrar o meu erro. Realmente estou fazendo da forma que você citou acima... Vou alterar esse cMDF e cCT agora mesmo. Abraço, Wagner

OK, ja passei o assunto a ele obrigado...

Bom dia Wagner, Você esta cometendo um erro que muitos cometem. Quem disse que o valor de cMDF tem que ser igual a nMDF? No final da pagina 100 do Manual do MDF-e versão 3.00 temos: nMDF = Numero que identifica o Manifesto: 1 a 999999999 cMDF = Código aleatório gerado pelo emitente, com o objetivo de evitar acessos indevidos ao documento. O campo nMDF tem um tamanho que varia de 1 a 9 dígitos, por outro lado o cMDF tem um tamanho fixo de 8 dígitos. Tanto o nMDF quanto o cMDF fazem parte da chave que contem 44 dígitos, não faz nenhum sentido ter nessa chave dois campos com o mesmo valor. Pelo jeito você comete esse erro no CT-e, correto? Essa transportadora esta vulnerável, pois se o XML ou o DACTE cair na mão de um concorrente, esse poderá (se tiver paciência) descobrir quais são os remetentes e destinatários mais frequentes, bem como o valor cobrado pelo frete. Desta forma o concorrente poderá entrar em contato com essas pessoas (remetentes / destinatários) oferecer o mesmo serviço por um preço mais em conta. Pare e pense, você esta pondo em risco o futuro dessa transportadora.

Tem que testar pois o LazReport é para Lazarus o projeto correspondente e ele é o FreeReport mas não lembro se funciona no Tokyo

Qual a marcar/modelo da balança? Pode ser a configuração dela que está com o tipo de protocolo que envia o peso de forma constante e não quando você solicita.

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

Apenas usuários que tiveram presente no Dia do ACBr ou são do SAC do ACBr, tem acesso a esses arquivos... Para contratar o SAC, veja esse link: https://www.projetoacbr.com.br/forum/sac/sobre/

Excelente Sergio vou testar agora

Daniel, Esqueci de enviar um exemplo do PDF já com a nova Fonte. Sat.pdf

Boa tarde, o pipino ainda continua, coloquei uma rotina na minha aplicação, se retornar " Erro:Erro: 12002 - TimeOut de Requisição", manda de novo, e de novo, e de novo, até conseguir, esta dando certo, demora mas vai, também aumentei o TimeOut pra 60 segundos...

Só funciona em homologação. Em produção, manda normal o código.

Boa tarde Paulo, Verifique se o arquivo Goiania.ini na seção assinatura os campos RPS e RpsGerar estão recebendo o valor 1.

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

conseguiu resolver seu problema?

No site não encontrei nenhuma informação. Apenas tem a informação que fica a critério de cada UF exigir ou não essa informação. Achei a resolução do estado de Minas revogando a obrigatoriedade: Resolução que obrigava o envio: http://www.fazenda.mg.gov.br/empresas/legislacao_tributaria/resolucoes/2017/rr5071_2017.htm Resolução que revoga o envio: http://www.fazenda.mg.gov.br/empresas/legislacao_tributaria/resolucoes/2018/rr5151_2018.htm Os demais estados ainda não localizei, mas acredito ser verídica a informação...

Sim, já havia olhado a referida documentação. Como dito ali, este seria o melhor caminho... porém, não é viável aplicar este conceito a minha necessidade. Estou migrando do BDE para FireDac(7 para Tokyo), e isto implicaria em, primeiramente, setar o "Connection" de todos os componentes de acesso a dados para conseguir centralizar este controle. No momento, estou trabalhando com com a conexão definida ao "ConnectionName". Entendo que o grande ponto no meu contexto é: o FireDac abre uma transação implícita ao dar um ".Post" que, se não for comitada, só será no momento no encerramento da conexão.

Desses links já chegaram a ler essa parte

A correção do contador de registros no registro trailer do BB foi corrigida dia 26/10, então recomendo que atualize o seus fontes. Sobre os outros erros, durantes os testes que fiz e de outros usuárias a respeito de um outro erro, como descrito no tópico abaixo, não deu esses erros no número sequencial dos registros. Se possível, atualize os fontes e refaça os testes ou até utilize, nos testes, o .pas que disponibilizei no mesmo tópico, se ainda persistirem o erro anexe o arquivo de remessa para que seja analisado por favor.

Olá ! Também tive este mesmo tipo de problema “Access violation at address ...” na abertura de meus programas que usam o ACBR. Mas para encurtar a mensagem já adianto, oque resolveu foi o cliente formatar a máquina, depois do Windows zerado tudo funcionou normalmente! Oque me levou a esta conclusão foi que no ambiente de desenvolvimento Windows 10 funcionava 100 % sem erro algum. Já nos clientes alguns com Windows Vista, Windows7, Windows10 rodava tranquilo igual ao meu ambiente de desenvolvimento (até no Windows XP rodou sem problemas). Porem em 2 ou 3 clientes dava o erro. Uso Delphi XE7 original e tive problema!

Bom dia Alisson, Tanto o CTe (DACTE) quanto o MDFe (DAMDFE) se utilizam do mesmo Report (Fast ou Fortes)?

Valeu! Estudando em 3, 2, 1...

opa..

bom dia.. voces nao tem como pedir para os contadores, entrarem em contato com os fiscais do sefaz, para dar uma pressão e eles resolverem isso?

Bom dia, dannymazzo. Estranho... Aqui funciona perfeitamente. Tente apagar a pasta do ACBr, baixe novamente e tente executar o demo.

Sim já existe logo subo os demos para o repositório.

@Jean Semolini Foi enviado ao repositório correções para resolver o problema do envio e também algumas atualizações em relação ao Demo em Java. Lembrando que ser for usar SSL ou TLS precisa também das bibliotecas do OpenSSL que se encontra na pasta DLLs\OpenSSL\1.0.2.13\.

Amigo, você estava certo. Fazia essa configuração em tempo de execução na hora do envio e na consulta não fazia. Coloquei configurado no componente e ficou ok. Obrigado pela ajuda. Não sei como colocar [Resolvido] no título..rs

Boa tarde. A ambiente de testes deles voltou a funcionar. Se enviar a nota com a série "TESTE", o webservice retorna a nota número 370 com dados fictícios sem erros.

Mas esse problema não é exatamente sobre a IBXQuery ou UniQuery. É sobre objetos e referência. Bom, em algum momento ele precisa se comunicar com o BD. Então a conexão precisa ser feita. A menos que estejamos falando de coisas diferentes aqui... Mas pelo que você mencionou anteriormente, a conexão funcionava. Veja o que você mesmo escreveu antes: Isso significa que aconteceu a conexão. É um pouco difícil orientar vocês porque não entendi muito bem o que vocês querem fazer nem sei qual é o framework que vocês estão utilizando para fazer o ORM.

Achei o problema. Essa linha: Ide.cMDF estava comentada. Alterei o meu sistema para ela receber o número do mdfe e deu tudo certo. Obrigado pessoal pela ajuda. Grato, Wagner

Visulizar Arquivo SPED com Padrões de Projeto/Apresentando ORMBr/Distribuição DFe Por: @Isaque Pinheiro O autor do ACBrSPED irá mostrar uma técnica para tirar melhor proveito do uso dos componentes SPED, aplicando padrões e boas práticas para minimizar e facilitar manutenções futuras. Vou mostrar o recurso de Distribuição de documento eletrônico com o ACBr e como ele poderá te ajudar em fazer download dos XMLs armazenadas no SEFAZ. E por último apresentação do projeto ORMBr Framework for Delphi, o que é, o que ele faz, como pode te ajudar, o ORMBr é um projeto opensource do qual sou autor e mentenedor. Veja também o vídeo: Autor Daniel Simoes Enviado 19-11-2018 Categoria Dia do ACBr 1a edição

Visulizar Arquivo NFC-E NO MOBILE: DA TEORIA A PRÁTICA Por: @Régys Silveira Demonstração prática de como construir servidores REST no Delphi com o intuito de facilitar a emissão de NFC-e/CF-e utilizando aplicativos mobile. Baixe os fontes e apresentação em: https://regys.com.br/palestra-dia-do-acbr/ Veja o vídeo em: Autor Daniel Simoes Enviado 19-11-2018 Categoria Dia do ACBr 1a edição

Boa noite. obrigado já está no svn. favor testar novamente

Em SP, quem utiliza a NFC-e precisar possuir um aparelho SAT ativado para realmente estar em conformidade com a legislação estadual.

Então acabei solucionando o meu problema pegando o arquivo antigo que eu tinha DACTE_OS.fr3 e efetuando o ajuste independente do arquivo que está no repositório. (Parece que o do repositório não é compatível com o meu da versão 4). O que eu utilizava era de agosto de 2017. Em anexo o que eu alterei, caso interesse comparar. DACTE_OS.fr3