Italo Giurizzato Junior

Boa tarde Carlos, Muito obrigado pelas informações, fiz algumas alterações como você pode ver no arquivo em anexo: 20-ger-nfse-soap.xml Não tenho como testar o envio, uma vez que não possuo um certificado válido.

Boa tarde Marcelo, Muito obrigado pela colabora e desculpe pela demora. Já esta disponível. Favor atualizar os seus fontes.

Boa tarde Igor, Por favor abra a unit ACBrCTeWebServices, verifique se a linha 799 esta desta forma: infEvento.tpAmb := TpcnTipoAmbiente(FConfiguracoes.WebServices.AmbienteCodigo-1); Note que existe um menos 1, por que, o ambiente de produção é 1 e o de homologação é 2, correto? Mas o TpcnTipoAmbiente é definido da seguinte forma: TpcnTipoAmbiente = (taProducao, taHomologacao); Trata-se de um conjunto de valores que neste caso possui apenas dois, correto? Devemos lembrar que o índice do primeiro elemento é zero e não um, sendo assim isso explica o menos 1. Se configuramentos o ambiente para homologação a propriedade AmbienteCodigo vale 2, fazendo as contas 2-1 é um ou seja vai retornar o elemento de índice 1 ou seja o segundo elemento do conjunto que neste caso é taHomologacao. Concluo que o seu fonte tem alguma coisa alterada.

Boa tarde, A mensagem de rejeição é clara, o código da cidade de descarga diverge da UF de descarga. As cidades incluídas são de MG, qual é a UF informada em UFFim? Se possível post como anexo o XML do MDF-e que esta sendo rejeitado.

Boa tarde Carlos, O XML do RPS é criado pelo componente segundo a versão 2.00 do layout definido pela ABRASF. Alem disso o lote a ser enviado é submetido ao validador do componente que compara o XML com o XSD (Schema). Caso o XML contenha algum dado errado ou sua estrutura esta fora do estabelecido no XSD o componente já apresenta um erro de validação. O lote por sua vez é envelopado, ou seja, incluído dentro de um outro XML que vamos chamar de Envelope, este por sua vez é enviado para o Web Services. O componente esta gerando o seguinte Envelope em anexo: 19-ger-nfse-soap.xml Por favor de uma olha e me diga o que esta faltando ou o que esta a mais para que eu possa fazer as devidas correções. Lembrando que os dados não são reais.

Boa tarde lesf, Maravilha, vamos analisar e muito obrigado pela colaboração.

Boa tarde Igor, Por favor post como anexo o arquivo de envio e de retorno da respectiva CC-e.

Vamos as correções: Informado: [ide] cUF=DF modal=01 correto: [ide] cUF=53 modal=1 informado: [infCTe001] chCTe=53140811538486000132550010050285121050285123 SegCodBarra=0001 [infNFe000] chNFe= correto: [infCTe001001] chCTe=53140811538486000132550010050285121050285123 Observações: Procure sempre ter em mãos os manuais e notas técnicas, pois nelas temos a estrutura do XML com a descrição do campo e uma observação dele. Em cUF você informou a sigla e na Nota Técnica 2013/004 versão 1.00a do MDF-e página 93 temos que se trata do código da UF do emitente do MDF-e, portanto devemos utilizar a tabela do IBGE de código de unidades da federação. Outra coisa no grupo infCTe devemos colocar dois índices o primeiro se refere ao municipio de descarregamento e o segundo se refere ao CTe vamos a um exemplo: [DESC001] cMunDescarga= código do município 1 xMunDescarga= nome [infCTe001001] chCTe=chave do primeiro CT-e cuja carga vai ser descarregada no município 1 [infCTe001002] chCTe=chave do segundo CT-e cuja carga vai ser descarregada no município 1 [DESC002] cMunDescarga= código do município 2 xMunDescarga= nome [infCTe002001] chCTe=chave do primeiro CT-e cuja carga vai ser descarregada no município 2 Se o campo não tem informação não precisa incluir no arquivo e quando um grupo possui índice este sempre inicia em 1. Faça as correções e tente novamente.

Bom dia, Por favor não post conteúdo de arquivos. Outra coisa, sem o arquivo completo com todos os dados, não temos como lhe ajudar, pois não sabemos se você omitiu ou se não foi informado mesmo e se omitiu qual a informação que realmente esta no campo. Desculpe, mas com o arquivo que você postou não tenho como lhe ajudar.

São Carlos foi apenas um exemplo. Mas me diga onde você informa a UF de carregamento e a de descarregamento? O que vem a ser UF = PR -- Município = ABAPA na primeira imagem?

Bom dia Otavio, Se você utiliza o componente ACBrNFe basta abrir o fonte ACBrNFeUtil que esta na pasta: ...\Fontes\ACBrNFe2 e procurar pela function GetURLMG, você vai notar que as URLs para NFC-e não estão definidas. Se você souber quais são, por favor post aqui no fórum para que possamos atualizar o componente.

Bom dia Laster, Inclua a linha em negrito. (...) ACBrMDFe1.Manifestos.LoadFromFile(cArqMDFe); ACBrMDFe1.EventoMDFe.Evento.Clear; with ACBrMDFe1.EventoMDFe.Evento.Add do begin (...)

Bom dia, Quando você alimenta o componente, logo no grupo <ide> devemos informar a UFIni - Sigla da UF de Carregamento e UFFim - Sigla da UF de Descarregamento. Depois temos o grupo <infMunCarrega> onde devemos informar o código e o nome dos municípios de carregamento (limite de até 50), pois bem esses municípios tem que pertencer a UFIni. Da mesma forma também temos o grupo <infMunDescarga> onde devemos informar o código e o nome dos municípios de descarregamento (limite de até 100), pois bem esses municípios tem que pertencer a UFFim. Note que a rejeição diz: Código do Município diverge da UF de descarga do MDF-e Ou seja, os dois primeiros dígitos do código informado em cMunDescarga que se refere a UF não condiz com a sigla informada em UFFim. Em UFFim você informa MG, isso significa que a carga vai ser descarregada em Minas gerais, mas informa como cidade de descarregamento: São Carlos que fica no estado de São Paulo, isso esta errado. Se o caminhão vai fazer entrega em cidades de MG e de SP, devemos emitir 2 MDF-e. No primeiro relacionando somente a carga que vai ser descarregada em MG e o segundo relacionando somente a carga que vai ser descarregada em SP. Espero ter ajudado.

Bom dia Pedro, Se o seu cliente e a sua aplicação segue a legislação, ou seja, assim que a SEFAZ retorna o protocolo de autorização, um e-mail contendo o XML assinado e protocolado é enviado automaticamente ao destinatário, ótimo, basta solicitar aos mesmos os arquivos XML. Vamos a uma conta besta. Estive vendo agora de pouco um HD externo de 2 Tera por 400 reais. Supondo que o XML assinado e protocolado de uma NF-e em media tenha um tamanho de 10 K, então podemos armazenar nesse HD: 214.748.364,8 arquivos. Portanto o custo por arquivo é de: R$ 0,00000186264514923095703125 Se o FISCO cobrar R$ 1,00 por cada XML não apresentado a multa seria de R$ 50,00 uma vez que você disse que perdeu 50 notas. Agora se ele prefere pagar uma multa de R$ 50,00 em vez de investir R$ 400,00 para ter um custo ZERO para cada nota armazenada, ai o problema é dele.

Bom dia Paulo, Muito obrigado pela colaboração, já esta disponível.

Boa noite Glenio, Os Schemas da NFC-e são exatamente os mesmos da NF-e 3.10 Você os encontra dentro da pasta: ...\Exemplos\ACBrNFe2\Delphi\Schemas\V310 Qual é exatamente a mensagem de erro do validador? Verifique se você não esta informando nenhuma informação referente ao destinatário que possa esta gerando esse erro. A não ser que como se trata de teste há necessidade de informar pelo menos o CPF do destinatário para que o componente inclua o como nome do mesmo a mensagem informando que se trata de uma nota sem valor fiscal.

Boa noite Renato, O problema só ocorre com o certificado desse cliente? Se sim, o problema então é com o certificado.

Boa noite Rogério, A cidade de Resende/RJ é atendida pelo provedor Tiplan e São José dos Pinhais/PR é atendida pelo provedor Ginfes. Não é preciso adicionar nada, basta você configurar corretamente o componente para a cidade desejada. Estude as 3 procedure do programa exemplo, Salvar, Carregar e Configurar no que diz respeito a configuração do componente. O programa exemplo possui um combobox com algumas cidades incluídas a titulo de exemplo, caso essas duas cidades não costão no combobox inclua elas da mesma forma que as demais e realize os testes. A procedure AlimentarComponente se utiliza de valores a titulo de exemplo, portanto ao enviar um RPS com os dados que ai estão poderá ocorrer rejeição.

Pedro, No meu entendimento o XML de uma NF-e é um documento fiscal sendo assim devemos tomar todos os cuidados possíveis e imagináveis. Um HD externo de 500 Giga não custa absolutamente nada comparado o beneficio que ele traz. Fazer uma rotina que toda vez que uma NF-e é autorizada, seja feita uma cópia do seu XML no HD externo, não é tão difícil assim.

Boa tarde Pablo, VlDoc seria o valor total da nota, se sim Total.ICMSTot.vNF tem esse valor. VlAbatNt seria o desconto na nota, se sim Total.ICMSTot.vDesc tem esse valor. IndFrt se refere quem é o responsável pelo frete, se sim transp.modFrete tem essa informação. Você não esta misturando informações sobre os itens e totais da nota?

Boa tarde Apóstolo, Respondendo as suas perguntas: 1-Em cada terminal precisará ter o certificado digital? Se sim, seria melhor usar o acbrNfeMonitor que pega este certificado no servidor, ou eu posso fazer isso diretamente no componente? Tudo depende de como você vai implementar a sua solução, uns utilizam apenas UM certificado instalado no servidor que recebe todas as solicitações e faz todo o processo e devolve aos PDVs os XMLs assinados e protocolados para que o DANFE seja impresso. Caso resolva deixar cada PDV autônomo a melhor solução é instalar o Certificado A1 em cada um deles. 1.a) O Token (CSC) substitui esse certificado físico? Não, o CSC é um código alfanumérico utilizado para gerar o QR-Code 2-Já li que a impressão é opcional. Mas no mercado poderá ser concomitante ou impressão somente ao final após envio? A impressão é após o envio, lembre-se o DANFE com validade jurídica só pode ser impresso com base no XML assinado e protocolado. 3-Onde encontro exemplos de como enviar em lotes para autorização? Poderá ser somente no final do dia? O envio da nota para SEFAZ é logo após o cliente ter efetuado o pagamento da compra, ou seja não pode ser deixado para o final do dia. 4-Li alguma coisa sobre usar o AcbrECF. É só para o SAT (em SP) ou pode ser usada no RJ para a NFC-e? Até onde sei ECF é uma coisa NFC-e é outra. Sei que meus clientes me perguntarão sobre fiscalização. O que posso fazer para evitar a sonegação, isto é, depois da venda fazer cancelamentos para não autorizar? O emitente tem prazo de 30 minutos para efetuar o cancelamento de uma NFC-e, mas se ele fizer um cancelamento visando sonegar, vai se dar mau, pois o próprio cliente poderá denunciar, uma vez que este vai possuir o DANFE e ao consultar pela chave ou pelo QR-Code vai constar que a nota foi cancelada.

Boa tarde Pedro, Não, mas peça para o seu cliente entrar em contato com a SEFAZ e fazer a solicitação. Mediante uma boa justificativa a SEFAZ vai enviar a ele por e-mail por exemplo um arquivo com todas as notas solicitadas.

Boa tarde, Primeiramente o seu DACTE foi modificado, contem uma lista de vencimentos????? Segundo na versão 2.00 do CT-e (segundo o Manual versão 1.01 do DACTE (página 2) na tabela de controle de verões consta que o campo ICMS ST do DACTE foi excluído. Portanto não se deve mais imprimir essa informação no DACTE quando se tratar da versão 2.00 do CT-e. Sendo assim a sua alteração não procede.

Boa tarde Lucas, A SEFAZ não dispõe de nenhum Web Services para realizar esse tipo de consulta. A solução é o próprio emitente ter esse controle. Isso é simples basta o sistema a ser desativado apresentar qual foi o numero da última nota emitida em cada série utilizada.

Boa tarde Mikel, Você tentou consultar informando outras UF?