Italo Giurizzato Junior

Boa tarde, Mais um contador que andou bebendo gasolina.

Paulo, Realmente não consta nas NT a data de fim da versão 1.00, mas pelo relato de colegas no fórum assim que começou a versão 1.00a a 1.00 foi paralisada. O pessoal só consegui emitir o MDF-e na versão 1.00a

Boa tarde Osmar, O Valida, compara o XML gerado pelo componente com os schemas. Acusa por exemplo se um campo string tem menos que o minimo de caracteres ou mais do que o máximo definido. Acusa também a ausência de uma informação obrigatória. Um exemplo o CNPJ tem que possuir 14 dígitos caso este tenha 13 ou 15 o Valida vai apresentar a falha, mas se o mesmo tiver 14 não é capaz de informar se o mesmo é valido ou não. Quem faz isso é o validador da receita que valida o CNPJ (realiza o calculo dos dígitos verificadores) checa se a IE informada se refere ao CNPJ, entre outras coisas, caso encontre alguma irregularidade a SEFAZ nos retorna uma Rejeição. Sendo assim uma coisa é a falha na validação apontada pelo componente e que neste caso a nota nem sequer foi enviada e outra coisa é a Rejeição retornada pela SEFAZ, onde ocorreu o envio e a mesma não aceitou a nota por conter irregularidades. Neste caso basta sanar os problemas, informado os dados corretos ou fazendo os cálculos de forma correta e enviar novamente.

Boa tarde Paulo, A versão 1.00 não é mais aceita pela SEFAZ. Configure o componente para a versão 1.00a e desenvolva a sua aplicação. A grande maioria do que foi adicionado na versão 1.00a é opcional, logo da para você desenvolver a sua aplicação de forma simples e depois vai melhorando. A versão 1.00a passou a ser aceita no ambiente de produção em 01/12/2013.

Boa tarde, Houve uma alteração que não permite mais corrigir a chave de uma NF-e informada como documento originário, ou seja, grupo: infNFe, campo: chave. Essa alteração entrara em vigor em ambiente de produção de 01/08/2014 até 01/09/2014. Mas a Nota Técnica 2014/001 que traz essa informação não faz referencia a nenhum campo do grupo infNF.

Bom dia Wislei, Na versão feita em Quick Report, caso cUnid for Tonelada o valor de qCarga é multiplicado por mil para ficar em conformidade com o título do quadro: Peso Total (Kg). Ao meu ver ou fazer algo semelhante na versão em Fast Report ou dependendo do valor de cUnid alterar o título do quadro. Deixar somente como título: Peso Total e abaixo apresentar o peso sem informar a unidade fica complicado.

Valdir, Não tem nenhuma tabela nesse sentido. A conselho você ter em sua aplicação uma tabela de configuração, onde uma delas seria o formato da alíquota.

Bom dia, Primeiramente, peço para que não inclua no texto da sua postagem o código fonte, post ele como anexo como você fez com o XML. Desta forma a sua postagem fica mais curta. Respondendo a sua pergunta: Um MDF-e só pode contem CT-e ou NF-e não pode ter ambos modelos de documentos em um mesmo MDF-e. Normalmente um MDF-e emitido por uma transportadora só vai constar CT-e e ou CT (conhecimento de transporte comum de papel); Por outro lado uma empresa que realiza o próprio transporte de suas mercadorias vendidas em seu MDF-e vai constar somente as NF-e ou NF (nota fiscal comum de papel) caso esta ainda não esteja obrigada a emitir a NF-e.

Bom dia Valdir, Depende do provedor, uns devemos informar 5% como sendo 0.05 e outros como 5.00

Boa noite Arnaldo, Como você pode ver pelo conteúdo do XML de retorno da SEFAZ as únicas informações retornadas são: Nome, IE, CNPJ, UF, código da Situação, indicador de credenciado a emitir NF-e e indicador de credenciado a emitir CT-e.

Boa noite Arnaldo, Enquanto tivermos como retorno o valor 1 para Ind. Continuação devemos realizar uma nova consulta e utilizar o último NSU retornado pela última consulta. Exitem relatos no fórum que colegar tiveram que realizar dezenas e até centenas para que as notas começassem aparecer.

Boa tarde a todos, Retificando a informação: Não se manifestaram interesse as UF: Espirito Santo e Santa Catarina. Leiam este link: http://blog.totvs.com/projeto-de-nfce-ja-contabiliza-25-estados-em-todo-brasil-2/

Boa tarde, Não informar como UF de percurso as UF de Carregamento e Descarregamento. Esse é o seu erro, você informar a UF PR como de Descarregamento e incluiu ela no percurso também.

Boa tarde Rafa, Sim, só esta faltando Santa Catarina e Tocantins. Temos Estados já em produção, outros realizando o piloto com algumas empresas. E tem alguns que só vão iniciar o piloto no ano que vem.

Bom dia EFV, Na unit ACBrProvedorBetha - function GetSoapAction altere: acRecepcionar: Result := 'http://www.betha.com.br/e-nota-contribuinte-ws/recepcionarLoteRps'; para: acRecepcionar: Result := ''; Teste novamente.

Bom dia Cleber, Utilizo o Delphi 7 com o Quick Report.

Bom dia Arnaldo, Post como anexo o XML retornado pela SEFAZ ao realizar a consulta ao cadastro.

O que é preciso saber é com relação as regras para emitir o MDF-e: Carga Fracionada e transporte Interestadual. Se o Fornecedor B do Destinatário A (que vai realizar o transporte da carga com transporte próprio) emitir somente uma NF-e de toda a carga, e se o Destinatário A só vai transportar a carga adquirida do Fornecedor B, temos então uma carga - Lotação. Neste caso emitir um segundo documento o MDF-e para relacionar somente uma NF-e vai contra os princípios do MDF-e. Agora se ele compra de vários fornecedores e coloca todos os produtos no caminhão podemos considerar carga fracionada, uma vez que uma fração da carga é de um fornecedor e outra de outro. Mesmo que o destinatário seja o mesmo, por questões de fiscalização em uma fronteira entre Estados a utilização do MDF-e é mais rápido.

Dércio, Após o QR-Code, mais precisamente logo após o protocolo de autorização é permitido incluir qualquer coisa mesmo que não conste no XML, como por exemplo uma mensagem de Feliz Natal. Acredito que você poderia estar incluindo essa informação no final sem nenhum problema.

Bom dia Thiago, Uma coisa é certa você não esta com os fontes atualizados. Pois essa alteração foi realizada pelo Jairo e disponibilizada por mim em 15/04/2014.

Bom dia Dércio, Na NFC-e não existe o transportador, normalmente é o próprio destinatário que leva a mercadoria, a não ser no caso de Delivery, mas mesmo assim, até onde sei, não podemos informar o transportador.

Bom dia André, Algo de errado você esta fazendo, pois nunca ocorreu comigo. Uma vez que o XML tem que ser assinado para ser enviado. O que pode ocorrer é o XML assinado após o envio ficar sem o protocolo, mas isso é resolvido realizando uma consulta. 1. Carrego o XML assinado; 2. Realizo a Consulta; O XML é atualizado ficando assinado e protocolado. Outra coisa, na minha aplicação o XML é gerado e assinado somente uma unica vez através do comando Enviar. Não fico gerando o XML e salvando, depois carrega para assinar e salva novamente, depois carrega novamente para enviar. Outra coisa importante, o CTe tem uma TAG chamada cCT - código do conhecimento de transporte, esse código deve ser aleatório e faz parte da chave e consequentemente pode alterar a assinatura e o DigestValue. Se toda vez que você gerar o mesmo XML gerar um novo cCT e depois realizar a sua assinatura vai ocorrer o problema que você descreveu.

Bom dia Graça, Vamos ver se eu entendi: "§ 7º Na hipótese estabelecida no inciso II desta Cláusula, a obrigatoriedade de emissão do MDF-e é do destinatário quando ele é o responsável pelo transporte e está credenciado a emitir NF-e.". Se o Destinatário da carga é que vai realizar o transporte da mesma e este esta credenciado a emitir NF-e, fica obrigado a emitir o MDF-e, correto? Se sim, neste caso só se a carga contida no caminhão for fracionada e interestadual caso contrario não há necessidade. Esse é o meu entendimento.

Bom dia Caetano, Resposta da SEFAZ: "A respeito do tema de eliminação do web service da consulta status serviço, informo que o assunto foi tratado na reunião do Grupo XML de Documentos Fiscais Eletrônicos realizada em Porto Alegre de 29 a 31/01. A maioria dos técnicos do Fisco presentes se manifestou favorável a retirada do ar deste serviço não apenas para NFC-e mas também para a NF-e modelo 55. Todavia, o assunto será primeiramente discutido pela Coordenação Técnica do ENCAT na próxima reunião do Grupo Técnico dos Players de NF-e que corresponde a um grupo de representantes de empresas de provimento de soluções de NF-e. Este GT é coordenado pela GS1. Desta forma ainda não há definição se este we service será eliminado ou não e qual seria a eventual data prevista para discontinuidade deste serviço. Caso se decida pela retirada do ar deste serviço, o fato será amplamente divulgado com antecedência para que as empresas emissoras de NF-e e NFC-e se adaptem a esta nova realidade. De todo modo, a orientação técnica é que não se utilize, em nenhuma hipótese, este web service para automação de entrada e/ou saída de contingência. Recomenda-se que a empresa que queira automatizar este processo deva utilizar as informações estatísticas obtidas do próprio processo de autorização de NF-e/NFC-e. Lembramos ainda que a informação do tempo médio de autorização de NF-e nos últimos 5 minutos consta de campo tMed (página 26 do Manual de Orientação ao Contribuinte v 5.0)."

Boa noite Rick O problema é dos aproximadamente 30 provedores implementados uns 27 seguem o padrão ABRASF, um que você se basear é o ISSDSF.