Painel de líderes

Bom dia a todos, Na pasta: ...\Exemplos\ACBrDFe\Schemas\CTe temos os schemas: cteTiposBasico_v3.00.xsd cteTiposBasico_v3.00_Homologacao.xsd O schema cteTiposBasico_v3.00_Homologacao contempla as mudanças ocorridas na estrutura do XML do CT-e na versão 3.00a, já o outro não contempla. Até o dia 25/08/2019 devemos usar o arquivo cteTiposBasico_v3.00 em nossos clientes uma vez que eles estão emitindo os CT-e em produção. Para aqueles que desejam realizar os testes no ambiente de Homologação deverão seguir os passos abaixo: rename cteTiposBasico_v3.00.xsd cteTiposBasico_v3.00_Producao.xsd rename cteTiposBasico_v3.00_Homologacao.xsd cteTiposBasico_v3.00.xsd A partir do dia 26/08/2019 deveremos enviar para os nossos clientes o arquivo cteTiposBasico_v3.00_Homologacao renomeado para cteTiposBasico_v3.00 Isso se a SEFAZ comprir com as datas publicadas.

Bom dia, Verifiquei que a classe para o Banco Bradesco (arquivo ACBrBancoBradesco.pas) está faltando o motivo 76 na função TACBrBancoBradesco.COdMotivoRejeicaoToDescricao, conforme Manual anexo. Fiz a alteração, incluindo a linha "76: Result := '76-Pagador Eletrônico DDA (NOVO)- Esse motivo somente será disponibilizado no arquivo retorno para as empresas cadastradas nessa condição';" logo depois da linha nr. 1312. Anexei o fonte. ACBrBancoBradesco.pas

Bom dia pessoal, Com a versão 3.00a do CT-e temos um novo evento chamado Comprovante de Entrega. Esse evento é emitido pela própria transportadora e não pelo destinatário da mercadoria. Nesse evento temos um campo obrigatório chamado hashEntrega, cuja descrição: Hash (SHA1) no formato Base64 resultante da concatenação: Chave de acesso do CT-e + Base64 da imagem capturada da entrega (Exemplo: imagem capturada da assinatura eletrônica, digital do recebedor, foto, etc) Nota 1: A critério do autor deste evento, este campo pode ser utilizado como índice para acesso as informações do Comprovante de entrega. Nota 2: A SEFAZ não tem nenhum controle sobre a informação deste campo. Observação: 28 caracteres são representados no schema como 20 bytes do tipo base64Binary. Nesse primeiro momento o componente não esta calculado o hash ficando a cargo da aplicação do desenvolvedor, pois vamos verificar a possibilidade de implementar. Para quem utiliza o ACBrMonitor abaixo segue um exemplo de como montar o arquivo INI do evento de Comprovante de Entrega: [EVENTO] idLote=1 [EVENTO001] chCTe= chave do CT-e cOrgao= Codigo da UF CNPJ= CNPJ do emitente dhEvento=25/07/2019 10:30:00 tpEvento=110180 nSeqEvento=1 nProt= numero do protocolo de autorização do CT-e dhEntrega=24/07/2019 17:30:00 nDoc= Documento de identificação da pessoa que recebeu a entrega xNome= Nome da pessoa que recebeu a entrega latitude= Latitude do ponto da entrega (detectado pelo equipamento do transportador, exemplo: PDA, tablet, celular) longitude= Longitude do ponto da entrega (detectado pelo equipamento do transportador, exemplo: PDA, tablet, celular) hashEntrega= Hash (SHA1) no formato Base64 resultante da concatenação: Chave de acesso do CT-e + Base64 da imagem capturada da entrega (Exemplo: imagem capturada da assinatura eletrônica, digital do recebedor, foto, etc) dhHashEntrega= Data e hora da geração do hash da entrega ; xxxx pode variar de 0001 até 2000 [infEntregaxxxx] chNFe= chave da NF-e da mercadoria que foi entregue Para quem utiliza o componente, abaixo temos um exemplo de como enviar o evento em questão: ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.New do begin infEvento.chCTe := ChaveCTe; infEvento.CNPJ := CNPJEmitente; infEvento.dhEvento := now; infEvento.tpEvento := teComprEntrega; infEvento.nSeqEvento := 1; infEvento.detEvento.nProt := nProtocoloAutorizacao; infEvento.detEvento.dhEntrega := datahoraEntrega; infEvento.detEvento.nDoc := NumeroDocumento; infEvento.detEvento.xNome := NomedoRecebedor; infEvento.detEvento.latitude := fLatitude; infEvento.detEvento.longitude := fLongitude; infEvento.detEvento.hashEntrega := hashdaEntrega; infEvento.detEvento.dhHashEntrega := datahhoradoHashEntrega; InfEvento.detEvento.infEntrega.Clear; // o bloco abaixo poderá se repetir por até 2000 vezes with InfEvento.detEvento.infEntrega.New do chNFe := ChaveNFe; end; ACBrCTe1.EnviarEvento( 1 ); // 1 = Numero do Lote

Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.

Boa tarde. Depois de MUITO tempo finalmente consegui atualizar as aplicações aqui da empresa para o trunk2 . Durante a conversão identifiquei algumas cidades que estavam apontando para o provedor incorreto ou não constavam no arquivo. Segue abaixo as cidades: Alteradas: [3133808] Nome=Itaúna UF=MG Provedor=GINFES Nova: São Gonçalo do Pará Cidades.INI: [3161809] Nome=São Gonçalo do Pará UF=MG Provedor=WebISSv2 NomeURL_H=homologacao NomeURL_P=saogoncalodoparamg WebISSv2.ini [URL_P] RecepcaoLoteRPS_3161809=https://%NomeURL_P%.webiss.com.br/ws/nfse.asmx [URL_H] RecepcaoLoteRPS_3161809=https://%NomeURL_H%.webiss.com.br/ws/nfse.asmx Um ponto que percebi e que me parece haver uma duplicidade de provedores do fonte (Sigcorp e SIGISS), creio que os dois se referem a mesma empresa, sendo que o SigISS não possui nenhuma implementação. Como precisava implementar uma cidade neste provedor, segui o que estava sendo usado (SigCorp). Tive de modificar parte do INI do provedor, pois estava fixo para o município de Avaré - SP. INI do provedor em anexo. Cidades.INI [3145208] Nome=Nova Serrana UF=MG Provedor=SigCorp NomeURL_H=novaserrana NomeURL_P=novaserrana [3504503] Nome=Avare UF=SP Provedor=SigCorp NomeURL_H=avare NomeURL_P=avare Depois de anos no trunk1, é muito bom poder voltar a contribuir . SigCorp.ini

Boa tarde, diogo_maxx. Encontrei o seguinte erro no arquivo anexado: Resultado Nota NFe51190700046385800920559200000000811994751819 O XML contém os seguintes erros: Rejeição[904]: Informado indevidamente campo valor de pagamento. Regras de validação: Regra de Validação[904]: Informado o campo Meio de Pagamento igual a sem pagamento (tag:tPag=90, id:YA02) e informado campo Valor do Pagamento diferente de zero (tag:vPag<>0, id:YA03).

Boa tarde O ACBr possui componentes específicos para cada equipamento, por exemplo Componentes: ACBrBalanca, ACBrEtiqueta - (Comunicação impressora Térmica de Etiqueta). No ACBrMonitor voce pode ver como funciona cada componente e integrar na sua aplicação, realizando o procedimento que precisa... Mas não vai realizar todo o processo descrito acima de forma automática. Para conhecer todos os componentes veja o manual do ACBrMonitor: https://acbr.sourceforge.io/ACBrMonitor/Apresentacao.html

Muito obrigado pela contribuição. Fiz a implementação baseada nela com algumas alterações. Subi as alterações para o SVN na Revisão 17369. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Funcionou. Conforme a Dica acima da Capicon

Aqui em MG mesmo problema. Só consegui autorizar no ambiente de contingência da SVC-RS. Esse parece ser o único, ou um dos únicos que já implementou essa versão em homologação.

Ajuste SINIEF 11/2019 altera CST e CRT e extingue o CSOSN CONFAZ altera CST – Código de Situação Tributária através do Ajuste SINIEF 11/2019 (DOU de 12/07) e extingue o CSOSN – Código de Situação da Operação no Simples Nacional. O Ajuste SINIEF 11/2019 (DOU 12/07) extingue o CSOSN e mantém apenas o uso do CST para as operações realizadas por todos os contribuintes do ICMS (Optantes e não optantes pelo Simples Nacional). Atualmente empresa optante pelo Simples Nacional que recolhe o ICMS neste regime, utiliza o CSOSN para emissão dos documentos fiscais e as empresas do Regime Periódico de Apuração – RPA utilizam o CST – Código da Situação Tributária do ICMS. Uso apenas do CST – Código de Situação Tributária do ICMS A medida vai simplificar o dia a dia das rotinas dos contribuintes e também dos profissionais da área fiscal. A partir de quando será utilizado o CST para todas as operações? A partir de 1º de janeiro de 2022 todas as operações com mercadorias e serviços tributados pelo ICMS o contribuinte terá de utilizar o CST para determinar a tributação do imposto estadual. A Tabela B – Determina a Tributação do ICMS Atualmente existem duas Tabelas B: CST – Código de Situação Tributária para operações realizadas por empresa não optante pelo Simples Nacional (11 códigos);e CSOSN – Código de Situação da Operação no Simples Nacional (10 códigos) A Tabela B – CST, que determina a tributação do ICMS atualmente utilizada apenas pelo contribuinte do RPA, e é composta por 11 códigos passará a contemplar 23, mas com uma vantagem, vai abranger também operações realizadas por contribuinte optante pelo Simples Nacional. Será que isso realmente procede?

Boa noite! Estou com um problema na emissão de uma nota cujos itens possuem alguns produtos com benefício fiscal (redução de base de cálculo de ICMS). Até onde eu sei a regra é a seguinte : Se você informar alguma redução na BCICMS fica obrigado a informar o motivo da Desoneração do ICMS e o valor da desoneração do ICMS. Mas isso é apenas no produto que foi aplicado a redução. A nota Técnica prevê os casos de Desoneração para CTS 20, 30, 40, 70 e 90. Ou seja PODE ocorrer desoneração(não é uma regra, pois é apenas no produtos que sofreram redução na BCICMS por benefício fiscal) Além do mais manual da Nota Fiscal ainda diz: vICMSDeson só pode ser informado nos casos onde motDesICMS = 3, 9, 12 e caso o valor do vICMSDeson seja nulo não se deve informar motDesonICMS. Agora estou com uma nota que possui dois itens com Desoneração mas a receita me retorna rejeição por que não informei a o motivo da desoneração ou o valor da Desoneração nos outros itens que não possui nem a mesma. Alguém sabe me dizer por quê? Eis Aqui um XML de exemplo. Agradeço se puderem me ajudar! Rejeicao: Nao informado valor do ICMS desonerado ou o Motivo de desoneracao [nItem:1] 1-env-lot.xml

Bom dia, Estou testando as modificações do CT-e 3.00a, que inclui o QrCode no XML, porém ao tentar enviar para o CT-e é retornado o seguinte erro "Rejeição: Falha no Schema XML do CT-e". Isso acontece quando a propriedade "GerarInfCTeSupl" está fgtSomenteHomologacao, que é justamente o que o @Italo Jurisato Junior citou no post sobre a versão 3.00a do CT-e. Já se atribuo fgtNunca, consigo enviar e autorizar. - Os Schemas do CT-e estão atualizados. Mais alguém com o mesmo problema e uma possível solução?

Rapaziada deu certo aqui, eram os calculos, vou enviar o arquivo certinho de como ficou o xml. Tem que calcular certinho os valores... 51190700014271753149559200000000121939344958-nfe.xml

Bom dia, Segue anexo inclusão da formatação e validação das placas no ACBrValidador com o padrão Mercosul e com testes unitários. Att. ACBrValidador.pas ValidadorTeste1.dfm validadorteste1.lfm acbrvalidadortest.pas

Boa tarde centuryinf, da uma olhada nesse link onde o italo respondeu sobre essa mensagem..

Tente as configurações abaixo:

Ok, vou iniciar os testes novamente...

Boa tarde, Obrigada pela contribuição, adicionada para validação. Att.

Entendi, então a Bematech não suporta o mesmo formato da Elgin Era o que imaginava mesmo Obrigado pelo Retorno

Boa tarde. Basta alterar o ini e realizar novamente o teste, se der certo anexe aqui, por favor. Att.

Boa tarde. Anexe imagem desses cupons, assim como as configurações efetuadas. Att.

Boa tarde Felipe, Acredito que sejam estas as informações que você precisa: -> Configuração SSL <- SSL Lib. = libOpenSSL SSL Type = LT_TLSv1_2 Crypt. Lib. = cryOpenSSL HTTP Lib. = httpOpenSSL XML Sign. Lib. = xsXmlSec Obrigado.

Você está passando uma constante onde era esperada uma variável

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Bianca, No método DistribuicaoDFePorUltNSU você esta informando o Código da UF e o CNPJ do seu cliente correto? Não pode informar o CNPJ do Fornecedor. O valor inicial de UltNSU deve ser zero e depois sempre usar o valor retornado no campo UltNSU sem acrescentar nada a esse valor, pois se ele retornar o valor 500 e você informar 501 a SEFAZ vai retornar do 502 em diante, sendo que o correto é retornar do 501 em diante. Não entendi o seu ultimo paragrafo (notas onde o CNPJ informado está como Autorizado ). Por favor explique isso melhor.

Tive o mesmo problema com o CST 20 para o Rio de Janeiro. Segundo a RESOLUÇÃO SEFAZ Nº 13 DE 14 DE FEVEREIRO DE 2019, se enquadraria na mesma situação os CST's 20, 30, 40 e 70.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Atualizei os fontes novamente hoje e funcionou.

Bom dia Cleversonviana, Faça a checagem pelo portal https://dfe-portal.svrs.rs.gov.br/Mdfe/ValidadorXML. A Placa e CPF estão errados. Placa sem o - HNF1482 e o CPF está Zerado. The 'http://www.portalfiscal.inf.br/mdfe:placa' element is invalid - The value 'HNF-1482' is invalid according to its datatype 'String' - The Pattern constraint failed.The 'http://www.portalfiscal.inf.br/mdfe:CPF' element is invalid - The value '0' is invalid according to its datatype 'http://www.portalfiscal.inf.br/mdfe:TCpf' - The Pattern constraint failed.The 'http://www.portalfiscal.inf.br/mdfe:tpRod' element is invalid - The value '00' is invalid according to its datatype 'String' - The Enumeration constraint failed.

Obrigado Felipe.

Bom dia, dpaulabh Veja que o XML anexado, apresenta erros de estrutura ou falta de tags: Resultado Nota NFe31190717168238000476550010000221091027514680 O XML contém os seguintes erros: Falha de Esquema: Não existem notas validas neste xml, para realizar a validação, a nota deve conter o elemento NFe.

Anexo manual: layout_cobranca_port_30_09_09.pdf

Obrigado Daniel, vou verificar

Bom dia, Help_infor. Veja que a propriedade agora se chama MostraPreview

Bom dia, É muito simples, você tem uma rotina que lê os dados do conhecimento do banco de dados e alimenta o componente, correto? Na sua rotina tem algo do tipo: with ACBrCTe1.Conhecimentos.Add.CTe do begin (...) end; A propriedade Conhecimentos é uma lista quando executamos o Add.CTe um conhecimento é adicionado a essa lista. Logo para você enviar um lote com 10 conhecimentos (por exemplo) basta executar a sua rotina 10 vez, é obvio que a cada execução ela tem que pegar do banco de dados as informações do próximo conhecimento.

Boa noite, Coloca o xml completo pois o seu não está assinado. Tive este problema e era os schemas.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde pessoal, Com a versão 3.00a do MDF-e temos um novo evento chamado Inclusão de DF-e. Apesar do nome DF-e, no momento só podemos incluir NF-e e não CT-e. Vale lembrar que o MDF-e só pode conter NF-e ou CT-e, ambos já mais. Para que possamos informar NF-e em um MDF-e o emitente do mesmo tem que ser um transportador de carga própria. Por outro lado para que possamos informar CT-e o emitente do MDF-e tem que ser um prestador de serviço de transporte, ou seja, uma transportadora. Portanto já deu para perceber que esse evento no momento não poderá ser utilizado por uma transportadora. Dito isso vamos ao que interessa: Para que o emitente possa enviar o evento de Inclusão de DF-e no MDF-e tem que constar a tag: indCarregaPosterior com o valor 1. Abaixo temos um fragmento de arquivo INI do MDF-e para quem utiliza o ACBrMonitor mostrando como fazer para que a tag acima seja gerada: [ide] (...) indCarregaPosterior=1 ; se o valor for zero ou essa linha não existir a tag não será gerada. (...) Para quem utiliza o componente como alimenta-lo para emitir o MDF-e com a tag em questão: (...) Ide.indCarregaPosterior := tiSim; // se o valor for tiNao ou não constar essa linha a tag não será gerada. (...) Vamos agora ver como que fica o arquivo INI do evento de Inclusão de DF-e para que usa o ACBrMonitor: [EVENTO] idLote=1 [EVENTO001] chMDFe= chave do MDF-e cOrgao= Codigo da UF CNPJCPF= CNPJ ou CPF do emitente dhEvento=24/07/2019 17:04:00 tpEvento=110115 nSeqEvento=1 ; (sequencial, para o proximo DF-e tem que ser 2 e assim por diante) nProt= numero do protocolo de autorização do MDF-e cMunCarrega= código IBGE do municipio onde ocorreu o carregamento das mercadorias referente ao DF-e a ser incluido xMunCarrega= descrição do municipio ; xxxx pode variar de 0001 até 2000 [infDocxxxx] cMunDescarga= código IBGE do municipio onde ocorrerá o descarregamento das mercadorias referente ao DF-e a ser incluido xMunDescarga= descrição do municipio chNFe= chave da NF-e a ser incluida Para quem utiliza o componente, abaixo temos um exemplo de como enviar o evento em questão: ACBrMDFe1.EventoMDFe.Evento.Clear; with ACBrMDFe1.EventoMDFe.Evento.New do begin infEvento.chMDFe := ChaveMDFe; infEvento.CNPJCPF := CNPJCPFEmitente; infEvento.dhEvento := now; infEvento.tpEvento := teInclusaoDFe; infEvento.nSeqEvento := 1; infEvento.detEvento.nProt := nProtocoloAutorizacao; infEvento.detEvento.cMunCarrega := cCodigoMunicipio; infEvento.detEvento.xMunCarrega := xDescricaoMunicipio; InfEvento.detEvento.infDoc.Clear; // o bloco abaixo poderá se repetir por até 2000 vezes with InfEvento.detEvento.infDoc.New do begin cMunDescarga := cCodigoMunicipio; xMunDescarga := xDescricaoMunicipio; chNFe := ChaveNFe; end; end; ACBrMDFe1.EnviarEvento( 1 ); // 1 = Numero do Lote

Boa tarde. Talvez este tópico lhe ajude Att..

Boa tarde. Verifique o arquivo cidades.ini para saber se esta cidade já está atendida no ACBrNFSe, caso contrário recomendo que compare com as demais cidades atendidas pelo provedor e adicione a mesma para seus testes. Att.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde. Talvez os tópicos de nossa base de conhecimento possam lhe ajudar. https://www.projetoacbr.com.br/forum/forum/87-mdf-e/ Att.

No cliente, resolvemos o problema utilizando a impressão centralizada pelo pos printer, porque a impressão pelo fortes também estava com alguns problemas no layout com aquela impressora em especifico.

BigWings Obgridado pela Dica. Acabei descobrindo que a rejeição se tratava de uma lei do estado do Rio de Janeiro que obriga informar esse bendito valor do icms desonerado para produtos CST 030 e 040. Parece que já funcionando em homologação mas não está em produção. Mandei um email para SEFAZ estou aguardando retorno. http://www.fazenda.rj.gov.br/sefaz/content/conn/UCMServer/path/Contribution Folders/site_fazenda/legislacao/tributaria/resolucao/2019/RESOLUÇÃO SEFAZ Nº 13 DE 14 DE FEVEREIRO DE 2019.htm

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Descobri que apenas rateando o valor da desoneração nos outros itens que estão dentro da regra do cst é que valida a nota. Se eu colocar o vICMSDeson igual a 0 não gera as tags no XML. Isso seria um bug da SEFAZ na hora de validar? Ou tem como fazer o componente gerar pelo menos a tag vICMSDeson com o valor zerado?