Italo Giurizzato Junior

Bom dia Maikon, Na unit pgnreGNREW.pas a alteração abaixo não resolveria o problema? Gerador.wCampo(tcStr, '', 'documentoOrigem ', 01, 18, 1, GNRE.c04_docOrigem, '', True, 'tipo="' + FormatFloat('00', GNRE.c28_tipoDocOrigem) + '"'); Desta forma não seria necessário alterar o tipo do campo c28_tipoDocOrigem de Integer para String.

Bom dia Edu, Se tratando do MDF-e, com certeza vai funcionar, pois só temos uma SEFAZ que recepciona todos os MDF-e de todas as UF, é a SEFAZ-Virtual do Rio Grande do Sul.

Bom dia Ala, Dessa outra forma não funciona? SSL.SSLType := LT_TLSv1_2; Configuracoes.Geral.VersaoDF := ve300;

Boa tarde Edu, Sim, deveria estar funcionando no ambiente de homologação, mas infelizmente algumas SEFAZ não estão fazendo o dever de casa.

Boa tarde, Veja o fragmento de código abaixo: Gerador.wCampoNFSe(tcStr, '#33', 'CodigoMunicipio ', 01, 0007, 1, OnlyNumber(NFSe.Servico.CodigoMunicipio), DSC_CMUN); Gerador.wCampoNFSe(tcInt, '#34', 'CodigoPais ', 04, 04, 0, NFSe.Servico.CodigoPais, DSC_CPAIS); Gerador.wCampoNFSe(tcStr, '#35', 'ExigibilidadeISS ', 01, 01, 1, ExigibilidadeISSToStr(NFSe.Servico.ExigibilidadeISS), DSC_INDISS); Gerador.wCampoNFSe(tcInt, '#36', 'MunicipioIncidencia ', 07, 07, 0, NFSe.Servico.MunicipioIncidencia, DSC_MUNINCI); Gerador.wCampoNFSe(tcStr, '#37', 'NumeroProcesso ', 01, 30, 0, NFSe.Servico.NumeroProcesso, DSC_NPROCESSO); Note que a tag <CodigoMunicipio> é gerada com o valor atribuído ao campo CodigoMunicipio, já a tag <MunicipioIncidencia> é gerada com o valor atribuído ao campo MunicipioIncidencia. Se ambas as tags estão com o mesmo valor, me leva a crer que a sua aplicação esta atribuindo o mesmo valor a ambos os campos.

Boa tarde Celso, Foi você que acrescentou essa cidade no arquivo Cidades.ini ? Se sim, favor anexar para que eu possa conferir.

Boa tarde Jean, O XML da nota esta sendo salvo em disco? Infelizmente existem provedores que não retornam o XML da NFS-e. Qual é o provedor?

Boa tarde Everton, Você chegou a testar? Eu sinceramente não sei e infelizmente não tenho como testar.

Boa tarde Rafael, Pode ser que o retorno de evento da NF-e seja diferente do retorno de evento do CT-e. Mas acredito que a solução que você encontrou para o CT-e possa ser aplicada também para a NF-e.

Boa tarde Weslei, Favor atualizar os fontes e faça novos testes.

Bom dia André, Você não pode comparar esses dois XMLs. Lembre-se que o componente gera o XML do RPS e envia para o webservice do provedor e este por sua vez verifica se todas as informações estão corretas, caso afirmativo o webservice gera e retorna o XML da NFS-e. Se você tentar comparar os dois XMLs que anexou vai esta comparando o XML do RPS gerado pelo componente com o XML da NFS-e gerado e retornado pelo webservice do provedor. Isso explica a diferença entre eles. Você precisa comparar o XML do RPS gerado pelo componente com um exemplo de XML de RPS fornecido pelo provedor. O ideal é comparar o Envelope gerado pelo componente com o Envelope que o webservice espera receber. Explicando: O componente inicialmente gera o XML do RPS, este é colocado dentro de um outro XML que chamamos de Lote, o Lote por sua vez pode conter até 50 RPS. Depois o Lote é colocado dentro de outro XML que chamados de Envelope ou Soap, é este que é enviado para o webservice. Se tiver alguma coisa errada na montagem do Envelope pode ocorrer o erro 500. O componente possui uma propriedade de configuração (Configuracoes.WebServices.Salvar) quando o valor dessa propriedade é True o XML (Envelope) é salvo em disco. Se o provedor lhe fornecer o Envelope de envio de Lote é possível comparar com o que o componente gera. O nome do arquivo Envelope de envio gerado pelo componente é: *-env-lot-soap.xml O nome do arquivo Lote gerado pelo componente é: *-env-lot.xml O nome do arquivo RPS é: *-rps.xml Infelizmente a montagem do Envelope feita para um provedor nem sempre funciona para outro provedor. Se o provedor não fornecer um exemplo de Envelope vamos ficar na tentativa e erro.

Boa tarde Weslei, Para mim o fontes do programa exemplo não tem utilidade nenhuma para mim. Por favor anexe o XMLs gerados após a ultima atualização dos fontes.

Bom dia Natanael, Por favor leia esse artigo: Como obter o XML da Transportadora CT-e.

Weslei, Por favor atualize novamente e faça novos testes. Não sei porque, mas a alteração que eu tinha feito no arquivo INI se perdeu. Fiz novamente e enviei para o repositório.

Bom dia Luiz, Isso é muito estranho. Na unit ACBrBPeDABPeESCPOS temos a seguinte linha: FPosPrinter.Imprimir('',False,True,True,NumCopias); Coloque um break point nessa linha para sabermos se o parâmetro NumCopias esta com a quantidade de cópias que você configurou.

Ronie, Se não foi autorizado pelo fato de ter ocorrido erro ao enviar, você pode resolver o problema da seguinte forma: 1. Envia o MDF-e 100, já que agora a SEFAZ esta operando normalmente, é bem provável que ele seja autorizado. 2. Tendo o MDF-e 100 autorizado, efetue o cancelamento do mesmo.

Weslei, Isso pode indicar que você andou fazendo alterações nos arquivos que eu alterei, neste caso o tortoise não costuma atualizar. Sugiro você deletar o arquivo INI do provedor e a unit ACBrNFSeWebServices, por fim atualize novamente.

Bom dia Ronie, O que tudo indica é que a SEFAZ-MG utiliza os mesmos servidores para recepcionar o CT-e, CT-e OS e o BP-e. Quando a SEFAZ-MG entrou em contingência e o pessoal começou a emitir o CT-e através da SVC-SP (SEFAZ-Virtual de Contingência de São Paulo) os que emitem o BP-e passaram a ter problemas, ou seja, não estavam conseguindo emitir.

Bom dia Ronie, No meu entendimento devemos fazer o seguinte: 1. O MDF-e de numero 100 foi enviado mas a SEFAZ não retornou o resultado do processamento. 2. Quando isso ocorre devemos realizar uma consulta. 3. Podemos ter como resposta: o retorno acusando que o MDF-e foi autorizado, ou foi rejeitado (neste caso devemos fazer as devidas correções e enviar novamente), ou que o MDF-e não consta na base de dados (neste caso devemos enviar ele novamente) ou ocorrer erro de conexão com a SEFAZ. 4. Caso ao consultar ocorrer erro de conexão, ai sim você emite o MDF-e em contingência, mas em vez de só mudar o tipo de emissão, mude também o numero para 101. 5. O MDF-e 101 tem as mesmas informações do 100 mas só que o tipo de emissão é contingência. 6. Ao emitir os próximos MDF-e verifique primeiro se a SEFAZ voltou, se não voltou continue emitindo em contingência. 7. Quando a SEFAZ voltar a operar, devemos enviar todos os MDF-e emitidos em contingência. 8. Consultar a situação do MDF-e 100, para saber se ele foi autorizado ou não. 9. Se sim, devemos cancelar ele, pois o 101 como dito antes tem as mesmas informações do de numero 100. Espero ter ajudado.

Bom dia Weslei, Você atualizou todas as pastas? Esta usando o programa exemplo do ACBrNFSe para realizar os testes?

Boa tarde Igor, Você esta com todos os fontes de todas pastas atualizados? Esta configurando corretamente o componente com a versão do e-Social atualmente em uso? Esta realizando testes com o programa exemplo do componente?

Weslei, Favor anexar os XMLs gerados nesse ultimo teste.

Nilton, Quando você baixa os fontes da suíte ACBr na pasta: ...\Fontes\Terceiros\DelphiZXingQRCode se encontra a unit ACBrDelphiZXingQRCode. Não se trata de um componente, apenas uma unit que você declara em uses do seu form que vai conter a rotina apresentada pelo Daniel.

Olá Pessoal, Muitos tem interesse em obter o XML da transportadora (CT-e) para facilitar a entrada do Contas a Pagar, etc. Segundo a legislação, quem emite um CT-e tem por obrigação legal de disponibilizar o XML assinado e com o protocolo de autorização ao tomador do serviço, assim que a SEFAZ autorizar o conhecimento. Essa disponibilização pode ser feita por e-mail, ou seja, o emitente envia para o tomador o XML via e-mail. Sabemos que isso nem sempre ocorre, por 2 motivos: 1. No cadastro do tomador não consta o endereço de e-mail; 2. A aplicação do emitente não possui esse recurso ou esta desativado. Mas temos uma alternativa. O componente ACBrCTe possui os seguintes métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe: DistribuicaoDFePorUltNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do ultimo NSU> ) DistribuicaoDFePorNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do NSU> ) Primeiramente vamos entender o que vem a ser esse tal de NSU. NSU - numero sequencial único, é um numero atribuído pelo Ambiente Nacional ao documento ora compartilhado pelas SEFAZ-Autorizadora. Exemplo: o emitente do conhecimento é do Estado de São Paulo, logo o conhecimento é enviado para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional os conhecimentos que foram autorizados, o Ambiente Nacional por sua vez atribui um NSU para cada conhecimento que receber. Vamos agora entender como funciona os dois métodos mencionados acima. O método DistribuicaoDFePorNSU é o mais simples de entender, pois este simplesmente baixa o documento que possui o NSU informado. Note que usei o termo documento, pois o webservice DistribuicaoDFe pode retornar os seguintes tipos de documentos: Conhecimento Completo e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um evento, o que teremos como retorno será o XML do evento e não o XML do conhecimento. Por outro lado o método DistribuicaoDFePorUltNSU nos retorna uma lista com até 50 documentos, cujos NSU são superiores ao NSU informado. Exemplo: DistribuicaoDFePorUltNSU( 35, 12345678000123, 450 ) ===> 450 é o valor do Ultimo NSU. Ao executar o método, como dito anteriormente poderá nos retornar uma lista com até 50 documentos, pois bem suponha que retorne 50, os NSU desse documentos retornados serão, 451, 452, 453, ...., 498, 499, 500. Lembre-se que nessa lista podemos ter Conhecimentos Completas e Eventos Completos. Através de uma propriedade chamada Schema nos traz a informação do tipo de documento retornado. Temos também outras duas propriedades muito importantes, são elas: UltNSU e MaxNSU. A propriedade UltNSU nos informa o numero do NSU referente ao ultimo documento da lista, já a propriedade MaxNSU nos informar o maior NSU existente no Ambiente Nacional. Continuando o exemplo acima, vamos supor que após a execução os valores de UltNSU e MaxNSU são respectivamente 500 e 750. Era de se esperar mesmo que o valor de ultNSU seja 500 pois informamos 450 e foi retornado 50 documentos, logo o NSU do ultimo é 500. A próxima vez que formos executar o DistribuicaoDFePorUltNSU devemos informar o valor 500, para que ele retorne os documentos a partir de 501 que é o próximo da lista. E devemos repetir o procedimento até que o valor de ultNSU seja igual a maxNSU, desta forma vamos ter baixado todos os documentos disponibilizados pelo Ambiente Nacional. Lembre-se que o valor de MaxNSU tende sempre a crescer a medida que novos conhecimentos forem emitidos e compartilhadas com o Ambiente Nacional. O DistribuicaoDFe não serve apenas para que possamos obter o XML da transportadora (CT-e), mas também descobrirmos se existe alguma empresa emitindo conhecimentos contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Prestação de Serviço em Desacordo. Para saber mais sobre o Distribuição DFe vide a Nota Técnica 2015/002 versão 1.00a, que se encontra disponível no Portal Nacional do CT-e e com relação ao evento Prestação de Serviços em Desacordo vide o Manual CT-e Visão Geral v3.00a que se encontra no Portal do Conhecimento de Transporte Eletrônico - SVRS. Informação importante, o serviço Distribuição DF-e, é atendido pelo Ambiente Nacional, portanto não tem nada haver com a SEFAZ-Autorizadora do emitente do conhecimento ou do tomador. Se algo falhar nesse processo, a "culpa" é do Ambiente Nacional.

Boa tarde Weslei, Por favor não fique postando em vários lugares. Já lhe respondi em uma outra postagem.