Painel de líderes

Bom dia a todos, Se atribuir o valor zero a cNF o Monitor vai gerar um cNF (Código Aleatório da Nota Fiscal) automaticamente. Eu não recomento. A minha sugestão é que a aplicação que gera o arquivo TXT para o Monitor se encarregue de gerar esse código aleatório com no máximo 8 dígitos maior que zero e salve no banco de dados juntamente com os demais dados da nota. Quando for gerar o arquivo TXT pegue o código aleatório e atribua ao campo cNF. No meu entendimento esse é o procedimento correto.

Boa tarde Heto, Feito, bastava alterar o arquivo Cidades.ini, favor atualizar todos os fontes de todas as pastas. Inicie os testes com o programa exemplo.

Vc viu o exemplo q postei acima?

Tive que fazer algumas alterações para que seu comando fosse aceito. Verifique principalmente a parte de pagamentos. exemplo-sat.txt

As URL de produção ainda não estão no componente, ainda nem foram divulgadas. Quando o ACBr não encontra a URL para a versão 4.00 ele pega a URL da versão anterior, no caso a 3.10. O cabeçalho do XML enviado na versão 4.00 é diferente, por isso o erro de Schema. Para funcionar na versão 4.00 você deve testar em homologação e só precisa configurar a propriedade SSLType como LT_TLSv1_2.

Já abri um protocolo, assim que me responderem posto aqui, mais, se alguém mais quiser entrar na fila. Contato 4000-1230 - Abrir chamado [email protected] Departamento de TI. [email protected]

https://github.com/ACBrNet/ACBr.Net.Sat

Boa tarde, descobri o problema das dlls, era isso ao ativar o sat o monitor ficava aguardando o sat que nao era encontrado fazendo com que parasse de responder. Um outro problema era de conflitos de portas com a impressora e o sat, desinstalando os drivers e instalando novamente resolveu, quanto as dlls so foi copiar a bemaSat32.dll para mesma pasta do monitor que funcionou...

Fiz isso. Obrigado pela força.

Quem comunica com o SAT é o monitor, nesse caso se for necessário no mesmo diretório dele. Mas veja no tópico citado sobre o OpenSSL e TLS, tem um tópico relacionado que diz onde no Windows as DLLs devem ser colocadas.

Bom dia pessoal do ACBr, Estava com o problema e aparentemente não tinha solução.. Porém, ontem ao fazer uma nova atualização dos fontes do ACBr e compilar novamente o projeto ACBrMail, funcionou perfeitamente o envio pelo servidor próprio. O engraçado foi que não mexi em nada nem nos fontes atualizados, nem nas configurações de acesso. Isso me faz crer que era alguma coisa nos fontes que foi corrigida. Agora, está tudo funcionando perfeitamente. Achei pertinente avisar, para podermos colocar o tópico como resolvido! Obrigado a todos que colaboraram. Um abraço!

Boa noite @Juliomar Marchetti. Realmente esta com grandes diferenças. Quando fui homologar com a Caixa também achei isso. Se analisar os arquivos Boleto.fr3 e o BoletoNovo.fr3 (no svn) você vai constatar grandes diferenças também. Homologuei o BoletoNovo.fr3 pela Caixa e passou de primeira. Mas o BoletoFatura.fr3 tive que modificar. Quanto ao arquivo comentado aqui, sugiro que modifique para BoletoFaturaNovo.fr3 no lugar de BoletoFatura.fr3 mantendo os 2 arquivos. Assim os usuários poderá escolher o que melhor atende o Banco X ou Y. Para complementar, segue abaixo o texto da homologação com o arquivo original (BoletoFatura.fr3) para você analisar e tirar as conclusões finais: Um forte abraço. Fábio Gabriel

Bom dia Jeferson, Entendo perfeitamente, também concordo que devemos fazer um software PAI - Programa a prova de imbecil. Mas esse camarada que alterou o XML de uma nota de entrada, fez isso com qual intensão? Se ele é capaz de fazer isso imagina o que mais ele é capaz de fazer se tiver acesso livre ao banco de dados. Ou ela fez isso para te ferrar ou ferrar o dono da empresa, logo não é uma pessoa confiável.

Convenhamos, mesmo que você gere o arquivo... como você espera subir para um WebService, um arquivo de Estoque "monstro" com 40mil itens ? OK.. isso não é culpa sua.. é na verdade do SEFAZ de SC, que aparentemente não pensou nesse detalhe... (mesmo com compactação, o arquivo continuará muito grande para ser transmitido em uma requisição HTTP/POST)

Sugiro, usar a solução do ACBr, removendo a sua solução do seu aplicativo.

Do change-log do componente para Fast: No para Fortes: Sugiro que visite os tópicos destacados.

Salvem o arquivo no diretório do Demo do ACBr e testem. ACBrNFeServicos.ini

Estava com o mesmo erro de vocês. Entrei em contato com o SEFAZ-GO e me informaram que foram alterados os endereços. Recebi o e-mail abaixo. NFeAutorizacao - https://homolog.sefaz.go.gov.br/nfe/services/NFeAutorizacao4?wsdl NFeRetAutorizacao - https://homolog.sefaz.go.gov.br/nfe/services/NFeRetAutorizacao4?wsdl RecepcaoEvento - https://homolog.sefaz.go.gov.br/nfe/services/NFeRecepcaoEvento4?wsdl NFeInutilizacao - https://homolog.sefaz.go.gov.br/nfe/services/NFeInutilizacao4?wsdl NFeConsultaProtocolo - https://homolog.sefaz.go.gov.br/nfe/services/NFeConsultaProtocolo4?wsdl NFeStatusServico - https://homolog.sefaz.go.gov.br/nfe/services/NFeStatusServico4?wsdl NfeConsultaCadastro - https://homolog.sefaz.go.gov.br/nfe/services/CadConsultaCadastro4?wsdl -- Antonio Carlos G. Godoi Gerência de Informações Econômico-Fiscais - GIEF Coordenação de Documentos Fiscais SEFAZ/GO

Estou com o seguinte erro no próprio demo Cabeçalho - falha no Schema XML, estou testando a versão 4.00, atualizei hoje também os fontes

Verifique se o campo RespostaPagamentoMFe.StatusPagamento está com o valor SalvoEmArmazenamentoLocal E não precisa fazer o passo 2 se a resposta do EnviarPagamento for SalvoEmArmazenamentoLocal

Só esclarecendo. Eu estava fazendo testes porque achei que o ambiante de homologação já estava funcionando por causa dessa notificação que recebi da receita: 08 junho, 2017 ERICK EVANGELISTA DO AMARAL CPF 003.352.969-80 NF-e e NFC-e, versão 4.00, em ambiente de homologação A Receita Estadual do Paraná informa aos contribuintes emissores de Nota Fiscal Eletrônica (NF-e) e Nota Fiscal do Consumidor Eletrônico (NFC-e), que foi publicada a nova versão do sistema autorizador de NF-e e NFC-e, versão 4.00, em ambiente de homologação. Essa nova versão contém as alterações previstas na Nota Técnica 2016.002, versão 1.10. Abaixo os novos endereços dos serviços 4.00: NF-e https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeStatusServico4 https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeAutorizacao4 https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeConsultaProtocolo4 https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeInutilizacao4 https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeRecepcaoEvento4 https://homologacao.nfe.sefa.pr.gov.br/nfe/NFeRetAutorizacao4 https://homologacao.nfe.se fa.pr.gov.br/nfe/CadConsultaCadastro4 NFC-e https://homologacao.nfce.sefa.pr.gov.br/nfce/NFeStatusServico4 https://homologacao.nfce.sefa.pr.gov.br/nfce/NFeAutorizacao4 https://homologacao.nfce.sefa.pr.gov.br/nfce/NFeConsultaProtocolo4 https://homologacao.nfce.sefa.pr.gov.br/nfce/NFeInutilizacao4 https://homologacao.nfce.sefa.pr.gov.br/nfce/NFeRecepcaoEvento4 https://homologacao.nfce.sefa.pr.gov.br/nfce/NFeRetAutorizacao4 https://homologacao.nfce.sefa.pr.gov.br/nfce/CadConsultaCadastro4 Atenciosamente, Coordenação da Receita do Estado Secretaria de Estado da Fazenda do Paraná

Boa tarde a todos, Segundo a Nota Técnica 2016/002 versão 1.20 - a data de liberação do ambiente de homologação foi alterada para 03/07/2017.

O mesmo problema com Delphi Seatle para resolver tive que pegar midas.dll da pasta bin e colocar na pasta System32, SysWOW64 e na pasta do Meu Projeto

Apague o ponto.

Tive o Mesmo problema com o Delphi Seattle. Para resolver eu troquei midas.dll que estava na pasta SYSTEM e copiei a que estava na pasta do Delphi

Sou do Paraná e até onde sei o servidor de homologação aqui era para estar funcionando. Utilizo ACBr MonitorPLUS Ver.1.1.0.8 e também estou tento o mesmo retorno, será que fiz algo de errado? [ENVIO] Versao=PR-v3_8_3 TpAmb=2 VerAplic=PR-v3_8_3 CStat=242 XMotivo=Cabecalho - Falha no Schema XML CUF=41 NRec= DhRecbto=27/06/2017 11:16:40 TMed=0 Recibo= 41170627764801000180550010000000011000000017-nfe.xml