Painel de líderes

Em anexo ACBrNFSeXServicos.ini

Boa tarde! Muito obrigado pela contribuição. Foi criada a #TK-3316 para inclusão deste município

Bom dia, Foi enviado para homologação do arquivo, estou aguardando o retorno. Muito obrigado.

Boa noite, Confirmando, caso não tenha feito assim, instale novamente marcando a opção para remover versões anteriores. Pesquise se não tem alguma ACBrJSON.dcu nos caminhos que estão configurados nas configurações de library.

Olá, obrigado a todos que responderam. Solução: Quando eu fiz o banco de dados para substituir o arquivo.ini de configuração, eu acabei preenchendo as variaveis do PROXY. Com isso dava erro visto que eles não eram reais. Debuguei paralelamente os dois e percebi que o exemplo não tinha o proxy e o meu estava com valores ficticios. Resolvido apenas retirando os valores de proxy e funcionou.

Boa tarde pessoal, Recebemos a pouco da AFRAC a informação de que o pleito que vinha sendo feito pela entidade para postergação desta obrigação foi atendido!! A nova data para inicio da obrigatoriedade para o grupo que iniciaria em janeiro/2023, sendo ele supermercados, minimercados e hipermercados, agora é abril/2023, já para os demais contribuintes a data permanece a mesma, julho/2023. At.

Olá Pessoal, Mais uma notícia "boa" para o início do próximo ano.. E quais são as novidades? Não poderia ser diferente, e claro, são Alterações no Layout e regras de validação da NF-e/NFCe e também alguns novos códigos de rejeição. Quanto aos novos campos Inclusão de campo destinado a informar NF-e referenciada em sigilo Aumento do número de documentos referenciados. Quanto as regras de validação Removidas regras relativas as restrições para emissão de NFe por pessoa física Corrigida validação do CNPJ do Resp. Técnico para ser aplicada somente se existir informação par a tag no XML Alterada para ser a critério da UF a aplicação da regra de validação do Regime Tributário informado bate com cadastro na SEFAZ, inclusive com novos códigos de rejeição Inclusão de regras garantido a consistência da NFe Referenciada Inclusão de restrições quanto a referencia de NFCe Inclusão de restrições relativas as operações permitidas para NFe emitida por não contribuintes do ICMS Inclusão de validação quando o FCP for obrigatoriamente 0 conforme tipo de operação (adoção a critério da UF) Quanto aos Código de Rejeição 951 - Rejeição: Chave de Acesso referenciada com código numérico zerado não permitida para finalidade diferente de normal. 952 - Rejeição: Chave de Acesso referenciada com a mesma Chave Natural da Nota Fiscal atual 953 - Rejeição: Informado ECF referenciado para CFOP 5.929 em UF que não permite essa referência 475 - Rejeição: Operação não permitida para não contribuinte 474 - Rejeição: FCP não deve ser destacado na NF-e conforme legislação estadual Sobre a aplicação na NFe e NFCe Em relação as regras de validação, somente a regra relativa a validação do CNPJ do Responsável Técnico(ZD02-10) e a regra relativa ao Código do Regime Tributário-CRT (7C21-10) se aplicam a ambos os documentos, as demais são exclusivas para NFe. Sobre as regras a critério da UF Este tipo de regra sempre causa dúvidas, afinal tira o padrão nacional daquela informação, nesta NT tivemos a inclusão dos campos que permitirão a informação de documento referenciado, porém sem informar a chave do mesmo, no caso, a tag refNFeSig, que somente poderá ser adotada após as UFs publicarem sua regulamentações internas. Mas para esclarecer a motivação da inclusão desta tag, conversamos com a AFRAC e fomos informados de que se deve ao fato de que em alguns setores acontece venda triangular, e dado a haver a chave do documento recebida pelo cliente, ele acaba tendo informações sobre o valor pago anteriormente pelo seu fornecedor, gerando desconforto entre as partes. Quanto a vigência da NT Ambiente de Homologação: 07/02/2023 Ambiente de Produção: 03/04/2023 Sobre as mudanças nas soluções ACBr Por se tratar de inclusão de novos campos e alteração na quantidade máxima de documentos referenciados, será necessário adequações no Componente, assim como no ACBrMonitorPlus e a ACBrLib, tais alterações serão enviadas ao SVN a tempo da SEFAZ liberar o ambiente de homologação com estas mudanças. Naturalmente que havendo a inclusão de novas informações, também se fará necessário algum grau de adequação da aplicação, conforme o segmento na qual a mesma é utilizada. Até aqui tivemos um breve resumo dos pontos trazidos por esta NT, mas para se aprofundar melhor, recomendamos que continue a leitura até o final do artigo. 1. Alterações do layout Inclusão do Referenciamento de NF-e por Chave com código numérico zerado (Campo: refNFeSig). Criação de campo específico no grupo de Documento Fiscal Referenciado (NFref) para permitir ao contribuinte referenciar Nota Fiscal Eletrônica, modelo 55, informando a Chave da NF-e com o código numérico zerado. Essa alteração visa garantir a manutenção do Sigilo Fiscal da NF-e referenciada. Importante A utilização deste campo fica restrita a situações previstas em legislação específica de cada UF. A referência pela chave de acesso completa (campo: refNFe) continua obrigatória nos casos de NF-e de devolução, complementar e quando a legislação exigir. Cuidados quanto as tags refNFe e refNfeSig Os campos refNFe e refNFeSig não podem constar ao mesmo tempo no XML, ou seja, ou ele contém o campo refNFe ou o campo refNFeSig. Alteração do número máximo de ocorrências do grupo de Documentos Fiscais Referenciados (tag: NFref) O grupo de Documentos Fiscais Referenciados (tag: NFref) passou de um máximo de 500 para 999 ocorrências, para atender situações em que era necessário referenciar mais que 500 documentos numa mesma NF-e. 2. Alterações de Regras de Validação Criação das Regras de Validação garantindo a consistência da Chave Referenciada BA02a-10, BA02a-20, BA02a-30, BA02a-40, BA02a-50, BA02a-60, BA02a-70, BA02a-80, BA02a-90, BA02a-100 Essas regras visam garantir a consistência da Chave Referenciada com código numérico zerado (tag: refNFeSig) além de evitar que esse referenciamento aconteça em uma NF-e com finalidade diferente de normal. Remoção das Regras de Validação quanto a emissão de NF-e por Pessoa Física C02a-04, C02a-08, C02a-14 Atualmente existe um controle das SEFAZ no credenciamento individual para emissão da Nota Fiscal pelos Contribuintes Pessoa Física (CPF). Eliminadas as Regras de Validação que controlam a opção da UF em aceitar ou não a emissão de Nota Fiscal para os Contribuintes emitentes Pessoa Física. Criação da Regra de Validação destinada a rejeitas referenciamento de NFC-e na NF-e I08-186 O objetivo desta regra é impedir o referenciamento de ECF em uma NF-e com CFOP 5929 ou 6929, uma vez que em algumas unidades federadas o ECF já foi completamente substituído por NFC-e e não existe mais a possibilidade de seu referenciamento para estas operações. Alteração das Regras de Validação quanto as operações permitidas para Não Contribuintes do ICMS I08-194 e I08-198 Algumas SEFAZ concedem IE para não Contribuinte do ICMS, mas limitam a emissão de NF-e de venda unicamente pelo Emissor de Nota Fiscal Avulsa disponibilizado pela própria SEFAZ. Alteração da Regra de Validação quanto a forma de informar os valores de FCP N17c-30 Conforme a legislação estadual, algumas SEFAZ controlam a informação dos valores vinculados ao Fundo de Combate à Pobreza (FCP) no processo de apuração do imposto, impedindo essa informação individualizada em cada NF-e. Alteração da Regra de Validação quanto ao CNPJ do Responsável Técnico somente se houver a informação ZD02-10 Melhorada a documentação da RV, efetuando a validação unicamente se a informação do CNPJ do Responsável Técnico for informada. Criação da Regra de Validação para validar a existência na base de dados da UF emitente do documento relativo a chave referenciada 3BA02a-10 Regra de validação para verificar a existência da Chave Referenciada com código numérico zerado na base de dados de NF-e da UF emitente do documento. Alteração da Regra de Validação quanto a informação do Código de Regime Tributário informado no XML 7C21-10 A RV 7C21-10 controla a informação na Nota Fiscal do CRT ou CSOSN, conforme o cadastro do Contribuinte na SEFAZ. Alterada esta Regra de Validação para ser opcional por UF.

Boa tarde pessoal! Agora o componente ACBrCEP está ainda mais completo, foi adicionado recentemente a integração com provedor de serviços BrasilAPI, para utiliza-lo basta configurar no componente a opção wsBrasilAPI. Vale lembrar que como tanto o ACBrMonitorPlus quanto o ACBrlibCEP são baseados no componente, o recurso também está disponível para eles! Saiba mais como funciona a integração feita de forma transparente pelo componente, na documentação do provedor https://brasilapi.com.br/docs#tag/CEP-V2

Muito obrigado Diego! Farei os testes.

Boa tarde! Sim, temos! Por favor, veja os links https://anchor.fm/projeto-acbr/episodes/ACBrPIXCD---O-componente-do-Projeto-ACBr-para-se-integrar-com-diversos-PSPs-do-mercado-e1jpnfl https://anchor.fm/projeto-acbr/episodes/Dia-do-ACBr-2022-ACBrPixCD---Principais-dvidas-mapeadas-e-respondidas-e1p2kpk

Boa tarde, sim tudo funcionando, acabei de validar.

Está acontecendo apenas no Padrão Entrega, os demais estão abrindo normalmente.

Obrigado Juliomar. Bóra usar ACBrTEFD então.

Boa tarde Glauber, Esta realizando testes usando o programa exemplo do componente? Se sim, configurou corretamente a aba Certificados? O certificado esta com a chave como exportável?

Anexa o arquivo ACBrNFSeXServicos.ini com a cidade incluída. Desde já muito obrigado pela colaboração.

Boa tarde, Esta em análise uma contribuição de integração com o Inter. At.

Boa tarde Almeida, Pela URL que você passou não ocorreu troca de provedor. A cidade continua sendo atendida pelo provedor SmarAPD só que agora passou a utilizar o webservice que segue a versão 2.03 do layout da ABRASF. Vai ser necessário alterar o arquivo ACBrNFSeXServicos.ini para a cidade de Cubatão/SP da mesma forma que foi alterado para a cidade de Mogi das Cruzes/SP. Como alterar, leia o tópico abaixo:

Boa tarde, Informação importante: Toda vez que for informar o código de uma cidade, devemos sempre informar o código IBGE, se for o caso o componente se encarrega de converter o código IBGE para o código TOM como é o caso do provedor IPM. O componente também se encarrega de converter o código TOM para o IBGE ao ler um XML, quando for o caso.

Pessoal, boa tarde! Sobre a cidade de Januária/MG, provedor Síntese, ABRASF revisão 2.04 (Para comparação, já existem a cidades de Bocaiuva e Tumiritinga no ACBr para esse provedor): Em homologação: Envio: ok Cancelamento: ok Consulta por RPS ou Faixa de numeração: diz que precisa ser assinado. Se coloco para assinar dá erro de que "signature" não era esperado. Não consegui testar. (Questionei o provedor via e-mail, mas ainda não recebi resposta.) Em produção: Envio: ok Cancelamento: ok Consulta por RPS ou Faixa de numeração: ok (e não precisa ser assinado) Em relação ao cancelamento, em dois testes que fiz no ambiente de produção, no Webservice consta status 2 de cancelada. Porém, no site deles, na consulta ainda mostra "status = simples", ou seja, que a nota não estaria cancelada. Só que ao imprimir um relatório deles no mesmo site, onde é gerado um PDF com todas as notas emitidas, as notas de testes que fiz aparecem com status de cancelada. Acredito que isso possa ser um problema deles lá de sincronia etc. Estou tentando contato com eles para confirmar essa questão do cancelamento e para confirmar os endereços (eu deduzi o endereço de produção baseado nas configurações das cidades de Bocaiuva e Tumiritinga). Acredito que esteja tudo certo com o ACBr. A dificuldade é que eles podem demorar a responder. Configurações da cidade que usei para os testes: [3135209] Nome=Januaria UF=MG Provedor=Sintese Versao=2.04 ProRecepcionar=https://januaria.sintesetecnologia.com.br/nfsews/NfseWS HomRecepcionar=https://homologacao.sintesetecnologia.com.br/nfsews/NfseWS Utilizei os schemas que já constam no SVN do ACBr para o provedor Síntese.

Bom dia Henrique, A cidade Rio Verde/GO se utiliza do provedor Centi e este só tem um serviço para recepcionar o XML do Rps que é o GerarNfse. Esse serviço trabalha no modo síncrono e só aceita um Rps de cada vez. No novo componente ACBrNFSeX, devemos usar o método Emitir com o segundo parâmetro meAutomatico, desta forma ele vai usar o modo de envio apropriado para cada provedor que no caso do Centi é o modo de envio unitário. Neste caso não temos um lote de Rps e sim apenas um Rps assinado ou não dependendo do provedor que depois é incluído no Envelope soap para ser enviado para o webservice. Se esta ocorrendo erro de assinatura invalida, acredito que o motivo seja, vogais acentuadas, cedilha ou o "E" comercial que muitas empresas colocam na razão social.

Bom dia Gustavo, Se o XML de envio não esta com o lote assinado o problema é que você esta com os fontes desatualizados. Favor atualizar todos os fontes de todas as pastas e reinstale o ACBr e depois faça novos testes.

Bom dia, Se você atribuir o valor True a propriedade de configuração abaixo o XML do Rps vai ser salvo em disco na pasta Recibos. Configuracoes.Arquivos.Salvar Caso não queira salvar os XML em disco e sim no banco de dados a dica é: O XML do Rps se encontra na propriedade XmlRps da lista de notas, veja: XMLdoRps := ACBrNFSeX1.NotasFiscais.Items[X].XmlRps onde [X] é a posição do XML na lista de notas.

Claro...segue em anexo... ACBrBoleto.zip não tinha lembrado do patch... farei isso.. obrigado...

faça um patch no svn e guarde. assim não vai perder. e se precisar fazer update faça normal depois aplica o patch

Bom dia! Por favor, depois de executar o método ACBrNFSeX.GerarToken, tente pegar o retorno assim: Token := ACBrNFSeX.WebService.GerarToken.Token; Preencha a property ACBrNFSeX.Configuracoes.Geral.Emitente.WSChaveAutoriz := ValorObtidoToken; com ele e tente Emitir novamente.

Bom dia @Josemar Sabino, Creio que o ACBrETQ ainda não suporte esse modelo... Os modelos implementados são: PPLA, PPLB, EPL2 e ZPL2

Boa noite, Seu cenário parece correto. Esses dias foram feitas algumas correções no e-social e talvez tenham relação com o seu problema. Tente a última versão e informe se o problema persiste.

Não suportamos Java com ACBrTEFD e ACBrTEFAPI . mas tu pode tentar ver o código fonte dos exemplos do delphi e ver se pode

Toda a parte lógica da aplicação deverá ficar no back end ( e até mesmo por questões de segurança ). A parte do front seria a parte visual para o cliente.

Iniciamos o dia recebendo diversos relatos nos grupos do discord do ACBr assim como em nosso fórum relativos a problemas na emissão da NFe em SP, os quais parecem ser problemas na SEFAZ-SP, já que a mesma ativou a contingência as 15:38 e permanece assim até o momento. Fonte: http://www.nfe.fazenda.gov.br/portal/principal.aspx

Pessoal, Vi muitos tópicos com dúvidas para instalação das versões que não permitem compilação por linha de comando. Caso seja útil, segue resumo para a instalação manual com passos que funcionaram para mim. Não utilizo todos os módulos do componente, mas acredito que tudo funcione corretamente seguindo esses passos. Testei vários projetos e todos compilaram. Atenção: A versão CE não destina-se a testes e não deve ser instalada na sua empresa caso o seu faturamento geral ultrapassar os limites estabelecidos. Neste caso, solicite uma licença trial e evite ficar irregular. No final do tópico coloquei um link de outro tópico contendo destaques dos valores e condições para utilização da versão CE. Instalar o ACBr no Delphi CE ou Trial 1. Descompactar a pasta ACBrInstall_CE no raiz do ACBr ---> ACBrInstall_CE.zip 2. Dependências 2.1. Instalar o fortes reports: https://github.com/fortesinformatica/fortesreport-ce * Abrir o .dpk * Botão direito sobre ele e clicar em Build * Botão direito e clicar em Install 2.2. Quem possui e utiliza o Fast, instalar o Fast 2.3. Unit scope names: Acessar Tools / Options / Language / Delphi / Library / Unit scope names >>> Adicionar “Vcl” na lista * O arquivo Registrar_UnitScopeNames_Vcl.reg preenche a informação, sobrepondo o padrão , que é em branco. Fazer com o Delphi fechado. 3. Grupos de projetos para geração das bpls * para evitar retrabalho, veja o erro 4.1 pois pelos meus testes sempre foi necessário alterar para “.dres” no DCLACBr_Comum.dpk 3.1. Quem possui o Fast, ignorar o item 3.2, abrir o InstalacaoFR.groupproj e processar o Build All com o botão direito no grupo InstalacaoFR 3.2. Quem não possui o Fast, abrir o InstalacaoRL.groupproj e processar o Build All com o botão direito no grupo InstalacaoRL 4. Erros 4.1. Caso ocorra o erro "Resource ACBR not found" * Botão direito sobre o DCLACBr_Comum.bpl, “View Source” * Alterar de {$R *.otares} para {$R *.dres} 4.2. Caso ocorram erros como Graphics, Forms, Controls , etc “not found“: * Caso não tenha feito a configuração geral no item 2.3, pode ser feito por pacote: adicionar Vcl em Project / Options / Building / Delphi Compiler / Unit scope names 4.3. Se ocorrerem erros nas classes do Fortes ( TfrmCTeDAInutRL, TfrlGuiaRL, TfrlDAMDFeRL, TfrmMDFeDAEventoRL, TfrlXDANFSeRL ) na primeira abertura do grupo de projetos, basta ignorá-los e dar ok, pois estão reclamando das dependências que ainda serão instaladas no grupo. 4.4. Caso ocorram erros como "Fortes report Unit 'RLReport' not found": (colaboração do @felipe de souza) * Adicionar ao library o caminho do source \trunk\source 5. Após compilar todos os pacotes, executar o arquivo para vincular(instalar) os componentes ao Delphi * Feche o Delphi para registrar as bpls 5.1. RegistrarComponentesFR.reg para quem possui o Fast, não precisando executar o item 5.2 5.2. RegistrarComponentesRL.reg para quem não possui o Fast Obs: Não possuo o Fast então não tive como compilar nem testar o .reg para validar, apenas adicionei os pacotes no grupo e gerei o arquivo. Caso alguém valide e precise de ajustes, por favor compartilhe a correção para ajudar os demais. ACBrInstall_CE.zip Conforme mencionado no início, segue tópico contendo destaques dos valores e condições para utilização da versão CE.