Diego Foliene

Boa tarde! Para fins de documentação da alteração, foi criada a #TK-6050 para o caso. Como já realizou os testes e o retorno foi positivo, vamos disponibilizar a alteração no SVN.

Combinado, fico no aguardo. Caso ache que tenha informações sensíveis e não possa ser enviado direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail por favor.

Olá pessoal! No dia 09/10/2024 foi publicada a versão 1.01 desta nota técnica. Alterações Gerais A nova versão traz uma explicação sobre os tipos de guia (tpGuia): Guias para Animais GTA - Guia de Trânsito Animal TTA - Termo de Transferência Animal. DTA - Documento de Transferência Animal. Guias para Vegetais GTV - Guia de Transito Vegetal. ATV - Autorização Trânsito Vegetal. PTV - Permissão de Trânsito Vegetal. Guias Florestais SisFlora - Sistema de Comercialização e Transporte de Produtos Florestais. SIAM - Sistema Integrado de Informação Ambiental. DOF -Documento de Origem Florestal. Também consta na NT orientação informando que com exceção do Pará, Mato Grosso e Minas Gerais a NF-e deve ser emitida antes do Documento de Origem Florestal DOF. Leiaute Foi adicionado no grupo defensivo o campo CPFRespTec que vai receber o CPF do Responsável Técnico emitente do receituário. Regras de Validação Adiciona a regra de validação ZF02-20 para validar se o item informado é defensivo agrícola. Adiciona a regra de validação ZF03a-10 que valida o campo CPFRespTec. Adiciona observações que tornam as regras de validação opcionais a critério da UF. Datas Implantação Teste: 04/11/2024 Implantação Produção: 01/04/2025 E como fica o ACBr? As modificações visando atender a versão 1.00 desta nota técnica já foram efetuadas, não tendo sido disponibilizadas ainda porque a Sefaz não liberou os arquivos de schema. A mesma TK será utilizada e o campo CPFRespTec será adicionado. Leia a versão 1.01 desta nota técnica AQUI.

Bom dia @Diogo Loff. Primeiro de tudo, muito obrigado pela contribuição! Toda colaboração é e sempre será mais do que bem vinda. Estou analisando as contribuições que disponibilizou. Na unit ACBrNFeDANFEFRDM.pas, você sugeriu modificar no Split o ponto e vírgula(;) pelo pipe(|). Para este caso, eu entendo que isso acabaria chumbando o pipe e não respeitaria a config propriamente dita. Eu substitui o Split pelo StringReplace direto(conforme foi feito com o CT-e em situação semelhante). Fiz um teste em meu ambiente e parece estar tudo certo, mas por garantia, também pedi um apoio ao pessoal que possui a versão indicada do Fast Report(não aquela que vem no GetIt) para que também façam um teste antes de disponibilizar. Na unit ACBrDFeDANFeReport.pas, você sugeriu uma modificação que faz a quebra em casos que haja o infAdic, não tenha o infCpl, mas tenha outras informações posteriormente. Por favor, pode disponibilizar um exemplo de como está no XML que ocorreu o problema? Em meus testes estou utilizando um XML que está desta forma: <infAdic> <infAdFisco>InfAdFisco: PED123; PED465; ;|</infAdFisco> <obsCont xCampo="ObsCont-Ped132;|"> <xTexto>ObsCont-Texto; Text2; Texto3|</xTexto> </obsCont> <obsFisco xCampo="ObsFisco-Ped123|"> <xTexto>ObsFisco-Texto; Texto2; Texto3;|</xTexto> </obsFisco> <procRef> <nProc>02/2024</nProc> <indProc>4</indProc> <tpAto>14</tpAto> </procRef> </infAdic> (tem ponto e vírgula e pipe para testar a configuração). Em meus testes com o Fortes, tanto no impresso em retrato quanto no impresso em paisagem, não vi diferença aplicando a alteração para o que já está no SVN. Nos prints abaixo, a parte de cima é com a unit do SVN e a de baixo é com a alteração sugerida:

Boa tarde! Por favor, a LibXML2 está devidamente instalada no ambiente?

Olá pessoal! No dia 03/02/2024 foram publicadas a Nota Técnica Nº 02/2024 e a Nota Orientativa Nº 01/2024. Também foram republicadas a NT01/2024 e a NT05/2024. Tudo isso com o objetivo de adequar o e-Social e orientar os segmentos empresariais dos municípios de até 156 mil habitantes que foram afetados pela Lei nº 14.973/24 sobre como proceder. Foi criada a #TK-6073 em nosso backlog para análise das modificações e adequação do componente caso necessário. As notas técnicas referenciadas podem ser encontradas AQUI. A nota orientativa pode ser lida na integra AQUI. A notícia original pode ser lida na integra AQUI.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica é possível verificar que múltiplas Sefaz estão com contingência agendada para o dia 13/10/2024, com previsão de inicio às 05h00 e encerramento às 12h00. Para utilizar as soluções do ACBr em contingência durante este período siga as orientações do tópico abaixo:

Olá pessoal! Ao acessar o portal SPED MG no dia 09/10/2024, foi exibido o seguinte aviso informando que a Sefaz de MG vai passar a validar a regra de consumo indevido no ambiente de produção em 03/02/2025.

Olá pessoal! No dia 07/10/2024 foi publicada a versão 2.1.2.a do leiaute do Reinf. Esta nova versão consolida as alterações descritas nas notas técnicas 01/2023, 02/2023, 03/2023, 04/2023, 01/2024, 02/2024 e 03/2024. Na mesma data, também foram publicados novos schemas para atender a última nota técnica 03/2024. As alterações já estão disponíveis tanto no ambiente de produção restrita quanto no ambiente de produção. Os novos documentos relacionados a nova versão do leiaute podem ser encontrados AQUI. Com destaque ao arquivo Controle de alteracoes Leiautes da EFD-Reinf v2.1.2a base v2.1.2.pdf, que traz um compilado das alterações desta nova versão em relação a anterior. E como fica o ACBr? Dentre as modificações, há alteração de ocorrências de campos já existentes e adição de novos, portanto, serão necessárias modificações no componente ACBrReinf que posteriormente serão refletidas na Lib e no Monitor. Criada a #TK-6070 para adequação dos fontes. Qualquer novidade será relatada neste tópico.

Olá pessoal! Consultando o Portal da NFe às 10h09, é possível verificar que a contingência foi prolongada ativa até às 12h00.

Olá pessoal! No dia 08/10/2024 foi publicada a nota técnica 2024/001 em sua versão 1.00 trazendo alterações no leiaute da DC-e e correções relacionadas ao MOC. Alterações Chave de Acesso Esta nota técnica traz alterações na consideração da chave de acesso, corrigindo o Id dos campos em que seriam extraídos as informações de ano e mês de emissão da DCe, modelo da declaração, série da declaração, número da declaração, forma de emissão da DCe e dígito verificador para correta geração da informação da chave de acesso no documento. Web Service - DCeRecepcaoEvento - Geral Foi corrigido as nomenclaturas dos schemas de eventos para que fiquem de acordo com o referido arquivo .xsd Também foi removido do grupo de informações do registro do evento que é devolvido no retorno do web service as tags cOrgaoAutor, CNPJDest/CPFDest e emailDest. Web Service - DCeRecepcaoEvento - Cancelamento As regras de validação que testam se a data do evento é maior do que data do processamento ou se o emitente é habilitado para emissão do DC-e foram removidas. Web Service - DCeConsultaProtocolo Adicionada regra de validação para verificar se a UF da chave de acesso é atendida pelo web service. Alterações no leiaute Adiciona no Tipo do Emitente da DCe (tpEmit) o valor 4 que corresponde a "ECT". Remove o grupo de informações de empresa com emissão própria(EmpEmisProp) e seus campos. Adiciona o possível grupo para informações da empresa brasileira de correios e telégrafos(ECT) possuindo os campos CNPJ e xNome. Adiciona no grupo infAdic um campo para receber as informações adicionais da empresa brasileira de correios e telegrafos (infAdECT). Altera o nome do grupo campo de uso livre do fisco de obsCont para obsFisco. Adiciona um grupo campo de uso livre do emitente (obsEmit). Adiciona um grupo campo de uso livre do ECT (obsECT). Regras de validação Remove regra de validação da rejeição 568 que validava se estava faltando o atributo versão na tag raiz do DC-e. Altera o texto da regra de validação C02a-20 que devolve a rejeição 407 e também adiciona mais detalhes na descrição do erro. Altera o texto da regra de validação C02-40 que devolve a rejeição 503 para que valide também CNPJ da ECT. Remove as regras D16-10 e D16-20 que devolviam as rejeições 230 e 231, validando respectivamente se a DC-e foi feita com emissão própria com tipo de emitente incompatível e se o CNPJ do emissor próprio era diferente do CNPJ do emitente. Adiciona as regras de validação D18-10, D19-10 e D19-20 para validações relacionadas as informações do ECT. Adiciona as regras de validação I06-10 e W16-20 para validar o valor do produto e também o total da DCe. Datas Implantação Teste: 30/10/2024 E como fica o ACBr? Como a nota técnica traz alterações no leiaute, modificações serão necessárias no componente ACBrDCe. Foi criada em nosso backlog a #TK-6069 para adequação do componente. Qualquer novidade será disponibilizada neste tópico. Leia a nota técnica na íntegra AQUI.

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo está com a contingência agendada para o dia 13/10/2024, com previsão de início às 06h00 e encerramento às 20h00. Para utilizar as soluções do ACBr em contingência durante este período, siga as orientações do tópico abaixo:

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica é possível observar que a Sefaz de Minas Gerais ativou a contingência no dia 08/10/2024 às 21h00, com previsão de permanecer ativada até às 10h00 do dia 09/10/2024. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo:

Boa tarde! Por favor, quais são as mensagens de erro que está recebendo? Conferindo aqui, o campo consta como obrigatório, sendo sempre gerado vazio.

Boa tarde! Foi feita uma edição corretiva no tópico. Recebemos novas informações, confirmando que a portaria mencionada internaliza o E-CONF, mas que o mesmo ainda é opcional no estado, com portaria que venha a definir a obrigatoriedade ainda a ser publicada.

Bom dia! Tópico vinculado a #TK-6059 criada para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será divulgada aqui.

Olá pessoal! No dia 08/10/2024 foi publicada a versão 1.20 desta nota técnica. Visão Geral Esta nova versão traz alterações para permitir emissão de NFC-e com CFOP 5.9.49 com CSOSN9000 ou CST40 para registro de gorjeta na UF de SP. Alterações As regras de validação I08-150, N12-40 e N12a-40 que validam o CFOP e o CSOSN/CST informados foram alteradas para permitir no estado de SP o uso do CFOP 5.949 junto ao CST 40 ou CSOSN 900 no caso de simples nacional. Datas Ambiente de Homologação: 30/09/2024 Ambiente de Produção: 07/10/2024 Leia a versão 1.20 desta nota técnica AQUI.

Olá pessoal! No dia 07/04/2024 foi publicada a versão 1.20 desta nota técnica. A nova versão entre em vigor nos ambientes tanto de homologação quanto de produção de maneira imediata a sua publicação. Ela altera a regra de validação YA09-20, dando a ela o seguinte texto: Efetivamente aumentando o limite do troco para R$ 300.000,00 Leia a versão 1.20 na íntegra AQUI.

Boa tarde @Infoel. Por favor, pode disponibilizar um MVP que simule o problema?

Boa tarde! Por favor, veja este tópico:

Realmente, não tem mesmo. Um ponto que vale destacar é que as datas 30/12/1899 correspondem a data "zero", o que quer dizer que a Lib não está recebendo os valores. Não domino a sua linguagem, mas pelo que pude averiguar, ela faz uso de tipagem dinâmica. Por favor, faça um teste forçando os valores para os tipos esperados pelo método. De acordo com o GPT, ficaria assim: local cFunction := 'PIXCD_ConsultarCobrancasCobV' local ADataInicio := CTOD('02/10/2024') // Converte uma string para data local ADataFim := CTOD('03/10/2024') // Converte uma string para data local ACpfCnpj := '42792981067' local ALocationPresente := .F. // Valor booleano (False) local AStatus := '1' local PagAtual := '1' local ItensPorPagina := 50 // Valor numérico local sResposta := '' local esTamanho := 0 nResult := dllCall(self:nHandle, self:nCallingConvention, cFunction, ADataInicio, ADataFim, ACpfCnpj, ALocationPresente, AStatus, PagAtual, ItensPorPagina, @sResposta, @esTamanho) Conferindo nos exemplos disponibilizados por membros da comunidade em nosso SVN, também é possível observar que nos parâmetros de string, é utilizado este método hb_StrToUTF8 no parâmetro.