Italo Giurizzato Junior

Bom dia Matthias, Você teria condições de entrar em contato com o provedor e solicitar ao mesmo o Schema (arquivo XSD) que nos permite validar o XML gerado antes do envio do mesmo ao provedor? Se sim, por favor, post como anexo o schema utilizado pelo provedor Tecno, pois ainda não temos ele. Sem esse arquivo não temos condições de realizar alterações no componente para que o mesmo aceite dois ou mais serviços, se é que isso é aceito por este provedor. Quero deixar claro que o layout padrão do XML do RPS prevê somente um serviço por nota. Uma coisa é o código de tipo de serviço cadastrado na prefeitura para a empresa em questão e outra coisa a discriminação do que foi feito.

Bom dia José, Por favor leia a Nota Técnica que trata sobre o assunto Distribuição de DF-e. Você vai descobrir que o método DistribuicaoDFe já realiza o download de uma NF-e que foi previamente manifestada.

Bom dia Marianoasa, O XML de uma NF-e é composto por 3 grupos apenas: <NFe> onde temos todos os dados pertinentes a venda. <Signature> onde temos a assinatura digital. <protNFe> onde temos as informações referente ao protocolo de autorização da nota. Sendo assim não adianta procurar no XML da nota informações sobre eventos, uma vez que a manifestação do destinatário é um evento e o mesmo é armazenado em um XML separado. Quanto você diz: (...) "em algum lugar que possamos saber o status, se deram ciência ou confirmaram a nfe." o possamos saber se refere ao destinatário ou ao emitente da nota? Se é o destinatário, no meu entendimento, uma vez que é este que se manifesta, a aplicação tem que armazenar no banco de dados o tipo de manifestação realizada em uma determinada nota. Ao realizar a consulta através do DistribuicaoDFe temos que popular uma tabela no banco de dados com os seguintes dados: ChaveNFe > chave da nota (44 digitos) CodManif > código da manifestação, se zero significa que não foi manifestada ainda DataManif > data que foi realizada a manifestação Motivo > Motivo, usado na manifestação: Operação não Realizada. Ao realizar a Manifestação a aplicação tem que atualizar o registro referente a nota que esta sendo manifestada. Desta forma a sua aplicação tem como saber quais notas foram manifestadas ou não, se foi, quando foi e qual a manifestação registrada. Agora se você se refere ao emitente da nota, o mesmo pode utilizar o DistribuicaoDFe para obter os resumos ou eventos de manifestação registrados pelos destinatários das notas.

Bom dia Paulo, Todos os arquivos que possuem a palavra "-soap" no nome não precisam ser salvos, pois são apenas uteis quando ocorrem erros, principalmente no inicio do desenvolvimento. Sendo assim basta atribuir o valor False a propriedade Salvar do grupo de propriedades: WebServices. Temos o PathNFe e o PathSalvar, se não me falha a memória os arquivos de envio e de retorno, como exemplo: *-env-lot.xml e *-rec.xml são salvos na pasta definido em PathSalvar, por outro lado os XML referentes as notas são salvos na pasta definida em PathNFe.

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

Boa tarde Maria, Não estou entendendo. Se você é o destinatário da nota, após manifestar a mesma e ao realizar uma nova consulta usando o método DistribuicaoDFe você terá como retorno o XML completo da nota com o status de autorizada. Não existe um status para a NF-e que diz que a mesma foi manifestada ou não. Uma coisa é o XML da NF-e (<chave>-nfe.xml) que para ter validade jurídica tem que estar assinado e com o protocolo de autorização. Cancelamento, Manifestação, CC-e são eventos vinculados a NF-e, portanto se trata de outro XML (<ID>-procEventoNFe.xml).

Bom dia Helio, Isso esta errado no arquivo TXT: (...) [seg] xs:any=cteModalRodoviario_v2.00.xsd [Rodo] (...) o correto é: (...) [infSeg001] respSeg=0 (remetente), 1 (expedidor), 2 (recebedor), 3 (destinatário), 4 (emitente do CT-e) ou 5 (tomador de serviço) xSeg= informar o nome da seguradora nApol= informar o numero da apólice nAver= informar o numero da averbação vCarga= informar o valor da carga para efeito de averbação [Rodo] (...)

Bom dia a todos, Primeiramente, vamos colocar uma coisa na cabeça: Rejeição não tem nada haver com Schemas e ponto final. Os schemas são utilizados para validar o XML antes do envio, e o mesmo foi enviado significa que esta em conformidade com os schemas que vocês estão utilizando. Posso inventar um CNPJ totalmente absurdo, mas se ele tiver 14 dígitos não vai ocorrer erro na validação, mas com certeza a SEFAZ vai rejeitar o Documento Fiscal Eletrônico que eu enviei pelo simples fato do CNPJ informado não existir. Segundo, o problema não é isolado, pelo que vejo é geral, o Leandro e o Paulo acredito que seus clientes se utilizam da SEFAZ-SP, já o Luis não sei. Se também utiliza está claro que o problema encontra-se na SEFAZ-SP, sendo assim a unica coisa a ser feita é infernizar a SEFAZ. Peça a seus clientes que liguem, enviem e-mail, etc. quem sabe desta forma eles resolvam o problema o mais rapidamente.

Boa tarde Isaac, Por favor leia a Nota Técnica que trata sobre a Distribuição de DF-e. O que você tem como resposta ao usar esse método são as notas emitidas contra o seu CNPJ e os eventos gerados pelo emitente da nota. O evento que você gerou, ou seja, o de manifestação que vai receber é o emitente da nota. Por outro lado o evento de CC-e gerado pelo emitente da nota quem recebe é você o destinatário da mesma. Na Nota Técnica que mencionei acima temos um fluxograma que mostra claramente como tudo isso funciona, bem como uma tabela mostrando o que cada um tem acesso.

Bom dia, Primeiro é preciso saber qual é o provedor que atende a cidade em questão. Se o provedor já esta implementado no componente basta acrescentar a mesma na unit pnfsConversao, da mesma forma que as demais e por fim na unit ACBrProvedorxxxxxx que atende a mesma. Por fim realize os testes, estando tudo OK, anexe as units alteradas aqui no tópico para que possamos realizar um merge e enviar para o repositório.

Bom dia Luis, Alguns provedores necessitam de um cadastro para que o contribuinte possa emitir a NFS-e via Web Services.

Bom dia Luis, Essa alteração foi feita em qual unit? Por favor post ela como anexo para que possamos realizar um merge.

Boa noite, Favor ler a Nota Técnica que trata sobre o assunto. O método DistribuicaoDFe no primeiro momento pode retornar um resumo da NF-e e em outro o XML completo da NF-e, sem a necessidade de usar o método DownloadNFe.

Boa noite Isaac, Não, mas se você realizar a manifestação do destinatário, em uma nova consulta você terá o XML completo da mesma, bem como os resumos de evento e até mesmo os eventos vinculados a nota, como por exemplo: CC-e, Cancelamento, etc.

Boa noite, Muito obrigado pela colaboração, assim que possível vamos avaliar e estando tudo OK estaremos disponibilizando.

Boa noite Luiz, Ao enviar um MDF-e e temos essa rejeição, não existe uma propriedade com a chave do MDF-e não encerrado, mas ela é retornada na mensagem da Rejeição.

Boa tarde Allan, Na sua aplicação é possível o cupom de numero 500 fazer referencia a NFC-e de numero 485? Supondo que a diferença se refere aos cupons cancelados antes da emissão da NFC-e. Se for possível, não vejo problema nenhum.

Boa tarde Isaac, Sim, o método faz o serviço completo, ou seja, descompacta os resumos e notas completas e salva em disco se assim você desejar. Estude um fragmento de código chamado ConsultarNFeDestinadas que encontra-se dentro da pasta: ...\Exemplos\ACBrNFe2

Boa tarde Bruno, Muito obrigado pelo retorno. Fico aguardando uma posição final.

Boa tarde Guilherme, Por favor atualize os fontes e teste novamente.

Boa tarde a todos, No meu entendimento, a aplicação deve sempre utiliza o numero da nota a ser emitida o numero da anterior + 1. Desta forma não teremos problemas. Fora isso pode-se criar uma rotina que checa se existe algum buraco, ou seja sequencia das notas quebrado, por exemplo, temos a nota de numero 500, 502, 503, ... detectado a falha a rotina deve registrar em uma tabela os números de notas não utilizados, neste caso a de numero 501. Essa tabela tem que possuir também outros campos que indica se o numero foi inutilizado ou não, data de inutilização, numero de protocolo, e justificativa. Desta forma o form de inutilização de numeração só estaria disponível para inutilizar os números que constam na tabela como não inutilizados. Após a inutilização de todos, não teria como o usuário inutilizar outro numero. Ficando assim o sistema protegido contra erros.

Boa tarde Claudio, A NFC-e herdou praticamente tudo da NF-e, sendo assim, segundo o seu exemplo, onde temos um desconto no segundo item, se tratando de desconto na NF-e o desconto deve ser rateado entre todos os itens da nota, portanto se será data um desconto de 50% na segunda unidade de um item devemos lançar 25% de desconto para cada um. Lembre-se na NF-e não existe o desconto no valor final da nota e sim desconto rateado entre todos os itens. Portanto na NFC-e o desconto funciona da mesma forma.

Boa tarde a todos, Se não me falha a memória quando você compra um produto com o cartão de crédito e solicita o parcelamento do valor, alem do comprador pagar parcelado para a operadora do cartão o comerciante também recebe parcelado da operadora. Portanto quem paga e que recebe é em parcelas. No meu entendimento "a prazo" significa que o comerciante vai dar um prazo para que o cliente efetue o pagamento total, por exemplo 20 dias, por outro lado "outros" entendo como o parcelamento do valor em duas ou mais parcelas. Como as datas de vencimento do cartão de crédito é complicada, uma vez que a primeira parcela posso estar pagando dentro de poucos dias ou somente daqui a 40 dias, a minha sugestão é colocar como: A Vista.

Boa tarde Robinho, Se o problema ocorre com apenas alguns CT-e, com certeza o problema é a digitação dos valores ou a sua rotina que calcula o valor total do frete (vTPrest).

Boa tarde Batista, Já esta disponível.