Italo Giurizzato Junior

Boa tarde, Acredito que não tenha ficado claro a minha postagem. A NF-e modelo 55, se não me falha a memória somente o DF aceita uma NF-e só com serviços, os demais Estados tem que ter pelo menos um item referente a venda de produto. Em qualquer caso devemos informar o CNPJ ou CPF do Emitente da NF-e. Na Nota Técnica 2013/005 versão 1.03 página 47, esta muito claro isso, onde devemos informar o CNPJ ou CPF (campos: C02 e C02a) Se fosse possível utilizar o CEI teríamos o campo C02b <CEI> e isso não existe na estrutura do XML. No caso da NFS-e - Nota Fiscal de Serviço Eletrônica, como você pode ver não tem nada haver com NF-e, trata-se de um documento fiscal eletrônico exclusivo para serviços e não para venda de mercadorias. Na NFS-e o emitente é chamado de Prestador e devemos informar o CNPJ ou CPF do mesmo, na estrutura do XML também não existe o CEI. A unica coisa que aparece com relação a construção civil é um grupo chamado <ConstrucaoCivil> que contem dois campos: <CodigoObra> e <Art>. Desculpe, uma coisa é o contador querer, outra coisa é poder. Peça para ele lhe mostrar o XML de uma NF-e onde em vez de ter sido informado o CNPJ ou CPF do Emitente foi informado o CEI. Detalhe importante esse XML tem que estar assinado e protocolado como autorizado pela SEFAZ.

Rick, Se a URL do Web Service ou o SoapAction estivessem errados é bem provável que a conexão com o provedor não seria realizada. Como esta ocorrendo a conexão e uma prova disso é o retorno acusando que o usuário é inválido. Pelo exemplo noto uma falta de padronização veja: String recibo = soap.nfdEntrada("55555555555", "cRDtpNCeBiql5KOQsKVyrA0sAiA=", 123089, xml); System.out.println("RECIBO: "+recibo); /* String recibo = soap.nfdEntradaCancelar("555.555.555-55", "cRDtpNCeBiql5KOQsKVyrA0sAiA=", xml); System.out.println("RECIBO Cancelar: "+recibo);

Bom dia Sandro, Nota Técnica 2013/005 versão 1.03 - página 45 campo verProc = Versão do Processo de emissão da NF-e (Observação: Informar a versão do aplicativo emissor de NF-e). Resumindo, esse campo <verProc> se refere a versão da sua aplicação não tem nada haver com a versão do XML da NF-e.

Bom dia a todos, A SEFAZ não leva em consideração o motorista (condutor). Devemos encerrar um MDF-e e emitir um novo quando ocorrer alteração do motorista. Temos um evento para incluir novos motoristas após a emissão do MDF-e. Mas ao emitir um MDF-e a SEFAZ não checa se o motorista incluído consta em outro MDF-e que ainda não foi encerrado. A regra é: Se modal rodoviário: Verificar se existe MDF-e não encerrado, para a placa principal (mesmo CNPJ base do emitente do MDF-e, mesma placa, mesma UF carregamento, mesma UF descarregamento e Data de emissão diferente). *Na data de emissão considerar dia, mês e ano. Por favor procure sempre ter em mãos os manuais e notas técnicas, a regra acima consta na Nota Técnica 2013/004 versão 1.00a (página 40) - regra G055.

Bom dia André, Fiz uma alteração na unit pcteSignature.pas e disponibilizei ela na sexta-feira se não estiver enganado. Por favor atualize os fontes e teste novamente.

Bom dia Narlem, A mensagem de erro de validação é bem clara, veja: TAG:<ide> ID:B02/cUF(Código do UF (Unidade da Federação)) - Conteúdo inválido. Você não informou ou o conteúdo esta errado, neste caso o campo cUF do grupo <ide>. [identificacao] NaturezaOperacao=VENDA MERC. ADQ./RECEB. TERC. EM OP modelo=55 cUF=?? aqui você tem que informar o código da UF (por exemplo 35 = SP) Inclua no seu TXT os campos reclamados pelo validador.

Bom dia Rick, Vendo os XMLs, notei que você informou 5555555 como sendo o CPF do usuário esta correto isso? Uma vez que o erro é Usuário inválido.

Boa tarde Fernando, O programa exemplo do MDF-e utiliza o DAMDFE feito em Quick Report, já o NF-e que eu saiba utiliza o Rave.

Boa tarde, Qual é a URL de consulta via QR-Code utilizado pela SEFAZ-RJ se tratando da NFC-e? Precisamos dessa informação para que possamos atualizar os fontes do componente, desta forma ele vai gerar a URL correta do QR-Code.

Boa tarde Andressa, Se você se refere ao combobox, tem que fazer o que o Juliomar disse, inserir manualmente conforme as demais. Lembre-se, esse programa é um exemplo e não uma solução, logo você não pode se basear na lista de cidades que estão no combobox. Esta disponível uma tabela feita em Excel com todas as cidades brasileiras, as que já estão implementadas consta o nome do provedor.

Boa tarde a todos, Incrível, gostaria de saber primeiramente, qual é a dificuldade em manter os fontes atualizados diariamente? Segundo o programa exemplo do ACBrNFSe possui um botão onde você informa o código IBGE da cidade desejada e ele retorna o nome do provedor, caso esta já esteja implementada. Se aparecer a palavra Nenhum como nome do provedor, significa que para a cidade solicitada não existe nenhum provedor relacionado. Obs: quando digo atualizar os fontes é atualizar todos os fontes de todas as pastas e após a atualização sempre compilar o programa exemplo ou a sua aplicação com a opção Build.

Boa tarde Andre, Faça uma cópia do CT-e protocolado (este que você postou), e gere novamente e assine o mesmo CT-e. Não precisa validar. Depois compare o conteúdo das TAGs do grupo Signature, mais precisamente as TAGs: SignatureValue e X509Certificate. Se não me falha a memória a assinatura fica inválida porque o X509Certificate fica com apenas 256 caracteres. Uma pergunta: os arquivos de envio e retorno estão sendo salvos em disco?

Boa tarde Welton, O sistema que você se refere é o programa gratuito da SEFAZ? Se sim, você não tem o DAMDFE impresso, nele você tem a chave. E não é inutilizar, ou você encerra caso o serviço tenha sido executado ou você cancela. Outra coisa, não tem como saber se um motorista esta relacionado a algum MDF-e via conexão com a SEFAZ.

Boa tarde, Note que o problema encontra-se no Documento Auxiliar de impressão de eventos e não no DAMDFE.

Boa tarde Andre, Maravilha, ficarei no aguardo do seu retorno.

Bom dia icozeira, Realmente notei esse problema das duas mensagens, quando fiz as modificações. Acabei optando por deixar a de Homologação, uma vez como se trata de testes, logo esta falando de um ambiente controlado. Ao emitir em ambiente de produção vai aparecer a mensagem: Contingência quando o tipo de emissão for 9. Quanto a estourar o tamanho a solução vai ser diminuir o tamanho da fonte, diretamente no layout do DANFE. O parabéns é para todos nós, inclusive para você por estar disponibilizando aos seus clientes uma solução para emissão de NFC-e baseada nos componentes ACBr.

Juliomar, Atualizado e compilado, sem nenhum problema.

Bom dia João, Qual é o CFOP que você esta utilizando? Se for o que consta no titulo do tópico, ou seja o 6.656, o grupo 6.000 se refere a saídas ou prestações de serviços para outros Estados. Sendo assim a mercadoria em questão vai ser transportada, e quem vai transporta-la?

Bom dia Eric, Muito obrigado pela colaboração. Já esta disponível. Acrescentei mais uma coluna chamada HOMOLOGADO. Pessoal, por favor, postem neste tópico os nomes das cidades que já estão conseguindo emitir NFS-e em produção com a versão mais recente dos fontes disponibilizados no repositório, para que eu possa acrescentar a palavra SIM na coluna HOMOLOGADO. Aqueles que ainda estão na faze de testes por favor informe que esta testando para que neste caso seja colocado EM TESTE. Desde já muito obrigado a todos.

Bom dia Juliomar, No caso do ACBrCTe temos no inicio da function GetCertificado o CoInitialize(nil) e no final o CoUninitialize, este não se faz necessário?

Bom dia Andre, Vamos analisar os códigos do Assinar e Valida. Na procedure Assinar temos o XML assinado armazenado na variável vAssinada, cujo conteúdo é atribuído a Self.Items.XML. No final da procedure salvo em disco (se configurado) o conteúdo de vAssinada gerando assim o arquivo: <chave>-cte.xml A procedure Valida por sua vez, primeiramente checa se o conteúdo de Self.Items.XML contem a TAG Signature, caso negativo a procedure Assinar é executada. Depois é utilizado o conteúdo de Self.Items.XML para realizar a validação. Notei que ao ler o conteudo de Self.Items.XML é executado o GetCTeXML que por sua vez executa o GerarXML ou seja gera novamente o XML. Vamos a mais um teste, na definição da propriedade XML na unit ACBrCTeConhecimentos altere a linha em negrito: property CTe: TCTe read FCTe write FCTe; property XML: AnsiString read GetCTeXML write FXML; property XMLOriginal: AnsiString read FXMLOriginal write FXMLOriginal; para: property CTe: TCTe read FCTe write FCTe; property XML: AnsiString read FXML write FXML; property XMLOriginal: AnsiString read FXMLOriginal write FXMLOriginal; Isso vai fazer com que o XML não seja gerado toda vez que a propriedade é lida.

Bom dia Rafael, Como assim 2 MDFe no lote? Segundo a Nota Técnica 2013/004 versão 1.00a só é aceito um MDF-e por lote.

Boa tarde Stefan, Você leu a NT que sugeri?

Boa tarde Rafael, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Rafael, Muito obrigado pela colaboração, já esta disponível.