Italo Giurizzato Junior

Boa tarde Walter, Leia o ajuste SINIEF 15 de 28/09/2012 na integra através do link abaixo: http://www.fazenda.gov.br/confaz/confaz/ajustes/2012/AJ_015_12.htm Mais precisamente: “Cláusula décima sétima A obrigatoriedade de emissão do MDF-e será imposta aos contribuintes de acordo com o seguinte cronograma: I – na hipótese de contribuinte emitente do CT-e de que trata o Ajuste SINIEF 09/07, no transporte interestadual de carga fracionada, a partir das seguintes datas: a) 1º de julho de 2013, para os contribuintes obrigados a emissão do CT-e de que trata o inciso I da cláusula vigésima quarta do Ajuste SINIEF 09/07; 1º de novembro de 2013, para os contribuintes obrigados a emissão do CT-e de que trata o inciso III da cláusula vigésima quarta do Ajuste SINIEF 09/07; c) 1º de abril de 2014, para os contribuintes obrigados a emissão do CT-e de que trata o inciso IV da cláusula vigésima quarta do Ajuste SINIEF 09/07; d) 1º de agosto de 2014, para os contribuintes obrigados a emissão do CT-e de que trata o inciso V da cláusula vigésima quarta do Ajuste SINIEF 09/07; Acho que responde a sua pergunta.

Boa tarde Warlen, Você atualizou os fontes da pasta PCN2?

Thiago, Existe dois processos de checagem: 1. Validação realizada pelo próprio componente. A validação consiste em submeter o XML assinato ao schema (fornecido pela SEFAZ), essa validação verifica os tamanhos dos campos, os numeros de casas decimais, a presença dos dados obrigatórios. Nesse processo não é checado se o CNPJ é válido ou não. Quando o componente detecta alguma inconsistencia nada é enviado a SEFAZ e uma mensagem de erro de validação é apresentada pelo componente. 2. Validação realizada pela SEFAZ. A validação realizada pela SEFAZ, alem de submenter o XML assinado ao schema, valida também o conteudo das informações, como por exemplo se o CNPJ é válido ou não, entre outras coisas. Quando a SEFAZ detecta alguma inconsistencia o XML não é aceito e é retornado um XML contendo a rejeição (motivo pelo qual a SEFAZ não aceitou). A minha sugestão é que você não permita que o usuário informe dados inválidos, por exemplo: ao cadastrar o remetente/destinatário checar se o CNPJ, a Insc. Estadual são válidos, etc. e impedir que o cadastro seja feito caso ocorra falhas na validação. Desta forma você minimiza as rejeições da SEFAZ.

Thiago, Na verdade basta essa linha: DmCte.ACBrCTe.Enviar(cdsID.AsInteger); Porque o Enviar executa internamente o Assinar que gera o XML, assina e salva em disco. Executa também o Valida e caso o CTe tenha sido autorizado pela SEFAZ o mesmo é impresso. O XML é salvo dentro da pasta que você configurou, agora caso você deseja salva-lo no banco de dados, pesquise no fórum você vai encotrar algumas sugestões dos colegas. O que você quer dizer com interferência?

Bom dia Helder, Não, o que esta disponivel é a rotina de envio de evento no caso o EPEC, mas a SEFAZ ainda não liberou os ambientes de homologação e produção. Os ambientes vão estar disponiveis somente em abril (homologação) e maio (produção) de 2013. Cancelamento e CC-e estão previstos na NT mas sem prazo de implementação por parte da SEFAZ.

Thiago, Quanto ao CNPJ ele esta correto, mas encontrei outros problemas: O código do pais não é 55, segundo o IBGE o código do Brasil é 1058, como você informou o código 55 não esta aparecendo corretamente as seguintes informações: cMun, xMun e UF. <rem> <CNPJ>06272199000940</CNPJ> <IE>121166988</IE> <xNome>CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xNome> <fone>9935253094</fone> <enderReme> <xLgr>RODOVIA BR 006</xLgr> <nro>KM 32</nro> <xBairro>CENTRO</xBairro> <cMun>9999999</cMun> <xMun>EXTERIOR</xMun> <CEP>65940000</CEP> <UF>EX</UF> <cPais>0055</cPais> <xPais>BRASIL</xPais> </enderReme>

Bom dia Thiago, Se possível poste como anexo o XML.

Boa tarde Joemil, Você esta com os fontes atualizados? Se sim, note que o componente ACBrNFSe tem uma propriedade dentro do grupo WebServices chamada ConsultaLoteAposEnvio, cujo valor padrão é True. No seu caso altere o valor para False.

Dionatan, Você atualizou os fontes da pasta PCN2? Se sim, verifique se o icone do fonte pcnConversao.pas contem a bolinha verde, se estiver vermelha ou amarelo, delete o arquivo e baixe novamente e depois abra o pacote PCN2 que encontra-se em ...\Pacotes\Delphi\ACBrNFe2 e compile. Depois abra a aplicação e compile com a opção Build.

Bom dia Dionatan, Não é comentado uma linha no fonte do componente que você vai resolver o problema. Você resolve o problema da seguinte forma: Primeiro, atualizando todos os fontes de todos os componentes, periodicamente. Segundo, compile a sua aplicação ou o programa exemplo usando a opção build. Pelo jeito faz tempo que você não atualiza seus fontes, pois a rotina de envio de eventos no componente ACBrCTe foi implementada por mim em novembro do ano passado.

Bom dia Leandro, Desculpa, a semana passada foi tumultuada, fiz algumas alterações e mandei para SVN, favor atualizar os fontes e testar.

Bom dia Cristian, Você pode indicar nos fontes o que você alterou ou acrescentou, exemplo: // Incluido por Cristian Enviar os fontes para o meu e-mail.

Bom dia, Você esta alimentando o componente de forma errada. Na unit que encontra-se a sua rotina, inclua em USES a unit pcnConversao. Depois faça desta forma: with Imposto do begin with ICMS do begin Imposto.ICMS.CST:=cst41; ICMS.orig:= oeNacional; ICMS.CSOSN:=csosn400; end; (....)

Ariel, Você fez a mesma pergunta neste tópico:

Boa tarde Ariel, Por favor não post a mesma questão varias vezes, espere que algum lhe responda.

Boa tarde Rogério, Por favor de uma olhada no manual do DACTE versão 1.00b página 15, temos uma tabela, leia a observação referente ao Peso Bruto (Kg).

Boa tarde Helder, Já encontra-se disponivel a alteração, favor baixar e testar.

Rodrigo, Eu não conheço o Fortes, e nem tenho ele instalado no meu Delphi. Vou ficar devendo essa para você.

Bom dia Rodrigo, A carga é fracionada ou lotação? Se for lotação exitem os campos próprios para essas informações e elas são impressas no DACTE, mas você tem que informar que a carga é lotação. Se for fracionada esses podem ser informados no campo de observação, visto que se forem colocados nos campos próprios eles não seram impressos no DACTE. Espero ter ajudado.

Boa tarde Johnbh3, Por segurança faça uma cópia dos fontes dos componentes e atualiza tudo, pois os fontes mais atuais tratam da presença ou não do prefixo nas tags.

Bom dia Sandro, Se possivel post como anexo o XML que é rejeitado.

Boa noite Amarildo, Como dito varias vezes, realizei algumas alterações no componente ACBrNFe para que este possa suportar o dois modelos de documentos fiscais ou seja a NF-e e a NFC-e. Estou realizando testes com o componente ACBrNFe alterado em uma maquina que tenho em casa. Os resultados dos últimos testes: Status do Serviço - Ok Envio em modo Síncrono (uma nota por lote) - Ok Consultar a Situação Atual da nota - Ok Cancelamento por evento - Ok Inutilizar faixa de numeração - Ok Todos os testes acima o tempo de retorno da SEFAZ ficou abaixo de 5 segundos. Envio em modo Assíncrono (mais de uma nota por lote, utilizado na NF-e) - Ok Neste teste temos um problema a SEFAZ esta demorando para efetuar o retorno, estourando o tempo em mais de 30 segundos. Já entrei em contato com a SEFAZ e a pessoa responsavel disse que até o final desta semana vai verificar o que esta ocorrendo. Você esta participando do projeto piloto? Se sim entre em contato comigo por e-mail. Como você pode ver já tenho o componente alterado e com varios testes realizados. As alterações realizadas por mim alem de atender a NFC-e já prepara o componente para a versão 3.0 da NF-e. Esta faltando desenvolver o DANFE da NFC-e.

Boa Noite Sandro, No que diz respeito a NF-e temos o Emitente e o Destinatário e as definições nos schemas dos campos IE para essas duas pessoas são diferentes. Para o Emitente temos: O campo IE esta definido conforme o tipo Tie, este tipo requer que seja informado o numero da IE ou a palavra ISENTO (no singular e todas as letras em maiusculo). Para o Destinatário temos: O campo IE esta definido conforme o tipo TieDest, este tipo requer que seja informado o numero da IE ou a palavra ISENTO (no singular e todas as letras em maiusculo) ou deixa-lo em branco ou seja vazio. Essas informações estão no arquivo: tiposBasicos_v1.03.xsd Temos ainda o tipo TieST que só aceita o numero do IE, esse tipo é usando para definir o campo IEST (Inscrição Estadual do Substituto Tributário) campo opcional do grupo <emit>.

Boa tarde Imatech, Favor atualiza os fontes e testar novamente. Agora é para ignorar o código L000 como sendo um erro.

Bom dia Dionatan, Na verdade a sua aplicação deve controlar de forma automatica o numero do RPS e não deixar que o usuário informe o numero que ele bem entender. O programa exemplo é o usuário que informa esse numero, mas trata-se de um programa exemplo, que mostra como usar as funcionalidades do componente. Logo não trata-se de um produto final.