Painel de líderes

Em um outro tópico do fórum um usuário estava alertando sobre a obrigatoriedade em criar a tag naoValid do InfoFech com o valor de N, pois era obrigatório. Contudo, essa obrigatoriedade veio apenas com o layout 1.3, nele os valores permitidos são S ou N, mas no layout 1.2 essa tag somente pode ser criada se o valor foi 's'. layout 1.2 Layout 1.3 Então eu fiz a seguinte alteração no código para atender os dois cenários: Em anexo segue o código para avaliação. pcesS1299.pas

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde @Diego Foliene Testei aqui e voltou a funcionar. Muito obrigado.

@Sandro Felipe Adad, Já esta no SVN.

Boa tarde @Anderson Grolli, Já esta no SVN.

@João Antônio, Já esta no SVN.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde @Marcelo Toller, Porque você deixou como padrão o modo de envio do lote como assíncrono? Quando o provedor disponibiliza os 3 modos de envio (Lote Assíncrono, Lote Síncrono e Unitário) damos como preferencia o modo de envio Lote Síncrono. Se você não deseja usar esse modo basta alterar o segundo parâmetro do método Emitir (exemplo abaixo). { O método Emitir possui os seguintes parâmetros: aNumLote (String) aModEnvio [meAutomatico, meLoteAssincrono, meLoteSincrono, meUnitario, meTeste] aImprimir (Boolean) Valor Padrão = True, portanto imprime o DANFSE } // meLoteAssincrono: Ajusta o Emitir para enviar um lote de Rps no modo Assincrono ACBrNFSeX1.Emitir(vNumLote, meLoteAssincrono);

Bom dia @Jeferson S Lima, Abra o arquivo ACBrNFSeXServicos.ini e leia as instruções que se encontram nas primeiras linhas do arquivo.

Bom dia @Marcelo Toller, O que você alterou na unit Pronim.Provider ?

Bom dia @Anderson Grolli, Muito obrigado pela colaboração, já foi criado a TK-6281 para realizar a alteração.

Consegui resolver o problema :-))))))) o erro está vindo do Bacen, achei o link que explica os erros : https://bacen.github.io/pix-api/index.html Tag Webhook Reúne erros dos endpoints que tratam do gerenciamento dos Webhooks da API Pix. WebhookOperacaoInvalida Significado: a presente requisição busca criar um webhook sem respeitar o schema ou, ainda, apresenta semântica inválida. HTTP Status Code: 400. endpoints: PUT /webhook/{chave}. Violações para o endpoint PUT /webhook/{chave}: o parâmetro {chave} não corresponde a uma chave DICT válida. o parâmetro {chave} não corresponde a uma chave DICT pertencente a este usuário recebedor. Campo webhook.webhookUrl não respeita o schema. Quer dizer que era um problema com a chave pix, eu estou usando a chave aleatoria, mudei para o cnpj ( somente números ) e deu certo Vou testar ainda com a chave pix aleatoria sem traços para ver se funciona. Obrigado ! Marcos

Boa noite Juliomar, desculpe a demora no retorno, foi solucionado o problema depois fiz uma nova atualização, verifiquei que fizeram um correção, está funcionando perfeito. Aproveitando o momento, tem como retorno (RESP) original do banco ? Desde já agradeço

Olá, O componente ACBrSPEDFiscal foi compatibilizado com a versão 3.1.7 do leiaute do EFD-ICMS/IPI e as alterações foram enviados na Rev-36270 conforme os itens a seguir. 1. Alteração da validação do registro C700 * Havia a exceção para o código 66 que foi removida. * Essa alteração não requer alteração no componente. 2. Alteração da obrigatoriedade dos campos 23 e 24 do registro D700 * Os campos passaram de "OC"(Deve ser preenchido quando houver valor) para "O"(Sempre preenchido) * Serão preenchidos zeros a partir de 2025 quando não for informado valor 3. Criação do campo 32 no registro D700 * Novo campo adicionado na classe. 4. Alteração da validação do campo 11 do registro D700 * Validação anterior corresponde à soma dos campos VL_SERV, VL_SERV_NT e VL_TERC subtraído das deduções da NFCom. * A partir de 2025: Corresponde à soma dos campos VL_SERV, VL_SERV_NT e VL_TERC subtraído do campo DED * Essa alteração não requer alteração no componente. 5. Criação do campo 17 no registro D750 * Novo campo adicionado na classe. 6. Alteração da obrigatoriedade dos campos 15 e 16 do registro D750 * Os campos passaram de "O"(Sempre preenchido) para "OC"(Deve ser preenchido quando houver valor) * Ficarão nulos a partir de 2025 quando não for informado valor 7. Alteração da validação do campo 07 do registro D750 * Validação anterior: Corresponde à soma dos campos VL_SERV, VL_SERV_NT e VL_TERC subtraído das deduções da NFCom. * A partir de 2025: Corresponde à soma dos campos VL_SERV, VL_SERV_NT e VL_TERC subtraído do campo DED * Essa alteração não requer alteração no componente. 8. Alteração da validação do campo 02 do registro E113. * Validação: * quando o modelo de documento for igual a 59 (CF-e SAT), 63 (BP-e) ou 65 (NFC-e), deve ser apresentado conteúdo VAZIO “||”. * Quando o modelo de documento for igual a 06 (NF/CEE) ou 66 (NF3e), o seu preenchimento é facultativo. * Campo de preenchimento obrigatório para os demais modelos de documento * O valor informado deve existir no campo COD_PART do registro 0150. * Essa alteração não requer alteração no componente. 9. Alterações de preenchimento dos campos 14, 24 e 25 do registro D100 9.1. Campo 14 * Informação do Manual: * Quando o campo 13 (TP_CT-e) for igual a “3 ou 5”, informar a chave do documento substituído. * Nas demais situações o campo não deve ser preenchido * Essa alteração não requer alteração no componente. 9.2. Campo 24 * Nova Informação do Manual: * preencher com o código do município de **ORIGEM** do serviço, conforme a tabela IBGE. * Preencher com 9999999, se Exterior. * Preencher com “9999998” quando se tratar de CT-e simplificado ou substituição de CT-e simplificado. * Essa alteração não requer alteração no componente. 9.3. Campo 25 * Nova Informação do Manual: * preencher com o código do município de **DESTINO** do serviço, conforme a tabela IBGE. * Preencher com 9999999, se Exterior. * Preencher com “9999998” quando se tratar de CT-e simplificado ou substituição de CT-e simplificado. * Essa alteração não requer alteração no componente. 10. Inclusão do Conhecimento de transporte eletrônico simplificado no registro D130 * Nova Informação do Manual: * Este registro tem por objetivo informar a partir de janeiro de 2025, o Conhecimento de Transporte Eletrônico Simplificado (Código 57, TP_CTe 4 e 5). * Em relação ao Conhecimento de Transporte Eletrônico Simplificado, este registro tem por objetivo identificar individualmente cada entrega/prestação abrangida neste documento * Essa alteração não requer alteração no componente. 11. Alteração no preenchimento dos campos 02, 03, 05 e 06 do registro D130 11.1. Campo 02 * Nova Informação do Manual em negrito: preencher com a informação constante no corpo do Conhecimento de Transporte Rodoviário de Cargas (CTRC) no campo consignatário ou no campo tomador do CT-e simplificado. * Essa alteração não requer alteração no componente. 11.2. Campo 03 * Nova Informação do Manual em negrito: preencher com a informação constante no corpo do CTRC ou do CT-e simplificado no campo redespacho. * Essa alteração não requer alteração no componente. 11.3. Campo 05 * Nova Informação do Manual: Caso trate de item de CT-e simplificado, preencher com o município de origem da prestação a que se refere este item. * Essa alteração não requer alteração no componente. 11.4. Campo 06 * Nova Informação do Manual: Caso trate de item de CT-e simplificado, preencher com o município de destino da prestação a que se refere este item * Essa alteração não requer alteração no componente. 12. Alteração na regra de validação do campo 18 do registro D100. * Nova Informação do Manual: Se CT-e simplificado (COD_MOD 57 e TP_CTe 4 ou 5), o valor deve ser igual à soma do campo VL_FRT do(s) registro(s) D130 existentes * Essa alteração não requer alteração no componente. 13. Alteração da exceção 4 do registro D100. * Nova Informação do Manual: A partir de janeiro/2025, para o CT-e Simplificado-modelo 57, conforme estabelecido pelo Ajuste Sinief nº 46/2023, deverão ser informados os respectivos Registros D130. * Essa alteração não requer alteração no componente. Até mais!!!

Olá. Não encontrei exemplos em Ruby, e comecei aqui a tentar uma implementação: https://github.com/reinaldoacdc/ruby-acbrlib Consegui fazer algumas chamadas, mas não consegui pegar o valor do sResposta. Aí vim aqui para saber se tem alguma forma que não estou vendo. Principais Refs: AcbrLib como trabalhar com Strings: https://acbr.sourceforge.io/ACBrLib/ComotrabalharcomStrings.html Ruby-FII: String as output parameter: https://github.com/ffi/ffi/wiki/Examples#strings-as-output-parameters Agradeço qualquer ajuda

É o PIP ....... E não mais a (;) no manual online esta com (;) ainda Tnanks ....

Continua com o mesmo problema ainda Na revisão: 36252

Um ponto que tem de ser levado em consideração é que a empresa só poderá contabilizar esta compra caso seja NFe, NFCe não seria contabilizada a não ser que seja emitida uma NFe a partir da NFCe com o CFOP 5949. Você pode emitir a NFCe, mas é bem provavél que a empresa solicitará a NFe posteriormente. Veja com a empresa se quer a emissão da NFe de uma vez.

Obrigado pelo retorno

O setor fiscal da empresa do seu cliente deve passar essas informações no caso o contador caso ele não tenha.

Bom dia, Problema identificado. Drive de CH340, do conversor USBxRS232. O driver mais recente de 2023, que é o instalado automaticamente pelo windows 11, apresenta o problema relatado acima. Solucionamos utilizando um driver CH340 instalável, versão de 2019, através de um executável. Vou disponibilizar no link abaixo, caso mais alguém esteja com problemas neste conversor. DRIVER CH340