Painel de líderes

Olá pessoal! Houve uma alteração na forma como o ACBrMonitorPLUS devolve a informação do nome do XML gerado. Quem utiliza o ACBrMonitorPLUS a muito tempo, provavelmente está acostumado a receber na resposta do mesmo, o nome do arquivo em dois locais diferentes como no exemplo abaixo: OK: C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml Autorizado o uso do CT-e. [Envio] CStat=100 CUF=35 DhRecbto= Msg=Autorizado o uso do CT-e. NProt=123XXX94 NRec= TMed=0 VerAplic=SP-CTe-2024-01-31-2 Versao=SP-CTe-2024-01-31-2 XMotivo=Autorizado o uso do CT-e. Xml=<CTe>...</CTe> [CTe352409XXXXXXXXXXXX395700100000000112147XXXX1] Id= XML= cStat=100 chDFe=352409XXXXXXXXXXXX395700100000000112147XXXX1 dhRecbto=05/02/2024 20:26:22 digVal=XXXXXXXXXXXXXXXXXXXXXXXX35oA= nProt=13XXXXXXXXXX994 tpAmb=1 verAplic=SP-CTe-2024-01-31-2 xMotivo=Autorizado o uso do CT-e. [CTe_Arq1] Arquivo=C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml Vejam que mesmo havendo na resposta uma seção específica para as informações do CT-e autorizado, há um seção [CTe_Arq1] que recebe somente o local onde o arquivo foi gerado. Esta seção [DFe_ArqX] costuma ser gerada no retorno quando assíncrono. Agora, com alguns documentos adotando somente o modo de envio síncrono e visando padronização na forma como está informação é devolvida tanto na resposta do Monitor e na resposta da Lib, está seção foi removida e a informação foi movida para a já existente seção com os dados do documento fiscal com o identificador NomeArq. Então a resposta agora será desta forma: OK: C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml Autorizado o uso do CT-e. [Envio] CStat=100 CUF=35 DhRecbto= Msg=Autorizado o uso do CT-e. NProt=123XXX94 NRec= TMed=0 VerAplic=SP-CTe-2024-01-31-2 Versao=SP-CTe-2024-01-31-2 XMotivo=Autorizado o uso do CT-e. Xml=<CTe>...</CTe> [CTe352409XXXXXXXXXXXX395700100000000112147XXXX1] Id= NomeArq=C:\ACBrMonitorPLUS\Logs\352409XXXXXXXXXXXX395700100000000112147XXXX1-cte.xml XML= cStat=100 chDFe=352409XXXXXXXXXXXX395700100000000112147XXXX1 dhRecbto=05/02/2024 20:26:22 digVal=XXXXXXXXXXXXXXXXXXXXXXXX35oA= nProt=13XXXXXXXXXX994 tpAmb=1 verAplic=SP-CTe-2024-01-31-2 xMotivo=Autorizado o uso do CT-e. Todos os meus retornos foram alterados? Foram alterados os retornos dos comandos de envio dos objetos do CTe e do MDFe, ambos documentos que adotaram somente o modo de envio síncrono.

Boa tarde! Foram disponibilizadas alterações visando a devolução destas informações. A forma como elas são devolvidas foi alterada. Para mais detalhes, por favor, confira: Versões do ACBrMonitorPLUS compiladas depois do dia 10/09/2024 deverão englobar as alterações. As compilações do ACBrMonitorPLUS ocorrem todas as terças na parte da manhã. Assim que for disponibilizada nova versão, por favor, queria atualizar seus Monitor para realizar novos testes e reportar qualquer problema.

Estava tentando encontrar o evento com problema porém acontece somente ás vezes, sem alguma simulação, se encontrar algo trarei.

Boa tarde, Pela mensagem de erro é uma validação de schema, ou seja, alguma coisa na estrutura do arquivo não está correta. Missing child elements quer dizer que deveria ter um conteúdo "filho" de uma parte do arquivo e esse conteúdo não existe. O ideal seria avaliar o arquivo para identificar corretamente o problema.

Bom dia. Fiz um novo modelo de impressão de danfe, para impressão de etiqueta. Tem como inserir no ACBR? Grato ACBrNFeDANFeRLClass.pas ACBrNFeDANFeRLEtiqueta.dfm ACBrNFeDANFeRLEtiqueta.pas pcnConversao.pas

também tem relação com a ACBrLib, pois o OpenSSL é uma dependência externa, carregada de forma dinâmica, pelo código do ACBr

Boa Tarde... sim.. pcesConversaoeSocial.pas

Boa tarde, eu efetuei as alterações sugeridas no programa exemplo e ele responde de maneira mais rápida. O que acho estranho é que minha implementação faz da mesma forma. A única diferença que não alimento o componente ACBRNFe com xml. Eu gero as informações, faço o processo de validar, assinar e transmitir e executo após o envio do e-mail e impressão. Tem um firewall/proxy mas que em tese não deveria influenciar porque no processo do envio propriamente dito o tempo é o mesmo do programa exemplo. Estamos adotando uma nova abordagem para criar vários lotes com somente uma NF até porque logo teremos de implementar o envio em forma síncrona. Logo que for possível testar, darei um feedback!

Boa tarde @gkenji, Esquece o segundo erro, se concentre no primeiro que ao meu ver tem a ver com o CNAB informando, pois o CNAB tem haver com o código da atividade do prestador de serviço. Para mais informações sobre o segundo erro, leia o tópico a seguir:

Boa tarde, apenas para complementar nao encontrei acima. Chegou a testar com o programa exemplo NFe q está em nosso repositório? Outra pergunta.. ai na sua rede tem algum firewall ou servidor proxy? controle de usuarios na rede?

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

Testado no cliente e tudo certo. apenas configurações e ajuste do DV do nosso numero Obrigado pessoal

Top Diegaooo, bela noticia Muito obrigado

Segundo o manual do TLS, temos que passar estes parâmetros ao chamar a função ConfiguraIntSiTefInterativoEx em ParametrosAdicionais

Boa tarde! Apenas complementando a resposta do meu amigo @Alexandre de Paula com uma dica. No comando de envio do e-Social, existe um parâmetro para dizer qual é o grupo aos quais o evento pertence. function TACBreSocial.Enviar(AGrupo: TeSocialGrupo): boolean; begin WebServices.EnvioLote.Clear; result := WebServices.Envia(AGrupo); end; TeSocialGrupo = (egIniciais = 1, egNaoPeriodicos = 2, egPeriodicos = 3); Confirme se está passando o parâmetro correspondente aos eventos que está tentando adicionar. Por exemplo, se você está tentando transmitir o evento S-2200, você deve passar o valor egNaoPeriodicos no parâmetro.

Oi @EMBarbosa. É verdade, pode remover ele. Acabei me esquecendo de retirá-lo. Eu estava utilizando ele pra fazer o loop de cancelamento conforme fosse recebendo os registros pendentes. Daí eu fiz as correções depois e acabei me esquecendo de remover este parâmetro. Segue a correção em anexo ACBrTEFAPICliSiTef.pas

Também acho que não precisamos da propriedade ConfirmarPendente em TACBrTEFResp... a propriedade Confirmar, parece ter a mesma funcionalidade... Como ela é inicializada como False, na criação de TACBrTEFResp, bastaria ligar ela quando a 899-105 estiver True... E deveríamos também usar ela como Boolean e não String

Analisando os fontes sugeridos.. parece haver um "memory leak" em ACBrTEFAPICliSiTef notei uma repetição do código abaixo? if not Assigned(LRespostaTEFPendente) then LRespostaTEFPendente := TACBrTEFRespCliSiTef.Create; e esse objeto LRespostaTEFPendente parece que nunca é destruído... mas adicionado na lista de respostas pendentes, apenas se vier um registrador 1319 Eu achei esse código inseguro, na minha opinião o LRespostaTEFPendente poderia ser criado em um método (uma sub-function)... a adicionar ele na lista, no finaly, se ele não for nulo...

Boa tarde ! As dependências estão instaladas? Tente sudo apt install xvfb xauth libxml2 libgtk2* ttf-mscorefonts-installer

Além da possibilidade que o @Alexandre de Paula citou pode ser que, algumas impressoras vem de fabrica com o emulador prolific para virtualização da com. Algumas Elgin são assim, se vc utilizaro auto teste, vai ver q a comunicação vai estar serial virtual, acaba detectando e dependendo deste drive. o que vc pode fazer é baixar o kit tools da elgin e configurar para USB.

Bom dia @JeannyPaiva, Já esta no SVN.

Bom dia Alexandre, tenho algumas coisas para finalizar ainda, assim que deixar tudo pronto e documentado irei postar. Obrigado

Tente usar o CST cstRep60 ICMS.CST := cstRep60;

Resolvido, obrigado pela ajuda.

Teste realizados junto à SiTEF e finalmente estou homologado. Obrigado a todos! Em especial a @Juliana Tamizou@EMBarbosa@Juliomar Marchetti e @Daniel Simoes pelo brilhante trabalho no código do ACBrTEFAPI e demais componentes, e a toda equipe ACBr. Agora quero homologar no PayGOWeb.

Boa tarde @thi4182, Essa unit é do componente antigo e não estamos mais dando suporte a ele. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX. O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração

Boa tarde @Carmo, Eu sei o que você esta pensando. Vou enviar hoje um arquivo contendo apenas 1 lote no arquivo, este vai ser de numero 0001. Amanhã vou enviar um outro arquivo também com apenas 1 lote, este vai ser de numero 0002. E assim por diante. Mas na minha interpretação da regra não é isso. O numero do primeiro lote de todos os arquivos que você enviar sempre vai ser 0001. Veja como é a estrutura de um arquivo que é enviado ou retornado. Note que todos os arquivos são compostos por um registro Header como numero do lote obrigatoriamente tem que ser 0000 e por um registro Trailer cujo numero do lote obrigatoriamente tem que ser 9999. No componente esses dois registros são o Registro0 e Registro9: Note que ao gerar o Registro0 é definido o valor zero para a variável FQtdeLotes. Entre esses 2 registros temos os registros que compõe o lote, note que podemos ter 1 ou mais lotes. Cada lote vai conter o seu registro de Header (Registro1) e seu registro de Trailer (Registro5) e entre esses 2 registros temos os registros chamados de Segmento. No componente temos: Note que ao gerar o Registro1 que é o Header do lote o FQtdeLotes é incrementado e esse incremento só ocorre ao gerar o Registro1. E esse numero de lote é utilizado por todos os registros que compõe o Lote e também no Registro5 que é o Trailer do lote. Isso diz ao banco que todas essas "linhas" pertence a um único Lote. Se o arquivo possuir um segundo Lote, um novo Registro1 vai ser gerado e consequentemente o seu numero de lote vai ser 2 e todos os seus Segmentos e o Registro5 vão ter como numero do lote igual a 2. Experimente forçar o Registro1 começar com um numero diferente de 1 para o numero do Lote. Use o programa exemplo para esse teste. Na procedure que gera o Registro1 coloque mais um Inc(FQtdeLotes) e faça o teste. Esses fragmentos de códigos acima estão na unit CNAB240.GravarTxtRemessa.

Olá pessoal! No dia 09/09/2024, por volta das 14h41 começamos a receber em nosso Discord múltiplos relatos de problema ao consumir os web services do MDF-e. Todos os relatos tem em comum o mesmo retorno: Vejam que o erro indica ser um problema no banco de dados do servidor. Por volta das 15h06 foi relatado que a transmissão foi normalizada.

Bom dia @Anderson Grolli, Já esta no SVN.

Bom dia @Carmo, Veja a imagem a baixo: Essa é a regra para o campo "Lote". Essa regra deixa claro que devemos informar "0000" ao campo Lote do registro Header e "9999" ao campo Lote do registro Trailer. Um arquivo pode conter um ou mais Lotes e a regra também deixa claro que o campo Lote do primeiro Lote incluído no arquivo tem que receber o valor "0001", caso o arquivo tenha um segundo lote este deve ser de numero "0002" conforme consta na regra. Essa é a minha interpretação da regra acima.

Boa tarde! Sim, você consegue gerar tanto com o A1 quanto com o A3. Dito isso, particularmente recomendo o uso do A1. Com ele você pode utilizar a OpenSSL, não ficando assim dependente de atualizações do windows. O A3 costuma dar dor de cabeça. Neste LINK, no final da página, temos um vídeo falando sobre uma parceria de vendas de certificado junto ao pessoal do ACBr e da TecnoSpeed que pode ser do seu interesse. Caso você já tenha um certificado A3 e esteja enfrentando problemas para transmissão de NFC-e com ele, por favor, forneça mais detalhes com a mensagem de erro na íntegra.

Aqui pra mim estava dando o mesmo erro com Windows 11 no cliente e na minha maquina com o certificado A3, e consegui resolver da seguinte forma: 1- Vá até o Painel de Controle do Windows. 2- Escolha a Opção "Opções da Internet"; 3- Vá até a aba “Avançadas”; 4- No bloco “Configurações”, vá até as últimas opções e deixe configurado como na imagem abaixo: 5- Vá em executar, digite certlm.msc para abrir a interface de certificados, caso esse comando não funcione, utilize o comando certmgr.msc. Remova estes certificados listados na imagem abaixo: 6- Execute como Administrador o InstaladorCadeias_1.0.2.0.exe, clique em Instalar e aguarde até que o processo seja finalizado. 7- Execute o FixCrypto_TLS1_2_Windows.reg. 8- Descompacte o CA.zip e execute o ac soluti ssl ev.cer e o Raiz-icp-brasil v10.cer. 9- Reinicie a máquina e teste novamente a comunicação com a Sefaz.

Olá Pessoal, É com muita satisfação que venho informar a todos que o componente ACBrNFe ganhou novas units para Consultar a Situação de uma nota, solicitar a inutilização de um numero ou faixa de números, enviar eventos e para administrar o CSC (Código de Segurança do Contribuinte) usado na NFC-e, este ultimo não sei informa-los quais UF possuem um webservice para esse serviço. Foram criadas novas units para gerar o XML de pedido de consulta, de inutilização de envio de eventos, bem como as units que fazem a leitura do retorno foram reescritas. Elas se encontram em uma nova pasta: ...\Fontes\ACBrDFe\ACBrNFe\Base\Servicos O que muda na minha aplicação? Nada, pois essas units são utilizadas pelo próprio componente. Porque foram criadas essas novas units? As units antigas se utilizam das units pcnGerador e pcnLeitor para geração e leitura do XML respectivamente. As novas units se utilizam das units ACBrXmlWriter e ACBrXmlReader que tem a mesma função de geração e leitura. Não chegamos a realizar testes de velocidade nessas novas units criadas para o ACBrNFe, mas a um tempo atrás a unit responsável por ler o XML de um CT-e contendo aproximadamente 1.800 (mil e oitocentos) notas vinculadas demorava cerca de 6 minutos para realizar a leitura. Foi criada uma nova unit se utilizando o ACBrXmlReader para realizar a leitura do XML do CT-e, foi realizado um teste com o XML contendo 1.800 notas vinculadas e o mesmo foi lido em aproximadamente 6 segundos. Veja o ganho em velocidade na leitura do XML, de 6 minutos para 6 segundos. Por conta dessa performance resolvemos reescrever todas as units que utilizam as units pcnGerador e pcnLeitor visando a passar a utilizar as units ACBrXmlWriter e ACBrXmlReader. Não é um trabalho fácil e rápido. As novas units foram escritas, foi criado os testes unitários para cada uma delas, depois de testadas fizemos a migração, um trabalho que consumiu varias semanas. Em breve as units antigas vão ser removidas do SVN. Esse trabalho vai ser realizado em outros componentes? Sim, o próximo é o ACBrCTe, depois o ACBrMDFe. Estamos trabalhando para deixar os componentes mais velozes.

Hangout , iniciando Acbrlib integrando com Windev