Italo Giurizzato Junior

Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.

Bom dia a todos, 18/06/2019 Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do CT-e/CT-e OS e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 22 de Julho de 2019 e em produção a partir do dia 26 de Agosto de 2019, contempla a atualização do schema do CT-e, criação do Evento Comprovante de Entrega dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do CT-e, cuja especificação das configurações para impressão no DACTE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DACTE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DACTE. Da mesma forma, as RV G238 a G243 e N135 a N140 passarão a ser aplicadas em 02/09/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção.

Bom dia todos, 19/06/2019 Implantações da Consulta QR Code e do WS Sincrono de MDF-e Foram implantados na SEFAZ Virtual RS os serviços de consulta QR Code e Recepção Síncrona de MDF-e no ambiente de homologação. As empresas já podem testar conforme especificado no MOC 3.00a, as URL´s dos serviços contam no menu Serviços deste portal. Obs: A consulta QR Code pelo smartphone poderá apresentar erro de certificado digital, o usuário poderá clicar em avançado e pedir para acessar mesmo assim, ou instalar o certificado raiz brasileira v2 em seu dispositivo pelo link: http://acraiz.icpbrasil.gov.br/credenciadas/RAIZ/ICP-Brasilv2.crt. Só será necessário baixar a primeira vez. Esta foi uma mudança feita pelo próprio ITI, responsável pelo ICP-Brasil, na forma como as raízes são baixadas pelos navegadores de smartphone. Até o final da semana que vem vamos disponibilizar as alterações necessárias no componente ACBrMDFe para que seja possível o envio de MDF-e no modo Síncrono.

Boa noite Gabryel, Para que isso seja possível se faz necessário fazer a mesma implementação feita no evento 1060 nos demais eventos.

Boa o tarde, O seu problema não tem nada haver com o que esta sendo tratado nessa postagem. O seu problema é referente ao certificado.

Boa tarde Rick, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde, Qual é a configuração no que diz respeito ao SSLLib e demais campos abaixo? Esta enviando par ao ambiente de homologação ou produção?

Elisângela, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Everton, Esse componente não esta 100% é preciso fazer correções e melhorias, outra coisa, não tem todos os bancos implementados nele.

João, Esse outro software não grava os XML de eventos (por exemplo) ou possui um relatório das notas manifestadas?

Boa tarde João, Lembre-se que o DistribuicaoDFe não retorna o que você emite. O evento de Manifestação do Destinatário foi emitido por você, logo a SEFAZ entende que você tem que ter o XML do mesmo. Por outro lado o XML da nota do seu fornecedor bem como o evento de Carta de Correção (por exemplo) emitidos por ele você consegue baixar através do DistribuicaoDFe. Entendeu?

Boa tarde Jhonlenon, Primeiramente se deixássemos você emitir notas como costuma emitir (cNF = nNF) todos os seus clientes iriam passar a ter as notas rejeitadas pela SEFAZ a partir do dia 02/09/2019. O motivo é muito simples a SEFAZ vai rejeitar notas cujo valor de cNF seja igual a nNF. as notas que você emitiu antes da atualização dos fontes dos componentes tem o cNF = nNF, como você vai fazer para carregar o XML para poder imprimir novamente o DANFE ou enviar um evento? Muito simples, veja abaixo como é a definição da função LoadFromFile: function LoadFromFile(const CaminhoArquivo: String; AGerarNFe: Boolean = False) ; Boolean; Notou que o LoadFromFile tem 2 parâmetros, sendo que o segundo se for True o componente vai gerar novamente o XML e como no seu caso os valores de cNF e nNF são iguais vai ocorrer o erro. Pois bem, basta não informar o segundo parâmetro, assim esse assume o valor False que faz com que o XML não seja gerado novamente. Simples assim.

Boa tarde, É o provedor EL, que tem o seu próprio layout e no retorno traz essas meia dúzia de informações mas até hoje não sabemos se devemos anexar ao XML do RPS para deixa-lo completo. Eu não me recordo o que o pessoal andou fazendo para poder imprimir o DANFSE. Não sei se eles pegam algum link que contem os dados da nota e através de um navegador se tem o DANFSE.

Boa tarde Elisângela, Além de acrescentar a URL da cidade no arquivo INI do provedor se faz necessário também incluir a mesma no arquivo Cidades.ini Você fez isso? Poderia anexar também o arquivo Cidades.ini?

Boa tarde Gabryel, Pelo que entendi, você quer carregar o XML de um evento e-Social e depois ler as informações contidas nesse XML através da leitura dos campos, correto? Pois bem, isso não é possível ser feito porque não foi implementado uma rotina que "popula" os campos ao ler o XML. A ideia do LoadFromFile deste componente é ler o XML e deixar disponível para o envio. Mas você pode analisar as alterações feitas nas Units: pcesTabelas (function TTabelas.LoadFromString(const AXMLString: String): Boolean;) e pcesS1060 (function TEvtTabAmbiente.LerXML: Boolean;) Algo semelhante você vai ter que fazer para os eventos que você desejar. No caso do evento 1030 as alterações deverão ser feitas nas units pcesTabelas e pcesS1030. Fique a vontade em fazer essa implementação. Toda ajuda é bem vinda o projeto.

Bom dia Everton, Uma pequena correção, o programa exemplo do componente ACBrCNAB se encontra também no Branches na pasta: ...\Exemplos\ACBrCNAB\Delphi Felipe, o ACBrBoleto gera um arquivo texto a ser enviado para o banco referente a cobrança, por outro lado o ACBrCNAB tem como objetivo a gerar um arquivo texto a ser enviado também para o banco, mas referente a pagamentos.

Bom dia ALA, Cada PDV tem um BD e no servidor tem um outro que concentra tudo de todos os PDV? Se sim, veja bem no BD local você tem "N" informações sobre a nota o código seria apenas mais uma informação se der um problema nesse BD não é o código que você vai perder e sim todas as informações da nota. No XML da nota temos a data e hora de emissão, e tudo o que esta no XML é levando em consideração para gerar o DigestValue que se encontra na assinatura. Se você gerar novamente o XML com a mesma data mas com a hora de emissão diferente da primeira, pronto o DisgestValue vai ficar diferente e ao consultar a nota na SEFAZ para pegar o protocolo de autorização o componente não vai atualizar o XML pois o DigestValue do XML é um e do protocolo é outro. Noto que você esta se preocupando com uma coisa e esta esquecendo de outra tão importante quanto.

Bom dia, O componente gera o XML do RPS que deve ser enviado para o provedor e este retornar o XML da NFS-e. O componente ao receber o XML da NFS-e do webservice do provedor se encarrega de salvar o mesmo em disco (se o componente estiver configurado para isso). De posse do XML da NFS-e, ai sim podemos emitir o DANFSE. Você disse que é salvo um XML (*-nfse.xml), favor anexar um para que possamos analisar.

Boa tarde ALA, Qual é o problema da sua aplicação gerar um código aleatório e armazena-lo juntamente com os demais dados da nota? Na rotina que lê as informações do banco de dados e passa para o componente, tem uma linha que lê numero da nota da tabela e passar para nNF, correto? Qual seria a dificuldade de ler o código que obviamente estar armazenado em outro campo e atribuir a cNF?

Boa tarde Josafar, Por favor leia essa noticia: Código Numérico inválido, Chave não Gerada Ela trata sobre a NT, inclusive tem a função que gera o código aleatoriamente conforme a SEFAZ sempre exigiu.

Boa tarde, Como essa questão de imprimir o QR-Code no DANFSE é uma ou outra cidade que tem, não foi implementado. No meu entendimento deveria ser feito um DANFSE especifico com o QR-Code, pois não podemos colocar no padrão, pois por padrão não existe o QR-Code no DANFSE.

Boa tarde Professor, Não existe uma sequencia correta. Provedores que seguem a versão 1 do layout da ABRASF só disponibiliza o serviço de envio de lote no modo assíncrono: botão [Enviar Lote RPS (Enviar)] Já os provedores que seguem a versão 2 do layout da ABRASF a principio disponibilizam os 3 tipos de serviços: envio de lote no modo assíncrono: botão [Enviar Lote RPS (Enviar)], o envio de lote no modo síncrono: botão [Enviar Lote RPS (EnviarSíncrono)] e o GerarNFSe: botão [Enviar um RPS (Gerar)]. O botão [Gerar Lote RPS] apenas gera o lote e salva em disco, não faz mais nada. Pode ser utilizado para os provedores que não tem webservice, neste caso o componente gera o lote de RPS e através do site do provedor você importa o mesmo. Para os provedores que não seguem a ABRASF, a dica é abrir o arquivo INI do mesmo e ver quais são os serviços oferecidos.

Boa tarde Daniel, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde, Esse XML que você anexou é do RPS. O DANFSE foi feito para imprimir os dados do XML da NFS-e e não do RPS.

Boa tarde Rodrigo, Muito obrigado pela colaboração, ainda hoje vou enviar para o repositório.