Cristiano Caritá

Testei aqui com as mesmas configurações suas (Certificado A3 - Envio em Homologação - NFe 4.0 - Ceará - winCrypt). O resultado foi: Usando SSLType=LT_All -> Erro HTTP 403 (o mesmo erro para homologação e produção) Usando SSLType=LT_TLSv1_2 -> Funcionou perfeitamente (tanto para o webservice de homologação quanto para o de produção) Por favor experimente fazer o teste em outro computador.

Uma coisa importante que notei nos meus testes é que se você colocar SSLType=LT_all (que teoricamente deveria funcionar nesses casos) muitas vezes ocorre esse problema. (vivenciei isso ao tentar consultar um cadastro de empresa situada em SP). Para funcionar corretamente você precisa colocar especificamente SSLType=LT_TLSv1_2 (lembrando de usar cryWinCrypt, httpWinHttp e xslibXML2) Faça o teste aí e diga se funcionou.

Campos Currency não possuem erros de arredondamento por definição, até o limite de 4 casas decimais. Não faz sentido trocar para Double, que é passível de erro de arredondamento. Deve haver alguma anomalia no código da sua rotina.

Pelo que me lembro da discussão a respeito, o problema é passível de ocorrer quando se utilizar como parametro do SSLXmlSignLib o MsXml, XmlSec ou Capicom, sendo que se fica "livre" do problema se usar a LibXml2. Qual a sua configuração no SSLXmlSignLib?

https://cfesat.wordpress.com/2016/04/07/resposta-a-consulta-tributaria-54932015-de-18-de-dezembro-de-2015/

Como sugestão, caso seja possível tecnicamente, seria bom criar um repositório-espelho no Github ou similar (nem que esse seja somente para leitura, podendo fazer alterações no ACBr somente via Sourceforge) para o caso de acontecer novamente o problema com o Sourceforge. O que acham?

Interessante notar que para o ambiente de Homologação, a data da Última Verificação é: 15/02/2018 04:05:02 Já para o ambiente de Produção, os dados estão sendo atualizados corretamente...

Basta substituir o uso do ConsNFeDest (que foi desativado pela sefaz) pela DistribuicaoDFe.

O problema é que no relógio do computador não está marcado "Ajustar automaticamente o relógio para Horário de verão". Quando é marcado essa opção, o timezone interno muda automaticamente para GMT -02:00 durante o horário de verão, daí não dá problema. Ocorre frequentemente do Windows não estar atualizado, daí as datas do horário de verão não baterem com o real e dar problema na definição do timezone vigente.

Infelizmente, ou você economiza papel ou economiza tempo. Nesse caso não dá para ter os dois simultaneamente...

Infelizmente não é possível imprimir qualquer coisa ao lado do QR-CODE (ou qualquer outro tipo de código de barras) via comandos ESC/POS. Só compondo como imagem via um gerador de relatórios (Fortes/Fast/etc)

Isso é exatamente o que eu faço. Veja minha explicação neste tópico (dia 12/01/2018)

Por favor consulte o tópico abaixo: https://www.projetoacbr.com.br/forum/topic/40765-chave-duplicata-mas-diferente/

Já olhou o espaço disponível na partição do HD onde está sendo salvo o log e/ou arquivos xml?

Interessante é que eu uso rotineiramente 3 casas decimais (para itens vendidos por kg) e nunca tive esse tipo de problema. Por favor verifique se o arredondamento adequado está sendo feito ao salvar os dados no banco de dados. Preferencialmente, evite o uso de ponto flutuante nos campos que armazenam valores no banco de dados (use decimal, money, currency ou equivalente para evitar erros de arredondamento)

Arredonde para duas casas decimais o valor que você pegou do banco de dados quando for associar à propriedade qCom no produto da NFe. Isso é um problema comum nas variáveis de ponto flutuante.

É importante salientar que a passagem do preço/kg para a balança somente é possível se a balança estiver configurada para usar o protocolo Prt5

Daniel, eu já havia feito essa modificação no passado. O fluxo é o seguinte: 1) Seleciona-se o produto no PDV, que caso seja produto vendido a peso, abre-se uma janela pedindo para colocar o produto na balança. O envio do preço/kg do produto é mandado para a balança nesse momento. 2) O produto é colocado na balança, que mostra para o cliente o preço/kg, o peso do produto e mostra também no display da balança o valor total em R$ a ser pago, facilitando a visualização pelo consumidor (isso é que é útil). Por exemplo numa sorveteria, onde o produto é pesado à vista do consumidor. 3) É feita a leitura do peso normalmente, seguido do registro do item e segue para o próximo produto.

O que eu faço é o seguinte: Para evitar uma grande quantidade de NFC-e marcados para cancelamento/inutilização, caso encontre uma falha de comunicação ou timeout, mudo para modo de emissão em contingência, e só dali a 5 minutos a partir do início da entrada em contingência (isso deixo configurável) o programa vai tentar mudar novamente para modo de emissão online. Para habilitar novamente o modo de emissão online, eu testo antes o status do webservice para ver se está em operação. Se não estiver, testo novamente dali a 5 minutos, e assim por diante. Ao retornar ao modo online, o sistema envia automaticamente os NFC-e que ficaram em contingência e que ainda não foram transmitidos e também faz a inutilização/cancelamento daqueles que tiveram a numeração pulada, Isso diminui drasticamente a quantidade de NFc-e pendentes de inutilização/cancelamento. Note que se ao tentar enviar o NFC-e retornar código de erro 12007, não é necessário pular a numeração, pois nesse caso a requisição ao webservice nem chegou a ir para a internet.

Recomendo a todos que leiam o texto apresentado no link abaixo, que trata da compatibilidade de certificados no padrão SHA2 (CNG – Cryptography Next Generation) com o Windows 2003/XP: https://uilson76.wordpress.com/2014/08/15/certificados-sha2-e-ca-windows-server-2003/

Basta o SAT estar conectado. Ela não depende do computador para fazer o envio dos dados.

Parece que o SAT da Dimep tem um driver Android: ftp://dsat.dimep.com.br/dsat/5%20-%20Driver%20Android.zip

O Fisco, pelo que entendi, respondeu que deve ser impresso após o extrato, ou seja, não se deve mexer no extrato. O que quiser imprimir a mais não pode ser no "meio" do extrato, mas sim após ele.

Se o SAT é do cliente, então deve ser SAT de produção. Não é possível usar o SAT de produção em modo de homologação.

O emulador do SAT é bugado nessa parte de troco. Na fase de testes eu tive o mesmo problema com ele (até troco negativo eu vi). No SAT real esse problema de troco não ocorre.