Painel de líderes

ola @João Paulo Müller , é duvida minha também ... O que fiz para tentar esclarecer para todos nós e inclusive pessoal do devel do ACBR, mandei um e-mail para Portal do MDFe do RS, o que é quem cuida do projeto MDFe, fazendo essa pergunta para os mesmos. Tentei contato com a ANTT, mas infelizmente pessoal da ANTT esta mais perdido do que nós. Estou aguardando o retorno da resposta desse questionamento que fiz para o pessoal do RS. Assim que me retornarem vou colocar aqui.

Boa tarde. @-=Ma®©oS=-, obrigado pela ajuda, eu me localizei aqui e consegui iniciar os testes.

Boa tarde a todos, Existe uma briga visível entre a ANTT e a SEFAZ. O componente ACBrMDFe já esta pronto para as alterações publicadas na NT 2020/001 versão 1.03 - MDF-e Integrado. Como também esta pronto e já temos alguns membros aqui do fórum utilizando o componente ACBrCIOT que acessa o webservice do eFrete. Portanto, vamos aos testes.

Olá Pessoal, Noticia publicada no Portal do Conhecimento de Transporte Eletrônico - SVRS - SEFAZ-Virtual do Rio Grande do Sul 09/03/2020 Disponibilizada transação no portal para tomadores de serviços O evento prestação de serviço em desacordo agora pode ser realizado no portal da SVRS com o certificado digital do tomador do serviço. O evento deve ser usado somente nas hipóteses de erro na prestação de serviço em relação a valores ou na identificação equivocada do tomador do serviço. Com certificado digital será possível gerar o evento através da assinatura diretamente no navegador. Para isto o usuário (tomador) deverá utilizar Chrome, com Java atualizado e sem bloqueadores de popup. Será solicitado o download de um arquivo que deverá ser executado pelo usuário. Essa transação atende um pedido histórico das empresas que possuem dificuldade na geração desse evento que permite a substituição do CTe, alterando o tomador do serviço. Para acessar o serviço o tomador deve entrar no site https://dfe-portal.svrs.rs.gov.br/Cte e acessar o link chamado: Prestação de Serviço em Desacordo.

olá , fiz essa pergunta diretamente para o Portal do MDFe do RS, enviando um e-mail, pois tenho essa duvida também e nao tem nenhum lugar com relação a isso.

Olá, Teria como você anexar os xmls da mesma nota gerada que passou? Assim podemos comparar o que funciona com o que não funciona e tentar diagnosticar melhor o problema.

Fazendo a comparação, tem diferença sim no tiposBasico_v1.03.xsd, uma delas é justamente a declaração do TCOrgaoIBGE: Outra coisa que notei é que aparentemente você está misturando os schemas de diversos documentos (GNRE, MDFe, NFe, CTe...). Isso não é recomendado e pode causar problemas pois existem arquivos com mesmo nome, ou versão diferentes. O ideal é separar em pastas como está no repositório.

São os pedidos dos clientes que acabam confundindo a gente. Informando o total do icms não valida a NFe mesmo não. Retirei os valores de ICMS da totalização e validou/autorizou. Muito obrigado pela ajuda!!!

Boa tarde @BigWings.... Unit: ACBrGNREGuiaFRDM Método: procedure TdmACBrGNREFR.CarregaDados; Linha: 170 Na melhoria da impressão da GNRE que eu havia sugerido e vc fez uma modificação para Retrocompatibilidade, acabou ficando com uma pequena falha, no momento do teste, eu não percebi que o SVN não havia sobreposto minha modificação no arquivo local, e acabei testando em cima da minha própria sugestão... Agora que deletei os fontes e baixei novamente, percebi que ficou com falha.. Segue nova sugestão, respeitando a sua alteração anterior, somente a origem da comparação ficou errada... Antes case TipoDocEmitente of Agora : case FieldByName('TipoDocEmitente').AsInteger of Me desculpe pela falha no teste... Fico no aguardo.. Att.: Gustavo Déo ACBrGNREGuiaFRDM.pas

Não é incomum as prefeituras trocarem de provedor do serviço, muda o prefeito e mudam os contratos... O provedor AsessorPublico está implementado, então se é mesmo esse o provedor atual, bastaria alterar no Cidades.ini.

Anexe o arquivo por favor. Eu fiz teste pelo demo em Lazarus e não tive problemas. Na verdade tive sim o mesmo erro. Vi que o @EMBarbosa enviou uma correção para o repositório referente a esse problema. Por favor atualize os fontes e teste novamente.

Também não consegui replicar pelo programa exemplo. Se conseguir crie uma aplicação simples onde o problema ocorra e anexe os fontes aqui.

oi pessoal, confesso que fiquei um pouco preocupado quando vi o componente dando erros, mas aparentemente não deu nenhuma divergencia com meu projeto depois do erro apresentado eu 1- fiz um clean up na pasta do repositorio do acbr com o tortoise 2- recompilei todo o lazarus mandando limpar os dados antigos 3 - removi essa dependencia do projeto: depois disso tudo voltou a funcionar normalmente. então peço desculpas pelo post mas talvez ajude outros que tbm usam LAZARUS

O certo seria rodar o chkdsk. Acho que você não deveria deixar os componentes dentro duma pasta do "Onedrive". Na verdade quanto menor o path melhor. Por isso é melhor algo como "c:\componentes\ACBr\" ou simplesmente "c:\ACBr" se possível.

Olá pessoal, Foi publica a NT 2020/001 do MDF-e e ela já se encontra em nossa biblioteca. Resumo: O projeto MDF-e Integrado tem como objetivo a disponibilização, pelas Secretarias de Fazenda, de uma infraestrutura digital de documentos, legislações e processos voltados para a simplificação da emissão de documentos fiscais eletrônicos de transporte e integração, dentro de um ecossistema digital, que permite às Empresas Transportadoras de Cargas (ETC), Transportadores Autônomos de Cargas (TAC), ANTT, Administradores de Meios de Pagamentos e as próprias Secretarias de Fazenda, o aperfeiçoamento dos seus processos e compartilhamento de informações entre todos estes atores, a partir de um único documento e infraestrutura já consolidada e em uso por todos os envolvidos. Diante desse desafio, as Secretarias de Fazenda e o ENCAT, vêm nos últimos meses e em parceria com os diversos atores intervenientes, adotando uma série de ações estruturantes voltadas para superação das dificuldades atuais enfrentadas pelos órgãos de controle e geração de um ambiente operacional mais eficiente e competitivo, a exemplo das ações descritas abaixo: Aprovação de legislação nacional que normatizou o compartilhamento dos MDF-e dos 27 estados com os órgãos reguladores de transportes; Aprovação de legislação nacional que normatizou a obrigatoriedade de emissão do MDF-e em todas as operações de transporte, sejam elas intermunicipais ou interestaduais; Implantação da plataforma digital e registro de eventos eletrônicos que permitem ao transportador confirmar a entrega da mercadoria ao destinatário, possibilitando assim, a redução do prazo para o recebimento do frete por parte do caminhoneiro; Aprovação de legislação criando a Nota Fiscal Fácil (NFF), que permitirá aos contribuintes que operam com vendas de mercadorias e transportadores autônomos emitirem seus respectivos documentos fiscais de forma simplificada e a partir do seu próprio smartphone, conforme legislação publicada no D.O.U. do dia 19/12/2019 (Ajuste SINIEF No. 37 de 13 de dezembro de 2019); Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TAC-Independente como TAC-Agregado; Automação do processo de fiscalização do Piso Mínimo do Frete (Tabela do Frete), nos termos da Resolução ANTT nº 5.849 de 16 de julho de 2019. Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. Com essa NT temos: - Alterações de schema e regras de validação do MDF-e - Alterações no schema do modal rodoviário no grupo infANTT - Criação do evento de Pagamento da operação de transporte Portanto teremos um evento novo, criação do grupo Produto Predominante <prodPred> na parte geral do MDF-e, alteração no grupo informações do contratante, inclusão dos campos <xNome> e do <idEstrangeiro>, no modal rodoviário foi criado o grupo informações do pagamento do frete <infPag>. Novas Regras de Validação: Se modal rodoviário e indicador de pagamento for a prazo (tag:indPag=1): O grupo de informações a prazo deve ser informado (grupo:infPrazo). Implementação Obrigatória. Gera a Rejeição: 724. Se modal rodoviário, o grupo produto predominante deve estar informado (grupo: prodPred). Implementação Obrigatória. Gera a Rejeição: 725. Se modal rodoviário e MDF-e possuir apenas um DF-e transportado no grupo infDoc: O grupo de informações da carga lotação (infLotacao) deve estar informado. Implementação Facultativa. Gera a Rejeição: 726. Se modal rodoviário e informado grupo de pagamento, rejeitar se CNPJ/CPF do responsável pelo pagamento estiver inválido. Implementação Obrigatória. Gera a Rejeição: 727. Se moda rodoviário e informado grupo de pagamento, rejeitar se CNPJ do IPEF estiver inválido. Implementação Obrigatória. Gera a Rejeição: 728. Vai ocorrer alterações no componente? Sim Vai ocorrer alterações nos schemas? Sim Vou ter que adequar a minha aplicação? Sim Prazos: Ambiente de Homologação: 09/03/2020 Ambiente de Produção: 06/04/2020

O erro ocorre ao instalar, mas recebi agora a licença da Embarcadero. vou iniciar do zero e instalar tudo pelo instalador do acbr. se der erro volto a postar. Grato

Boa tarde pessoal, estive analisando a NT 2020.001 e pude observar que agora será gerado o CIOT automaticamente pelo MDFe. Nesse caso não será mais necessário o preenchimento das tags do grupo <infCIOT> ? Estou em dúvida pois vejo no fórum um fluxo bem grande sobre o componente ACBrCIOT. Esse componente é utilizado para geração do CIOT, confere? Mas se o CIOT será gerado automaticamente pelo MDFe então não será mais necessário o uso deste componente? Há alguma outra necessidade de uso desse componente (ACBrCIOT) ? Vi no fórum o pessoal usando o evento proprietário do veículo, porém não entendi a necessidade do mesmo. Ainda sobre o CIOT, o Italo publicou um tópico sobre a grande preocupação em gerar o CIOT, mas essa informação já não existia anteriormente através do grupo <InfCIOT> ? Outra dúvida que tenho é sobre o grupo <InfPag>, como estão tratando o preenchimento das informações deste grupo? Disponibilizam os campos para o usuário parametrizar ou há alguma integração necessária? Agradeço a atenção.

Você configurou para usar EscPos, mas não definiu as configurações da Impressora em: https://acbr.sourceforge.io/ACBrMonitor/PosPrinter.html

Italo, fiz o teste conforme me indicou. Funcionou direitinho, agradeço muito!

Está sim Juliomar, após algumas pesquisas, consegui resolver... eu havia esquecido de colocar o código dtmOC.cdsManifestoItem.DisableControls; e depois o dtmOC.cdsManifestoItem.EnableControls; Obrigado pelo retorno. Abraços!

Boa tarde Pessoal façam o update para a última revisão do SVN, depois rode o instalador e marquem para apagar tudo. explicação antes ele largava os compilados direto na pasta Lib/LibXX agora ele tem algumas pastas a mais tipo win32, win64 , android etc. como a anterior não foi limpa ou recompilada ela vai existir ali e o Delphi vai confundir. por isso marquem para efetuar a limpeza total do ACBr do micro de vocês garanto que vai funcionar

mantenhas as DLLs do OpenSSL e da LibXML2, na mesma pasta do seu .EXE http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x86/ http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.0.2.21/x86/

deve ser uma forma interna que esse modem codifica os caracteres... o fabricante precisaria fornecer o algoritmo de conversão

ACBrSMSClass.pas

Obrigado pelo Retorno. Legal, assim que obter o retorno compartilhe essa informação conosco. Com relação a InfPag, você já implementou ? Como implementou ou pretende implementar? Estou pensando em disponibilizar os campos para preenchimento do usuário. Existe algum tipo de integração pra facilitar o preenchimento dessas informações?

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

Obrigado Italo. Peço desculpas pela postagem repetida, é que havia pensado que precisava abrir uma outra postagem para o assunto. Irei realizar o teste conforme me indicou.

Boa tarde Celente, A tag Competência existe no layout do RPS dos provedores que seguem a versão 2 do layout do RPS que não é o caso do BHISS que é o da cidade de Porto Alegre que segue a versão 1. Os provedores que seguem a versão 1 do layout da ABRASF tem a tag competência na estrutura da NFS-e não do RPS. Isso explica o motivo de você alimentar o campo e ele não ser gerado no XML do RPS.

function FormaDataHora(ADataHora : String) : TDateTime; begin Result := StrToDateTime(Copy(ADataHora, 7, 2) + '/' + Copy(ADataHora, 4, 2) + '/' + Copy(ADataHora, 1, 2)+' '+ Copy(ADataHora,10,8) ); end; corrigir a função e a agora a data e hora vem correntamento.... segue minha contribuição para comunidade

Podem fechar o tópico achei no manual da nfe que o cotribuinte não preenche é feito pelo fisco então não precisa ter o campo.

Em [x]Harbou não tem mas é simples criar uma classe seguindo o padrão da outras, vou colocar na lista de tarefas aqui.

Com certificado digital não precisa chamar o método login, já pode usar as funções diretamente (Motorista, etc.) Mas acho que precisa fazer o cadastro pra ter o hash.

deve normalizar em breve... veja o aviso na página...

No svn. Obrigado.

Desculpa Italo, farei isso.

Não sei se esse componente tem esse recurso... Já falei com o @Régys Silveira, autor do componente, para sabermos mais...

Assinantes do SAC ou baixar os fontes e compilar no lazarus o SAC tem a opção Trial pra conhece o mesmo. sugiro entrar e ver. de quebra já ajuda o projeto

Via código as margens do FR também são informadas em mm. Apenas no designer o padrão é cm.

Você informa desta forma mesmo na sua rotina, ou usa o método modBCToStr? Pra mim a única explicação seria essa propriedade estar sendo informada como dbiNenhum. Assim geraria a tag em branco no XML.

Eu tirei a tag ICMS no simples e foi imitida. Obrigado.

Só o pacote ACBr_NFCe_DanfeRL foi removido, não o componente. Então visto que seu projeto já utilizava o outro pacote era só remover a dependência deste pacote mesmo. Não tem porque pedir desculpas. Talvez seu passo a passo ajude a outros.

Boa noite. Dando uma olhada rápida. Teu xml está ok. Só deve controlar a numeração de sequencia dos itens. Tipo o tem primeiro item na nota está = 3 e o segundo item está = 4. Onde o correto seria... <det nItem="1"> e <det nItem="2"> , pois voce so tem 2 itens no xml.

Boa Tarde Gustavo. Eu realizei o teste com os códigos do ambiente de produção e então o web service começa a pedir os códigos errados. eu ainda estou testando em ambiente de Homologação. Assim que possível eu realizo o teste em ambiente de Produção. Muito Obrigado pela dica. Tópico resolvido por enquanto.

Anexa o XML, assim fica fácil saber a possível origem do problema.

Olá Pessoal, A SEFAZ-RS resolveu antecipar a liberação do ambiente de homologação. 02/03/2020 Implantada NT 2020.001 em Homologação Informamos que a NT 2020.001 que trata do MDF-e Integrado, encontra-se implantada no ambiente de homologação da SVRS. As regras de validação restritivas 725 e 726 deverão ser ativadas na próxima semana. Quero lembra-los que o componente ACBrMDFe já contempla todas as alterações publicadas na NT 2020/001, o programa exemplo foi alterado para exemplificar os novos campos, grupos bem como o novo evento. Os novos Schemas já estão disponíveis a um bom tempo. Na próxima versão do ACBrMonitor já vai estar disponível a atualização do manual do mesmo que mostra como gerar o arquivo INI do MDF-e com os novos campos e grupos, bem como gerar o arquivo INI do novo evento.

Achei o problema. Mudei a impressora padrão do windows. Grato.

Atualização do windows. vou fechar tópico pois está extenso e depois ninguém vai conseguir se achar. novos problemas, novas dúvidas vamos criar em especifico. já existe sobre essa situação alguns tópicos.