Italo Giurizzato Junior

Winder, Essa pessoa da SEFAZ que lhe respondeu esta mais por fora do que umbigo de vedete. O grupo <toma4> esta definido no schema chamado cteTiposBasico_v3.00.XSD na linha 453 portanto dentro da definição do tipo TCTe que se encontra na linha 114. Por outro lado o grupo <toma> esta definido na linha 2881, portanto dentro da definição do do tipo TCTeOS que se encontra na linha 2394. Resumindo, se você vai emitir um CT-e o componente se utiliza da definição do tipo TCTe, por outro lado se for emitir um CT-e OS ele se utiliza da definição do tipo TCTeOS e dentro desse tipo não existe o grupo <toma4>.

Boa tarde a todos, A relação das chaves foi incluída para facilitar o fiscal, pois desta forma deixa claro em "papel" quais são as notas referenciadas naquele MDFe. E se não me falha a memória o DAMDFE feito em Fortes Reportes apresenta a cidade e as chaves das notas onde a carga vai ser descarregada.

Boa tarde Windel O grupo <toma4> só existe no CT-e (modelo 57) no CT-e OS (modelo 67) temos o grupo <toma> conforme consta no manual. O grupo <toma> só não é gerado em caso de Excesso de Bagagem, veja no seu XML que a tag <tpServ> tem o valor 6 que significa Transporte de Pessoas, ou seja Fretamento. Logo, devemos gerar o grupo <toma>. Como você informando 9 em indIEToma isso significa que o tomador não é contribuinte, neste caso a tag <IE> dentro do grupo <toma> não deve ser gerada. Se o tomador for contribuinte mas é isento a tag <IE> deve ser gerada com a palavra "ISENTO".

Bom dia, Se não esta gerando a tag <mdfeProc> significa que o MDF-e enviado não foi autorizado. Você precisa configurar o componente para salvar os XMLs secundários. Configuracoes.Geral.Salvar := True Desta forma os arquivos de envio e de retorno da SEFAZ serão salvos em disco, desta forma será possível ver o que esta ocorrendo. Aliais a sua aplicação tem que pegar o status e a descrição do mesmo e apresentar na tela caso seja diferente de 100, pois pode esta ocorrendo uma rejeição e esta não esta sendo apresentada.

Luís, Só existe uma única rotina referente a eventos. Isso que você esta fazendo é uma consulta. Porque você não pega o XML referente ao evento logo após o seu envio? Desta forma você sabe o tipo de evento que se trata o XML, pois se você solicitou o cancelamento, o XML que você vai pegar é o de evento de cancelamento e não de carta de correção por exemplo.

Bom dia Everson, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

ALA, Por favor, procure manter no assunto do tópico, favor pesquisar e se não achar crie um novo tópico para um assunto novo.

Bom dia Avelino, O componente ACBrNFSe permite que você carregue o XML da NFS-e e imprima ou gere o PDF da DANFSE.

Bom dia, Você não achou o programa exemplo do componente eSocial na pasta de Exemplos?

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum.

Bom dia João, Já temos um componente chamado ACBrBPe, inclusive temos um programa exemplo que você deve utilizar para realizar os testes e estudar todas as funcionalidades do componente. Para saber mais sobre o BPe te aconselho a visitar o Portal Nacional do BPe: https://dfe-portal.sefazvirtual.rs.gov.br/BPe Como você pode ver abaixo duas noticias referente a MG que se encontram no Portal. 06/03/2018 Primeiro BP-e autorizado em produção na SEFAZ MG O primeiro BP-e autorizado no ambiente de autorização da SEFAZ Minas Gerais foi da Empresa Gontijo de Transportes com a chave de acesso 31180316624611009873630010000000011650133380 no dia 02/03/2018. 27/02/2018 Disponibilizados Endereços de MG Foram disponibilizados na seção de Serviços do portal os endereços aos webservices de autorização do BP-e do estado de Minas Gerais nos ambientes de homologação e produção. Bons estudos.

Bom dia ALA, Não, todos as empresas emitentes de CT-e ou NF-e, não podem como devem emitir o MDF-e para transporte interestadual e em alguns estados intermunicipal.

Bom dia Luis, Isso esta estranho, pois verificando as duas rotinas que geram o arquivo *-procEventoCTe.xml, ambas estão gerando da mesma forma ou seja na tag <procEventoCTe> esta sendo informado o atributo versão e o NameSpace. A não ser que você esteja extraindo esse grupo do arquivo *-CTeDFe.xml, neste arquivo temos o XML do CTe e a lista de eventos vinculados ao mesmo. No arquivo *-CTeDFe.xml o grupo <procEventoCTe> só possui o atributo versão.

Bom dia Vinício, Isso significa que o que esta escrito na coluna de observação referente ao grupo <infTribFed> podemos desconsiderar?

Boa tarde Luis, Favor anexar os dois XMLs para que possamos analisar melhor.

Boa tarde Bruno, Você costuma configurar o componente via código ou Object Inspector? Se for via código é simples de resolver, basta remover o componente do Form, salvar a aplicação, e incluir ele novamente.

Barrys, O provedor Fiorilli segue a versão 2 do layout da ABRASF, logo ele disponibiliza 3 método para enviar o RPS para o webservice. Enviar, Gerar e EnviarSincrono (idêntico ao enviar só que o envio é no modo síncrono em vez de assíncrono). O Gerar permite o envio de apenas um RPS por vez, já os outros 2 permite o envio de até 50 RPS. Aparentemente esta tudo OK. Entre em contato com o provedor e questione se existe um usuário e senha especifico para o envio em ambiente de homologação.

Boa tarde Barrys, Favor anexar os arquivos *-soap.xml Se eles não estão sendo salvos basta atribuir o valor True a propriedade: Configuracoes.WebServices.Salvar

Boa tarde, Pela imagem notei que o MDF-e foi enviado e aparentemente foi autorizado, abra o arquivo *-mdfe.xml e veja no final dele se consta o protocolo de autorização. O arquivo assinalado com a linha vermelha se refere ao arquivo final do processamento de um evento, abra o arquivo *-procEventoMDFe.xml e note que nele deve constar os dos do evento que você enviou e no final o protocolo que acusa a vinculação do evento ao MDF-e em questão.

Barrys, Me parece que esse é um retorno do provedor. Favor anexar os XML gerados ao realizar o envio. Se não me falha a memória para o provedor Fiorilli é necessário informar o usuário e senha. Apesar da mensagem maluca, acredito que o problema seja esse, é preciso se cadastrar para usar o webservice do provedor, este por sua vez vai fornecer um usuário e senha.

Bom dia Barrys, O problema também ocorre com o programa exemplo? Em vez de libWinCrypt, tentou com libCapicom?

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

Boa tarde Augelias, Realmente teve muitas alterações e com certeza algo saiu do controle. Essa unit que você esta usando e que esta cancelamento normalmente você poderia anexar? Desde já muito obrigado.

Boa tarde Bruno, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório a correção.

Boa tarde Léo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.