Painel de líderes

O ACBrMonitorPlus muitas vezes pode emitir janelas e pedir interação com o usuário (exemplo ao visualizar um DANFe). Por isso, ele não é um bom candidato para ser uma aplicação de serviço... Pelo menos, não no momento.

Boa tarde! Segui o link: https://www.projetoacbr.com.br/forum/topic/44051-erro-12175-um-ou-mais-erros-foram-encontrados-no-certificado-secure-sockets-layer-ssl-enviado-pelo-servidor/ Esse link acima me ajudou fui tentando fazer de tudo que postaram ai deu certo. Obrigado.

Geralmente este erro é causado pelos seguintes fatores. Infecção por vírus. Incompatibilidade dos drivers instalados. Falhas no hardware. Sistema operacional corrompido. Em qualquer caso, um técnico especializado poderá resolver seu problema. Já tivemos esse erro aqui e o problema era a placa de vídeo.

Problema solucionado. Inadvertidamente alguém informou um proxy. Obrigado.

Italo, esquece eu esqueci de tirar o .nfse deu certo, vou começar a listar as nfes emitidas para fazer o cancelamento e te falo se deu problema. obrigada novamente

Boa tarde Oliveira, Note que essa tag é opcional logo precisamos de um valor para dizer que ela não deve ser gerada. Sendo assim acrescentei o enumerador: prpNenhum que vale zero. Se não é para gerar a tag você deve atribuir esse valor ao respectivo campo ou um dos outros 2 disponíveis. Mesmo assim, muito obrigado por informar que estava gerando de forma errada.

Complementando a resposta do Italo: NT 2018.001 06. Serviço: Pedido de Inutilização de numeração (item 4.4 do MOC) 06.1 Leiaute do Pedido de Inutilização (Item 4.4.1 do MOC) Para as empresas (pessoa jurídica) existe a operação de Inutilização de Numeração, que registra a numeração da Nota Fiscal que foi inutilizada pela empresa. Ou seja, a empresa informa que esta numeração não será utilizada. O controle de Inutilização de Numeração não será aplicado para o emitente pessoa física. Nota: O leiaute atual do Pedido de Inutilização não prevê a informação do CPF do emitente.

O correto talvez fosse você pedir o cliente para se cadastrar. Por outro lado, talvez você queira fazer o download e disponibilizar você os arquivos para seus clientes. Talvez por FTP.

Senhores, Publicada PORTARIA SAIF Nº 033/19 que prorroga a data de obrigatoriedade de emissão do Bilhete de Passagem Eletrônico definida pelo Ajuste SINIEF 22/18, de 01 de julho de 2019 para 01 de outubro de 2019. http://www.sped.fazenda.mg.gov.br/spedmg/bpe/

Verifique o Visualizador de Eventos do Windows. Ele costuma trazer mais informações sobre as falhas do sistema.

Sua pergunta "boba" foi certeira. Na Bahia o token esta correto já no ES o meu cliente colocou o numero do certificado em vez do Token valeu.

pergunta boba.. o token está certo?

O Fato é que o SEFAZ está descontinuado esse serviço... o novo site usa um Recaptcha que nós não conseguimos interagir por programação... Até o Momento, não conhecemos um novo WebService do SEFAZ que possa fornecer gratuitamente essas consultas

Quer dizer que o XML está sem o protocolo de autorização.

Boa tarde, O verificador da Tanca guarda compatibilidade com o protocolo Gertec, é muito possível que funcione sem ajustes.

Perfeito Marcelo, Resolveu meu problema. Muito obrigado.

Boa tarde, Me recordo que houve alguma situação anterior que gerou sim esta mudança, mas em todo caso não seria mais simples sua aplicação já enviar ao componente o valor com 2 casas decimais? Att.

Boa tarde, ok, agradeço por ser de verdade, porque como nunca tinha recebido e vivo acessando de maquinas diferentes e windows diferentes também fiquei com medo de tantos fork´s que depois roubam dados etc... tipo aqueles de bancos, valeu HASA

Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Fonte:https://dfe-portal.svrs.rs.gov.br/Mdfe/Avisos/137

Boa tarde, Temos mudança sim no arquivo ACBrMDFeServiços, pois agora temos um webservice especifico para recepcionar os MDF-e que forem enviados no modo Síncrono. E acredito que teremos que ter uma opção no ACBrMonitor onde você possa configurar se deseja Modo Síncrono ou Assíncrono. Pela que andei lendo futuramente teremos somente o envio no modo Síncrono do MDF-e, visto que o envio sempre foi unitário, ou seja, sempre foi enviado somente 1 MDF-e de cada vez.

Boa tarde, Uma pequena correção. Em vez de: [ObsCont] xCampo=Motorista xTexto=Guilherme regime fagnani / CNH: 06697747686 / RG: 452626006 / CPF: 02768261830 [ObsCont] xCampo=Placas xTexto=CYR-9159 CPR-3038 Faça da seguinte forma: [ObsCont001] xCampo=Motorista xTexto=Guilherme regime fagnani / CNH: 06697747686 / RG: 452626006 / CPF: 02768261830 [ObsCont002] xCampo=Placas xTexto=CYR-9159 CPR-3038 O ObsCont é uma lista, logo devemos incluir o seu indice.

Boa tarde Vinício, Note que o XML que o componente esta gerando é o de consulta a situação do lote, já o modelo que lhe passaram se refere a consulta ao lote. O componente possui um método para cada tipo de consulta.

compreendi! Obrigado pelo retorno

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

Bom dia Joabe, Se não me falha a memória se tratando de Produtor Rural não é possível inutilizar numero ou faixa de números. Dai o erro retornado pela SEFAZ. Aproveitando: Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr com o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada?

Bom dia, favor atualizar os fontes.

Bom dia O ACBrMonitorPLUS não vai funcionar como um Serviço do Windows, mas sim como uma aplicativo em Segundo Plano, que fica no Systray do Windows monitorando os comandos recebidos.

Bom dia, Obrigada por informar, adicionado ao calendário ACBr. Tópico movido para a sessão de noticias. Att.

Bom dia, No manual CobrancaEletronicaBanrisul_pdr400_vrs14012019_ed13.pdf(Leiaute CNAB 400 Posições Padrão Febraban) A principio diz que . 157-158 e 159-160 podem ser preenchidas indiferente da ordem e não podem ser repetidas,bem como você @Juliana Tamizou mencionou acima. Obrigado pela atenção.

Bom dia. Obrigada pela contribuição, adicionada para validação. Att.

Bom dia ALA, Caso queira contribuir com o projeto basta pegar uma das Units: pnfseNFSeW_xxxx.pas copiar com o nome pnfseNFSeW_SigISS e fazer as alterações necessárias para que ela gere o XML conforme o manual. Esse é o primeiro passo. Depois é preciso alterar a unit pnfseNFSeW.pas para que ela reconheça a unit nova. Por fim iniciar os testes.

Aparentemente está faltando aspas duplas, nos Parâmetros String, conforme a Sintaxe de comandos do ACBrMonitorPLUS

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

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

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

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

use o pesquisar do forum que ira encontrar muita informacao. segue um link muito bom

Revisei a documentação aqui e, de fato, o vItem é calculado pelo SAT e não aparece no XML. Ele é calculado baseado no SAT baseado em qCom, vUnCom, etc. Falha minha! rs Mesmo assim, ainda enfrento o problema, mesmo com todos os campos com RoundABNT

O ACBrInStore é capaz de interpretar códigos de Barras, In Store... ( que iniciam com 2 )

Boa tarde. O ACBrETQ imprime qualquer código que for informado, você precisa apenas se certificar de escolher o tipo de código correto. Também vale ressaltar que oque costuma ocorrer quando o produto não tem código de barras é ser atribuído um valor qualquer, como por exemplo o código interno no seu sistema. Veja ..\tools\Etiqueta, em o manual definindo os códigos aceitos conforme o tipo. Att.

Sobre a dica do Rafael acima do modo RAW, veja esse tópico: Você também pode tentar usar pelo compartilhamento de rede. Veja esse outro tópico:

Esta usando todos os INIs iguais ao do exemplo. Estou batalhando na verificação do componente. Verificando todos os processos do exemplo, mas até agora sem sucesso. A minha aplicação está na mesma maquina que foi testado o exemplo. Vou analisar novamente..

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

De forma semelhante ao material disponibilizado pela SEFAZ-MG, a SEFAZ-SP também publicou em seu portal a relação das regras de validação facultativas a UF da NT 2019.001 as quais a mesma exigirá. Clique aqui para visualizar a tabela publicada no portal da SEFAZ-SP.

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já sabia era rejeitado... Isso é praticamente um ataque de DDOS, nos servidores do SEFAZ... Quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós não sabemos como seu sistema funciona, nem conhecemos os seus clientes. Ainda mais, o ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe, o item "2.1 Código de Segurança do Responsável Técnico - CSRT" que nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

Bom dia Lucas, Você configurou o proxy no programa exemplo? Se sim, a rede possui um proxy instalado? Se não tem, não se deve configurar o proxy.

Caro Carlos Alberto, primeiramente, qual banco você usa. No meu caso eu uso o Firebird 2.1 e persisto o XML da NFe no banco por dois motivos. Se o seu sistema funcionar em rede, os xml's ficaram fragmentados pela empresa e em caso de formatação das máquinas ou demais danos os mesmos podem ser perdidos. Neu caso eu uso um campo blob e logo apos o envio da nota set XML para um MEMO e a minha função que gera SQL persiste esta informação. O fato de gravar o XML adiantou a minha vida por que o usuário poderá utilizá-lo de qualquer estação em que estiver logado e simplesmente o carrego para imprimir danfe, cancelar, exportar, etc. Isto é o que eu faço, mas como eu faço pode não ser útil para você por que talves os componentes que você usa para persistir em banco pode ser diferentes dos meus, a geração do sql etc. Espero ter dado uma luz.