-
Total de ítens
6.130 -
Registro em
-
Última visita
-
Days Won
199
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Diego Foliene postou
-
Desligamento do Protocolo SSL 3.0 do SAT no dia 12/08/2024
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! Na página Sobre o SAT da Sefaz de São Paulo, consta um recado informando que no dia 12/08/2024 a partir das 08h30 a Sefaz vai iniciar o processo de desligamento do protocolo SSL 3.0, com previsão inicial de o processo durar 2 horas. Durante esse período pode ocorrer instabilidade da comunicação com a Sefaz e por isso orienta que a ativação de novos SATs sejam feitos fora deste período. Também é lembrado que: Após este processo, os somente os SATs que se comunicam usando o protocolo SSL 3.0 não vão mais conseguir realizar comunicação. Esse processo já foi previamente comunicado pela Sefaz em aviso no dia 15/03/2024 (noticiado em nosso fórum no tópico Desligamento dos protocolos SSL 3.0 e TLS 1.0 para SAT nos próximos meses no dia 28/03/2024 e também no tópico ATENÇÃO!!! Desativação de Protocolos inseguros na comunicação dos SATs SSL3.0 e TLS1.0 no dia 13/06/2024). A tabela abaixo mostra os modelos de SAT afetados por este processo: Fabricante Modelo de SAT Versões de Software Básico de SAT Há atualizações de SAT para versão mais segura? ControlID S@t-Id 01.02.00 SIM Kryptus EASYS@T 01.00.02 e 01.00.04 NÃO Sweda SS-1000 02.00.01 SIM-
- 1
-
-
Olá pessoal! Ao conferir no painel Situação SVC, é possível confirmar que a Sefaz de Goiás está com a contingência ativada desde às 02h10 do dia 29/06/2024, com previsão de permanecer ativada até às 08h00 do dia 01/07/2024 Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo:
-
- 1
-
-
Olá pessoal! Foi publicada a versão 1.21 desta Nota Técnica. A nova versão trás uma correção na documentação do evento "Ator Interessado" esclarecendo que o CNPJ informado no evento não receberá o evento de Comprovante de entrega na NF-e Cancelamento(foi alterado de "SIM" para "NÃO" a última coluna da última linha da tabela anexada no tópico acima). As datas permanecem as mesmas da versão 1.20. A versão 1.21 da NT pode ser encontrada na íntegra AQUI.
- 1 reply
-
- 1
-
-
Contingência ativada para a Sefaz de Minas Gerais
Diego Foliene replied to Diego Foliene's tópico in Notícias do ACBr
Olá pessoal! A Sefaz de Minas Gerais ativou novamente a contingência às 15h37 do dia 29/06/2024, com previsão de permanecer ativa até às 12h00 do dia 30/06/2024.- 1 reply
-
- 1
-
-
Publicada nova tabela do IBPT 24.1.F 20/06/2024 até 30/07/2024
um tópico no fórum postou Diego Foliene Notícias do ACBr
Foi publicada a versão 24.1.F das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/06/2024 até 30/07/2024 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto" foi, não se esqueça de realizar a atualização de seus clientes. Fonte : De Olho no Imposto-
- 2
-
-
Boa tarde! OpenSSL apenas com A1. Embora tenhamos relatos de membros que usam A1 com Wincrypt, ele é o recomendado para A3.
-
ERRO VENDENDO DOIS PRODUTOS, MAIS SEPARADOS FUNCIONA!
Diego Foliene replied to cristiano informatica's tópico in ACBrMonitor PLUS
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico. -
Bom dia! Tópico vinculado a #TK-5659 para análise do caso. Usando o programa exemplo em C# e a versão mais recente da Lib no Fórum: Apaguei o arquivo ACBrLib.ini. Executei a Lib para que a mesma criasse um novo. Preenchi com dados fictícios, o PathSchemas do meu ambiente e as informações do certificado que tenho. Testei e recebi uma Rejeição E138 - Informe o CNPJ autorizado a executar o serviço. Com o programa exemplo em execução, alterei as configurações do emitente colocando as mesmas do arquivo INI disponibilizado previamente no Discord e salvei as configurações. Fiz um novo teste e recebi Rejeição E138 - Informe o CNPJ autorizado a executar o serviço. Renomeei meu arquivo ACBrLib.ini para .old, colei o arquivo ACBrLib.ini disponibilizado no Discord no diretório para que a lib carregasse dele. Fiz um novo teste e recebi o erro 500 conforme reportado. Comparando os dois arquivos com o WinMerge, com exceção dos certificados, do PathSchemas e da opção SalvarWS, a única diferença apontada foi a configuração de um proxy no seu arquivo. Por favor: As informações de proxy estão corretas? O nome do servidor é mesmo "XXX"? Para salvar a senha, você usou o Config_GravarValor ao invés de adicionar manualmente no INI, correto? É possível fazer um teste em um ambiente sem proxy?
-
untilPara mais informações confira:
-
Olá pessoal! Ao conferir no painel Situação SVC-RS é possível observar que a Sefaz do Mato Grosso está com contingência agendada. Com previsão de inicio às 08h00 do dia 30/06/2024 e término às 09h40 do dia 01/07/2024. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo:
-
- 1
-
-
Contingência ativada para a Sefaz de Minas Gerais
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! Ao conferir no Portal da Nota Fiscal Eletrônica, podemos ver que a Sefaz de Minas Gerais ativou a contingência no dia 27/06/2024 às 07h58, com previsão de encerramento às 12h00 do mesmo dia. Para utilizar as soluções ACBr em contingência siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação em nosso Discord.- 1 reply
-
- 2
-
-
Se você configurou as opções para salvar os arquivos, ela gera o XML automaticamente na pasta para você. Agora se quiser recuperar o XML e trabalhar dentro do sua rotina, sim você pode usar o ObterXML
-
Bom dia! Veja que no conteúdo da resposta da Lib você tem: {"...<Protocolo>a406109f-47d5-4e30-bfdc-48b103e67161<\/Protocolo> <\/EnviarLoteRpsResposta>"} Isso é um indício de que o método de envio que este provedor usa é o assíncrono. Quando o envio é assíncrono, você: Envia o XML de RPS para o web service do provedor. Recebe de volta do Web Service, um número de protocolo que atesta que o seu XML foi recebido pelo web service. Consulta a Situação do Lote usando o número de protocolo com o método NFSe_ConsultarSituacao. Recebe no retorno da consulta de situação um número que indica qual é a situação atual do lote, os número geralmente* são: Número 1 que indica que o XML não foi recebido pelo web service do provedor. Número 2 que indica que o XML foi recebido, mas que ainda não foi processado. Número 3 que indica que o XML foi recebido e foi processado com erros. Número 4 que indica que o XML foi recebido e foi processado com sucesso. *Em alguns poucos provedores específicos, os números podem representar condições diferentes, mas pelo que pude conferir, não é o caso do Pronim. Se consultar a situação e receber 3 ou 4, você consulta o Lote com o método NFSE_ ConsultarLoteRps para receber os erros caso a situação seja 3 ou o XML da NFSe* caso a situação seja 4. *Alguns provedores não devolvem o XML completo, mas sim apenas algumas informações de que a nota foi aceita. Portando, agora você precisa consultar a situação com este protocolo que recebeu.
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
-
Olá pessoal! Informamos que a ACBrLibSAT possui agora dois novos métodos. São eles: SAT_CarregarXML: método que permite carregar as informações de um XML de CFe na Lib. SAT_ObterINI: método utilizado para que a Lib devolva o conteúdo de um CFe no formato de um arquivo INI. Ambos métodos foram implementados visando fornecer uma maior liberdade para que possam trabalhar com as informações de um CFe com a Lib. Um extra para quem é do C# Para aqueles que utilizam a ACBrLibSAT com C# e fazem uso das classes que disponibilizamos em nosso SVN ou no Nuget, com a adição destes novos métodos, agora é possível preencher a classe de alto nível com o conteúdo do CFe com poucas linhas. Vejam um exemplo: var xmlPath = Helpers.OpenFile("Arquivo xml CFe (*.xml)|*.ini|Todo os Arquivos (*.*)|*.*"); if (string.IsNullOrEmpty(xmlPath)) return; acbrSat.CarregarXML(xmlPath); // Linha responsável por preencher a classe. CupomFiscal cFe = acbrSat.ObterCFe(); //As propriedades vão ter os valores que foram lidos do XML carregado. cFe.InfCFe.Id; cFe.Identificacao.CNPJ; cFe.Destinatario.xNome;
-
- 1
-
-
Bom dia! Muito obrigado! Criada a #TK-5632 para análise do caso e parecer por parte da equipe de consultores.
-
Olá pessoal! No dia 21/06/2024, foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 12 / 2024 que trás as seguintes alterações nas Tabelas Externas 5.1.1, 5.2 e 5.3 da EFD para o estado de Santa Catarina: O correio eletrônico pode ser baixado e lido na íntegra AQUI. As tabelas já atualizadas podem ser encontradas AQUI.
-
- 3
-
-
Implementação em produção da NT2024/002 para NFCom
um evento no calendário postou Diego Foliene Prazos SEFAZ
Para mais detalhes confira: -
Implementação em Homologação da NT2024/002 para NFCom
um evento no calendário postou Diego Foliene Prazos SEFAZ
Para mais detalhes confira: -
Nota Técnica 2024/002 - NFCom: Alterações no Layout e em Regras de Validação
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! Foi publicada a Nota Técnica 2024/002 que traz alterações no layout da NFCom e em suas regras de validação. Alterações Adição de novo cClass Adiciona na Tabela de Códigos de Itens da NFCom (cClass) o novo item: Alterações no Schema da NFCom Adiciona os seguintes novos campos: Campos referentes a informação da Nota modelo21/22 em papel na hiótese de um Cofaturamento referenciar um documento anterior a implantação eletrônica gNF > CNPJ: CNPJ do emitente do documento fiscal. gNF > mod: Modelo do documento. gNF > serie: Série do documento fiscal. gNF > nNF: Número do documetno fiscal. gNF > CompetEmis: Ano e mês da emissão da NF gNF > hash115: Hash do registro no arquivo convêncio 115 Indicador opcional para indicar que uma nota referenciada na nota de faturamento existe somente em modelo papel indNFComAntPapelFatCentral: Informa que a NFCom Anterior de Faturamento centralizado não é eletrônica Alterações nas regras de validação Dentre as alterações nas regras de validação, vale destacar: Regra G64, Rejeição 255: Altera a regra para que passe a mesma só seja aplicada quando o tipo da NFCom for de Ajuste(finNFCom = 4). Regra G67, Rejeição 515: Altera a mensagem de rejeição para: Adição de regras: Adiciona as regras de validação G76a com a rejeição 697, G76b com a rejeição 699 e G76c com a rejeição 700 para validar os novos campos do grupo gNF Adiciona a regra de validação G91a com a rejeição 698 para validar o novo campo indNFComAntPapelFatCentral. Datas Implantação Homologação: 01/07/2024. Implantação Produção: 15/07/2024. E como fica o ACBr? Como pode ser visto, nota técnica traz a inclusão de novos campos e por isso, alterações nos fontes do ACBr serão necessárias. Foi criada #TK-5624 em nosso backlog para implementação das alterações, quaisquer novidades serão divulgadas neste tópico. Leia a Nota Técnica na íntegra AQUI.-
- 1
-
-
Boa tarde! Por favor, pode fazer um teste definindo nas configurações gerais a codificação resposta para Ansi? Se o problema persistir, volte a codificação para UTF8, defina PathSalvar e SalvarWS nas configurações específicas da NFSe, faça novo teste e disponibilize os arquivos -soap.xml gerados no caminho que definiu em PathSalvar para que possamos analisar.
-
-
Quando devo encerrar um Manifesto Eletrônico de Documentos Fiscais(MDF-e)?
um tópico no fórum postou Diego Foliene MDF-e
Olá pessoal! Quando falamos de um Manifesto Eletrônico de Documentos Fiscais (MDF-e), uma dúvida recorrente que pode vir a surgir é a correta maneira de utilizar o evento de encerramento. O que diz o Manual? O Manual de Orientação do Contribuinte Visão Geral, traz a seguinte definição para o evento de encerramento: O que isso quer dizer? Na prática, isso quer dizer que quando terminado o trajeto e também toda vez que houver alteração de carga é necessário encerrar o MDF-e vigente e emitir um novo. Pode dar um exemplo? Vamos considerar como exemplo hipotético uma caminhão que saia de MT para entregar parte de sua carga em SP e o restante em MG. Neste cenário devemos: Emitir um MDF-e com carregamento em MT e descarregamento em SP (aqui toda a carga deve ser incluída) Emitir um segundo MDF-e com carregamento em MT e descarregamento em MG (só com a carga que vai para MG). Os 2 MDF-e podem ser emitidos um em seguida do outro antes mesmo de o caminhão partir de SP. Quando o motorista avisar que toda a carga referente a SP foi entregue, a empresa que esta em MT encerra o primeiro MDF-e. Quando ele avisar que o resto da carga destinada a MG foi entregue, a empresa encerra o segundo MDF-e. Vamos considerar outro exemplo em que um caminhão parte de SP ao RJ com um carga, mas no meio do trajeto, ocorre a quebra do veículo de tração ou de reboque e o mesmo precisa ser trocado. Neste exemplo, o MDF-e emitido originalmente deve ser encerrado e um novo MDF-e com a informação do novo veículo deve ser emitido. Por fim, em um cenário em que um caminhão parte de SP com destino a MG, quando chegar em seu destino e a carga for entregue o MDF-e correspondente deverá ser encerrado. Observações Importantes: Um MDF-e encerrado não pode ser cancelado. Um MDF-e só pode ser cancelado se o caminhão não saiu da empresa para realiza o transporte da carga. Todo MDF-e tem que ser encerrados (exceto os cancelados) quando a carga é descarregada ou quando ocorre alteração conforme já apresentado acima. Dica aos desenvolvedores: Ao treinar o usuário a usar a aplicação de emissão de MDF-e deixe bem claro o conceito de MDF-e Cancelado e MDF-e Encerrado.