Painel de líderes

Já temos a Data e Local Definidos... A segunda edição do Dia do ACBr, ocorrerá no Parque Tecnológico de Sorocaba, no dia 14 de Setembro de 2019 (Sábado). Reserve essa data na sua agenda, e não perca a chance de participar do 2o encontro da Maior Comunidade de Open Source para Automação Comercial do Brasil Em breve já devemos iniciar a construção de novo Site para a 2a edição do evento, com mais informações, como Grade, Palestrantes, Valor, duração etc...Além é claro, de abrir o acesso a inscrições com preços promocionais para o 1o Lote... (e lembrem-se que o primeiro inscrito recebe um brinde especial do ACBr) Quer Saber como foi o Evento anterior ? Acesse a página do Evento em: https://www.projetoacbr.com.br/diadoacbr/ Todas as palestras do evento anterior, foram Filmadas. No Link abaixo, você poderá ver a coleção de vídeos disponíveis... https://www.projetoacbr.com.br/forum/video/collection/4-dia-do-acbr-1a-edição/ Algumas palestras são abertas e podem ser assistidas por todos usuários do fórum... As demais estão disponíveis para os participantes do Evento anterior e usuários do SAC do ACBr, Como todas as palestras são filmadas, os usuários que se inscreverem no 2a edição do Dia do ACBr, não perderão nenhuma palestra... mesmo que elas ocorram de forma concomitante.. Quer ser um palestrante ? Se você tem interesse em palestrar ou ministrar Workshops, entre em contato conosco, de forma privada. Já estamos pensando na Grade de palestras e formato do evento... Por favor nos detalhe a sua ideia de palestra e porque você acha que o assunto é estratégico para o conhecimento da comunidade do ACBr.

Se for operação com consumidor final veja este tópico, por favor

O problema realmente indica falha na comunicação... o SAT acende a Luz do SEFAZ? Pode ainda ser alguma instabilidade temporária no SEFAZ

bom dia, Perfeito, me salvou. Agora vai uma sugestão para o ACBRMonitor, isso poderia ser tratado no próprio ACBR, ele percebendo que é uma operação interestadual com consumidor final e não contribuinte daria para resolver isso internamente no acbrmonitor. Mesmo preenchendo os campos de forma equivocada. Mais uma vez obrigado. PROBLEMA RESOLVIDO. abraços,

Bom dia Duarte, A estrutura do arquivo é: [CCE] [EVENTO001] (...) [EVENTO002] (...) até [EVENTO999] (...) Logo da forma que você esta fazendo esta errado, ou seja, o numero do primeiro evento no arquivo ser 002, isso explica o erro de index que aparece, pois a rotina esta a espera da sessão [EVENTO001] se não encontra considera que o arquivo esta vazio. Se a nota já possui uma carta de correção e esta seria a segunda, logo deveria funcionar com o valor 2 em nSeqEvento. Se você monta o arquivo com a sessão [EVENTO001] e nSeqEvento=2 ocorre erro de duplicidade, a minha suspeita é que a primeira carta de correção enviada o valor de nSeqEvento foi 2. A minha sugestão é que você informe o valor 3 para nSeqEvento. Seria de grande ajuda para confirmar a minha suspeita, se você anexar o XML *-procEventoNFe.xml da primeira carta de correção dessa nota.

Boa tarde Italo, obrigado pelo retorno, não me atentei a isso, vou confirmar e volto pra fechar o tópico se for o caso.

Estava funcionando, inclusive no HOMOLOGAÇÂO ele esta correto, mais acho que deve ter tido algum erro e retornaram com o WEBSERVICE padrão, note que se você gerar direto pelo PORTAL ele estava colocando a versão 2.0 em alguns estados agora ele retornou com o 1.0 padrão. Estou enviando tudo pelo 1.0 que inclusive se colocar o versao="1.00" para de funcionar novamente. É pelo que vi eles devem ter ajustado vou alterar aqui e testar depois mando novamente a classe. Ele estava aceitando: Versão 1.00 - Os lotes do 1.00 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <TLote_GNRE xmlns="http://www.gnre.pe.gov.br"> <guias> Versão 2.00 - Os lotes do 2.00 <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <TLote_GNRE versao="2.00" xmlns="http://www.gnre.pe.gov.br"> <guias> Pelo que vi acho que arrumaram pois no manual esta previsto que o lote da 1.00 só aceita GUIAS 1.00 e o lote 2.00 agora aceita os dois modelos tanto 1.00 quanto 2.00 desta forma creio que deve estar aceitando a TAG de versão no cabeçalho. <?xml version="1.0" encoding="UTF-8"?> <TLote_GNRE versao="2.00" xmlns="http://www.gnre.pe.gov.br"> <guias> <TDadosGNRE versao="1.00"> ... </TDadosGNRE> <TDadosGNRE versao="2.00"> ... </TDadosGNRE> </guias> </TLote_GNRE>

Tem razão, alterei apenas as da SVRS, RS usa um webservice diferente. Aguarde que... Aparentemente ainda não estão validando a URL em produção, mas deve mudar também, está sendo verificado se a alteração caso feita agora em produção não vai causar problemas.

Muito Obrigado pela Ajuda.

Entendi, agradeço por terem analisado, vou fazer sim, entro em contato se surgir alguma dúvida ou assim que terminar anexo para ser adicionado ao projeto. Obrigado.

Já solucionei ! Era problema de comunicação com cliente, estava sem o cabo de WAN para comunicação com a SEFAZ. Erro bobo mas notificado por um técnico presente. Muito obrigado pela resposta ! Pode concluir o tópico ! ??

Realmente são layouts diferentes embora se trate da mesma Cooperativa e cobrança Bradesco, a versão existente no componente é "CRESOL CENTRAL - SCRS (Chapecó)" . Será necessário implementar uma nova classe para essa cooperativa, sendo igual a já existente alterando apenas os pontos de divergência. Se desejar contribuir, poderá anexar o fonte e podemos adicionar ao projeto.

Ok, entendido, excelente explicação, analisado o arquivo *-procEventoNFe.xml e lá consta nSeqEvento=1. Mas contudo, em respeito a sua explicação executamos uma consulta no site da NFE e lá constava a ciência de emissão pelo destinatário que tinha entrado com nSeqEvento=2, alteramos o nSeqEvento para 3 e a carta foi acatada pelo servidor. Agradeço muito pelo apoio e principalmente pela explicação detalhada! Tenham um excelente dia.

Bom dia, Anderson Carvalho Farias. Veja o exemplo abaixo: tPag := TipoTransacao; ex: fpCartaoCredito = Tipo da Transação do cartão, se credito ou débito; vPag := ValorCredito; ex 20.00 = Valor pago na transação; tBand := BandeiraCartao; ex: bcVisa = Bandeira selecionada pelo usuário; cAut := NSU; // ex: 444444; código do comprovante informado pelo usuário; CNPJ := CnpjOperadora; ex: 99999999999999 = CNPJ vinculado a tabela ref. a bandeira selecionada;

Agradeço a explicação. Vou, inclusive, ler a norma técnica. O que vocês informaram tem todo o sentido, pois sou desenvolvedor para a própria empresa onde trabalho.

Bom, eu fiz um boleto colocando na DigitoAgencia=, o Posto = 24, que é o caso do meu cliente, e a princípio calculou certinho. Depois vou fazer mais boletos e qq coisa, posto aq. Abraços, obrigado pela atenção.

Bom dia, Reginaldo, obrigado pela informação.

A princípio, pode usar o CNPJ da empresa onde foi desenvolvido. Isso é chamado de "sistema próprio". Quer dizer, sistema desenvolvido pela própria empresa. Isso está de acordo com o que o Felipe disse acima.

A contadora ("pouco disposta") me instruiu a fazer uma nota de devolução onde irá anexar no livro de ocorrência da empresa. Vou dar encaminhamento, e assim que tiver um desfecho, compartilho o resultado.

Boa noite, Seguindo a lógica do fluxograma existente na Nota Técnica 2014.002 v1.02b. Quando o destinatário cria um evento de manifestação, é gerado um NSU para o emitente com o evento do destinatário. Olha o que diz o item 7: O método DistribuicaoDFe retorna os NSU's que o Ambiente Nacional cria. Ou seja, se o Ambiente Nacional cria um NSU para o emitente da nota com os dados do evento criado pelo destinatário, logo você terá acesso.

Pois é. SEFAZ parece não ter noção do nosso dia-a-dia, perder tempo com alterações sem necessidade ou sem mesmo aviso. Ficar o dia todo até descobrir que basta enviar sem o "http", complicado. Basta alterar o .ini e executar o .bat "Compila_RES.BAT" que o .res é gerado novamente.

Boa tarde Duarte, Neste caso você tem que incrementar o campo: nSeqEvento, pois é ele que diz quantas cartas de correções foram enviadas para a mesma nota. Quando enviamos a primeira CC-e o valor de nSeqEvento é 1, ao enviar a segunda tem que ser 2 e assim por diante. Reafirmo: devemos incrementar esse campo quando se tratar da mesma nota.

Boa tarde Daniel, O componente ao gerar o XML de um evento, se encarrega de assinar e validar para garantir que a estrutura e os dados estejam em conformidade com os schemas. Sendo assim, concordo com a sugestão do Felipe.

Olá boa tarde. Isso seria um exemplo da nota do fornecedor de entrada. Vc registrará ela no seu Sistema com essas informações. Quando vc for fazer a NF Venda, vc vai utilizar essas informações nessas tags 60 e 500 do item.

Bom dia, Josafar Nascimento da Silv. De acordo com a Nota Técnica, a Sefaz considera como Responsável Técnico as empresas : Desenvolvedora do sistema de emissão ou empresa responsável tecnicamente pelo sistema de emissão.

Bom Dia a todos. Passei pelo mesmo problema em dois clientes utilizando o mesmo modelo de equipamento mencionado pelo Alexandre( Elgin Linker I ), porém as DLL's que ele disponibilizou acima não resolveram meu problema, foi necessário intervenção por parte do suporte da fabricante, então disponibilizo as DLLs que sanaram o meu problema caso alguém precise. DLL ELGIN.rar

Alterado e testado apenas para fazer a leitura do XML, demais funções ainda não implementadas. pnfsConversao.pasElotech.iniCidades.iniSigIss.inipnfsNFSeR.pas

Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação, tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. Vamos a uma explicação mais longa... O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.

Boa tarde Mauricio, Além de atualizar os fontes você reinstalou os componentes?

Será disponibilizado uma nova versão do monitor, mas até então basta substituir o arquivo abaixo na pasta do ACBrMonitor. ACBrNFeServicos.ini

Isso. Elas não são mais geradas por causa dessa validação. Claro que, caso percebamos que há alguma margem na lei para elas serem geradas por outro motivo, faremos a alteração no componente. Só não parece ser o caso no momento.

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

@charles.libano executa somente o ACBrNFeServicos.rc (duplo click, compilador do delphi(BRCC32 se encarregará de resolver a questão e transformar o ACBrNFeServicos.ini no ACBrNFeServicos.RES. Pra conferir a alteração abra o ACBrNFeServicos.RES e verifique a URL na seção do seu estado.

Nunca testamos essa impressora... Se ela for compatível com Epson Esc/Pos, configure como se fosse uma Epson

MG e a receita 100099

Muito bom . Aqui na Bahia mesmo não vai ser obrigatório então ja deixei como no padrão fgtNunca

Fiz a atualização do FastReport para a 5.6.18. Peguei o ultimo arquivo fr3 da DANFE da pasta exemplos (eu havia alterado algumas coisas para a empresa). Reinstalei o ACBr. Não apresentou mais o problema. Podem fechar o topico se acharem necessário.

Bom dia Conforme descrição do erro, por ser uma operação Consumidor Final, Fora do Estado deve informar FCP apenas no grupo "ICMSUFDEST", remova a tag vFCP e pFCP do grupo ICMS e Total

Bom dia, Na imagem não mostra a msg de erro. Att.

Bom dia, Notem que esta situação já sendo discutida neste tópico. Att.

Bom dia Guto, Muito obrigado pela informação, vou fazer as devidas correções no arquivo INI. Uma observação o seu arquivo INI esta desatualizado, pois os atuais não tem mais a linha que define o encoding.

Sim.. parece correto... nos fontes do Demo do ACBrPosPrinter você poderá ver exemplos de como usar as diversas Tags suportadas pelo componente ACBrPosPrinter

Boa tarde João, Pelo fragmento de código da unit notei que os seus fontes estão desatualizados. Favor atualizar todos os fontes de todas as pastas. Reinstale a suíte ACBr usando o ACBrInstall_Trunk2 deixando marcado a opção para apagar os arquivos antigos. Refaça os testes.

Boa tarde Fabio, Eles quebraram o XSD? Antes era apenas um arquivo nfse.xsd agora é um para cada serviço. Isso faz com que o arquivo INI do provedor seja alterado.

Boa tarde. Primeiro recomendo verificar nos manuais do banco se esta carteira trabalha com os 11 dígitos livres e se sim, creio que seja o caso de ajustar a função citada anteriormente. Att.

Boa tarde. Vendo um tópico relativo a outro assunto, notei que ja unit do BB já existe a função para separar o convenio do nosso número, seria a NossoNumeroSemFormatacaoLerRetorno(). Faça um teste utilizando a mesma. Att.

Boa tarde, Vejam que tem uma discussão sobre este erro neste tópico. Att.

Olá, @Luciano César Gimenez Clique aqui para ver esse tópico, nele eu dei uma sugestão para conseguir atender as necessidades dos ambientes de Homologação e Produção. Nosso amigo @EMBarbosa incorporou essas alterações que sugeri, aplicando algumas melhorias nela. Mas o fato é que será necessário "virar a chave" no dia em que o ambiente de Produção começar a exigir essas tags.