Italo Giurizzato Junior

Boa tarde Jheff, Qual é o motivo dessa alteração? Segundo a NT 2012/002 trata-se de um campo Data, o XML retornado contem a Data e a Hora? Se possível poste como anexo o XML de retorno a consulta de NFe Destinadas.

Eric, Acredito que o unico lugar é o campo Discriminação, onde você discrimina o serviço e acrescenta mais essas informações.

Boa tarde Helio, Muito obrigado pelas correções, fiz as devidas alterações e já econtram-se dispiniveis.

Bom dia Marcus, Para mim isso é novidade, mas caso a prefeitura de São Paulo, venha adotar o layout ABRASF, com certeza que vamos implementar, uma vez que o componente ACBrNFSe só atende as cidades que seguem o ABRASF.

Bom dia Eric, Conforme o manual da ABRASF esse campo pertence ao XML da NFSe e não ao XML do RPS. Como o XML da NFSe é gerado pelo provedor, portanto esse campo só é preenchido pelo mesmo. Logo não adianta você alimentar esse campo quando for gerar o XML do RPS, pois ele não vai constar no XML a ser enviado para o provedor.

Bom dia Bruno, Primeiro desfaça o que você fez, segundo você esta sabendo que o cancelamento de uma NFe agora é por evento? Pesquise no fórum, existem muitos post sobre o assunto.

Boa noite Ricardo, Não se faz necessário, uma vez que não se usa mais esse código e sim o código da cidade nas demais funções.

Boa noite Darlana, Na implementação que fiz no meu sistema, criei 2 tabelas, uma para armazenar o NSU e data da última consulta, a outra com os dados da nota retornada pela consulta e a última manifestação realizada pelo usuário.

Boa tarde a todos, Por favor tentem executar o procedimento desse tópico:

Boa tarde Neguta, No XML temos a tag contendo a data e hora de emissão do mesmo, você esta passando somente a data, consequentemente a hora esta ficando zerada. Informe também a hora, utilize para isso a função do Delphi: Now.

Boa tarde Walmir, Você leu a NT que trata sobre o assunto? Essa consulta é realiza para obter a lista de NFe que foram emitidas contra o seu CNPJ ou seja você é o Destinatário e com a lista em mãos você pode se manifestar sobre cada uma delas. Por favor leia a NT 2012/002 disponibilizada no Portal Nacional da NF-e, para que você possa se entender melhor do que se trata.

Boa tarde Flavio, No momento o componente não vai sofre alterações por dois motivos: 1. O que foi publicado não é uma Nota Técnica e sim uma Orientação de Preenchimento; 2. Como as mudanças se referem a novos campos, há necessidade da publicação de novos schemas de validação. Lendo o documento publicado com mais atenção temos: Final da página 3: (...) A estrutura do grupo ICMS 51 – Diferimento deveria ter a seguinte estrutura para registrar corretamente os valores da operação: (...) Inicio da página 4: (...) Assim, enquanto não houver a adequação da estrutura do ICMS 51 – Diferimento, os casos de diferimento parcial devem ser informados no grupo ICMS90 da seguinte forma: (...)

Bom dia Diogo, Obrigado você pela contribuição.

Bom dia José Geraldo, Esta disponivel uma alteração, favor baixar e testar. Para obter o numero do protocolo veja se o comando abaixo vai resolver: sProtocolo := ACBrMDFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt;

Bom dia, Você instalou qual versão do Quick Report? Qual é o erro?

Bom dia Walter, Experimente comentar essas 2 linhas e teste, acredito que vai funcionar do mesmo jeito, também não vejo a necessidade.

Bom dia Akai, O XML contendo a solicitação de consulta contem a assinatura digital, o que eles mais querem? A não ser que o certificado utilizado não seja do prestador de serviço.

Bom dia Diego, Continuo checando, mas não encontrei nada, nem uma letra que seja a mais ou a menos que poderia estar ocasionando o problema.

Bom dia a Todos, Quanto ao Quick Report, já esta disponivel a alteração. Não tenho como alterar os demais.

Boa tarde a todos, Se o DANFE em questão é o da NF-e, precisamos saber se é o DANFE feito em Quick Report, Rave, etc. Para que possamos efetuar a correção/auteração de forma correta.

Boa tarde Clonemar, A cidade de Canoinhas/SC já esta incluida no componente.

Boa tarde Walter, Como dito anteriormente, se ocorre o envio, mas não obtemos o retorno com o protocolo de autorização, não devemos enviar novamente. Caso contario ocorre a rejeição de Duplicidade. Você deve fazer com que a sua rotina seja capaz de detectar se ocorreu alguma falha e tratar essa falha da melhor maneira possível. Se você pesquisar no fórum acredito que vai encontrar alguns postes tratando sobre o assunto. Dica, mesmo se a rotina apresentada for para a NFe, você pode aproveitar a idéia para o CTe, pois existe uma semenhaça muito grande entre os comandos.

Boa tarde Diogo, Existia sim uma falha no componente que ao gerar o arquivo a tag estava sendo gerada de forma errada sendo que o correto é procEventoNFe. Problema este resolvido a vários meses, favor atualizar os todos os fontes de todos os componentes e compilar a sua aplicação com a opção Build que encontra-se no menu Project.

Bom dia Diego, Por favor, você que tem um certificado válido, cheque para mim o endereço correto do SoapAction para Inutilização de numeração do CT-e.

Bom dia Walter, Vamos separar o seu problema em 2. 1. "dai da um erro qualquer..." Ao enviar um lote de CT-e para SEFAZ, pode ocorrer varios problemas, um deles é a SEFAZ receber o lote, processar o mesmo e por algum motivo não retornar o protocolo de autorização. Neste caso não devemos enviar o lote novamente e sim realizar uma consulta para obter o protocolo. Pode ocorre da SEFAZ, nem sequer receber o lote, neste caso devemos enviar novamente. Pode ocorrer rejeição de um ou mais CT-e continos no lote, neste caso devemos avaliar a rejeição de cada um efetuar a correção e enviar novamente somente os CT-e que foram rejeitados em um novo lote. Como você pode ver cada caso é um caso e o procedimento a ser tomado é diferente. 2. com relação ao numero do lote que você chama de CodLote, na minha aplicação eu controlo esse numero, fazendo que ele seja incrementado de 1 a cada lote enviado.