Strtok cst ibs cbs acbr

O risco que já vi é o campo de apresentação ser lido como se fosse a classificação, e não é. Discordo de confiar só no cclasstrib, porque a regra vem com descrição própria e o nome curto nem sempre bate. A gente já teve, no fechamento, nota saindo com classificação errada porque o time olhou só a apresentação. Por isso prefiro ler o cst completo e conferir a classificação na tabela oficial. Discordo com respeito, porque confiar no nome sozinho cria um risco que aparece tarde.

Concordo em parte com a Patrícia, mas discordo da tabela. Mesmo assim, então, meu alerta é que a tabela vira um cadastro paralelo, e aí a situação fica difícil de auditar. O significado do código muda conforme a regra tributária, e a tabela não acompanha isso sem manutenção. Vale guardar só a descrição do cst oficial e revisar quando houver mudança de regra. Patrícia, você revisa essa tabela todo mês?

Tenho uma dúvida curta, a sua equipe lê o cst pelos primeiros caracteres ou pelo nome do campo? Eu, já adianto, viu, que a nossa mineração segue outro caminho. O time usa uma tabela para os códigos reduzidos e só depois confere a rejeição do retorno. Isso vale quando o volume é alto e o arquivo muda pouco. Quando o arquivo muda muito, o melhor é ler pelo nome, porque a posição pode escorregar de uma versão para outra.

No meu caso, na mineração, eu leio o retorno do ACBr quase todo dia. Alexandre, você disse que o nome do campo é mais estável, mas as informações que voltam do sistema às vezes saem fora da ordem do cst. Sua equipe consegue confirmar, nessas informações, qual campo ficou de fora? E, agora, o problema é que eu não sei se o campo permite a mesma leitura em cada linha. Teria um exemplo para me mostrar?

Se o cst vier inexistente no cadastro, o tamanho fixo não salva a nota, e é aí que discordo do João. O ponto é esse, veja, o ganho é ler o código inteiro sem depender da posição. Quando o valor já vem informado de fora, a validação precisa acontecer na entrada, senão a gente só empurra o erro para a frente. Eu prefiro checar na chegada e não no meio do processo, por causa do fechamento. Discordo com educação, porque deixar o ajuste para depois custa mais caro.

O que importa, Alexandre, é saber se o grupo sai indevidamente na nota quando o campo está vazio. No ABAP que eu mantenho, migrando de outro ERP, o indicador de CST vem da tabela e às vezes chega sem o grupo. Você disse que o tamanho fixo resolve, mas no seu caso os três dígitos iniciais chegam sempre idênticos ao código completo? Preciso decidir, no fim das contas, se faço a checagem no código ou no cadastro.

Concordo com o Renato. Eu complemento que, quando o grupo governamental vier vazio, o gtribcompragov não pode aparecer, e o cst da linha segue a mesma regra. A checagem é pulada por muita gente, e olha que, pois é, ela é simples. Grupos governamentais aparecem pouco no nosso volume, mas quando aparecem a leitura muda tudo. No SAP que a gente usa agora, a regra rejeita a nota se esse grupo vier sozinho. Vale fazer um teste com uma nota de cada tipo antes do fechamento.

Alexandre, na nossa distribuidora a equipe seguiu outro caminho. Não lê o cst por posição, lê o código inteiro e confere a regra da exceção no cadastro. Sobre isso, o caminho é, ó, usar o gcompragov como chave quando a nota traz o grupo de aquisição pública, e deixar o gibscbs de fora da leitura inicial. Isso vale quando o arquivo é grande e ninguém quer depender do tamanho da linha. Quando o volume é pequeno, o strtok resolve sem drama. Eu fico com a chave, porque ela é mais previsível quando a gente precisa fechar o mês.

Concordo em parte, o strtok ajuda a separar a linha, mas não serve para ler o cst. O campo conteúdo já traz o código e o sentido, bem, resumindo, então leia pelo tamanho fixo e não pelo espaço. Na minha equipe, no setor de serviços com o GUEPARDO Tax, a gente fez isso e a composição ficou certa em todos os testes. Nas compras, cuidado, porque o campo muda de posição quando a linha vem com um item a mais. Eu usaria o nome do campo, não a ordem dele.