Painel de líderes

Olá Pessoal, Essa noticia é para quem gera o arquivo INI com as informações do serviço prestado. Os provedores que possuem layout próprio acabam tento campos que não encontramos normalmente no layout da ABRASF. Foram incluídos na semana passada os campos para os provedores Infisc e IPM: Campos incluídos para o provedor Infisc: ModeloNFSe - campo para informar o modelo da NFS-e; refNF - campo para informar uma NF; TipoEmissao - campo para informar o tipo de emissão. Valores aceitos: (N = Normal ou C = Contingencia); Canhoto - campo para informar o canhoto. Valores aceitos: (0 = Nenhum, 1 = Cabeçalho ou 2 = Rodapé); EmpreitadaGlobal - campo para informar Empreitada Global. Valores aceitos: (1 = Construcao Civil ou 2 = Outros). Campos incluídos para o provedor IPM: EnderecoInformado - campo para informar se o endereço foi informado. Valores Aceitos: (0 = Não, 1 = Sim ou vazio para não gerar a tag). Em breve a documentação do ACBrLibNFSe e do ACBrMonitor vão ser atualizados visando esses novos campos.

Olá! Colocamos os primeiros clientes em produção com o Banrisul Após os passos acima, com o cadastro no portal do Desenvolvedor, é liberado acesso no CNPJ do cliente. Com isso solicitamos a liberação do "Shared Secret (Client Secret)". O status ficará como Pendente, solicitar a liberação por e-mail [email protected]. Qualquer dúvida, posso auxilia-los.

Olá Pessoal, As dicas abaixo são validas para todos os os modelos de DF-e (Documentos Fiscais Eletrônicos). 1. A chave de um DF-e é composta por diversas informações e todas elas estão presentes no XML. A chave é composta pelo Código da UF (2 dígitos), Ano (2 dígitos) e Mês (2 dígitos) de emissão, CNPJ do emitente (14 dígitos), modelo do DF-e (2 dígitos), série (3 dígitos) e numero do documento (9 dígitos), tipo de emissão (1 dígito), código aleatório do documento (8 dígitos) e digito verificador (1 dígito). Devemos guardar no banco de dados, juntamente com os demais dados do DF-e as seguintes informações: Data/Hora de emissão e Código aleatório que deve conter somente 8 dígitos. Jamais use como código aleatório o próprio numero do documento, pois isso você deixa a chave vulnerável. O código aleatório deve ser gerado pela sua aplicação e armazenado no banco de dados conforme orientado acima, jamais deixe o componente gerar o código para você, pois desta forma você perde o controle dessa informação. A Data/Hora deve ser definida e também armazenada no banco de dados, jamais devemos usar a função Now na rotina que alimenta o componente, pois isso faz com que você também perca o controle dessa informação. Ao alimentar o componente com os dados do DF-e todas as informações devem ser lidas do banco de dados, com exceção do Digito Verificado da chave que é o próprio componente que o calcula. 2. De preferencia de guardar o XML do DF-e no banco de dados em vez de salvar em disco, pois alguns usuários desavisados resolvem excluir arquivos do HD da maquina por achar que tem muito arquivo salvo. Se isso ocorrer, ou seja, o usuário acabar deletando o XML de um DF-e, tendo todos os dados salvos no banco de dados basta fazer o seguinte: Alimente o componente com os dados do documento que estão no banco de dados, execute os métodos Assinar, Validar e Consultar. Desta forma você vai ter o XML de volta, mas lembre-se que esse processo só pode ser executado caso o DF-e tenha sido emitido dentro do prazo de 180 dias, passou de prazo não tem como recuperar. 3. Se ocorrer erro de internet (timeout por exemplo) como devo proceder? A resposta é muito simples: Não devemos enviar o documento novamente, pois o documento pode ser rejeitado por duplicidade. Não devemos gerar, assinar, validar o XML novamente, pois essa atitude pode mudar o código aleatório do documento e a data/hora de emissão caso você não seguir as orientações da primeira dica. Com isso ao enviar novamente o documento pode ser rejeitado por duplicidade com diferença chave, situação mais grave. Devemos sim carregar o XML que foi enviado através do método LoadFromFile (se esta salvo em disco) ou LoadFromString (se esta salvo no banco de dados) e em seguida executar o método Consultar. Antes de enviar o DF-e para a SEFAZ atualize o banco de dados mudando o status do documento como "Enviado", depois devemos executar o método Enviar. Se ocorrer o erro de internet a aplicação não deve permitir que o usuário envie novamente o mesmo documento uma vez que ele esta marcado como Enviado, mas a aplicação libera o documento para que o mesmo seja carregado e consultado conforme dito acima. Caso o retorno for uma rejeição acusando que o documento não se encontra na base de dados da SEFAZ, a aplicação pode tomar uma atitude automática de enviar novamente o documento, visto que ele não se encontra na base de dados da SEFAZ. Por outro lado se retornar o protocolo de autorização, como o componente esta com o documento "carregado" o XML será automaticamente atualizado e salvo em disco ou disponibilizado para que o mesmo possa ser salvo no banco de dados. A aplicação em seguida pode imprimir o documento auxiliar do DF-e. Seguindo essas dicas, muitos problemas com a emissão de DF-e são sanadas.

no caso os schemas vão parar de ficar validando do lado de cá pois é dinamico as formas de pagamentos e assim se adicionar novas não precisa se preocupar. creio que vão receber normal mesmo tu informando para que não chegue no dia e ocorra a situação de precisar sair atualizando os clientes ao mesmo tempo

Era isso mesmo Daniel, o tipo do argumento estava como inteiro, alterado para string finciou perfeitamente!! Obrigado.

Por favor verifique o primeiro parametro lote, q ele nao esta gerando quando passamos o Zero. a esquerda é o log do seu projeto Python e direita é o log c# com a mesma dll.

Bom dia pessoal! Acabei não respondendo aqui, o problema era realmente a região configurada na máquina. Ela está em outro país, aí o padrão que o Windows estava puxando era dos EUA mesmo! Envolvia configurações de padrões de data/hora, moeda e região mesmo (Estava mascarado também, a questão de ter vários usuários na máquina, aí precisava forçar eles estarem com o mesmo padrão do Brasil). Obrigado pela atenção!!

Já esta no SVN.

O Banco do Brasil informa que às 07h00 do dia 26/06/2024, ocorrerá a substituição do certificado que o Banco utiliza para validação da URL api.bb.com.br, por motivo de vencimento. Será instalado o novo certificado que está disponível abaixo, caso haja problemas nos produtos ACBrBoleto e ACBrPixCD relacionados a certificação digital, é importante realizar a instalação do certificado abaixo e realizar os testes novamente. Link para Download do certificado novo : https://publicador.developers.bb.com.br/bucket/api_bb_com_br_5c697eff2a.cer

O que é a Manifestação do Destinatário? Este conjunto de eventos, como o próprio nome já sugere, permite que o destinatário da NF-e possa se manifestar sobre a sua participação comercial descrita na NF-e, confirmando as informações prestadas pelo seu fornecedor e emissor do respectivo documento fiscal. Este processo é composto de quatro eventos: 1. Ciência da Emissão 2. Confirmação da Operação 3. Registro de Operação não Realizada 4. Desconhecimento da Operação Como funciona o evento Desconhecimento da Operação? Este evento tem como finalidade possibilitar ao destinatário se manifestar quando da utilização indevida de sua Inscrição Estadual, por parte do emitente da NF-e, para acobertar operações fraudulentas de remessas de mercadorias para destinatário diverso. Este evento protege o destinatário de passivos tributários envolvendo o uso indevido de sua Inscrição Estadual/CNPJ. Como funciona o evento Operação não Realizada? Este evento será informado pelo destinatário quando, por algum motivo, a operação legalmente acordada entre as partes não se realizou (devolução sem entrada física da mercadoria no estabelecimento do destinatário, sinistro da carga durante seu transporte, etc.). Como funciona o evento Confirmação da Operação? O evento será registrado após a realização da operação, e significa que a operação ocorreu conforme informado na NF-e. Quando a NF-e trata de uma circulação de mercadorias, o momento de registro do evento deve ser posterior à entrada física da mercadoria no estabelecimento do destinatário. Este evento também deve ser registrado para NF-e onde não existem movimentações de mercadorias, mas foram objeto de ciência por parte do destinatário, por isso é denominado de Confirmação da Operação e não Confirmação de Recebimento. Importante registrar, que após a Confirmação da Operação pelo destinatário, a empresa emitente fica impedida de cancelar a NF-e. Apenas o evento Ciência da Emissão não inibe a autorização para o pedido de cancelamento da NF-e, conforme o prazo definido na legislação vigente. Como funciona o evento Ciência da Emissão? O evento de "Ciência da Emissão" registra na NF-e a solicitação do destinatário para a obtenção do arquivo XML. Após o registro deste evento, é permitido que o destinatário efetue o download do arquivo XML. O Evento da "Ciência da Emissão" não representa a manifestação do destinatário sobre a operação, mas unicamente dá condições para que o destinatário obtenha o arquivo XML; este evento registra na NF-e que o destinatário da operação, constante nesta NF-e, tem conhecimento que o documento foi emitido, mas ainda não expressou uma manifestação conclusiva para a operação. Todas as operações com o evento de solicitação de "Ciência da Emissão" deverão ter na sequência o registro do evento com a manifestação conclusiva do destinatário sobre a operação (eventos descritos nos itens 5.2, ou 5.3, ou 5.4). É possível reconsiderar o registro de um destes eventos? O destinatário poderá enviar uma única mensagem de Confirmação da Operação, Desconhecimento da Operação ou Operação não Realizada, valendo apenas a última mensagem registrada. Exemplo: o destinatário pode desconhecer uma operação que havia confirmado inicialmente ou confirmar uma operação que havia desconhecido inicialmente. O evento de "Ciência da Emissão" não configura a manifestação final do destinatário, portanto não cabe o registro deste evento após a manifestação final do destinatário. O que fazer quando a operação se realizou de forma diferente do descrito na NF-e, porém a mercadoria já foi recebida pelo destinatário? Caso a operação tenha se realizado, mas o conteúdo da NF-e não descreva corretamente da operação, o destinatário deverá se manifestar utilizando o evento "Confirmação da Operação", e adotar os procedimentos fiscais cabíveis de acordo com a legislação da unidade federada onde estiver estabelecido. Os eventos "Registro de Operação não Realizada" e "Desconhecimento da Operação" não devem ser utilizados nesta hipótese. Onde podemos consultar os eventos de Manifestação do Destinatário? A consulta pública na Internet foi alterada para exibir os eventos registrados na NF-e e pode ser realizada diretamente no Portal da NF-e (www.nfe.fazenda.gov.br) ou portais das Secretarias de Fazenda da circunscrição do emitente, a partir da informação da chave de acesso da NF-e. Os arquivos XML dos eventos também serão disponibilizados para os emitentes/destinatários constantes no documento fiscal. Uma vez que o destinatário tomou Ciência da Emissão é obrigatória a sua manifestação? Sim. Toda nota informada ao contribuinte tem que ter registrada a sua respectiva manifestação até um prazo máximo de 180 dias, contados da data da ciência. Este prazo máximo será reduzido gradativamente, conforme o interesse das Administrações Tributárias. O destinatário deve apresentar uma manifestação conclusiva dentro de um prazo máximo definido, contados a partir da data de autorização da NF-e, conforme tabela abaixo: A distribuição ocorrerá para os atores que desempenham papéis de emitente, destinatário, transportador e terceiros (informado na tag autXML), e englobará os documentos que estiverem com “SIM” na linha correspondente, conforme tabela abaixo: A geração de NSU, a partir da versão 1.10 da Nota Técnica 2014.002, irá considerar somente os usuários do serviço nos últimos 60 dias. É importante ressaltar que: a) para os usuários do serviço dos últimos 60 dias, a geração de NSU continuará normalmente; b) no caso de novos usuários desse serviço (distNSU), a geração de NSU ocorrerá a partir do primeiro acesso. Não haverá geração de NSU retroativo; c) qualquer usuário que deixar de utilizar o serviço (distNSU) por mais de 60 dias, terá a geração de NSU interrompida e retomada a partir da próxima consulta com este método. Não haverá geração de NSU retroativo ao período de interrupção. OBS: A partir da versão 1.13 da Nota Técnica 2014.002, os eventos gerados pelo Fisco, que forem passíveis de distribuição conforme a tabela acima, serão distribuídos ao emitente independente de manifestação do destinatário, ainda que emitente e destinatário sejam iguais.

Acompanhe a notícia a seguir que atualizaremos assim que houverem novidades.