A formatação que está saindo no PDF acima do codigo de barras não está correta, deve ser:
1- 4 blocos separados com 11 digitos com traço entre eles ou
2- 4 blocos de 11 separados por espaço ou
3- 4 blocos de 10+traco+dig tbm separados por espaços
conf desenhos abaixo
Olá, @MarcioOliveira.
Poderia nos informar o id da NFCom para verificarmos o que está ocorrendo, por favor?
nce_3a18da9f9d254f98acc16813274296f3
Realizamos um teste interno aqui e, até o momento, a linha digitável do código de barras no PDF da NFCom está sendo exibida conforme o padrão esperado.
Você poderia, por gentileza, realizar um teste direto utilizando o Postman ou Insomnia e nos enviar um print da seção do PDF onde a linha está sendo exibida incorretamente?
Segue abaixo print do resultado do GET pdf no postman
ao ler o codbar retorna esses caracteres
75697994100000890001300301112934154971708001
que é exatamente o que enviei
“codBarras”: “75697994100000890001300301112934154971708001”
está correto a leitura e os dados do codbar e só a impressão(formatação) no pdf que esta estranho para usual que são as img que mandei primeiro
Analisamos o caso e identificamos que o valor informado no campo codBarras está sendo enviado com o código de barras contendo apenas os 44 dígitos. No entanto, conforme definido na documentação do padrão, o campo codBarras deve conter a linha digitável, ou seja, o formato com 48 dígitos, o que pressupõe os dígitos verificadores:
É importante destacar que, de acordo com o Manual de Orientações do Contribuinte (MOC) do DANFE-COM, não devem ser inseridas no documento auxiliar informações que não constem no respectivo XML da NFCom, exceto o protocolo de autorização. Isso significa que não é permitido que o sistema calcule ou insira automaticamente os dígitos verificadores no momento da geração do PDF.
Portanto, para que a exibição ocorra corretamente, é necessário que o campo codBarras seja preenchido previamente com a linha digitável completa no XML, já no formato final que será apresentado no documento auxiliar.
Analisando melhor nossos dados e na correria para implantar essa NFCom esquecemos que para esse cliente o codBarras não é padrão FEBRABAN (48 dígitos), também chamado de “conta” usado por concessionárias (CPFL, SEMAE, VIVO, etc, etc). Esse cliente não é concessão e não conseguiu convênio para conta FEBRABAN.
É gerado no padrão CNAB pois usa boletos e no CNAB o codBarras (44 dígitos) é diferente da linha digitável(47 dígitos) que é formatada assim:
34191.09149 35732.820044 55945.870008 5 10180000235925
se mandarmos 44 do codBarras ou 47 da linha digitável teremos problemas dependendo do banco que capturado/digitado o dado.
Tem alguma forma de deixar de enviar esse codBarras para não gerar esse problema?
Esse cliente vai gerar de 20 a 30000 notas por mês. São 4 empresas de TV por assinatura e Internet que já faz um demonstrativo unificado com boleto unico de todos os serviços para o cliente, a NFCom é para cumprir obrigatoriedade legal.
Boa noite, @MarcioOliveira.
A linha digitável do código de barras é obrigatória apenas se o grupo de informações da fatura (gFat) for enviado. No entanto, o envio desse grupo é opcional. Portanto, caso não queira enviar o código de barras, basta não incluir o campo gFat no JSON da NFCom. Como consequência, os demais campos do grupo da fatura também não poderão ser informados: Competência, data de vencimento da fatura, QRCode do PIX, etc. Recomendamos validar com o seu cliente se a omissão dessas informações estará em conformidade com as exigências fiscais.
De qualquer forma, iremos analisar esse caso e implementar um ajuste na API para que a formatação do código de barras ocorra automaticamente. Avisaremos assim que essa melhoria estiver disponível.
o Grupo gFat é definido como opcional no MOC, mas a API não deixa passar sem ele informado com no minimo seus 3 campos CompetFat, dVencFat e codBarras.
Fizemos um teste com 0 no codBarras e ficou assim no PDF
inicialmente usaremos assim até
obrigado
A API aceita o envio da NFCom mesmo sem o grupo gFat, desde que ele seja completamente removido do JSON.
Caso ele seja incluído, ainda que parcialmente, todos os campos obrigatórios (CompetFat, dVencFat e codBarras) serão exigidos conforme o schema do padrão.
Não deu certo, não autorizou, alterado CNPJ e CPF para preservar identidade.
1-JSON enviado 2-JSON recebido API
{
“infNFCom”: {
“versao”: “1.00”,
“Id”: “NFCom33250246469—000140620000000010001030992420”,
“ide”: {
“cUF”: 33,
“tpAmb”: 2,
“mod”: 62,
“serie”: 1,
“nNF”: 1000,
“cNF”: “3099242”,
“cDV”: 0,
“dhEmi”: “2025-03-25T15:53:20Z”,
“tpEmis”: 1,
“nSiteAutoriz”: 0,
“cMunFG”: “3301009”,
“finNFCom”: 0,
“tpFat”: 0,
“verProc”: “1.00”
},
“emit”: {
“CNPJ”: “46469—000140”,
“IE”: “12478496”,
“CRT”: 3,
“xNome”: “CONECTE ON INTERNET E SERVICOS LTDA”,
“enderEmit”: {
“xLgr”: “R TEN CORONEL CARDOSO ANDAR 3”,
“nro”: “794”,
“xBairro”: “CENTRO”,
“cMun”: “3301009”,
“xMun”: “Campos dos Goytacazes”,
“CEP”: “29035044”,
“UF”: “RJ”
}
},
“dest”: {
“xNome”: “ELIANE PARAVIDINO CARNEIRO”,
“CPF”: “7353—0791”,
“indIEDest”: 9,
“enderDest”: {
“xLgr”: “R DR PINTO FILHO”,
“nro”: “247”,
“xBairro”: “IPS”,
“cMun”: “3301009”,
“xMun”: “Campos dos Goytacazes”,
“CEP”: “28025450”,
“UF”: “RJ”
}
},
“assinante”: {
“iCodAssinante”: “001900000120”,
“tpAssinante”: 3,
“tpServUtil”: 4,
“nContrato”: “001900000120”,
“dContratoIni”: “2007-11-20”
},
“det”: [
{
“nItem”: 1,
“prod”: {
“cProd”: “1320”,
“xProd”: “TOTAL 3XX RESIDENCIAL - SVA”,
“cClass”: “0100201”,
“CFOP”: “5307”,
“uMed”: 4,
“qFaturada”: 1,
“vItem”: 10,
“vDesc”: 0,
“vOutro”: 0,
“vProd”: 10
},
“imposto”: {
“ICMS40”: {
“CST”: “40”
},
“PIS”: {
“CST”: “01”,
“vBC”: 10,
“pPIS”: 0.65,
“vPIS”: 0.06
},
“COFINS”: {
“CST”: “01”,
“vBC”: 10,
“pCOFINS”: 3,
“vCOFINS”: 0.30
},
“FUST”: {
“vBC”: 10,
“pFUST”: 1,
“vFUST”: 0.10
},
“FUNTTEL”: {
“vBC”: 10,
“pFUNTTEL”: 0.50,
“vFUNTTEL”: 0.05
}
}
}
],
“total”: {
“vProd”: 10,
“ICMSTot”: {
“vBC”: 0,
“vICMS”: 0,
“vICMSDeson”: 0,
“vFCP”: 0
},
“vCOFINS”: 0.30,
“vPIS”: 0.06,
“vFUNTTEL”: 0.05,
“vFUST”: 0.10,
“vRetTribTot”: {
“vRetPIS”: 0,
“vRetCofins”: 0,
“vRetCSLL”: 0,
“vIRRF”: 0
},
“vDesc”: 0,
“vOutro”: 0,
“vNF”: 10
}
},
“ambiente”: “homologacao”,
“referencia”: “0140-001900000120-000001000”
}
2- JSON resposta recebida API:
{
“id”: “nce_3a18e61a020f4c429fe52a6d572bce38”,
“ambiente”: “homologacao”,
“created_at”: “2025-03-25T19:28:10.224Z”,
“status”: “rejeitado”,
“referencia”: “0140-001900000120-000001000”,
“data_emissao”: “2025-03-25T15:53:20Z”,
“serie”: 1,
“numero”: 1000,
“valor_total”: 10,
“chave”: “33250346469—000140620010000010001030992426”,
“autorizacao”: {
“id”: “evt_3a18e61a022e47fa8396c213556ea48f”,
“ambiente”: “homologacao”,
“status”: “rejeitado”,
“autor”: {
“cpf_cnpj”: “46469—000140”
},
“chave_acesso”: “33250346469—000140620010000010001030992426”,
“data_evento”: “2025-03-25T19:28:10.286Z”,
“numero_sequencial”: 1,
“data_recebimento”: “2025-03-25T19:28:11.067Z”,
“codigo_status”: 270,
“motivo_status”: “Rejeição: Grupo de informações da fatura deve informada para tipo de faturamento normal”,
“tipo_evento”: “autorizacao”
}
}
no aguardo
Olá, @MarcioOliveira.
Fizemos um ajuste agora visando a correta formatação do código de barras para linhas digitáveis de 47 ou 48 posições.
Por favor, realize novos testes e nos avise caso o problema persista.
Fizemos teste formatou corretamente a linha digitável, mas continuamos com problemas pois o codigo de barras são os dados da linha digitável(47 dígitos) convertidos e não os (44 dígitos) no padrão CNAB, além disso o unico APP que conseguiu ler e jogar para pagto foi no Mercado Pago os demais testados nem consegue ler o codigo (Itau, Inter, C6, Nomad, CEF, Nubank, Bradesco )
Na realidade queremos uma solução para não sair/imprimir o codBarras pois como disse esse cliente vai gerar de 20 a 30000 notas por mês. São 4 empresas de TV por assinatura e Internet que já faz um demonstrativo unificado com boleto unico de todos os serviços para o cliente, a NFCom é para cumprir obrigatoriedade legal, e pode emitir para mesmo cliente até 3 notas de empresas diferentes conforme os serviços que tem e vai dar confusão pois poderá haver notas diferentes com mesmo boleto e os valores notas podem não bater com o valor do boleto.
Podiamos colocar a tag assim “codBarras”: “0” e não informar a tag “gPIX” o a API não imprimir nem codbarras nem esse quadrado
Boa noite, @MarcioOliveira.
Fizemos mais um ajuste agora para não exibir o bloco do boleto de pagamento no DANFE-COM em casos onde não há código de barras válido e PIX.
Favor realizar novos testes.
ficou perfeito para nossa necessidade, obrigado
Este tópico foi fechado automaticamente 24 horas depois da última resposta. Novas respostas não são mais permitidas.
