Régys Silveira

Infelizmente algumas empresas passam por cima do certificado, veja a AVAST, dias atrás ela simplesmente deu na telha que um dos nossos softwares era um vírus, mesmo nós assinando e certificando o .exe junto ao VírusTotal, ela não checou em nenhum lugar, somente assumiu por conta própria e pronto.

Só para ter um outro ponto de vista, aqui eu fiz o seguinte, o sistema faz a troca automática, ao voltar para on-line ele tenta transmitir, se não conseguir a nota fica pendente de envio, ele vai tentando enquanto estiver on-line de tempos em tempo, se mesmo assim a nota não conseguir ser enviada o sistema notifica o usuário, e a notificação só some quando todas as notas forem transmitidas. Veja, no meu ponto de vista a questão jurídica recai sobre o software somente se ele não der opções de envio manual por parte do usuário dentro do prazo legal, entrar em modo off-line de forma manual ou automática não muda o envio, este ainda fica por conta do usuário. É só outro ponto de vista :)

Fiz o acerto para o ponto 1, na próxima compilação já estará OK. Para que a descrição não sobreponha você precisará colocar espaço, assim o relatório saberá onde quebrar corretamente, neste caso de exemplo tudo está emendado, por isso ele imprime direto, ele está entendendo que é tudo uma palavra só no final. Para sanar o problema das "?", na primeira aba do monitor marque as opções ANSI que estão logo a frente das lacunas onde você informa o arquivo de envio e retorno.

De qualquer forma, segunda-feira tem uma nova compilação semanal e provavelmente ele já estará atualizado, então já vai voltar o acerto.

Vi aqui que você usa: SAT.EnviarCFe(mmsissat.xml) O comando EnviarCFe deve receber o caminho completo do arquivo ou o conteúdo do arquivo, tente passar o caminho completo desse arquivo que você criou entre "" ou passe o conteúdo do arquivo ao comando, faça o teste por favor e reporte.

Problema no firmware da impressora, só eles podem corrigir.

Vou verificar com o Isaque, ele deve ter gerado o executável antes do meu envio de correção.

O recebimento é algo que está por fazer a um bom tempo no componente, isso realmente não está 100% pronto, ele somente grava hoje um arquivo com as mensagens recebidas.

É mais simples ligar no suporte do seu provedor TEF, eles já tem está informação para lhe passar.

Isso mesmo, na verdade fora o Fortes Report e o Fast Report, não é mais dado suporte a nenhum outro desde o Trunk2, isto foi votado aqui no fórum e amplamente discutido. Os usuários pode continuar utilizando sem problemas, mas o core do projeto ACBr não dará suportes em emissores de relatório diferente dos dois citados.

Você não está alterando a versão do layout sem querer em algum momento? Como você está enviando o comando para o monitor, anexe aqui o ent.txt que você envia por favor.

Deve ter algo de errado com seu SAT então, porque está tudo normal com outros usuários, eu acompanho alguns que são consultorias minhas e ninguém reportou nada de errado no monitor. Você está usando um SDK de desenvolvimento, se sim de qual marca? Se não, está usando o emulador?

Veja este link: https://regys.com.br/como-instalar-o-trunk2-do-acbr/

Então o suporte deles entregou que eles não fazem o dever de casa, porque quando se assina um arquivo você garante que determinado arquivo é de uma empresa X, o processo de obtenção do certificado para assinatura é bem chato é você tem que comprovar que você é você, com documentos e em alguns casos eles até ligam, comigo eles sempre depois de enviar tudo, ligam aqui para confirmar, para isso eles não usam qualquer telefone, usam um telefone que esteja em nome da empresa em um diretório público de telefones. Ou seja, existe todo um processo de prova, após assinado, qualquer software que faça verificação, deve olhar o certificado e checar a raiz dele junto a certificadora raiz do certificado, por isso é complicado, se um vírus é assinado, ele precisa de um certificado válido e autenticado, não basta somente um certificado sem raiz validadora ou certificação.

Isso mesmo, basta herdar a classe e sobrescrever ou reescrever um novo método que uso os antigos da forma que você precisa, assim você mantém suas personalizações sem perder as alterações no ACBr, o máximo que irá acontecer e algum método mudar e você precisar adaptar, mas ai neste caso, você mexe na sua herança somente.

Qual é a versão do ACBrMonitorPlus que está utilizando?

1 - A Data e hora de entrada de contingência é a data em que o usuário colocou o sistema em OffLine ou é a mesma da data e hora da emissão ? Data e hora em que o usuário colocou o sistema ou entrou em modo off-line. 2 - Mando imprimir uma vez com propriedade via consumidor em true e a outra vez com a propriedade em false ? Sim. 3 - Na transmissão, não vou fazer em lote, e sim uma a um por um loop, e o envio será um a um, ou seja sincrono. Posso fazer assim ? Depende do seu estado, se ele aceitar sincrono, envie sincrono, se não, envio assincrono. 4 - Acredito que haverá retornos a serem gravados, e devo pega-los por estar em sincrono em ENVIAR ? Os retorno são lidos da mesma forma que uma nota enviada normalmente 5 - O resultado da nota autorizada será cstat=100, ou é diferente os retornos ? Mesma coisa de uma nota enviada normalmente 6 - E pode ocorrer de a nota ser feita offline , e na transmissão ela ser rejeitada ou não autorizada ? Então a nota do cliente fica como ? Não vi casos desse tipo ainda, mas penso que pode variar de UF para UF. 7 - Esse prazo para transmitir os xmls offline é de quanto tempo ? ( pergunto para colocar algum tipo de aviso para o usuário não passar uma semana e dar por conta ) Depende de cada UF, mas o consenso geral previsto em lei é de 24 horas, mas isso pode ser alterado pela UF. Quanto a sua observação, você editou o texto da pergunta, a pergunta anterior era bem diferente desta.

O ACBrMonitorPlus usa o ACBrECF e não o contrário.

Eu comprei por aqui: http://codesigning.ksoftware.net/, não achei nenhum preço exorbitante, muito pelo contrário são bem em conta, na época que comprei o meu paguei algo em torno de 300,00, hoje com o dolar mais alto mesmo assim o de 1 ano fica em torno de 370,00.

Tem algo errado com está impressora ou conexão a ela, veja que o comando é enviado e ocorre o erro, se ela chega a imprimir é algo no retorno que não está legal, então o componente trata o erro como deveria. Você checou os cabos de conexão é drivers Daruma? Tente baixar o buffer de recebimento e envio no driver também. Qual timeout você configurou para o componente?

Esse valor "00000000000017" não é um código EAN válido, parece mais ser um código interno seu, EANs tem obrigatoriamente 8, 13 ou 14 digitos sendo que os 3 primeiros são referentes ao pais de origem do produto. Se você está tentando utilizar seu código próprio seria melhor passar ele sem os zeros a esquerda. Existe uma propriedade no DANFE "UsaCodigoEanImpressao", se ativa ele utiliza a tag Prod.cEAN se desativada ele utiliza a tag Prod.cProd.

Tentou com outros modelos?

Outra possível causa é você estar rodando o ACBrInstall fora do diretório onde baixou o repositório ACBr.

Fique tranquilo, internamente o ACBr resolve os endereços corretos para cada tipo de nota que você enviar, isso no momento do envio. Se você consultar o status por default ele vai consultar a NF-e, para ter o status do servidor da NFC-e precisaria antes de enviar a consulta de status configurar o monitor como emissor de NFC-e, com o comando NFe.SetModeloDF(nModeloDF) passando 55(NF-e) ou 65(NFC-e).

Você está utilizando Trunk ou Trunk2? As alterações do CEST estão somente no Trunk2, não damos mais suporte ao Trunk.