Italo Giurizzato Junior

Boa noite Guilherme, Você baixou todos os fontes? Se sim, abra o pacote ACBrComum e compila, isso pode resolver o problema.

é isso que da deixar na mão dos municipios, cada um quer fazer do seu jeito.

Boa tarde Wolver, Atualize os fontes, inclusive os arquivo de configuração, são 3 arquivos .INI

Boa tarde Elton, Acredito que sim, nesse últimos dias estive em contato direto com outro colega do forum que pretente utiliza-lo, o bom é que se trata de outro provedor: o ISS.NET, e não exite apenas o GINFES e o ISS.NET como provedores de NFSe usando o padrão Abrasf. Colocando no trunk tendo esses dois funcionando os demais, juntando forças vamos concluir.

Boa tarde Graça, Vamos as respostas: 1. Sim é o que esta no branches, tem um colega utilizando em produção em Araraquara - SP (Ginfes). 2. O componente não suporta o padrão DSF e até onde sei ele é totalmente diferente do ABRASF. 3. Sem problemas tenho instalado no Delphi o NFe, CTe e NFSe. 4. sim no arquivo Config_Municipio.ini que encontra-se na pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas

José, Pelo conteudo do arquivo ACBr.inc que você postou, os teus fontes estão desatualizados, inclusive o ACBr.inc

Bom dia José, O componente é capaz de gerar o XML tanto na versão 1.03 quanto na 1.04. Para definir qual versão a ser utilizada, deve-se alterar o arquivo ACBr.inc, no final deste arquivo é explicado o que tem que ser feito. Dentro da pasta ...\Exemplos\ACBrCTe temos arquivos TXT com fragmentos de código que mostra como alimentar o componente com os dados.

Bom dia Felipe, Sim, só precisamos de voluntários, para realizar a implementação. Caso você tenha interesse em colaborar, mão na massa.

Você tem o Quick Report Instalado? Se sim, abra o pacote de instalação remova o qrpt da lista, e manda compilar novamente e depois instalar.

Bom dia José, O fragmento do xml se refere a NFe ou CTe? Se CTe é do Emitente, Remetente, Destinatario, Receber, Expedidor, ... ? Isso costuma ocorrer quando o código do Pais é diferente de 1058.

Ainda não, estou checando as rotinas.

Bom dia a todos, O SEFAZ-MG está instavel, acredito eu pelo fato de estarem implementando em ambiente de produção a nova versão.

Então, Minas Gerais esta seguindo Mato Grosso, que também vai aceitar a versão 1.03 até 29/02/2012.

Boa tarde, Sim conferi, duas coisas me chamou a atenção: 1: se refere a data de emissão, foi passado somente a data e não data e hora, no seu xml esta assim: 2011-10-27T00:00:00 Note a hora esta 00:00:00 2: se refere ao nome do municipio do destinatário parece que a vogal A estava acentuada e foi substituida, no seu xml esta assim: VARGEaO Note a vogal A esta em minuscula Do resto parece estar tudo OK.

Boa noite, Os schemas da versão 1.04 são compostos por 28 arquivos, mais o arquivo: xmldsig-core-schema_v1.01

Bom dia Graça, No caso do Simples Nacional, acredito que devemos informar desta forma: Imp.ICMS.SituTrib := cstICMSSN; Imp.ICMS.ICMSSN.indSN := 1;

Cleber, O seu fonte pnfsConversao esta desatualizado, apague-o e baixe novamente.

Boa tarde Graça, Não, houve uma alteração bem drastica no schema e no xml de tal forma que no inicio do xml temos a sua versão do schema do CTe e no meio temos a versão do schema referente ao modal. Eu vou disponibilizar para o meu cliente 2 versões do programa.

Esta disponivel no Branches na pasta: ...\Exemplos\ACBrNFSe\Delphi

Cleber, No programa exemplo: Aba Emitente -> código da cidade = 3126109 Aba Certificado -> Assinar Lote = Ticado -> Assinar RPS = não Ticado Aba WebService -> Padrão = Abrasf -> Ambiente = Homologação Usei a opção Gerar e Enviar Lote.

Boa tarde Cleber, Testei aqui e estou tendo um retorno do webservice:

Boa tarde Graça, No site da SEFAZ de MT temos o seguinte comunicado: ::Comunicado para os emissores de CTe Nota 1: A versão 1.04 entrará em produção a partir de 01/11/2011, estando disponível em ambiente de homologação a partir de 01/09/2011. Nota 2: Informamos que a data final para utilização da versão 1.03 encerra-se em 29/02/2012. A partir de 01/03/2012 somente será aceita a versão 1.04, para os ambientes de homologação e produção. Nota 3: Nota técnica sobre alteração na validação de duplicidade está disponível no portal. Quanto aos demais, nada consta.

Bom dia Ricardo, Vamos a NT2009.006 da NF-e Página 7: GB10, GB10.1, GB10.2 refere-se a data de emissão e data de saída informada no XML. * Essas regras de validação é para garantir que a data de saída se informada seja igual ou posterior a data de emissão, observado que a data de saída não pode utrapassar 30 dias após a data de emissão. Exemplo: Data de Emissão: 28/10/2011 Data de Saída: 20/10/2011 ===> Rejeição data de saída anterior a data de emissão. Data de Emissão: 28/10/2011 Data de Saída: 30/10/2011 ===> Sem problemas, a data de saida é posterior a de emissão e esta dentro do prazo de 30 dias. Data de Emissão: 28/10/2011 Data de Saída: 20/12/2011 ===> Rejeição data de saída ultrapassa o prazo de 30 dias após a data de emissão. Página 8: GB17, GB20d, GB20e, GB20f refere-se a validação do CNPJ/CPF e IE do emitente da NF modelo 1/1A referenciada (veja páginas 110 e 111 do manual de integração para mais detalhes). GB20i refere-se a validação da chave do CTe Referenciado (veja página 111 do manual de integração para mais detalhes). Página 12: GI08, GI08.1 refere-se a validação do CFOP tanto para notas de saída quanto as de entrada. GI08.8 refere-se a validação do CFOP de Exportação. Como você pode ver são regras de validação que vão ser implementadas no webservices para validar o xml enviado por você. Se a sua aplicação esta informado os dados de forma correta não tem o que se preocupar. O que estava acontecendo, exemplo: o CFOP de exportação até agora se você informa-se 1234 passava, agora essa informação vai ser validada caso esteja errada a NF-e sera rejeitada. Espero ter ajudado.

Boa tarde, Eles devem ficar na pasta que você indicar como sendo a pasta que contem os schemas. Se possível favor postar o XML gerado para envio, que retornou o erro.

Boa tarde Ariovaldo, O componente ACBrNFSe, ainda não possui uma função para ler um arquivo TXT.