Italo Giurizzato Junior

Boa tarde Renan, Muito obrigado pela colaboração, já foi enviado para o repositório.

Bom dia Túlio, Muito obrigado pela contribuição, já esta no repositório.

Bom dia Antônio, É a idade kkkk. Já fiz a correção e estou enviando para o repositório, muito obrigado.

Bom dia Gustavo, As suas duas contribuições acima foram aceita e enviadas para o repositório.

Bom dia ALA, O arquivo Cidades.ini não contem nenhuma alteração para o novo provedor. Não entendi porque você anexou o arquivo.

Bom dia Gustavo, Muito obrigado pela colaboração, assim que possível vou analisar e estando tudo OK, vou enviar para o repositório.

Já esta no repositório o arquivo Cidades.ini corrigido.

Bom dia Antônio, Desculpe não ficou claro. Qual seria o valor correto do campo NomeURL_H ?

Bom dia Leonard, Qual é a configuração que você esta utilizando no programa exemplo?

Bom dia Orlando, Quando o MDF-e foi criado, o seu objetivo era ser emitido somente para transporte interestadual para facilitar e agilizar a fiscalização nas fronteiras entres os Estados. Mas agora a legislação mudou, portanto devemos emitir o MDF-e para qualquer transporte, seja ele interestadual ou intermunicipal. O transporte é sempre uma cidade e outra, mas quando eles se encontram em Estados diferentes é dito transporte interestadual e quando elas estão dentro do mesmo Estado é dito intermunicipal.

Bom dia Gabriel, Favor anexar o XML referente ao pedido de cadastramento de veiculo.

Bom dia, Vou alterar o arquivo INI e enviar para o repositório. Muito obrigado pela colaboração.

Boa noite Reinaldo, Por favor tenha um pouco mais de paciência, pois somente a partir do dia 09/03/2020 é que a SEFAZ vai liberar o ambiente de homologação com essas alterações. E somente a partir do dia 06/04/2020 o ambiente de produção. Logo não faz nenhum sentido você querer gerar o arquivo INI com essas informações sendo que os ambientes não estão prontos para processar um MDF-e com elas. Semana que vem (02-06/03/2020) vou estar atualizando o manual do ACBrMonitor. Nessa atualização vou mostrar como e onde informar os novos campos e grupos bem como o novo evento que se refere ao pagamento de frete.

Boa tarde Marcio, No que se refere as informações bancarias (grupo <infBanc>) devemos informar os campos: <codBanco> e <codAgencia> ou o <CNPJIPEF> Logo se você vai informar o código do banco e agencia deve-se deixar o campo CNPJIPEF em branco (vazio), por tanto não deve preencher o mesmo com zeros. A mensagem "Informar os zeros não significativos" significa que se for informado o CNPJ devemos acrescentar zeros a esquerda até que a informação tenha 14 dígitos.

Olá Pessoal, Foi publicado a versão 1.02 da NT 2020/001 referente as alterações no layout do MDF-e. O que mudou da versão anterior para esta? Apenas a redação das Regras de Validação do MDF-e, veja quadro abaixo a nova redação. Com relação ao resto, nada foi alterado e as datas para ativação continuam as mesmas.

Se você estiver com todos os fontes de todas as pastas atualizados, vai notar que no arquivo Cidades.ini a cidade de Catanduva/SP se utiliza do provedor Pronimv2.

Bom dia a todos, Pelo que eu notei essa nova versão da NT o que muda é a redação das regras de validação do MDF-e na SEFAZ. Essas regras se encontram na página 10 item 4.

Bom dia Barrys, O provedor Pronim possui 2 webservices: Pronim (que segue a versão 1 do layout da ABRASF) e o Pronimv2 (que segue a versão 2). Como você não informou a cidade não sei lhe informar se você deve usar o Pronim ou Pronimv2. Se for o Pronim o único método de envio é o Enviar. Tenha em mente que o GerarLote só serve para gerar e salvar em disco o Lote de RPS. Devemos usar esse método quando o provedor não possui um webservice para recepcionar, mas possui em seu site uma opção para importar o XML referente ao Lote. Agora se for o Pronimv2 temos a nossa disposição os métodos: Enviar, EnviarSincrono e Gerar. Lembrando que o Gerar permite o envio de apenas 1 RPS, já os outros dois podemos enviar um Lote com até 50 RPS.

Bom dia Gustavo, Eu particularmente não utilizo o componente, mas se dessa forma você esta conseguindo pegar as informações da guia para poder imprimi-la, então esta correto. Quanto ao nome do arquivo, acredito que não foi implementando nenhum campo que traz o nome do arquivo que contem os dados da guia.

Bom dia Gustavo, Se o ambiente de Produção esta funcionando, podemos descartar que o componente possua algum problema. Logo repito, favor entrar em contato com os responsáveis pelo webservice do GNRE da UF em questão e relata o problema que esta ocorrendo no ambiente de homologação.

Boa tarde a todos, Não sei se vai resolver o problema, mas fica ai a dica:

Boa tarde Ana, Esse grupo se refere ao proprietário do veiculo. No manual além desses campos tem mais alguns que devem ser gerados?

Boa tarde rlmariz, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e faça novos testes.

Olá Pessoal, O método Consultar agora possui um novo parâmetro chamado: AExtrairEventos. function Consultar(const AChave: String = ''; AExtrairEventos: Boolean = False) ; Boolean; Para quem utiliza os métodos direto da classe WebServices, deve acrescentar a seguinte linha: (...).WebServices.Consulta.ExtrairEventos := True ou False; O que ocorre quando o campo ExtrairEventos possui o valor True? Simples, quando realizamos um consulta a um DF-e além de retornar a sua situação é retornado também alguns eventos vinculados a ele, como por exemplo o evento de cancelamento. Se o valor de ExtrairEventos for True o método Consultar vai se encarregar de verificar se no retorno contem eventos, caso afirmativo eles serão extraídos e salvos em disco nas pastas conforme o seu tipo. Por exemplo, se no retorno tivermos o evento de cancelamento, será salvo na pasta: ...\Evento\Cancelamento o arquivo *-procEventoNFe.xml (caso estejamos consultando uma NF-e). Essa nova funcionalidade esta disponível nos componentes: ACBrBPe, ACBrCTe, ACBrMDFe, ACBrNF3e e ACBrNFe. Em breve tanto o ACBrMonitor quanto o ACBrLib vão passar a ter também essa funcionalidade. O que eu ganho com essa nova funcionalidade no método Consultar. Vamos supor que o seu cliente venha perder o XML da nota por exemplo, neste caso basta você ler os dados da nota do banco de dados, gerar e assinar o XML e por fim realizar uma consulta com o XML carregado, desta forma ao realizar a consulta a SEFAZ vai retornar o protocolo de autorização e o componente se encarrega de atualizar o XML acrescentando o protocolo nele, deixando-o assim um documento com validade jurídica. Mas se o seu cliente perder o XML de um evento como por exemplo o de cancelamento, não tinha como refazer o mesmo, pois não temos um método para consultar eventos, aliais a SEFAZ não possui um serviço para esse fim. Como dito acima o Consultar além de retornar a situação do documento e retorna também alguns eventos. Antes o componente ignorava esse conteúdo, mas agora foi implementado a extração dos eventos. Resumindo caso o seu cliente venha perder o XML de um evento (*-procEventoNFe.xml), lembre-se que o método Consultar pode recuperar ele novamente, desde que esse tipo de evento que foi perdido é retornado pelo Consultar. Espero que tenham gostado dessa nova funcionalidade.

Bom dia Ana, Informações do Transportador no MDF-e? Quais tags?