Italo Giurizzato Junior

Boa tarde, Realmente tem alguma coisa errada com esse provedor, pois ele deveria retornar o XML da NFS-e ao consultar a NFS-e por Rps, uma vez que no site a nota referente ao Rps enviado foi gerada.

Boa tarde Adelmo, Qual é o receio de usar os schemas que nós disponibilizamos?

Boa tarde, Porque você esta informando o código 50 a UF ?

Bom dia Claudio, Fiz uma pequena mudança e enviei para o SVN.

Bom dia a todos, Já esta implementado o provedor FGMaiss. Favor atualizar os fontes, reinstalem a suíte ACBr usando o ACBrInstall_Trunk2. Por fim façam os testes. Importante, o provedor FGMaiss foi implementado somente no novo componente ACBrNFSeX.

Boa a noite a todos, Já inclui na minha lista de tarefas. Por favor aguardem.

Boa noite Rômulo, Já esta no SVN.

Boa tarde Almeida, Tente realizar uma consulta através do método ConsultarNFSe, neste caso vai ser necessário passar o numero da NFS-e que você obteve com a consulta anterior.

José, Por favor faça um teste com a unit em anexo. ACBrNFSeXProviderABRASFv2.pas

Boa tarde José, Favor anexar o XML de retorno e não colocar ele como texto da postagem. Com o XML de retorno completo fica mais fácil a analise.

Bom dia Sergio, Muito obrigado pela colaboração. Notei que esse provedor se utiliza do mesmo layout do provedor WebFisco que já esta implementado. Vou incluir na minha lista de tarefas, acredito que até o final desta semana teremos uma solução.

Olá pessoal, Abaixo temos a lista de todos os provedores implementados no novo componente. // Provedores que seguem a versão 1 do layout da ABRASF: BHISS, CIGA, DBSeller, DSFSJC, FISSLex, geNFe, Ginfes, GovBr, ISSCuritiba, ISSFortaleza, ISSIntel, ISSNet, Lexsom, MetropolisWeb, Natal, NFSeBrasil, Publica, Recife, RJ, Salvador, SJP, SpeedGov, Thema, Tinus. // Provedores que seguem a versão 2 do layout da ABRASF: ABase, Actcon, Adm, ADPM, AEG, Asten, Centi, Coplan, DataSmart, DeISS, Desenvolve, Digifred, DSF, EloTech, eReceita, fintelISS, Fiorilli, Futurize, Giss, Goiania, GovDigital, iiBrasil, ISSDigital, ISSe, ISSJoinville, Link3, MegaSoft, Mitra, ModernizacaoPublica, NEAInformatica, NotaInteligente, Prodata, PVH, RLZ, Saatri, SafeWeb, SH3, Siam, SiapNet, SiapSistemas, SigCorp, Sigep, SisPMJP, Sistemas4R, SystemPro, TcheInfo, Tecnos, Tributus, VersaTecnologia, Virtual, Vitoria. // Provedores que seguem a versão 1 e 2 do layout da ABRASF: Abaco, Betha, Pronim, SilTecnologia, SimplISS, Tiplan, WebISS. // Provedores que tem layout próprio e também seguem a versão 1 ou 2 do layout da ABRASF: EL, Infisc, SmarAPD. // Provedores que tem layout próprio: Agili, AssessorPublico, Conam, eGoverneISS, Equiplano, GeisWeb, Giap, Governa, IPM, ISSDSF, Lencois, Siat, SigISS, SP, WebFisco.

Boa tarde, Você esta executando o comando abaixo: CTE.ENVIARCTE("C:\integra\nf-e\envio\32210630682959000115670010000000011999999126-cte.xml",1,1,1) Lhe pergunto: O XML esta salvo na pasta: C:\integra\nf-e\envio ?

Boa tarde, A descrição do evento é gerada automaticamente. Até hoje não entendi a necessidade da tag com a descrição uma vez que temos a tag que contem o código do evento. O que deve estar ocorrendo é que a descrição esta sendo gerada de uma forma e no schema esta de outra. Vou verificar e fazer as devidas correções. Como você utiliza o ACBrMonitor, lhe peço para aguardar até o pessoal liberar uma nova versão.

Bom dia Fabiano, Se você se refere ao pagamento a fornecedores, já esta disponível no Trunk2 o componente ACBrPagFor. Tínhamos um projeto inicial chamado ACBrCNAB em desenvolvimento e sendo disponibilizado em um repositório chamado Branches. Ao migrar ele para o Trunk2 a equipe ACBr resolveu trocar o nome para ACBrPagFor. Resumindo o componente ACBrPagFor é um componente que lhe permite gerar um arquivo TXT segundo o layout CNAB com os registros destinados a pagamento de títulos e tributos, ou seja, pagamento a fornecedores. Lhe convido a atualizar os fontes e reinstalar a suíte ACBr, não esqueça de marcar o componente ACBrPagFor. Faça os testes com o programa exemplo e fique a vontade e apontar erros, melhorias e implementação de outros bancos que por ventura o componente ainda não atende.

Bom dia Amauri, O que determina que o Rps vai ser enviado para o ambiente de homologação ou de produção é a configuração do componente. ACBrNFSe.Configuracoes.WebServices.Ambiente A linha que você incluiu na rotina que alimenta o componente com os dados do serviço prestado não se faz necessário. Uma coisa é a configuração do componente e outra e a alimentação dos dados. Note que no programa exemplo na aba WebService temos um quadro chamado "Selecione o Ambiente de Destino" nele temos as opções: Produção e Homologação. Toda vez que fazemos alguma alteração em alguma aba de configuração devemos clicar no botão [Salvar Configurações], caso contrario a alteração não é considerada. Pelo titulo da sua postagem a cidade é Guarulhos/SP, correto? Pois bem, essa cidade se utiliza do provedor Ginfes como diversas outras cidades, você é o primeiro a relatar esse problema de não conseguir enviar para o ambiente de produção. Se você esta fazendo testes com a sua aplicação acredito que antes de enviar você esta configurando o componente e nessa configuração consta que é para enviar para o ambiente de homologação. Procure sempre fazer testes com o programa exemplo, pois ele é o que temos de comum, entre você e nós da ACBr.

Bom dia, Chegou a instalar a Suíte ACBr através do ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada?

ÁLVARO ANTÔNIO DA SILVA BAHIA - COORDENADOR TÉCNICO DO ENCAT 11/06/2021 MDF-e: Lastro Digital Viabilizador do Mercado de Recebíveis de Transportes Você venderia seu carro para um desconhecido recebendo como pagamento um cheque pré-datado para ser liquidado em 30 dias? É evidente que não! Na era do PIX e da Duplicata Escritural, um recebível futuro que não esteja conectado “em tempo real” com seu respectivo lastro, no caso o saldo da conta, não apresenta a segurança necessária exigida pela atual sociedade conectada, muito menos pelo mercado financeiro. Atenta as atuais dificuldades enfrentadas por operadores do mercado de antecipações de recebíveis e a necessidade de ampliação da disponibilização de capital de giro para o segmento de transportes de cargas, em uma modelagem open banking e disruptiva, a Plataforma de Consultas para Antecipações de Recebíveis do Estados (www.placsvba.ba.gov.br), apoiada pelo ENCAT, o CONFAZ e o Ministério da Economia, juntamente com empresas dos segmentos de Registros de Duplicatas Escriturais, Transportadoras e instituições do segmento financeiro, estão desenvolvendo um portfólio de recebíveis de transportes lastreados a partir do Manifesto Eletrônico de Documentos Fiscais (MDF-e). Esta capacidade do MDF-e ser um lastro digital que registra uma operação de transporte devidamente vinculada à confirmação da existência e autenticidade da NF-e que originou a contratação da operação de transporte, conferem ao MDF-e uma condição única e de grande diferencial competitivo em relação a qualquer outro documento que se propõe a atuar como lastro de operações vinculadas aos serviços de transportes. São lastros que consideramos similares a cheques sem fundos, não vinculados aos seus saldos em conta, no caso a NF-e, que possibilitam a emissão de “lastros fictos” de transportes não vinculados aos processos comercias de vendas de mercadorias. Quando nos referimos ao MDF-e não estamos falando de um projeto futuro a ser desenvolvido nos próximos anos e sem escala, nos referimos a um dos melhores ecossistema de documentos fiscais do mundo, onde o MDF-e já é uma realidade implantada há mais de 10 anos, sendo sua utilização e emissão realizada de forma gratuita e sem a cobrança de tarifas para seus usuários, o que já disponibiliza, de imediato, um imenso estoque de recebíveis, sejam estes emitidos por autônomos (caminhoneiros) ou empresas do segmento de transportes, com segurança e atendimento aos requisitos impostos pelo sigilo fiscal das empresas. Toda essa infraestrutura disponibilizada pelas Secretarias de Fazenda dos Estados, trará uma grande oportunidade para financiadores que operam com antecipações de recebíveis, que terão seu raio de atuação ampliado para um gigantesco segmento atualmente inexplorado e com baixo nível de acesso a crédito. Para as Empresas de Transportes, esta nova linha de financiamento disponibilizará um fluxo de capital de giro que suprirá o desencaixe atual entre seus fluxos de recebimentos junto a seus embarcadores e os fluxos de pagamentos realizados para os Transportadores Autônomos contratados, que geralmente recebem a maior parte do frete a vista. Esta grande oportunidade de alavancagem financeira do segmento também trará vantagens para os caminhoneiros, que terão seu mercado de atuação ampliado a partir da capacidade de emissão de seus próprios documentos de transportes (MDF-e e CT-e), o que facilita a contratação direta dos seus serviços, eliminando a necessidade de intermediadores que diminuem suas receitas. Para isto, as Secretarias de Fazenda aprovaram legislação simplificando os documentos de transportes (Ajuste SINIEF 37/2019) e desenvolveram o App da Nota Fiscal Fácil, que já pode ser baixado através das plataformas IOS e Android. Os documentos de transportes emitidos a partir do Aplicativo da Nota Fiscal Fácil (MDF-e e o CT-e), diretamente do smartphone do caminhoneiro, também permitem aos seus contratantes a utilização do crédito do ICMS pago sobre o frete, vantagem tributária que não pode ser disponibilizada por outros tipos de documentos de transportes que venham a operar de forma paralela aos documentos fiscais. Por todas essas vantagens competitivas únicas, o MDF-e se consolida como um lastro digital que opera dentro de um ecossistema de negócios conectados, como o exemplo já citado do PIX. Quanto aos processos desconectados, como o exemplo dos cheques pré-datados, ou outros documentos não vinculados às suas NF-e e créditos do ICMS sobre o frete, já nascem obsoletos, duplicam obrigações, aumentam custos do segmento de transportes e, pior, são incapazes de atender as necessidades dos seus usuários e do implacável “Senhor Mercado”, que sabe fazer conta e julgar as melhores alternativas para manutenção de sua competitividade. ENCAT: Fazer acontecer e inovação são a nossa marca. Se você não viu nossos posts anteriores sobre este tema, publicados nas redes sociais do ENCAT e Portal de DF-e, não deixe de acessar nossas publicações nos canais descritos abaixo: 1) MDF-e: O Suporte Digital da Transformação dos Serviços de Transporte no Brasil (01/04/2021) Twitter: http://www.encat.org/?p=1760 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/2298 2) MDF-e: O Documento que Integra a Venda e a Entrega da Mercadoria (06/04/2021) Twitter: http://www.encat.org/?p=17686 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/2302 3) MDF-e e NFF Lançam Inovador Conceito de ICMS Pré-pago Portal ENCAT: http://www.encat.org/?p=1824 Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/Mdfe/Noticias/2398

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

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

Boa tarde Rômulo, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Carlos, Esse é o problema de querer gerar o XML através da nossa aplicação. Abra esses dois XMLs que você anexou através do Bloco de notas. Você vai notar que você esta gerando o seu XML de forma identada, já o gerado pelo ACBrMonitor segue a recomendação que consta no manual, ou seja, o XML não deve ter quebras de linhas e muito menos estar identado. Como o XML do MDF-e tem duas tags <UF> uma do veiculo e outra do proprietário se o XML estiver identado (que esta errado conforme o manual) teremos problemas na leitura dessa tag.

Bom dia, Com certeza algo esta errado no Ambiente Nacional, pois comparei o XML de envio do evento com a NT e não tem nada que possa esta provocando essa rejeição. Outra coisa, quando ocorre a rejeição 999 ou é falha no webservice ou algo consta no XML de envio que o webservice não compreendei ou não tem uma regra de validação especifica.

Bom dia Carlos, Não entendi direito, você utiliza o componente ou o ACBrMonitor? Quem gera o XML do MDF-e? Você poderia anexar o XML gerado antes e depois de ser assinado?

Bom dia Diego, Muito obrigado pela colaboração, já enviei para o repositório.