Italo Giurizzato Junior

Boa tarde a todos, O maior problema é que a NF-e 2.00 só aceita os seguintes valores para o tpImp = [1 = Retrato, 2 =Paisagem] o DANFE Simplificado aparece no manual da versão 3.10 cujo valor para tpImp é 3. E lendo a NT 2012/001 diz que pode ser impresso em uma bobina de largura minima de 55 milímetros. Como já temos um modelo do DANFE para NFC-e feito no Quick Report e em Forts se não me falha a memória, poderíamos criar outro DANFE aos moldes da NFC-e. Ele poderia ser atrelado ao tpImp = 3 (previsto na versão 3.10) ou não. Fica a sugestão.

Boa tarde plenus, Veja bem, não é bem assim que a coisa funciona, pois trata-se de documentos fiscais de modelos diferentes, o XML pode até ser igual. A SEFAZ implementou regras de validação para o modelo 55 = NF-e, mas não implementou para o modelo 65 = NFC-e. É preciso saber se vai ser implementado ou não, se sim, quando?

Boa tarde ALA, Você não esta esquecendo de nada? Não vi no seu código a linha que alimenta o campo prop.tpProp que por sinal é obrigatório. Não confundir com o tpProp do veiculo que se refere ao tipo de propriedade, ou seja, próprio ou terceiro. Já o tpProp do proprietário se refere ao tipo de proprietário, ou seja, Agregado, Independente ou Outros.

Boa tarde Marcos, A consulta que esta sendo feita com o programa gratuito esta sendo realizada antes da sua aplicação ou depois?

Boa tarde Wandarlei, Muito obrigado pela colaboração. Já esta disponível a sua alteração.

Boa tarde Miguel, Tenta conseguir com o pessoal um exemplo completo contendo inclusive as TAGs Envelope, Body, ....

Boa tarde ALA, Note que a mensagem diz que foi encontrado o elemento UF, e ele é inesperado segundo o conteúdo do grupo prop, é esperado IE, tpProp. Por favor sempre senha em mãos a estrutura completa do XML para que você possa ver quais são os campos obrigatórios e os opcionais de cada grupo.

Boa tarde Marcelino, A unica forma que conheço é essa. A solução é entrar em contato com a SEFAZ e apresentar a eles o erro que esta ocorrendo, no retorno deles que deveria conter o numero do recibo.

Boa tarde Jocimar, Alguns provedores permitem que você coloque algo em OutrasInformacoes e envie, mas a grande maioria não. Em vias de regra esse campo é utilizado pelo provedor, é ele que coloca o que bem entender nesse campo.

Boa tarde Lucas, O procedimento aconselhado pelo pessoal da SEFAZ é: 1. Enviar o lote, se for recebido e processado e retornar o resultado do processamento ótimo. 2. Se não retornar nada então consulta o status da SVC, se ela estiver ativa para a UF do emitente, ai sim devemos enviar o lote para a SVC. 3. Se o status da SVC não estiver ativa, deve-se aguardar um pouco e realizar uma nova consulta. Nesse primeiro momento essa ativação e desativação da SVC vai ser manual, ou seja, vamos depender de um funcionário da SEFAZ autorizadora ativar a SVC. Existe uma promessa de automatizar esse procedimento de ativação e desativação.

Boa noite Anderson, Sim, pelo simples fato do cancelamento ser um evento.

Boa noite Marcus, O ACBrNFSe não atende a cidade de São Paulo, pelo simples fato do provedor contrato pelo município não segue o padrão ABRASF.

Boa tarde TiFire, Os fontes estão atualizados? Lhe pergunto isso, pois se não me falha a memória esse problema tinha sido resolvido.

Boa tarde Herbet, Esse erro ocorre porque esse provedor em vez de usar "Id" como atributo a ser utilizado para assinatura usou "id", provocando esse erro.

Boa tarde Anderson, Se o componente estiver configurado para Salvar os arquivos de Envio e de Retorno da SEFAZ, o arquivo *-ProcCancNFe.xml será salvo em disco.

boa tarde bpinformatica, Favor atualizar os fontes e testar novamente.

Boa tarde mfcampaner, O Componente ACBrCTe já possui as rotinas necessárias para não só o envio da CC-e como também para a impressão ou geração em PDF da mesma, bem como o envio por e-mail para o tomador do serviço. Ocorre que o Monitor apesar dele se utilizar do componente, há necessidade de criar nele os comandos que você vai passar via arquivo TXT e isso não foi feito ainda. Porque? Pelo simples fato do Monitor hoje compilado e disponibilizado, gera o XML do CT-e na versão 1.04 e para esta versão não existe a CC-e. Os responsáveis pelo seu desenvolvimento e aprimoramento estão atentos as novas funcionalidades e estão trabalhando para ser lançado uma nova versão que vai atender todas as rotinas fiscais do CT-e versão 2.00, podemos citar a CC-e e o Cancelamento por evento.

Boa tarde Dênio, Se ocorreu um erro ao enviar, não existe retorno, você não concorda?

Boa tarde Tagales, Primeiramente se consta no site da SEFAZ que existe um evento de CC-e, quem poderia duvidar se é legal ou não? Outra coisa, quando você envia um evento, o mesmo é enviado para a SEFAZ autorizadora do Emitente, no caso a SEFAZ-SP, esta por sua vez fica responsável por enviar para o Portal Nacional da NF-e. Ocorre que isso não é automático, podendo levar minutos ou até horas.

Boa tarde Flavio, Se a SEFAZ ou o estabelecimento comercial estiver com problemas técnicos de conexão com a internet, você vai gerar o XML e enviar para onde? Dica: leia tudo o que se refere a Contingência da NT 2013/005 versão 1.03 bem como a NT 2013/007 versão 1.02 Essas NT bem como várias outras estão disponíveis no Portal Nacional da NF-e.

Boa tarde Elvis, Por favor compare o seu XML com a estrutura que se encontra nos manuais e notas técnicas do MDF-e, disponíveis no Portal Nacional da MDF-e.

Boa tarde Vanessa, Primeiramente, o programa exemplo do ACBrMDFe não tem a estrutura completa, trata-se apenas de um exemplo simplificado para que você possa ter um primeiro contato. A estrutura completa com as informações do que vem a ser cada campo, se é opcional ou obrigatório, favor baixar os manuais e notas técnicas que encontram-se disponíveis no Portal Nacional do MDF-e. Um fragmento de código da minha aplicação: for i:=0 to j do begin with Ide.infPercurso.Add do begin UFPer := DM_MDF.PercursosUFPerc.AsString; end; DM_MDF.Percursos.Next; end;

Boa tarde a todos, Na verdade alguns provedores aceita somente o envio de um lote de RPS, outros o envio tem que ser de apenas um RPS e tem outros cujo envio é síncrono e não assíncrono. Sendo assim o componente possui 3 métodos que podemos utilizar para enviar o RPS para o Web Services. Enviar - > trabalha no modo assíncrono e envia um lote contendo UM ou no máximo 50 RPS. EnviarSincrono -> trabalha no modo síncrono e envia um lote contendo UM ou no máximo 50 RPS. Gerar -> trabalha no modo síncrono e envia somente UM RPS. Como vocês podem ver, apesar do Web Services se chamar GerarNfse o componente não gera o XML da NFS-e e sim gera e envia o XML do RPS. Por favor não confundir com outro método que o componente oferece que é o GerarLote. Este por sua vez apenas Gera o Lote contendo UM ou no máximo 50 RPS e salva em disco, para que seja posteriormente importado através do site do provedor. Outra coisa importante cada provedor implementou os Web Services da sua maneira, portanto temos provedores que oferecem as 3 opções de envio e outros apenas UM. Se você tentar usar uma opção e receber a mensagem do componente informando que a funcionalidade escolhida não foi implementada pelo provedor XYZ, isso significa que, não se trata de um erro ou você fez algo de errado e muito menos que algo ainda precisa ser implementado no componente. O Ginfes por exemplo, só temos a opção de envio pelo modo assíncrono os outros dois não funciona, pela simples razão que o Ginfes não possui os Web Services para recepcionar o lote em modo síncrono ou simplesmente o envio de um RPS sem a necessidade de montar o lote. Se algum dia o Ginfes implementar o Web Services GerarNfse, basta liberarmos esse método para este provedor. Espero ter ajudado.

Stanley, Primeiro devemos configurar o modelo depois a versão. ACBrNFe1.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe1.Configuracoes.Geral.VersaoDF := ve310;

Boa tarde Stanley, Há no fórum farias postagens mostrando como se deve configurar corretamente o componente para que o mesmo gere o XML da NF-e na versão 3.10 Você tem que configurar via código as propriedades ModeloDF e VersaoDF do componente ACBrNFe.