italo.giurizzato.junior

Bom dia jGuto, Favor atualizar os fontes e testar novamente. Agora é para abrir através do navegador o XML da NFS-e que foi salvo automaticamente pelo componente.

Bom dia Celso, Muito obrigado pela informação. Favor atualizar os fontes e testar.

Boa noite Idez, Como dito, o campo OutrasInformacoes pertence a estrutura do XML da NFS-e que é gerado pelo provedor. Por pertencer a estrutura da NFS-e não tem como alimentar esse campo e incluir ele no XML do RPS, por 2 motivos; 1. O validador do componente não vai validar o XML; 2. O validador do Provedor não vai validar o XML. A saída é colocar a informação desejada no campo Discriminacao.

Boa tarde Castro, Talvez eles querem que você simplesmente, cancele a NFS-e que esta errada e emita uma nova sem a necessidade de informar que esta última esta substituindo uma outra anterior.

Boa tarde Roger, CTe Versão 2.00 os campos de complementação não existem mais. Simplesmente você emiti um novo CT-e cujo tpCTe é 1-CT-e de Complementação de Valores, lança os valores nos campos normalmente usados e informa a chave do CT-e que esta sendo complementado em: infCteComp.chave Não entendi o xNome?

Boa tarde Jander, Veja este link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-subcontratacao/

Boa tarde Idez, Esse campo (nome correto: Outras Informações), normalmente faz parte da estrutura da NFS-e e não do RPS (segundo padrão ABRASF). Checando o Schema do provedor Thema o campo: OutrasInformacoes faz parte do tipo complexo tcInfNfse. Portanto nem adianta alimentar esse campo, pois o componente não vai incluir ele no RPS e se altera-lo para que o faça, o XML não será validado.

Boa tarde a todos, Encontra-se disponível a implementação da Impressão da Inutilização de Numeração. No programa exemplo temos 2 novos botões que exemplificam a impressão bem como a geração do PDF. Atenção: a implementação foi feita em Quick Report.

Bom dia Matheus, Desculpe, mas não estou entendendo o motivo dessa consulta. Com essa consulta você quer saber se um determinado motorista consta em algum MDF-e ainda não encerrado? Se é essa a sua intensão, a resposta é não. Como lhe disse você vai ter que tratar isso na sua aplicação, se for o caso fazer alterações no banco de dados para armazenar tudo o que é informado em um MDF-e bem como se o mesmo esta encerrado ou não.

Bom dia Nilson, Por que não utilizar uma série diferente para cada PDV? PDV1: Série: 1 Numero da NFC-e: 1, 2, 3, .... PDV2: Série: 2 Numero da NFC-e: 1, 2, 3, .... (...)

Bom dia, Já inclui as URLs de homologação do Ceará, por favor atualize todos os fontes de todas as pastas e realize os testes.

Boa tarde Matheus, Via Web Services, não, você tem que tratar isso na sua aplicação.

Boa tarde Oneide, Tente realizar esses 2 testes: Como você emitindo em ambiente de testes, altere as URLs da function GetSoapAction que esta na unit ACBrProvedorBetha.pas Inclua nas URLs a palavra test: ..../e-nota-contribuinte-test-ws/.... Se não funcionar deixe as URLs em branco: Result := ''; Fazer essas alterações para todas as ações.

Boa tarde, Você utiliza o componente ou o ACBrNFeMonitor? Se for o componente você deve repetir o trecho abaixo, um para cada correção (limite de 20 correções): with ACBrCTe.EventoCTe.Evento.Items[0].InfEvento.detEvento.infCorrecao.Add do begin grupoAlterado := sGrupo; campoAlterado := sCampo; valorAlterado := sValor; nroItemAlterado := iNumItem; end;

Boa tarde, Segundo a mensagem de erro, foi encontrado um carácter inválido no conteúdo do texto, o texto neste caso acredito ser no arquivo: leiauteConfRecebto_v1.00.xsd ou no arquivo apontando pelo include ou seja, tiposBasico_v1.03.xsd

Boa tarde Carlos, Maravilha, precisamos de mais colaboradores como você. Assim que você concluir as alterações/correções, por favor post como anexo somente as units que sofreram alterações. Desde já muito obrigado.

Boa tarde Rodrigo, Com certeza o DAMDFE feito em Fortes Report esta com problemas. Você testou com a versão feita em Quick Report? Outra coisa importante, porque você esta alimentando a TAG: SegCodBarra? Essa TAG só é alimentada quando o CT-e ou NF-e foram emitidos em contingência FS-DA neste caso o DACTE ou DANFE possuem 2 códigos de barras.

Boa tarde Rigotti, Favor atualizar os fontes e testar novamente.

Bom dia Daniel, É o procedimento GerarXML que gera o conteúdo de ArquivoFormatoXML; Veja: LocCTeW.GerarXML; aCTe := LocCTeW.Gerador.ArquivoFormatoXML;

Bom dia Dionatan, A partir do momento que o cancelamento se tornou um evento, não se atualiza mais o XML que foi assinado e autorizado pela SEFAZ. Estou me referindo a NF-e, CT-e, NFC-e e MDF-e. Temos agora 2 XMLs: Um é o XML do MDF-e assinado e Autorizado, o outro é o processamento do evento (*-procEventoMDFe.xml) que contem a solicitação do cancelamento e a homologação do mesmo com o numero do protocolo e tudo mais. Já existe uma especie de Documento Auxiliar para imprimir o evento, bastando carregar os 2 XMLs mencionados acima e executar o comando ImprimirEvento. É possível ainda gerar esse DA em PDF. Por favor estude o programa exemplo do MDF-e que nele você encontrar botões relacionados a Eventos. Da para imprimir não somente o evento de cancelamento como também o de Encerramento.

Boa tarde Carlos, Por favor, poste o arquivo como anexo aqui mesmo no fórum.

Daniel, Ao realizar a consulta, você esta carregando o componente com o conteúdo do CT-e? Se não estiver carregando o componente procura pelo XML do mesmo salvo em disco, bem como o *-sit.xml Se não encontrar o *-cte.xml ele não gerar o CTeDFe consequentemente a propriedade RetCTeDFe fica vazia.

Boa tarde Dangelo, O componente ACBrNFSe gera o XML de envio e o submete a um validador próprio. O problema é que o componente esta gerando o XML esta validando-o segundo os schemas (arquivos XSD), para o componente o XML gerado esta em conformidade com os schemas, mas o provedor o recusa acusando que esta errado. Isso nos leva a crer que os schemas que estamos utilizando não condiz com o que o provedor esta utilizando. Se conseguíssemos os schemas corretos, teríamos condições de efetuar as correções na rotina que gera o XML e assim enviar ele corretamente. Resumindo a resposta do provedor: Se vira.

Boa tarde Dorivan Sousa, Segundo o manual que você postou esse provedor não segue o padrão de estrutura e nomenclatura da ABRASF.

Boa tarde Julio, O problema é que esse provedor não implementou o Web Service de Envio somente o Gerar.