Painel de líderes

É com muita satisfação, que conseguimos preencher TODAS as vagas de Patrocínio, para o Dia do ACBr... Veja o mapa abaixo: Isso demonstra o ótimo relacionamento que o Projeto ACBr, procura manter com Todos os Fabricantes de hardware para automação comercial... Em nossa área de Equipamentos Testados, você pode conferir um intenso trabalho que nossa equipe técnica realiza em conjunto com os Fabricantes de Hardware para automação comercial, para garantir uma ótima experiência de uso do ACBr, com os mais diversos equipamentos que suportamos... Não perca a chance de conhecer pessoalmente a equipe técnica de todos os Patrocinadores, e ainda a concorrer ao sorteio de diversos equipamentos. Confira em primeira mão, os lançamentos que estarão no mercado, no ano de 2019 Veja ainda esse tópico:

Olá pessoal, Decidimos prorrogar o Lote 2, até 31/10 (originalmente ele venceria no dia 16/10) O motivo, é que não poderíamos ficar insensíveis a situação atual no Brasil. Devido a proximidade do 2o turno das eleições, o foco de todos está nessa importante decisão que nós Brasileiros, iremos tomar no dia 28/10.... Sendo assim, você tem um tempo a mais para programar a sua vinda, ao Dia do ACBr, ao preço de R$ 279,00 (lote 2).. E se você é usuário SAC temos uma condição ainda melhor, sua inscrição por apenas R$ 195,30 até o final deste lote. Porém, não deixe para fazer a sua inscrição muito próximo do evento... Isso porque já estamos na reta final de vendas, e alguns horários de Palestras, já estão muito próximo da lotação máxima. Sendo assim, faça já a sua inscrição, e garanta a sua vaga, nas palestras que deseja participar, acessando: https://www.projetoacbr.com.br/forum/eventos/diadoacbr/inscricoes-palestras/ Você pode gerenciar as suas inscrições, usando o Link: https://www.projetoacbr.com.br/forum/eventos/diadoacbr/minha_inscricao/ Veja também esse tópico: Programação Completa

Com base no demo do ACBrNFe: Produto := NotaF.NFe.Det.Add; [...] Produto.pDevol := <percentual da mercadoria devolvida>; Produto.vIPIDevol := <valor do ipi devolvido>;

Parabéns é pouco para o ProjetoACBR, seus idealizadores e integrantes, simplesmente fantástico.

A tag pDevol é em relação à quantidade devolvida: NT 2013.005 v1.22:

Não é o ACBr que está rejeitando informar com 9 dígitos, mas o próprio schema do MDFe que tem esse limite. Veja que o campo RNTRC deve ter sempre 8 dígitos de acordo com o layout: A consulta na ANTT retorna 9 dígitos para qualquer RNTRC, sempre preenchendo com zeros a esquerda. Não há nada a fazer do lado do ACBr, se o RNTRC está habilitado e está tendo rejeição deve entrar em contato com a ANTT para saber o motivo.

Qual é a impressora que está utilizando? Por qual porta está imprimindo (COM, COM Virutal, USB, Spool do Windows)? Pelo o problema que está ocorrendo deduzo que esteja utilizando o Spool e algum documento fica travado na fila e quando reinicia a máquina esse documento é cancelado e o resto é impresso ou está com problema de comunicação com a impressora mas após reiniciar a comunicação volta e os documentos são impressos. Se for esse o caso reinstalar os drivers pode resolver.

Estamos a vários dias tentanto solucionar este problema junto ao SICOOB. Está havendo uma divergência entre os layouts utilizados entre as agências, ou entre homologação e produção. Existem 2 layouts: 1-exige preenchimento = ' ' na posição 72 do header; 2-exige preenchimento = '0' na posição 72 do header; No entanto, os 2 layouts são da mesma versão (081). Nem todas as agências estão utilizando o mesmo. Como a versão é a mesma, não temos um parâmetro para diferenciar os layouts. Segundo o SICOOB, somente o Banco Central poderá solucionar essa questão. No dia 04/10/2018, o responsável pelo TI da agência SICOOB de Uberlândia abriu um chamado junto ao Banco Central a fim de solucionar essa questão, mas o chamado continua em aberto.

Bom dia, kurtslucas. Veja a discussão desse assunto no tópico abaixo:

Boa tarde, Note que esses parâmetros se refere ao Retorno de envio da NF-e, mas que na realidade também é usado para a NFC-e, o CT-e e MDF-e. Depois do envio do lote de NF-e (por exemplo) é realizado uma consulta para saber o resultado do processamento do lote. O Aguardar determina o tempo de espera entre o envio e essa consulta. Tentativas determina o numero de vezes que essa consulta será realizada, pois ao consultar pode retornar que o lote ainda não foi processado. Intervalo determina o tempo de espera entre uma consulta e outra. Timeout determina o tempo que o Monitor vai aguardar para obter um retorno da SEFAZ antes de retornar uma mensagem de erro de conexão. Se é pedido para informar o tempo em segundos você não pode informar 01:30 (um minuto e trinta segundos) e sim em segundos, ou seja, 90. Essas propriedades são de configuração, sendo assim os valores atribuídos vão depender da internet do emitente do documento e da SEFAZ-Autorizadora. Logo não da para dizer a você quais os valores ideais para cada uma dessas propriedades, você vai ter que realizar testes.

Boa tarde, Fiz a implementação para a nossa equipe homologar. Estarei informando futuramente sobre os testes em produção. Att.

Olá pessoal, muito obrigado pelo rápido retorno. Eu cheguei a preencher a tag Produto.vIPIDevol e ainda deu o mesmo problemas. Não sabia sobre a tag Produto.pDevol. Este percentual é o valor percentual de IPI devolvido? Mais uma vez obrigado pela ajuda. vou fazer as alterações e testes aqui.

Estou com o mesmo problema na agência de Uberlândia;

Ok, problema resolvido. Mais uma vez obrigado.

Adicionando ao que o Júnior disse, pode-se conseguir as tabelas com todos os CST válidos para PIS e todos os válidos para COFINS no site do SPED. Inclusive fazer donwload dos arquivos textos usados pelo próprio Validador da EFD Contribuições (PVA). http://www.sped.fazenda.gov.br/spedtabelas/AppConsulta/publico/aspx/ConsultaTabelasExternas.aspx?CodSistema=SpedPisCofins

Obrigado pela informação, vou verificar e posto aqui o resultado da verificação para concluir o Fórum.

Bom dia, utilize o documento (Bem_Vindo_ao_Trunk2.pdf) que fica na pasta C:\ACBr. Este documento especifica a sequencia dos pacotes a serem compilados e instalados. Também encontrará vídeos tutoriais na internet.

Caso sua aplicação gere o XML e não esteja assinado ainda, deve utilizar o passo 2 e 3 antes do envio, ou utilize apenas o método de envio, veja que tem um parâmetro para assinar o XML ou não: https://acbr.sourceforge.io/ACBrMonitor/NFEEnviarNFe.html

Isso é muito complicado, e exige contratos da Sw,House e do estabelecimento, com a TEF House... Permitir que a aplicação final acesse o PinPad, é uma "brecha de segurança" ... e as TEF Houses tem muitas restrições em permitir isso

Esse erro foi corrigido nos fontes, na semana passada

Olá! Estou usando a configuração TimeOutPorThread (criada na revisão 14797) e estava enfrentando alguns erros de Access Violation em alguns clientes. Analisando verifiquei que o erro estava no método Enviar da classe TDFeSSL, mais especificamente no bloco abaixo: EndTime := IncSecond(now,TruncFix(TimeOut/1000)); SendThread := TDFeSendThread.Create( Self, TDFeSSLHttpClassOf(FSSLHttpClass.ClassType), ConteudoXML, AURL, ASoapAction, AMimeType); try while (SendThread.Response = '') and (Now <= EndTime) do Sleep(50); finally Result := SendThread.Response; SendThread.Abort; end; A TDFeSendThread não tinha nenhum tratamento de exceção no Execute e quando ocorriam erros na execução, como um erro de conexão ou sem Internet, a thread era abortada e no finally a variável SendThread já não existia mais, causando o AV. Acontecia esporadicamente e não era muito fácil de simular. Para corrigir o problema, implementei um tratamento de exceção no Execute da thread e tratei para abortar o while de verificação caso algum erro ocorra. Também alterei para que a thread fosse liberada manualmente ao final do envio. Peço que analisem e subam para o SVN se possível. ACBrDFeSSL.pas

hum...certo ...vou realizar alguns testes, tentar simular...muito obrigado por enquanto

A SEFAZ não disponibiliza o XML da NFCe via webservice. O emitente é o responsável legal pelo armazenamento dos arquivos XML.

Duplicado de:

Pessoal, muito obrigado pelos esclarecimentos. Deu certo pra mim aqui em homologação. Abraços.

Creio que você possa usar isso para detectar situações de TimeOut Erro HTTP = 0

Obrigado por sua resposta Daniel.

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

Que saiba nenhum estado que aderiu à NFCe exige homologação. Alguns exigem o cadastramento da empresa desenvolvedora e/ou software, como PR e PA. Essa situação pode mudar em breve, já que CTe e MDFe incluiram grupos para identificar a empresa desenvolvedora e responsável técnico, a ser informados a critério da UF. A NFe deve seguir o mesmo caminho. https://cdn.sefin.ro.gov.br/portalnfce/9ac05befca7d6499e3abec9bdfef2b68.pdf

Não deu certo. De qualquer forma, apenas alguns apresentam o erro. Os demais, mesmo com cabeçalho 1.3 abrem normalmente. Mas obrigado amigo! Bom dia! Então, acredito que vou ter que atualizar a ferramenta realmente. Imagino que seja alguma incompatibilidade com o Windows 10. Apesar de que a maioria dos PDF's não dão erro. Obrigado!

Olá José, Ontem mesmo, após sua orientação, modifiquei a aplicação, retirando Assinatura e Validação, deixando apenas o Envio, funcionou perfeitamente, consultei na SEFAZ pela chave e a nota foi autorizada, isso certifica que está ok ? No comando de envio, passo apenas três parâmetros, segue: NFe.EnviarNFe(<xml>, 1, 0) 2º parâmentro, pela documentação, seria o nLote, por ser parâmetro obrigatório. 3º parâmetro, tenho dúvida se é o bAssina, que é opcional ou se é o último bSincrono, que seria obrigatório. Tem como me esclarecer ? Como disse, está dessa forma desde qdo desenvolvi, em 2011, talvez precisa melhorar ou implementar. Grato desde já pela atenção.

Tópico fechado por falta de retorno do usuário

Bom dia, pradilsoncarlos. Conforme informei acima, você terá que analisar a documentação do provedor para saber se é possível utilizar esse recurso.

Bom dia. Acredito que bastaria substituir os locais onde usa o quickreport pelo ACBrETQ. Recomendo que analise o demo do componente para entender melhor seu funcionamento. Att.

Bom dia, está previsto adicionar estes métodos no ACBrMonitor, por enquanto realmente não tem.

Estranho, seu cabeçalho do pdf está com a versão 1.3, tem como voce mudar para 1.4? olha: %PDF-1.3 %Å­o 1 0 obj Abra o pdf seu pelo bloco de notas. tente mudar a versao.

Boa tarde, Raissa Takenaka. Tópico muito antigo. Sugiro que crie um novo.

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

Obrigado @Daniel Simoes, vou solicitar a empresa o pagamento do SAC para que possamos pegar a nova versão.

Bom dia, tiago Selecto. Veja se a sua pasta de Schemas está atualizada e atualize as DLLs

Você deve configurar para usar a versão 2.00 do QrCode.

Você jogou essa mensagem de erro no Google e caiu aqui no fórum, estou certo? Aqui tratamos dos componentes ACBr, para desenvolvimento em Pascal (Delphi e Lazarus). Essa mensagem de erro é comum em programas feitos nessas linguagens, se você está usando um programa específico para fazer a cópia, provavelmente é uma falha nele, procure um fórum específico para o aplicativo, ou a página do desenvolvedor.

Boa tarde, byteinfo. Veja o tópico abaixo, talvez possa te ajudar:

Olá! Fiquei caçando uma solução por dias na internet, em vão, e então peguei um dia fazendo inúmeros testes e monitorando o tráfego do Software Manifestador, para consulta ele somente acessa o IP 200.198.239.181, que é do domínio www1.nfe.fazenda.gov.br, que é do webservice do NFeDistribuicaoDFe. Não consegui descriptografar o tráfego para ter certeza do caminho do webservice, então resolvi inspecionar os "jar" baixados pelo "jnlp", descompactei e tentei encontrar alguma string que me indicasse um webservice diferente... Sem sucesso. Como eu já tinha todos os class, resolvi usar o "javap" e inspecionar os bytecodes... Sem sucesso. Fui mais além e utilizei então dois descompiladores e encontrei algo que me chamou a atenção, pois encontrei nos arquivo XML de consulta estavam com a versão 1.35: ---> br/gov/sp/fazenda/dsmd/ws/destinadas/br/gov/sp/fazenda/dsmd/common/util/DocumentoUtil400.java:1567: consNFeDest.setVersao(br.gov.sp.fazenda.dsmd.schemas.mdnfe.v100.TVerDistDFe.X_1_35); ---> br/gov/sp/fazenda/dsmd/ws/destinadas/br/gov/sp/fazenda/dsmd/schemas/mdnfe/v100/TVerDistDFe.java:26: public static final Enum X_1_35 = Enum.forString("1.35"); O mesmo para TVerResEvento e TVerResNFe, então encontrei os 'xsd"s da versão 1.35 e comparando com a 1.01 do pacote PL v1.02, alterou-se o xsd dos tipos de "tiposDistDFe_v1.01.xsd" para "tiposBasico_v1.03.xsd" contendo agora TNSU e TVerDistDFe, cUFAutor obrigatório, consChNFe não existe nessa versão, cSitConf agora existe no resNFe. Bom, a princípio alterei a versão na consulta por NSU para versão 1.35 para testar e funcionou bem, veio o cSitConf. Não sei se fiz tudo isso "à toa", mas como eu não encontrei a solução em lugar nenhum, resolvi ir a fundo, encontrar a solução e colocar aqui. v1.35.zip

boa tarde.. referente sua pergunta: ( A pergunta : Devo alterar o meu programa pra excluir as respostas anteriores ou espero uma versão mais nova do acbrmonitorplus com esta correção ?) sim.. voce deve alterar o seu programa, para sempre excluir o sai.txt antes de mandar o ent.txt novamente.. eu desde que uso o monitor, sempre foi assim.. blz..qualquer duvida.avise.

Para as NFe de emissão própria, os eventos gerados por terceiros (manifestação do destinatário, CTe autorizado, registro de passagem...) são retornados pelo método DistribuicaoDFe. Os eventos originados pelo próprio emitente não são retornados, já que o mesmo já tem o XML do evento no momento da emissão do evento. O método de Consulta de protocolo retorna apenas os eventos de cancelamento, carta de correção e EPEC. A UF tem, porém, a prerrogativa de retornar os demais eventos.

"Só vou tentar descobrir, porque as cartas reenviadas para mesma nota ( 2ª, 3ª carta de correção em diante ) ele passa a gravar na pasta eventos\nfce ao invés de continuar a gravar na pasta eventos\nfe, isso vai ser outro mistério, se descobrir eu posto aqui, senão, abro novo post." - Ok, descobrir. Para os que salvam XML de Notas Fiscais e eventos em pastas, segue um detalhe: Se o salvamento de arquivos estiver SeparaPorModelo:=true como é o caso do meu...o sistema gravará na pasta de eventos que você definir separado por NFe e NFC-e, assim se você não definir antes de gerar sua CCe como: ACBrNFe1.Configuracoes.Geral.ModeloDF := moNFe ele sempre irá salvar na pasta do último modelo de Nota FIscal usado, quer dizer, se vc emitiu uma NFe e no dia que resolveu emitir uma Carta de Correção vc emitiu uma NFC-e antes, o sistema sempre pega o último modelo usado e os eventos ficam gravados nela...portanto se vc quiser que seus eventos de NFe fiquem gravados na pasta de eventos\nfe ( por exemplo), você terá que definir que trata-se de uma NFe antes de gerar o evento, inclusive esse detalhe também ocorre no DEMO do ACBR.

Boa noite, Você pode testar a propriedade Schema do retorno. var DFe: TdocZipCollectionItem; begin [...] DFe := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[I]; case DFe.schema of schprocNFe: ; // NFe completa schresNFe: ; // NFe resumo schresEvento: ; // Evento resumo schprocEventoNFe: ; // Evento completo end; end;