Painel de líderes

Boa tarde, Fizemos uma correção no DanfeRetrato.fr3 relacionado a alteração do tópico abaixo: Depois da alteração, a impressão das colunas quando suprimido a coluna Valor Desconto estava incorreta, bem como o total de páginas impresso. Antes da correção: Após a correção: Segue em anexo o arquivo DanfeRetrato.fr3 corrigido. Se puderem por gentileza avaliar e, se estiver de acordo, disponibilizar no repositório, nós agradecemos. Obrigado a todos! DANFeRetrato.fr3

Bom dia pessoal, no evento S-2220 o campo procRealizado no manual é do tipo inteiro, mas dá falha de validação com o schema.. Falha na validação dos dados do evento: evtMonit-v_S_01_00_00 1824 - Element {http://www.esocial.gov.br/schema/evt/evtMonit/v_S_01_00_00}procRealizado: 197 is not a valid value of the local atomic type. Não sei se pode ser algum erro do layout, mas na Tabela 27 - Procedimentos Diagnósticos o campo código possuí 4 dígitos começando com zeros a esquerda, trocando o tipo do campo para string, passou na validação e subiu normal pro eSocial.. Segue fonte com os ajustes.. pcesS2220.pas

Boa tarde. Um cliente meu está tentando importar uma NF-e de Produtor Rural Modelo 55, e ela foi emitida por um Produtor que usa CPF (CPF na chave da Nota), usando uma Série na faixa 910 à 919. Eu estou usando a seguinte função para validar a Chave dessa Nota: ValidarChave(const chave: string) Essa função está na Unit ACBR\Fontes\PCNComum\pcnAuxiliar.pas. Mas ela está retornando o valor falso, invalidando a chave da Nota, quando na verdade eu verifiquei a chave na consulta NF-e do portal da SEFAZ, e está emitida corretamente, portanto a chave é válida. Nessa função há um trecho de código que faz a validação da chave da Nota tratando como um CNPJ ou CPF dependendo da Série utilizada, onde somente trata como CPF se estiver usando uma Série entre 920 e 969, conforme segue: case StrToInt(copy(aChave, 23, 3)) of // serie reservada para DFe eCPF emitida por aplicativo da Empresa Emitente 920..969: result := ValidarCPF(copy(aChave, 10, 11)); else // serie (001-889) reservada para DFe eCNPJ result := ValidarCNPJ(copy(aChave, 7, 14)); end; Verificando a Documentação da NF-e, eu constatei o seguinte tratamento: Faixa Emissor Identificador Assinatura procEmi 000-889 Aplicativo do Contribuinte (NFe) CNPJ e-CNPJ do contribuinte 0 ou 3 890-899 Site do Fisco (NFA-e) CNPJ / CPF e-CNPJ da Sefaz 1 900-909 Site do Fisco (NFA-e) CNPJ e-CNPJ da Sefaz ou e-CNPJ do contribuinte 1 ou 2 910-919 Site do Fisco (NFA-e) CPF e-CNPJ da Sefaz ou e-CPF do contribuinte 1 ou 2 920-969 Aplicativo do Contribuinte (NFe) CPF e-CPF do contribuinte 0 ou 3 (No caso, o meu cliente se encaixa na penúltima linha, Série da faixa 910 à 919, NFA-e Modelo 55 emitida por um CPF). Portanto eu fiz alterações nessa parte do código, ficando da seguinte forma: case StrToInt(copy(aChave, 23, 3)) of // Séries (000-889) reservadas para NF-e eCNPJ emitida por aplicativo da Empresa Emitente 000..889, // Séries (900-909) reservadas para NFA-e eCNPJ emitida no Site do Fisco 900..909: result := ValidarCNPJ(copy(aChave, 7, 14)); // Séries (910-919) reservadas para NFA-e eCPF emitida no Site do Fisco 910..919, // Séries (920-969) reservadas para NF-e eCPF emitida por aplicativo da Empresa Emitente 920..969: result := ValidarCPF(copy(aChave, 10, 11)); else // Séries (890-899) reservadas para NFA-e eCNPJ ou eCPF emitida no Site do Fisco, e outras possíveis Séries futuras result := ValidarCNPJ(copy(aChave, 7, 14)) or ValidarCPF(copy(aChave, 10, 11)); end; O arquivo atualizado com as alterações que fiz segue em anexo nesse post. Favor verificar e aprovar a alteração se possível. Aceito sugestões de melhoria. Agradeço desde já. Vlw! pcnAuxiliar#new.pas

Enviei ajuste para o repositório com base na sua sugestão, rev. 21830. Favor atualizar os fontes e testar.

O que você procura deve ser a API do serpro. essa sim permite baixar os xmls de qualquer nota em lote. https://www.loja.serpro.gov.br/consultanfe

Conforme leu acima não é nosso o problema e sim no SEFAZ entra em contato com eles, enche de ligação que eles correm resolver

Olá, Juliana td bem? Realmente faltou eu especificar melhor a situação. É que a prefeitura de Florianópolis adotou um padrão diferente para o envio das notas, através do protocolo OAuth2, que utiliza uma comunicação rest. Pedi o help aqui na esperança de ter alguém que mesmo utilizando o acbr para as outras cidades (como meu caso), possa ter conseguido resolver esse problema e tenha disponibilidade até mesmo de me prestar uma consultoria paga se for o caso. Obrigado

Boa tarde Rafael, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia a todos, Quero deixar aqui a minha opinião sobre esse assunto. Em nenhum manual ou nota técnica e muito menos na legislação que trata sobre a NF-e consta que devemos trocar o protocolo de autorização pelo de cancelamento. Pelo contrario no Ajuste SINIEF que instituiu a NF-e deixa claro que o XML da NF-e só terá validade jurídica se o mesmo estiver assinado digitalmente e com o protocolo de autorização. Outra coisa que devemos ter em mente é que ao cancelar uma nota fiscal temos um segundo XML que é o XML de processamento do evento, esse XML contem o pedido de cancelamento assinado digitalmente e o protocolo da SEFAZ que atesta que a nota esta cancelado, logo esse XML tem validade jurídica. Se a intensão é apenas imprimir no DANFE a tarja de nota cancelada, lembre-se que existe uma propriedade de configuração que defini que a nota esta cancelada. Por fim se o cliente ou o contador do mesmo venha com essa historia de alterar o XML, solicita o documento que determina que essa alteração pode ou deve ser feita no XML. Já lhe adianto não vão conseguir lhe mostrar documento nenhum, pois isso não existe.

Eu vou atualizar aqui e testar para te confirmar isso.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn

Bom dia, pelo o que vi nesse documento, isso é apenas uma sugestão e não uma rejeição a sua homologação. Pelo o que estão rejeitando é que o cadastro pertence a ACPARTS BRASIL SC LTDA e você informou PERFORMANCE CAR LTDA, por isso rejeitaram a homologação, referente ao digito da agencia, eles só passaram como sugestão a remoção, mas não que isso está impedindo o credenciamento. eles estão pedindo para ajustar o código beneficiário, razão social, informações de protesto, local de pagamento. o arquivo de remessa e ficha de pagamento tem que conter as mesmas instruções de protesto, juros e multas. Verifique essas demais questões, acredito que informando só isso correto o credenciamento é concluído Forte Abraço

Bom dia, Qual a necessidade de no XML de autorização, nas tags nprot inserir a informação de cancelamento ? pois desde que entrou a NFe 4.00 o cancelamento é por meio de eventos, então você sempre terá um XML autorizado e outro de evento de cancelamento vinculado a este autorizado, assim, realizando o seu cancelamento, essa questão acredito ser legado da NFe3.10, que não se aplica a NFe 4.00 e ao meu ver fazer a alteração do XML autorizado está errado. Poderia explicar a necessidade / embasamento que estão tendo nesta questão ?

Do jeito que está falando é um VCL. service que é um serviço do windows não vai te permitir interagir com telas. lembrando que o micro vai precisar estar ligado e logado para o programa rodar no tray

PageCount - Peço desculpas pela postagem desnecessária.

Maravilha... Foi esse mesmo o problema por algum motivo na maquina em questão do cliente o arquivo AcbrLib.INI esta ficando com esses campos com o valor 0, vou investigar o motivo. Mas colocando os valores na mão o problema foi resolvido e a nota emitida. Muito Obrigado pela ajuda

dbexpress não sei mas com firedac usa assim: Execute Block (dtvencto timestamp = :data) update tabela set campo=:dtvencto ... fdquery.ParamByName('data').AsDateTime := Now; fdquery.ExecSQL; no zeosdbo usa assim: Execute Block (dtvencto timestamp = &data) update tabela set campo=:dtvencto ... ZQuery1.ParamChar:='&'; ZQuery1.ParamCheck:=False; ZQuery1.ParamByName('data').AsDateTime := Now; ZQuery1.ExecSQL;

@Marcelo Pontes Melim, Boa tarde! Encontrei o mesmo erro que já havia relatado para o evento S2306, mas desta vez no evento S2399. No arquivo pcesS2399, linhas 306-308, está: if VersaoDF > ve02_05_00 then if obj.matricula = '' then Gerador.wCampo(tcStr, '', 'codCateg', 1, 3, 1, obj.codCateg); Novamente, acredito que a solução seja a mesma da vez anterior: if (VersaoDF <= ve02_05_00) or (obj.matricula = '') then Gerador.wCampo(tcStr, '', 'codCateg', 1, 3, 1, obj.codCateg); Agradeço pelo empenho em manter o código atualizado!

A SEFAZ-MS notificou os contribuintes que emitem NFe que houve atualização do certificado digital nos servidores da mesma, e por este motivo poderá ser necessário a atualização da cadeia de certificados ICP-Brasil nos contribuintes. Este comunicado foi realizado via email, conforme um dos membros de nossa comunidade gentilmente compartilhou conosco. Página com a NOVA CADEIA: https://www.nfe.ms.gov.br/manuais-de-atualizacao-da-cadeia-de-certificados/. Link para noticia no Portal da SEFAZ/MS Att.

Os arquivos que ainda estiverem na versão 1.4 deixarão de ser aceitos pelo webservice a partir de 21/05/2021, a partir desta data, serão aceitos somente arquivos compatíveis com a versão 1.5.1. Importante: Mesmo que a competência do arquivo a ser enviado seja abril/2021, o mesmo será rejeitado se estiver com versão incompatível a 1.5.1. Nesta mesma publicação, foram informados paradas para atualização do ambiente de produção do Reinf entre as 23:00 do dia 20/05/2021 e as 09:00 do dia 21/05/2021 devido a atualização para a versão 1.5.1. Link para Ato Declaratório 67/2020 aqui Fonte: Portal EFD Att.

Bom dia pessoal, Se você já nos acompanhou em alguma edição do Papo Pro, sabe como é um momento de muita troca de informação entre a equipe ACBr, convidados e toda a comunidade, com direito a bate papo e tudo que uma conversa descontraída pode oferecer. Nesta semana, traremos temas muito interessantes, os quais vale a pena acompanhar, e o melhor, abertos a toda a comunidade, por isso, não perca tempo e participe conosco !! Bom Papo a todos !!