Painel de líderes

Boa Tarde, Resposta do Farmacia Popular depois de varios emails enviados. PREZADO(A), INFORMAMOS QUE ESTAMOS COM INSTABILIDADE POR PARTE DO SISTEMA DO DATASUS REFERENTE AO NOVO DNS. SOLICITAMOS QUE MONITORE, POIS A QUALQUER MOMENTO PODERÁ SER ESTABILIZADO. A EQUIPE TÉCNICA ESTÁ EMPENHADA EM SOLUCIONAR A INSTABILIDADE O MAIS BREVE POSSÍVEL. O DNS ANTIGO NÃO SERÁ DESCONTINUADO ATÉ QUE POSSAMOS SOLUCIONAR A INSTABILIDADE DO NOVO DNS. **** Comunicado Importante *** O DNS ANTIGO NÃO SERÁ DESCONTINUADO ATÉ QUE POSSAMOS SOLUCIONAR A INSTABILIDADE DO NOVO DNS. CASO JULGUE NECESSÁRIO, PODERÁ RETORNAR AO DNS ANTIGO, PORÉM DEVE RETORNAR TAMBÉM O COMPOMENTE DE SEGURANÇA ANTIGO PARA OS TERMINAIS PARA NÃO GERAR DNA DA ESTAÇÃO INVÁLIDO, VERIFIQUE COM O SUPORTE TÉCNICO DO SEU SISTEMA. ASSIM QUE NORMALIZAR ESTAREMOS DEFININDO UMA NOVA DATA PARA ENCERRAMENTO DO DNS ANTIGO, FIQUE ATENTO AO SITE DO PORTAL PARA ACOMPANHAR A NOVA DATA.

A que a gente não tinha o que fazer, então resolvemos dificultar para vocês só por diversão mesmo.

Boa tarde. Estou realizando a importação de um arquivo SPED Fiscal através do componente TACBrSpedFiscalImportar, porém o registro D590 não está implementado. Em anexo está a unit com a modificação que realizei, para que atualize no svn. Obrigado. ACBrEFDBloco_D_Importar.pas

Boa tarde a todos, Neste caso o grupo <percurso> não se faz necessário uma vez que a UF de origem é vizinha da UF de destino. Só devemos informar o percurso quando o caminho tem que passar por um ou mais Estados que estão no meio do caminho entre a UF de origem e destino. Por exemplo UF origem = São Paulo, Destino = Mato Grosso, neste caso o caminhão tem que passar por Mato Grosso do Sul. No Percurso devemos neste exemplo informar somente a UF de Mato Grosso do Sul. O problema é outro, o MDF-e que foi anexado não foi autorizado pelo simples fato de existir um MDF-e que não foi encerrado. Por favor abra o arquivo: 359000464203839-pro-rec.xml Rejeição: Existe MDF-e não encerrado há mais de 30 dias para o emitente [chMDFe Não Encerrada:35181113296533000104580010000001181000000011][NroProtocolo:935180029067468] A chave em negrito é a chave do MDF-e que não foi encerrado. Enquanto esse MDF-e não for encerrado você não vai conseguir autorizar nenhum outro MDF-e.

Bom dia Lucas, Sim, fiz a correção desta forma : ACBrNFe.Configuracoes.Geral.VersaoDF := ve400; ACBrNFe.Configuracoes.Geral.VersaoQRCode := veqr200; Vou fazer o que você sugeriu... obrigado.

Bom dia Dercide, Em qual momento ocorreu esse erro? Esta estranho, pois o XML com o pedido de cancelamento foi gerado e assinado e o XML de retorno foi salvo.

Enviado ao SVN na revisão 16065. Queira por favor testar e reportar qualquer problema. Muito obrigado pela contribuição.

Depende muito de cada caso. Se você não estiver fazendo um loop muito grande talvez não perceba a perda de performance. Mas pode ser que você não tenha percebido porque nunca mediu. Algo útil é usar campos estáticos, (aqueles que você clica com o botão direito e manda adicionar em tempo de design), se existirem. Outra sugestão é criar variáveis que vão conter o campo. Existem muitos artigos sobre FieldByName em Delphi, como esse que você citou. Eu particularmente gosto desses, onde no segundo há algumas sugestões menos ou mais invasivas: https://www.delphitools.info/2010/11/30/fieldbyname-or-why-a-profiler-is-your-friend/ https://web.archive.org/web/20170530222831/http://delphi.about.com/od/database/ss/faster-fieldbyname-delphi-database.htm

Bom dia! Estava com o mesmo problema e resolvi alterando o timeout da requisição: TACBrCTe.Configuracoes.WebServices.TimeOut := 60000; Com essa alteração consegui emitir CT-e e MDF-e sem mais problemas.

Qual valor vc está informando no site http://simuladorposceara.azurewebsites.net ?

Já fiz em vários, RS, SC, MT e deu certo em todos. Na primeira tentativa da erro, na seguinte dá certo. Configuração deve ser Tlsall ou Tls 1.2

Eu sugiro você evitar esse método FieldByName ao máximo. Ele é muito lento e dificulta a manutenção do código. Com respeito ao erro, provavelmente o compilador converteu para string ou algum outro formato. E daí eu o erro mencionado:

Qual arquivo de relatório você está utilizando?

Juliana, Era isto mesmo, já deu certo. Muito obrigado mesmo pela sua boa vontade em em ajudar!

Boa tarde Sergio, Onde devemos editar e alterar o endereço do Portal do MDF-e? Desculpe não entendi.

boa tarde.. italo puxa..verdade.. me esqueci de ver o retorno..que falha minha.. realmente voce tem toda razão.. <?xml version="1.0" encoding="UTF-8"?> <retConsReciMDFe xmlns="http://www.portalfiscal.inf.br/mdfe" versao="3.00"> <tpAmb>1</tpAmb> <verAplic>RS20181016150131</verAplic> <nRec>359000464203839</nRec> <cStat>104</cStat> <xMotivo>Arquivo processado</xMotivo> <cUF>35</cUF> <protMDFe versao="3.00"> <infProt Id="MDFe111220181020503990"> <tpAmb>1</tpAmb> <verAplic>RS20181016150131</verAplic> <chMDFe>35181213296533000104580010000001251000000010</chMDFe> <dhRecbto>2018-12-11T10:20:50-02:00</dhRecbto> <digVal>dfOsO/F3X0hC/yHes0YlWfTxK9Y=</digVal> <cStat>686</cStat> <xMotivo>Rejeição: Existe MDF-e não encerrado há mais de 30 dias para o emitente [chMDFe Não Encerrada:35181113296533000104580010000001181000000011][NroProtocolo:935180029067468]</xMotivo> </infProt> </protMDFe> </retConsReciMDFe>

Boa tarde ALA, Até onde sei se o contribuinte é de MG ao emitir a NF-e, esta deve ser enviada para SEFAZ-MG, correto? Se a SEFAZ-MG esta parada ele pode enviar a nota para a SEFAZ Virtual de Contingência do RS, desta forma a NF-e vai ser autorizada e o XML vai conter o numero do protocolo. Por outro lado não importa qual seja a UF do contribuinte, o MDF-e sempre vai ser enviado para a SEFAZ-RS

Ola! O fonte que usei é este mesmo (https://gist.github.com/luizvaz/43ccbd85b16b6802218b50b6d34c26de), assinou corretamente pelo que parece, mas na hora de enviar a prefeitura não funciona, até mandei MP ao "Luiz Vaz" mas não respondeu, a URL abre no browser mas ao tentar enviar o SOAP retorna com erro 404, deve estar faltando alguma coisa na autenticação da conexão ou algo do tipo.

Boa tarde Luiz, Caso tenha, favor anexar o XML que foi recusado e o que foi autorizado pela SEFAZ para que possamos fazer os ajustes necessários.

O problema é que o componente permite você carregar e depois imprimir várias NF-e de uma vez só. Mas elas saem em arquivos diferentes e não em apenas um arquivo PDF. Então teria que passar uma lista de nomes de arquivos na mesma quantidade de NF-e carregadas. Isso gera uma grande complicação...

Só para complementar, recebemos hoje de manhã a resposta do SEFAZ-RS referente ao problema. Aqui retornou o serviço por volta de 09:30 sem fazermos nenhum procedimento... "Na tarde de ontem, ocorreu uma instabilidade na transmissão de NF-e e NFC-e para a SEFAZ RS. Os servidores da SEFAZ RS estavam com funcionamento normal. As NF-es e NFC-es que chegavam na SEFAZ eram processadas normalmente. O problema que ocorreu foi relacionado ao processo de transmissão. A transmissão de NF-e e NFC-e para a SEFAZ é feita através de 4 canais dedicados da internet. Se esses canais tiverem uma instabilidade, então o processo de transmissão de NF-e e NFC-e poderá ficar instável, mesmo que todo o restante da internet da empresa funcione normalmente. No dia de ontem, ocorreu uma instabilidade em um desses 4 canais dedicados. Isso causou dificuldades de transmissão. Aparentemente, a situação está sendo estabilizada, e a transmissão deve estar voltando a ocorrer normalmente. Peço que nos informem caso o problema de transmissão ainda esteja ocorrendo."

Muito obrigado. Cheguei a colocar essa questão do percurso porem como nao coloquei como obrigatorio pois acabei nao encontrando se era obrigatorio ou nao. Obrigado novamente

Ótimo... Muito Obrigado...

olá Daniel obrigado pelas respostas. Como vc disse, entendo que "zipar", "deszipar" não altera o encoding do arquivo. Porém, se eu subo o arquivo zip para um site que descompacta online, por exemplo: http://online.b1.org/online , o arquivo vem com a codificação correta. Acabei de testar sua solução porém continua dando o mesmo erro. Estou anexando novamente o xml, resultante da sua alteração, para vc avaliar melhor. Observe que o cabeçalho <?xml version="1.0" encoding="UTF-8"?> foi inserido desta vez, porém o arquivo continua com problema no nó: <infCpl>*Conf. Arts. 465 a 469 do RICMS/SP, aprovado pelo Decreto 45.490/00*Não incidência do ICMS conf. Art.7 Inciso XIII do RICMS 45.490/00</infCpl> obrigado pela ajuda. 000000000055725.xml

Solução para o Problema: Aqui no RS tivemos o mesmo problema hoje pela manhã em um único cliente, o qual usa internet da NET. Solicitamos que ele abrisse um chamado junto a net pedindo para trocar ou estabilizar a ROTA a qual trafega até chegar a Sefaz RS, dai a Net estabilizou ou trocou esta ROTA, contornando o problema de imediato. abraços a todos colegas Júlio Moras

Jorge, creio que o problema agora foi corrigido em definitivo... Será necessário apagar o pagamento pendente em sua conta... isso pode ser feito no link abaixo: https://www.projetoacbr.com.br/forum/sac/v2/meuspagamentos e gerar uma nova contratação... https://www.projetoacbr.com.br/forum/sac/v2/cadastro

Bom Dia! Atualizamos os fontes e passamos a receber erro no envio de email da NFSe quando usado o Fortes Report.. Acompanhando a execução notamos que o erro acontecia na linha 123 da unit ACBrNFSeDANFSeRLClass.pas. Reinstalamos os componentes através do ACBrInstall com a opção de remover arquivos antigos mas o erro persistiu. Para testes alteramos na unit ACBrNFSeDANFSeRLClass.pas a linha 123 de "frlDANFSeRLRetrato.SalvarPDF(Self, NFSe, FPArquivoPDF);" para "TfrlDANFSeRLRetrato.SalvarPDF(Self, NFSe, FPArquivoPDF);" e voltou a funcionar (anexo unit alterada). Por favor, podem analisar se o que fizemos foi correto? Grato Delfino ACBrNFSeDANFSeRLClass.pas

O Fato de Zipar, DeZipar, não altera o Encoding de um arquivo... Analisando... O problema ocorre... porque o conteúdo do ZIP está sem a Declaração do XML, no inicio do arquivo... ou seja, falta <'?xml version="1.0" encoding="UTF-8"?'> https://xmlwriter.net/xml_guide/xml_declaration.shtml

Olá, Bom Dia! Como você já fez a correção da versão nas configurações do ACBr: ACBrNFe.Configuracoes.Geral.VersaoDF := ve400; ACBrNFe.Configuracoes.Geral.VersaoQRCode := veqr200; E você não pode deixar de transmitir a SEFAZ essas notas, o ideal é gerar e assinar novamente o XML com os mesmos dados apenas com intuito de modificar somente o campo versão do qrCode, para que as notas possam ser transmitidas corretamente e não haja alteração da Chave de Acesso, Valor, Data Emissão... Att, Lucas L

O melhor seria adicionar um parâmetro NomeDoArquivo no método ImprimirDANFePDF, em vez de criar outra propriedade. Mas você já tentou usar a propriedade NomeDocumento? Se não me engano, ela é a base pro nome do arquivo PDF.

O ACBrInstall_trunk2.exe não cria os BPLs nos diretórios padrões do Delphi... (pois isso causa conflito quando há várias versões do Delphi na mesma máquina) Os BPLs são criados em: \ACBr\Lib\Delphi\LibDxx

Parece ser alguma indisponibilidade desse serviço "OpenPrinter", ou da conexão com a impressora...

Creio que com a Classe ACBrDFeSSL, você consiga realizar essa tarefa... Pode postar um exemplo de XML que você quer assinar ?

Bom dia Daniel, Se tratando de NFS-e precisamos tomar cuidado. Temos o XML do RPS e da NFS-e, é este último que devemos carregar para poder imprimir o DANFSE no papel ou gerar o seu PDF através do método ImprimirPDF. Utilize o programa exemplo para realizar os testes. Ao clicar no botão Imprimir ou PDF selecione o XML referente a NFS-e.

obrigado pela resposta, decidi aguardar um pouco mais para usar o Rio 10.3 tem outros componentes que uso que também ainda não estão compativeis. Obrigado a todos!

Bom dia Danilo, Você esta configurando o componente com o Capicom ou WinCrypt? Se for com Capicom favor testar com WinCrypt.

Bom dia Barrys, Você esta tentando enviar o RPS através do método Gerar, tente através do método Enviar e depois pelo EnviarSincrono.

Em homologação, aparentemente está normal. Fiz uns 30 testes seguidos e nenhum erro de certificado ou time out.

Ok e obrigado, me auxiliou muito.

bom dia este problema persiste, alguém conseguiu resolver este problema? Fiz as seguintes constatações que talvez possam ajudar na resolução deste problema: no método function TRetDistDFeInt.LerXml: boolean;, interceptei a string decodificada no padrão zip e a salvei em um arquivo. Quando passa pela linha abaixo: FdocZip.Items.FInfZip := UnZip(StrDecod); o arquivo zip já está com problemas de encoding, porém se pego este arquivo e descompacto via 7-zip, por exemplo, o mesmo fica com a codificação correta. Logo, concluo que o problema está na ferramenta de descompactação. Atualizei pelo site http://synapse.ararat.cz/doku.php/download porém o problema persiste. Meu próximo teste seria encontrar uma ferramenta no delphi que descompacte corretamente o xml do zip. Os desenvolvedores do ACBR podem nos ajudar neste sentido? Agradeço antecipadamente. 000000000055725.zip 000000000055725-ComErrodeCodificação.xml 000000000055725-Correto.xml

Tenho uma dica temporaria, mas acaba resolvendo. Faz assim, pega a URL do retorno do erro, https://cte.svrs.rs.gov.br/ws/ctestatusservico/CTeStatusServico.asmx Coloca no navegador, vai dar um timeout, ai vai listar algo como: executar o diagnostico de rede, ai vai aparecer o certificado, você aponta e depois testa no seu sistema.. Aqui funciona, mas ai logo cai de novo. Claro, não é a solução definitiva, mas não fazemos ideia de onde está o problema, se é sefaz ou operadoras... Estranho realizar o procedimento acima e passar normalmente, minha sugestão é ligarmos incansavelmente pra sefaz do RS pra tentar relatar o problema.

Acho que ele está se referindo ao posicionamento das informações. Me parece que ele deseja que as informações de log mais recentes sejam mostradas primeiro.

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

deu certo, obrigado!!!!!

Certo. Eu não tenho acesso aos logs do ACBrMonitor, estou tentando ajudar o escritório remotamente. Mas amanhã solicitarei os logs para o pessoal e coloco aqui. Obrigado, por enquanto!

Boa tarde BS, Os arquivos que você anexou se refere ao ambiente de homologação que conforme dito esta funcionando sem nenhum problema. Sendo assim eles não vão ajudar em nada, uma vez que o problema é no ambiente de produção.

Obrigado pelo retorno.

Não. Mas como mencionado nos tópicos, algumas propriedades agora são específicas para as classes que as utilizam. Por exemplo, algumas são específicas para NFC-e, e por isso você não vai conseguir acessá-las diretamente por meio da propriedade "TACBrNFe.DANFE".

Bom dia, Andremomb. Tente alterar a configuração para papel de 48MM para 80MM. Qual a configuração você está utilizando? Veja também:

Existe algumas opções: 1. Extrato direto com as Adquirentes. 2. Arquivo Retorno de Alguma VAN. 3. Ou como nosso amigo Marcelo comentou o Arquivo Retorno da Software Express. 1. Extrato direto com as Adquirentes. O mais trabalhoso... rsrs Provavelmente vc vai precisar solicitar para seu cliente o layout, estuda-lo e implementa-lo no seu sistema. Terá que fazer o download do Extrato Adquirente por Adquirente. Cada Adquirente tem seu próprio modelo/layout, normalmente são dois Arquivos, tem Adquirente que chega a enviar 5 arquivos... 2. Arquivo(s) Retorno de Alguma VAN. Vc vai fechar o contrato com uma VAN, e está fará o processo de realizar o download dos Extratos das Adquirentes, disponibilizando em um único lugar. Facilita pq os extratos estarão em apenas um lugar... Vc também terá o trabalho de interpretar Extrato por Extrato, quero dizer, a CIELO trabalha com um layout, a REDE é outro layout, e por ai vai... 3. Arquivo Retorno da Software Express Procure o comercial deles solicitando informações sobre o módulo de Conciliação. Mas basicamente, a SE irá te retornar um ÚNICO extrato, contento todas as transações. Apenas um layout para vc integrar... show né? xD