Italo Giurizzato Junior

Você tem certeza que a empresa contrata pela prefeitura de Marilia é Giss? Esse XML não tem nada haver com o layout da ABRASF. Como disse antes o provedor Giss segue a versão 2 do layout da ABRASF.

Pessoal, Nessa segunda postagem sobre o grupo de Informações do Responsável Técnico, vou colocar o posicionamento de cada SEFAZ se vão exigir ou não, a medida que eu tomar conhecimento. SEFAZ-SP nesse primeiro momento não vai exigir. SEFAZ-RS nesse primeiro momento não vai exigir. SEFAZ-MS vai exigir o grupo.

Boa tarde Milton, O que você acha de usar os schemas que nós disponibilizamos? Pasta: ...\Exemplos\ACBrDFe\Schemas\NFe

Boa tarde Pessoal, Primeiro foi o CT-e e o MDF-e a ter o seu layout alterado para contemplar um novo grupo: <infRespTec> Informações do Responsável Técnico, agora esta chegando a vez da NF-e. Os 3 componentes já estão preparados para gerar esse grupo. Alguns desenvolvedores já estão gerando o grupo <infRespTec> para o CT-e e MDF-e, tanto em homologação quanto em produção. No caso da NF-e as datas previstas são: para o ambiente de homologação é 25/02/2019 e para produção é 29/04/2019 alterado para 03/06/2019 (conforme consta na versão 1.30 da NT 2018/005). Quero deixar claro que essas datas se referem ao prazo para que as SEFAZ finalizem a implementação em seus webservices, portanto somente a partir dessas datas é que poderemos enviar o XML da NF-e com esse grupo. Portanto, a partir do dia 25/02/2019 teremos um prazo de 3 meses para realizar os testes em ambiente de homologação. Outra coisa importante a ser dita é que esse grupo é opcional, mas vai ficar a critério de cada UF torna-lo obrigatório ou não. Quais são as informações que compõe esse grupo? O grupo <infRespTec> é composto pelos campos: CNPJ da empresa que desenvolveu o software, xContato é o nome da pessoa responsável pelo software, email e fone dessa pessoa ou da empresa. Caso você opte por gerar esse grupo independente da UF exigir ou não, as 4 informações acima deveram constar. Como dito acima os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec>, para que isso ocorra basta acrescentar na sua rotina que alimenta o componente com os dados que vão fazer parte do XML as seguintes linhas... O exemplo abaixo é para a NF-e: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) infRespTec.CNPJ := xCNPJ_RespTec; // CNPJ da Empresa infRespTec.xContato := xContato_RespTec; // Nome do Contato infRespTec.email := xEmail_RespTec; // email do Contato ou Empresa infRespTec.fone := xFone_RespTec; // fone do Contato ou Empresa end; As linhas em negrito acima são exatamente iguais para o CT-e e MDF-e. Nas Notas Técnicas da NF-e, CT-e e MDF-e que se refere a esse grupo tempos ainda mais dois campos: idCSRT e hashCSRT que vão ficar para uma segunda etapa. O CSRT - Código de Segurança do Responsável Técnico, trata-se de um código alfa numérico que será fornecido pela SEFAZ através de uma página própria ou por um webservice, conforme consta na Nota Técnica. Sendo assim, enquanto a SEFAZ não criar essa página ou webservice não temos como solicitar o CSRT e portanto não podemos incluir no XML o idCSRT que é um numero sequencial e o hashCSRT que é o resultado do hash (SHA1 - Base64) da concatenação do CSRT mais a chave do documento. Os componentes já possuem no rol de configurações, as propriedades idCSRT (Integer) e CSRT (String), nessa primeira etapa devemos atribuir o valor zero a idCSRT e uma string vazia para o CSRT, para que os campos: idCSRT e hashCSRT não sejam gerados. Os valores padrões estabelecidos pelo componente são: idCSRT = 0 e CSRT = '' (string vazia). Reforço que o preenchimento dessas propriedades só devem ser feitas a partir do momento que a SEFAZ lhe fornecer o idCSRT e o CSRT. Vamos supor que as UF: x, y e z venham a exigir o grupo <infRespTec> e criem uma pagina ou webservice para fornecer o CSRT, caso você tenha clientes usando ou seu software para emitir NF-e ou CT-e ou MDF-e será necessário solicitar o CSRT em cada uma das UF. Resumindo o CSRT fornecido pela UF x só é valida para os seus clientes dessa UF que usam o seu software. Quais são as UF que vão exigir o grupo <infRespTec> não sabemos, logo devemos ficar atentos. A minha sugestão é que o seu software gere esse grupo independente da UF exigir ou não, pois o dia que ela resolver exigir você não vai precisar fazer nada, pois já consta no XML o grupo. A questão agora é quanto ao CSRT, como dito anteriormente, vai ficar para uma segunda etapa visto que, se faz necessário a SEFAZ criar a página ou webservice. O meu conselho é que no seu software na tela de configuração tenha os campos: idCSRT e CSRT para que você possa informa-los assim que obter. Detalhe importante, os campos idCSRT e hashCSRT só serão gerados no XML e de forma automática dentro do grupo <infRespTec> a partir do momento que as propriedades de configuração: idCSRT e CSRT passarem a ter valores validos. O texto ficou longo, mas espero ter passado todas as informações necessárias para que vocês possam fazer as alterações em seus softwares e desta forma ficarem em conformidade com as nas Notas Técnicas. Para quem não leu as NT, por favor leiam. NT 2018/005 versão 1.20 - Alteração do layout da NF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/NFe/NT/2018/ NT 2018/002 versão 1.01 - Alteração do layout do CT-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/CTe/NT/2018/ NT 2018/002 versão 1.02 - Alteração do layout do MDF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/MDFe/NT/2018/

Boa tarde Wesclei, Na minha maquina não abre, tentei com o Chrome e com o Edge. Se for possível, baixe o material disponível compacta e anexa aqui no fórum. Desde já muito obrigado pela colaboração.

Boa tarde, O provedor Giss ele não segue a versão 2 do layout da ABRASF? Porque o layout do XML da NFS-e tem tags completamente diferentes da versão 2?

Boa tarde, Use o ";" ponto e virgula, pois na hora de imprimir o DANFSE o componente faz a quebra de linha.

Boa tarde, Tente usar o libCapicom, para ver se ocorre o mesmo erro.

Fernando, O seu código esta errado, pelo simples fato dele não realizar o envio. É preciso debugar para saber porque esta aparecendo a mensagem de que o certificado não foi informado.

Bom dia a todos, Se não me falha a memória o componente ACBrNFe (usado no monitor) possui uma propriedade de configuração chamada: VerificarValidade. Se ela estiver com o valor True, antes do envio é feita a verificação, caso o certificado esteja vencido será apresentado uma mensagem avisando que a data de validade do certificado expirou. É preciso checar se o Monitor possui uma opção de configuração que ativa/desativa essa propriedade.

Bom dia Fernando, Com o programa exemplo também ocorre esse erro?

Bom dia Milton, Os novos Schemas você pegou de onde? Com os novos Schemas o que ocorreu? Pois dizer que com os novos não funcionou o envio, cancelamento é muito vago.

Bom dia Duarte, Você esta com todos os fontes atualizados? Esse erro esta ocorrendo quando você tenta cancelar uma nota?

Bom dia Eduardo, Os documentos anteriores de papel informados foram emitidos por uma outra transportadora (pelo que eu entendi). Sendo assim ela não deveria ter emitido um CT-e em vez de um Conhecimento Avulso (papel)?

Bom dia John, Conforme consta na página 5 da Nota Técnica 2014/002 versão 1.02b os webservices: ConstNFeDest e DownloadNFe foram desativados em 31/05/2017 sendo substituídos pelo DistribuicaoDFe. Mantivemos por um certo tempo no componente código referente a esses dois métodos, mas recentemente foram removidos, pelo simples fato de não fazer nenhum sentido manter uma rotina que acessa um webservice que não existe mais. Sugiro que leia com muita atenção a Nota Técnica mencionada acima para entender como que funciona o DistribuicaoDFe e consequentemente implementar de forma correta em sua aplicação.

Boa tarde Fabio, O XML de pedido de consulta está sem o CNPJ/CPF tag <nrInsc>. Se não me falha a memória ele pega essa informação da configuração do componente.

Boa tarde Fernando, Se não me falha a memória não há necessidade do certificado digital para consumir o webservice da AT&M.

Boa tarde a todos, Uma coisa é o grupo <infResTec> outra coisa são as tags <idCSRT> e <hashCSRT>, sendo que esta ultima para ser gerada se utiliza da chave e do CSRT. Em um primeiro momento uma determinada UF poderá exigir o grupo com as tags obrigatórias: <CNPJ>, <xContato>, <email> e <fone>. Depois, quando estiver disponível a geração (via site ou webservice) do idCSRT e CSRT essa determinada UF poderá vir a exigir as tags: <idCSRT> e <hashCSRT>. Amaury, te aconselho a fazer um novo questionamento, só que agora pergunte se a SEFAZ-SP vai exigir que seja gerado o grupo <infRespTec> = Grupo de Informações do Responsável Técnico.

Boa tarde Diogo, Fiz um teste com o programa exemplo que se utiliza do DACTE feito em Fortes Report. A impressão do DACTE - CT-e Complementar esta normal, ou seja, imprimiu todos os quadros necessários. Pelo seu relato algo esta errado no DACTE feito em Fast Report. Como não tenho conhecimento em Fast não vou poder ajudar, mas vou passar o problema para quem conhece o Fast.

Bom dia Adilson, Neste caso é preciso verificar o fonte DANFSE para ver o que esta ocorrendo, pois a impressão do "sim" ou "não" teria que estar condicionada ao valor do campo IncentivadorCultural.

Bom dia Adilson, Os provedores que aceitam um numero de lote constante significa que não fazem nenhuma checagem em cima dessa informação, logo ela ser constante ou sequencial crescente não vai mudar em nada para esses provedores. Portanto no meu entendimento devemos ter me nosso sistema um numero sequencial crescente para o numero do Lote independente de quem seja o provedor.

Bom dia Sandro, O ACBrMonitor se utiliza do componente ACBreSocial e este assim que gera o XML de um evento, já se encarrega de assinar e validar deixando-o assim pronto para ser enviado. A minha sugestão é que a sua aplicação pegue o XML assinado e remova a assinatura.

Bom dia Marlon, Nunca vi uma tabela relacionando as duas informações.

Bom dia, Favor ler a ultima linha da primeira postagem desse tópico.

Boa tarde a todos, Estou promovendo algumas alterações que visam simplificar o código do componente, com isso ele fica menor e o EXE da aplicação também. Mas tudo tem um preço. Se fez necessário criar novos campos em alguns arquivos INI de provedor, isso significa que depois da atualização de todos os fontes e recompilar a aplicação será necessário enviar para os seus clientes o novo EXE bem como os novos INI caso você utilize um provedor cujo INI sofreu alteração. Lista dos provedores cujo INI sofreu alteração: Agili, Agiliv2, Betha, Bethav2, BHISS, CONAM, CTA, DBSeller, DeISS, Digifred, EGoverneISS, EL, Equiplano, Fiorilli, GINFES, Infisc, Infisc-v11, IPM, ISSDSF, ISSe, ISSJoinville, MetropolisWeb, NotaBlu, Pronimv2, Publica, PVH, RJ, SimplISS, SmarAPD, SmarAPDABRASF, SP, SystemPro, Tecnos e Thema. Pretendo enviar essas alterações entre hoje (segunda) ou amanhã. Peço que após a atualização dos fones, façam testes e reporte os problemas.