Italo Giurizzato Junior

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

Bom dia Bruno, Fiz uma alteração no arquivo INI do provedor e ainda hoje estarei envia para o repositório. Quem sabe com essa alteração resolve o problema.

Bom dia André, A empresa da BA, vendeu e emitiu a NF-e. A transportadora por sua vez, vai emitir um CT-e relacionando a NF-e, informando como remente a empresa da BA e o destinatário de MG. A transportadora também vai emitir um MDF-e relacionando o CT-e, informando o local de carregamento como sendo BA e o de descarregamento como sendo MG. A emissão do CT-e e do MDF-e no meu entendimento deve ser feita pela transportadora quando o caminhão estiver na BA pronto para voltar para MG. A transportadora emite esses dois documentos e envia por email os PDF do CT-e e do MDF-e para a empresa na BA que prontamente vai imprimir e entregar para o motorista realizar o transporte.

Boa tarde, Ele vai, mas pelo que eu entendi você desenvolve em Delphi e esta fazendo uma aplicação semelhante ao Monitor, correto? Se sim, em anexo o modelo do arquivo INI do BP-e que vai ser utilizado pelo Monitor, bem como os dos eventos. ArqIniBPe.ini Evento_Cancelamento.ini Evento_NaoEmbarque.ini Evento_AlteracaoPoltrona.ini

Boa tarde André, Como o caminhão vai vazio até Bahia, não vejo a necessidade de emitir o MDF-e. No meu entendimento você deve emitir o MDF-e considerando a volta.

Boa tarde Arnaldo, Uma ideia para resolver esse problema. No seu controle de estoque você vai ter um item chamado Madeira. Ao chegar a nota você lança a entrada de 120 m3 do item Madeira, para ficar em conformidade com a nota. Depois através de uma opção especifica, realiza a saída por transferência (por exemplo) dos 120 m3 e ao mesmo tempo a entrada por transferência dos 120 caibros 5x2 e 60 caibros 5,5x2. O lançamento de entrada da nota é um lançamento que deve ser contabilizado. Já os lançamentos de saída e entrada por transferência não, pois não ocorreu alteração no estoque. Por fim quando ocorrer a venda deve-se realizar o lançamento de saída por venda do item vendido. Esse lançamento de venda é lógico que vai ser contabilizado. Espero ter ajudado.

Adilson, No arquivo INI do provedor em questão você acaba descobrindo. A principio os provedores que seguem a versão 1 do layout da ABRASF só oferecem o serviço de envio assíncrono (método Enviar). Já os que seguem a versão 2 costumam oferecer os 3 serviços: envio assíncrono, envio síncrono e o gerar (métodos: Enviar, EnviarSincrono e Gerar). Exemplos: provedor que segue a versão 1 Layout=ABRASFv1 provedor que segue a versão 2 Layout=ABRASFv2 Mas existem provedores que seguem a versão 2, mas não oferecem os 3 serviços como é o caso do TcheInfov2 que só tem o serviço de envio síncrono.

Bom dia Arnaldo, Vamos imaginar uma tora de 6 metros de comprimento e diâmetro de 30 centímetros. O que a madeireira vai extrair dessa tora? Pranchas, sarrafos, caibros, vigotas? Cada uma dessas peças poderá ter o comprimento de 6 metros, mas a largura e altura vão ser diferentes.

Luís, Pelo que entendi, esta ocorrendo erro de validação quando o valor do ISS é zero, correto? Se sim, os Schemas também estão atualizados? O mesmo problema ocorre com o programa exemplo?

Bom dia Adilson, O numero do lote que é gerado no XML deve ser passado como parâmetros pelos métodos Enviar ou EnviarSincrono, veja a sintaxe: function Enviar(ALote: integer; Imprimir: Boolean = True): Boolean; overload; function EnviarSincrono(ALote: Integer; Imprimir: Boolean = True): Boolean; overload;

Bom dia Bárbara, Segundo o arquivo INI do provedor IPM, note que o valor do campo Validar é zero, isso significa que o lote de RPS não vai ser validado, pelo simples fato do provedor não ter disponibilizado os Schemas para validação. Outra coisa, até onde sei esse provedor não requer que o RPS e ou Lote sejam assinados. Você chegou a fazer testes com o programa exemplo?

Bom dia Luís, Você esta com todos os fontes de todas as pastas atualizados?

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

Bom dia Everton, Qual erro? O de tela em branco?

Bom dia Wesley, Muito obrigado pela colaboração, já esta no repositório.

Luciano, Você esta com todos os schemas atualizados? Pois para a versão 3.00 não existe um XSD: tiposGeralCTe-OPENSSL.xsd

Boa tarde Luciano, No segundo XML ocorre erro de validação ou rejeição? Quando ocorre erro de validação o CT-e nem sequer é enviado para a SEFAZ. Já a rejeição é o motivo que a SEFAZ não aceitou o CT-e, logo ele foi enviado mas não foi aceito.

Bom dia Flavio, A cidade Araputanga/MT também se utiliza do provedor RLZ? Se sim, basta você incluir essa cidade no arquivo Cidades.ini aos moldes que foi feito para a cidade Tangara da Serra/MT. Se funcionar, por favor anexe o arquivo Cidades.ini para que possamos enviar para o repositório. Desde já muito obrigado pela colaboração.

Bom dia Everton, Por favor atualize os fontes e faça novos testes.

Bom dia Elaine, Note que no arquivo 55-env-lot-soap.xml a tag hashIdentificador esta vazia. O seu conteúdo é retornado ao solicitar a abertura de uma sessão. Se não esta retornando isso significa que o Identificação do Prestador e ou Senha informados na solicitação de abertura estão incorretos.

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.

Bom dia Cordeiro, Você esta perdendo tempo gerando a chave e passando para o campo ID, o componente ao gerar o XML gera a chave e atribui a chave gerada ao campo ID. Isso é uma segurança, pois muitos comentem erros ao gerar a chave. Se você quer armazenar a chave no banco de dados, é muito fácil, após alimentar o componente execute o método Assinar, este vai gerar o XML, assinar e salvar em disco se for o campo. Depois de executado o método Assinar você lê a campo ID, pronto você tem a chave para armazenar no banco de dados. Outra dica importante, vendo o seu XML notei que você esta atribuindo o numero do BP-e ao código do BP-e ( nBP é igual a cBP ). Isso esta errado e deixa a chave do seu BP-e (Documento Fiscal Eletrônico) fraca. A SEFAZ a partir de 02/09/2019, conforme consta na Nota Técnica 2019/001 não vai mais aceitar NF-e e NFC-e cujo valor de nNF seja igual a cNF. Resumindo as notas vão ser rejeitadas pela regra de validação B03-10 (que consta na NT mencionada acima). Acredito que até o final deste ano ou ano que vem os demais Documentos Fiscais Eletrônicos vão passar também a ter essa regra de validação. Sendo assim, quando for salvar no banco de dados as informações sobre o Bilhete, gere um código aleatório de no máximo 8 dígitos diferente de zero e do numero do bilhete (nBP) e salva junto com os demais dados do bilhete. nBP = é um numero sequencial cBP = é um numero aleatório (página 85 do Manual BPe versão 1.00a) - Código aleatório gerado pelo emitente, com o objetivo de evitar acessos indevidos ao documento. Espero ter ajudado.

Bom dia reij, As informações sobre produtos perigosos no CT-e versão 3.00 só devemos informar se o modal for aéreo, caso contrario não se deve informar. Por outro lado no MDF-e versão 3.00 podemos incluir as informações sobre produtos perigosos para qualquer modal. Checando o manual vigente do MDF-e bem como o novo, pois a partir de 10/2019 entra em vigor um novo layout, em ambos não esta previsto a impressão das informações sobre produtos perigosos.

Bom dia Renan, Em uma de suas postagens você anexou duas versões do Schema: tiposGeralCTe_v3.00 Qual das duas funciona sem nenhum problema com o xsLibXml2 ?