MIT041

Especificação de Processos –
CROWN – Versão: 6.0

FATURAMENTO
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Sumário

1. Dados Gerais..........................................................................................................................................................3
2. Descrição do Sub-Processo....................................................................................................................................3
2.1 – Cadastro de Cliente.................................................................................................................................................4
2.2 – Cadastro de Produtos.............................................................................................................................................5
2.3 – Cadastro de Condição de pagamento.....................................................................................................................6
2.4 – Cadastro de Vendedores/Representantes..............................................................................................................7
2.5 - Cadastro Tabela de Preços......................................................................................................................................7
2.6 – Cadastro de Transportadora...................................................................................................................................9
2.7 – Comissões.............................................................................................................................................................10
2.8 – Pedido de Vendas.................................................................................................................................................10
2.9 – Liberação de Pedidos............................................................................................................................................14
2.10 – Liberação Estoque/Credito.................................................................................................................................15
2.11 – Preparação Documento de Saída........................................................................................................................16
2.12 – Nota Fiscal Eletronica SEFAZ...............................................................................................................................17
2.13 – Eliminação de Resíduo........................................................................................................................................17
2.14 - Relatórios e Consultas.......................................................................................................................................18
3. Fluxograma ToBe.................................................................................................................................................19
4. Informações do Processo.....................................................................................................................................20
4.1 Relatórios............................................................................................................................................................20
5. Aprovação............................................................................................................................................................20

2
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

1. Dados Gerais

Nome do Cliente: Crown Embalagens Metálicas da Amazônia S/A

Código do Cliente: T55066

Nome do Projeto: Fênix Nº do Projeto: D000015801

N° Contrato: Produto: Protheus 12.1.25
Data: Julho 2020 Assunto: Levantamento Faturamento
Arquiteto: SANDRA NISHIDA Assinatura:

CNPJS contemplados para o escopo do projeto:

Empresa CNPJ Regime Apuração

01 01 - Crow Embalagens - CEMA Manaus AM 33.174.335/0001-85 Lucro Real Não Cumulativo
01 02 - Crow Embalagens - CEMA Cabreuva SP 33.174.335/0003-47 Lucro Real Não Cumulativo
01 04 - Crow Embalagens - CEMA Ponta Grossa PR 33.174.335/0010-76 Lucro Real Não Cumulativo
01 05 - Crow Embalagens - CEMA Estância Se 33.174.335/0011-57 Lucro Real Não Cumulativo
01 06 - Crow Embalagens - CEMA Teresina PI 33.174.335/0012-38 Lucro Real Não Cumulativo
01 07 - Crow Embalagens - CEMA Rio Verde GO 33.174.335/0013-19 Lucro Real Não Cumulativo

2. Descrição do Sub-Processo

Faturamento pode ser definido como a receita bruta decorrente da venda de mercadorias, de mercadorias e serviços
e de serviços de qualquer natureza.
Estrutura do módulo:
 Controle de Clientes
 Cadastro de Produtos
 Cadastro de Clintes x Produtos
Controle de Vendedores
Manutenção da carteira de pedidos de vendas
Listagem dos pedidos de vendas
Liberação automática, considerando crédito e estoque
Documentos de saída
Duplicatas
Controle de comissões
Integração com o financeiro
Implantação de títulos automaticamente na emissão da nota fiscal
Liberação de crédito
Integração com Estoque/Custos
Liberação de Estoque
Baixa no estoque físico-financeiro
Custos nos produtos vendidos e sua rentabilidade

3
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Integração contábil
Lançamentos Contábeis Automáticos
Impressão de DANFE
Integração com ACD

2.1 – Cadastro de Cliente

Principais Objetivos:
Cliente é a entidade que possui necessidades de produtos e serviços a serem supridas pela sua empresa.
Manter um cadastro de Clientes atualizado é uma ferramenta muito preciosa para usuários dos mais diversos
segmentos. Desde o microempresário até multinacionais, a partir do momento que uma empresa vende um produto
ou um serviço, seja para um consumidor final, para um revendedor ou produtor, é necessário conhecer, e manter o
conhecimento sobre quem são as entidades com as quais se está negociando.
É possível classificar os clientes em cinco tipos: Consumidor Final, Produtor Rural, Revendedor, Solidário e
Exportação. Essa divisão foi feita em função do cálculo dos impostos, tratado de forma diferenciada para cada tipo.
Conceitualmente, a maioria das vezes em que é emitido um Documento de Saída, o destinatário é considerado um
cliente, independentemente do tipo que ele possua, ou da denominação que a empresa tenha determinado para ele.
É importante que o cadastro de clientes esteja o mais completo possível, possibilitando assim o máximo de
informações a serem fornecidas e controladas pelo sistema. Quanto mais completo estiver o cadastro, mais
facilidades o usuário terá no sistema.
Alguns campos, obrigatórios ou não, deveriam ser preenchidos sempre, pois são campos que permitem ao sistema
gerenciar informações importantes.

Cenário atual:
1. O cadastro de um cliente é iniciado no departamento Comercial que insere os dados básicos da pasta
cadastral. O cliente nasce liberado para movimentações.
2. Para cadastrar o cliente, a Crown consulta dados nos no site da Receita Federal ou Sintegra de forma
manual.Na sequencia o departamento Financeiro preenche a pasta de Créditos, classe, risco e
vencimento.
3. Um fornecedor está sendo cadastrado como cliente também para casos de devolução de Compras.
Neste caso quem solicita seu cadastro é o Departamento de compras.
4. Na pasta Fiscal o campo A1_GRPCLI está sendo usado para definir grupos de um cliente devido ao
cadastro não esta sendo usado o campo Loja para definir clientes do mesmo grupo.
5. O limite de crédito dos clientes é pelo Grupo do cliente e não por filial. A Crown tem um controle em
Excel onde é calculado o limite global do cliente.
6. Não tem WorkFlow de envio de sequencia de responsáveis para o cadastro.O cadastro encontra-se
compartilhado entre filiais.
7. Existe na Crown um cadastro de Adicionais de Clientes que trata informações como TES, Condição de
Pagamento e Tipo de Frete.
8. Exite rotina customizada para bloqueio de clientes não faturados a cada virada de ano.

Cenário proposto:

4
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

1. A Totvs sugere que seja elencado as áreas responsáveis pelo cadastro e separando em pastas os dados de
cada área para preenchimento. Campos obrigatórios deverão ser avaliados. O cadastro pode nascer
bloqueado deixando uma área responsável pela sua liberação.
Neste processo caso identificado que as customizações do mesmo devam permanecer, os fontes envolvidos
serão revisados pelo time Totvs.
(*Item 01WishList Faturamento).
O cadastro do cliente nascerá na Astren, e a mesma fará esse Mashup.
Poderá ser usado a funcionalidade Mashup para atualizar alguns dados do cliente através dos sites da
Receita Federal.(*Item 02WishList Faturamento)
2. Não é necessário cadastrar um cliente como fornecedor e vice versa. O Protheus faz o tratamento
automático buscando o cadastro correto através do tipo de pedido de venda ou de compra ou nota fiscal.
3. Foi identificado o uso de campo padrão do sistema usado em Exceções Fiscais para identificar agrupamento
de clientes. O risco é se a Crown necessitar usar Exceções Fiscais, nao terá a possibilidade de usar campo
como filtro. Deverá ser reavalidado o agrupamento de clientes, para que sejam tratados com a logica de
Codigo e Loja padrões do sistema.(*Item 06 WishList Faturamento)
4. O Protheus calcula o limite de crédito para todas as lojas do Cliente, desde que o cadastro esteja estruturado
por Código e o Risco seja igual para todos eles. Deve-se ajustar o parâmetro MV_CREDCLI para realizar essa
tratativa. Exemplo de cadastro utilizando conceito de loja:
Cliente: COCA-COLA
001123 – 01 – COCA-COLA FIL 01– 3000,00
001123 – 02 – COCA-COLA FIL 02
001123 – 03 – COCA-COLA FIL 03.
A Crow usará a classificação das classes tipo A, B,C,D – Para bloqueio dos clientes no momento de geração de
Pedidos de Vendas, tanto manualmente ou via integração.
Análise dos Créditos dos clientes - A, passará os B,C,D serão bloqueados iniciando um processo no FLUIG.
Para este item no tratamento da precificação de clientes sugere-se utilizar a amarração de tabela de preço
vinculada ao cliente visto que no ambiente Crown as tabelas de preço são geradas para expecificamente para
cada cliente.
Será utilizado o campo A1_GRPVEN para identificar o agrupamento de clientes.

5. A Totvs sugere que seja usado o Fluig como parte do processo para que o cadastro possa ser preenchido de
forma sequencial pelas áreas responsáveis(*Item 01 WishList Faturamento).
6. Caso o tratamento deste cadastro seja somente as informações referentes a TES, Tipo de Frete e Condição
de pagamento orientamos a utilização dos campos e rotinas padrões para tratamento dos mesmos como TES
Inteligente, Tipo de frete no cadastro do cliente pondento realizaralteração do tipo de frete no pedido de
venda e Codição de pagamento vinculada na tabela de preço.
(*Item 03WishList Faturamento)
7. Esta rotina não existe no padrão do sistema e a mesma deverá ser mantida. (*Item 10 WishList Faturamento)
8. Emabalagens – No cadastro de cliente será inserido um campo para o controle informativo se o Cliente
possui Embalagem ou Não. A1_XEMBAL.
9. Cliente Exportação: o TES deve-se ser alterado manualmente no Pedido de Venda.

Obs.: Customizações inerentes ao cadastro do cliente inerentes ao processo serão mantidas e revisadas pelo time
Totvs.

5
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

2.2 – Cadastro de Produtos

O cadastro de Produtos contém as principais informações sobre produtos e serviços adquiridos, fabricados ou
fornecidos pela empresa, realizando o controle desses produtos em todos os módulos do Sistema.

As empresas exclusivamente comerciais tem, possivelmente, apenas produtos para revenda e materiais de consumo.

As empresas industriais tem, possivelmente, todos os tipos de produtos ou materiais utilizados para produção:
Produtos Acabados, Produtos Intermediários, Matérias-primas, Materiais de Consumo e Outros inclusive Mão de
Obra ou Serviços Agregados a fabricação que devem compor o custo do produto final.

A definição de produto é genérica e abrange muitos conceitos que podem variar de acordo com o ramo de atuação
da organização, bem como o módulo utilizado.

Produto Tampa: o TES deve-se ser alterado manualmente no Pedido de Venda.

Exemplo:

Módulo Produto
Oficinas Peças
Gestão Ambiental Resíduos
Gestão de Transportes Combustível
Transporte Municipal

Cenário atual:

Serviços estão sendo cadastrados com código genérico, código inteligente. O cadastro está exclusivo e há muitas
reclamações que os usuários devem cadastrar várias vezes. Tem um campo “Bloqueia OP” (Ordem de Produção), que
é por filial. 

1. Cliente questiona se o Cadastro de Produto não poderia ser compartilhado pois tem que cadastrar o
produtos6 vezes.
2. A pasta de “Impostos” do cadastro não estápreenchido totalmente.
3. Existe um cadastro de Grupo de produtos customizado preenchido pelo Comercial, mas é da área comercial.
Tem campos inativos para impostos que eram usados para calcular a tabela de preços.
4. Vincular produto x cliente x planta para geração da tabela de Preço de venda. Tem produtos que são usados
para vários clientes. Todo produto precisa estar na tabela de preços quando for PA (Produto Acabado) e
tampa.
5. Atualmente existe Workflow para cadastramento de produtos.
6. Atualmente existe customização de Cadastro Adjacentes de Produto e Produtos Adicionais para tratamento
de Código, Tamanho e conta contábil para diferenciar tamanhos de latas e Sub-Grupos de Produto.

Cenário proposto:

6
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

1. O cadastro poderá ser compartilhado desde que demais áreas, processos e customizações envolvidas
estejam alinhados entre si.
A Totvs sugere usar o Fluig como parte do processo para que o cadastro possa ser preenchido de forma
sequencial pelas áreas responsáveis. Campos obrigatórios deverão ser avaliados.
2. Deverá ser feito um saneamento de cadastro e ter como processo de usuários a manutenção preventiva e
efetiva dos mesmos.
3. Reavaliar a necessidade do preenchimento destes campos uma vez que estão inativos e a tabela de preço de
venda não atende mais os requisitos da empresa conforme informação passada pelos usuários.
4. Este processo deverá ser revisto junto com a nova tabela de preços de venda.
A Crown entende que a Tabela de Preços de Venda não atende mais os requisitos necessários para as
operações.
5. Atualmente existe um projeto interno Crown de gestão de cadastros de produtos(Astren), caso estas
integrações e gestão do cadastro não seja executada por esta nova ferramenta os processos de workflow
deverão ser mantidos. (*Item 14 WishList Faturamento)
6. Sugerimos a criação de tabelasgenéricas(SX5) para cadastramento destas informação centralizando no
cadastro do produtoos itens anteriormente controladas por esta customização. (*Item 15-18WishList
Faturamento)
Obs.: Existem campos customizados no cadastro de produto que caso não possamos substitui-los por campos
padrões os mesmos deverão permanecer no ambiente Crown e customizações envolvidas nestes campos deverão
ser revisadas e ajustadas.(*Item 07 WishList Faturamento)

2.3 – Cadastro de Condição de pagamento

Principais Objetivos:
As negociações de compras e vendas de produtos ou serviços, normalmente, se baseiam nas condições de
pagamento. Elas determinam como e quando serão efetuados os pagamentos, especificando datas de vencimentos,
número e valores das parcelas, descontos e acréscimos.
O Protheus permite a composição de diferentes condições de pagamento, considerando três campos principais:
"Código", "Tipo" e "Cond. Pagto". Sendo que a base da condição é determinada pelo campo "Tipo".
Conforme o tipo da condição, o sistema irá tratar de forma diferenciada o conteúdo dos campos "Código" e "Cond.
Pagto.", o que permite a configuração de diferentes condições de pagamento, para aplicação aos pagamentos tanto
de fornecedores como de clientes.

Cenário atual:
1. O cliente tem a tabela de Condição de Pagamento numerosa porque antes era exclusiva por planta e em
2016 unificou os cadastros de clientes, fornecedores e condição de pagamentos. Em Compras o usuário
utiliza qualquer condição de pagamento, onerando o Departamento Financeiro que tem de arrumar os
vencimentos dos títulos e fluxo de caixa.
A Crown entende que o cadastro deveria ser separado para usuários de Faturamento e Compras, uma vez
que hoje todos acessam e usam os códigos.
2. Cadastro está compartilhado entre filiais.

Cenário proposto:
1. Visto que a equipe Crown já realizou uma revisão do tema , em projeto iremos apenas monitorar o processo
de condição de pagamento que ficará sob responsabilidade da área financeira.
2. Será mantido o compartilhamento do cadastro.

7
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

2.4 – Cadastro de Vendedores/Representantes

Principais objetivos:
O Cadastro de Vendedores é imprescindível para realizar o cálculo e controle das comissões sobre as vendas dos
produtos de uma empresa, em que pode ser criado um critério próprio de identificação para cada vendedor,
possibilitando a divisão de vendedores por região ou por promoção de um produto.
Todos os impostos que incidem sobre a comissão são controlados pelo sistema e serão informados em campos
específicos.

Cenário atual:
Não tem vendedores. Um recurso cuidava das vendas, porém hoje não atua mais nesta atividade.
Consequentemente não há comissões.

Cenário proposto:
O Protheus possui cadastro de vendedores econtrole de comissões e poderão ser usados quando a Crown tiver esta
necessidade.

2.5 - Cadastro Tabela de Preços

Principais Objetivos:
Esta rotina permite a configuração e manutenção de uma Tabela de Preços para compor diversas formas de
comercialização, considerando, para um ou diversos produtos, condições específicas de venda, utilizando critérios
diferenciados, como região e faixa de preços.

Para compor os descontos e o preço de venda que serão aplicados, o sistema tem como referência o preço do
produto, que é definido no seu cadastro, através do campo Preço Venda.

Exemplo de aplicação de uma Tabela de Preços:

Item Cód. Desc. Produto Preço Preço de Vlr. Fator Estado Faixa
Produto Base Venda Desconto

001 000001 Computador 1.000,00 900,00 100,00 0,90 SP 500,00

002 000001 Computador 1.000,00 850,00 150,00 0,85 SP 999.999,99

 

No exemplo acima, o produto Computador terá um desconto de 10% sobre seu preço base quando
comercializadas 500 unidades, no Estado de São Paulo. Acima de 500 unidades, terá um desconto de 15%.

Além de definir os itens da Tabela, conforme exemplificado acima, o sistema permite determinar os
períodos de vigência, por intervalo de data e hora, assim como também, especificar uma condição de
pagamento.

8
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

As Tabelas de Preços são sinalizadas por uma legenda, sendo:

 Tabela Ativa - As tabelas ativas são aquelas que estão dentro do período selecionado.
 Tabela Inativa - Uma tabela torna-se inativa quando sua data de vencimento for ultrapassada.
 Tabela Ativa Especial - Indica que o vencimento da tabela foi alterado manualmente pelo usuário.
Cadastramento de promoções:

A tabela de preço (DA0 e DA1) tem a possibilidade de registrar as seguintes informações:

DA0 – Cabeçalho
• Data e hora inicial / Data de hora final de validade
• Tipo de hora – Único / Recorrente
• Tab. Ativa – Sim / Não

DA1 – Itens • Produto ou Grupo de Produtos

• Preço Base (retorna automaticamente o valor praticado no campo Preço Venda)
• Preço de Venda (valor que efetivamente será praticado na venda)
• Desconto / Fator (serão aplicados no campo Preço de Venda)
• Ativo (se este produto está ativo na grade)
• Estado
• Tipo de Operação (Estadual / Interestadual e etc.)
• Faixa / Moeda
• Vigência

Cenário atual:
A formação de preços é Feito em Excel - baseado em 4 indexadores: 2 em dólar e 2 em Reais: custo standard, custo
adicional por tipo de material, frete, margem. Os valores são em dólar. SKU é o produto individual. O grupo de
produtos é separado por tamanho de lata e insumo especial.
A Tabela é por cliente. Os valores são digitados na tabela centralizada manualmente, em média 20 produtos por
tabela. A rotina de Tabela de preços tem um botão de Gerar tabelas filhas paras as outras filiais. Este botão puxa
informações dos dados da tabela de Clientes Adicionais e dependendo da Tes cadastrada ele adiciona os impostos da
Tes. Para clientes pequenos o usuário copia a tabela e gera outros alterando o Ptax médio, e altera os valores
individualmente. O ptax cadastrado na tabela é o que foi acordado com o cliente. O pedido de venda é em Reais
convertido pela ptax da tabela de preço de venda. O preço do SKU é por grupo de produtos. A tabela de preço de
venda calcula em função da Tes cadastrada nela somando icms, pis e cofins. A Tes da tabela de precos é da lata. A
Tes da tampa é outra. Para exportação a Tes vem errada porque na customização tem uma validação que se o grupo
é nacional a rotina calcula impostos e não trata exportação de produtos sem impostos.

1. Não era necessário várias tabelas de precos de venda pois o preco é base dolar. Bastava uma tabela única
para todas as filiais ,e ao incluir o pedido de venda, quando há a conversão a Tes inteligente calcular os
impostos corretamente. Desta forma não seria necessário Tes na tabela de preco, no cadastro de clientes
adicionais, etc.
2. A tabela de preços de venda é por Cliente. Na tabela de preços tem um código para Tes. A tabela é
customizada (Tabela ZR) e tem 2 formas de gerar: explodindo (rotina) pelo código “mãe” do cliente e suas
filiais e, outra que entra na planta (filial) e insere manualmente.
3. A tabela de precos tem como base a moeda Dólar (D-1 para exportação que não está funcionando a
atualização automática). Uma outra rotina calcula o preço em Reais em função do cliente e da Tes para
vendas nacionais. Na tabela tem campos para informar a Tes, condição de pagamento, Cif/FOB (estes

9
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

campos tem em vários lugares - clientes, adicional de cliente, tabela de preço de venda). A Tabela de preços
de vendas customizada soma icms + pis e cofins para formar o preco de venda final, tendo limitações por
plantas. A tabela tem que ser incluída 6 vezes porque sao 6 filiais. O departamento Comercial entende que
não seria responsabilidade da área o preenchimento da Tes e o pedido de venda se perde (puxando Tes
errada, conflito CIF FOB, Condição de Pagamento).
4. Na mesma tabela pode ter vários grupos de produtos, caso o cliente inclua um produto novo, a tabela fica
travada para aprovação. A Crownentende que a aprovação seja somente se o grupo for diferente dos demais
já incluídos na tabela não bloqueando para qualquer produto.
5. Existe um WorkFlow para aprovação da tabela de precos e o mesmo não é interativo, ficando por conta do
usuário controlar a troca de emails e aprovar manualmente.
6. Para operações de Remessa de armazenagem está sendo obrigatório o usuário a inserir o produto na tabela
de preços de venda antes de inserir o pedido de vendas.
7. O frete informado na tabela de preço de vendas deveria respeitar o incoterme cadastrado na tabela de
precos. Neste caso o faturamento não está respeitando alterações do pedido de venda. Por exemplo: na
tabela de preco de vendas a modalidade de frete estáCIF e no pedido de venda esta FOB. O sistema continua
calculando o frete sem respeitar a mudança do dado no pedido de venda.
8. A Tabela de preços de venda encontra-se exclusiva para filiais.
9. Existe relatório de aprovações de tabela de preços.

Cenário proposto:
Iremos reestruturar a tabela de preço Crown centralizando as informações como:
 PTAX
 Condição de Pagamento
 Código do Cliente
 Aprovador
 Grupo de Produtos
 Valor de SKU em Reais(Com valores finais de venda.)
 Valor de SKU em Dolar(Informativo para composição do valor.)
Com isso as infomações serão centralizadas nas tabelas padrões DA0 e DA1 com funcionalidade de
importação XLS para atualização de dados e ou criação de nova tabela de preço.
Refente a tabela de fretes deveremos padronizar e gerar a condição de manutenção da mesma para
utilização dos dados de frete na composição do processo de venda e construção da tabela de preço, esta
tabela é customizada visto que o sistema não atende o modelo adotado pela Crown.
Posteriormente será realizado levantamento detalhado do item para construção da customização e suas
funcionalidades. (*Item 11 WishList Faturamento, item contido em MIT046.)

Aprovações das tabelas de preço serão realizadas via Fluig e manterão suas regras atuais ou seja o usuário
que irá criar a tabela não será usuário aprovador. Este detalhamento está contido nas MIFS de Fluig.(*Item
13 WishList Faturamento.)

Para relatórios de aprovação das tabelas de preço deverá ser desenvolvido pela área de TI Crown através da
ferramenta TotvsReport. (*Item 16 WishList Faturamento)

10
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Definição dos Campos da Tabela de Preço:

Valor PTAX - Valor negociado com o Cliente em US$ - PTAX - PRICE US$ --> TABELA DE PREÇO - DA1_XPRBAS

Valor Preço Base - PREÇO BASE --> TOTAL PRICE - DA1_PRCVEN

PREÇO TEM INCIDÊNCIA DE FRETE E ADICIONAIS NO PROD(FOSCO)

DA1->XCHARG --> DEVE-SE SER SOMADO AO VALOR DO DA1_PRCVEN
DA1__XLFRE --> VALOR DO FRETE NEGOCIADO --> CIF É INSERIDO NO VALOR.

O Preço de Venda, terá o acréscimo dos valores de impostos na Geração da NOTA FISCAL

Atenção: O Cliente é Exclusivo por FILIAL, porém a Tabela de Preço é Compartilhada. Analisar a tratativa.

2.6 – Cadastro de Transportadora

Principais Objetivos:
Nessa rotina devem ser cadastradas as transportadoras com as quais a empresa trabalha.
O cadastro de transportadoras pode ser utilizado nas rotinas:
Pedido de Venda - Informar a empresa que será responsável pelo transporte, tipo do transporte e valores.

Documento de Saída - Quando informada a transportadora e o tipo de frete (CIF ou FOB) no Pedido de Venda,
na geração do documento de saída, o Sistema faz os tratamentos dos valores referentes ao frete. Estes valores
podem ser verificados na Consulta às NFS de Saída.

Nos ambientes de Compras e Estoque/Custos, o sistema pode realizar a geração das notas fiscais de
conhecimento para pagamento de frete, além de fazer todos os cálculos de impostos.

Para gerar Notas de Conecimento de Frete, a transportadora também deverá estar no Cadastro de Fornecedores.

Cenário atual:
Não foi reportado dores no cadastro de Transportadoras.

Cenário proposto:
Usar a funcionalidade de cadastro padrão.
Foi solicitado pela Crown a possibilidade de executar atualização dos cadastros automaticamente conforme
utilização dos Mashup, este item foi adicionado na MIT046.

2.7 – Comissões

Principais Objetivos:
O Protheus efetua o controle de comissões, desde que predeterminados os percentuais no Cadastro de Vendedores,
no Cadastro de Clientes e no Cadastro de Produtos. As comissões são tratadas como obrigações a pagar pelo sistema
e calculadas automaticamente na preparação e geração das notas fiscais ou na implantação de um título a receber.
Para o cálculo das comissões o sistema verifica o percentual de comissão atribuído ao Cadastro do Vendedor, entre
emissão e baixa, sendo que aquele referente à baixa somente será calculado após o título a receber ter sido baixado.

11
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

O valor base da comissão é calculado considerando os dados do Cadastro do Vendedor, no que se referir a Frete, IPI,
ICMS, ICMS Retido e ISS.
O sistema permite alteração nas comissões de vendas calculadas e a atualização da data para pagamento das
comissões, o que viabiliza o controle daquelas que já foram pagas.
Cenário atual:
Não há pagamento de comissões

Cenário proposto:
Não haverá tratamento de comissão no Protheus.

2.8 – Pedido de Vendas

Principais Objetivos:
O pedido é considerado peça fundamental para o faturamento da empresa, pois determina as vendas e demanda de
produtos e serviços. É uma confirmação da venda e, quando há a necessidade de formalização das necessidades do
cliente em relação ao que sua empresa pode lhe oferecer, é o principal instrumento de efetivação deste
atendimento.
Existem vários tipos de pedido de venda:
N = Normal

D = Devolução
Quando ocorre uma devolução de mercadoria, é necessário que seja impressa uma "Nota de Devolução". Assim,
deve-se gerar um pedido de venda do tipo "D". Por isso deve haver a informação do número da nota fiscal de
origem, no campo respectivo, via tecla [F4]. O código fiscal não necessariamente deve ser respectivo às devoluções.

C = Complemento de preço
Quando existe a necessidade de complementar o preço de alguma nota fiscal, o campo "Quantidade" dos produtos
deve estar em branco. O tipo deve ser "C". Os demais dados devem estar idênticos à nota fiscal original.

P = Complemento de IPI
Este tipo de nota é necessário quando a alíquota ou o valor do IPI da nota fiscal for menor do que o devido. O valor
do IPI sempre será o total do pedido.
No Livro Fiscal, o valor do IPI será apresentado na coluna de "Tributado", independente do que for definido no TES
(Tipos de Entrada e Saída).
O procedimento de preenchimento deve ser:
Tipo = "P";
Código de Produto = código do produto original;
Quantidade = "0" (zero).

I = Complemento de ICMS
Este tipo de nota é necessário quando a alíquota ou o valor do ICMS da nota fiscal for menor do que o devido. O
valor do ICMS sempre será o total da nota fiscal, independente da definição da pergunta "Calcula ICM (S/N)" do
Cadastro de TES.
O valor do IPI não será calculado. No Livro Fiscal, o valor do ICMS será apresentado na coluna de "Tributado",
independente do que estiver definido na pergunta "Livro Fiscal ICM" do Cadastro de TES.
Não é gerada duplicata. O procedimento de preenchimento deve ser:

12
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Tipo = "I"; Código de Produto = código do produto original; Quantidade = "0" (zero).

B = Utiliza Fornecedor
Quando é enviado determinado produto para guarda/concerto/beneficiamento em terceiros, o sistema disponibiliza
um controle sobre estas quantidades. O sistema controla a quantidade de terceiros em poder da empresa e a
quantidade da empresa em poder de terceiros.
Para efetuar o controle de poder de terceiros, é necessário que os ambientes de Faturamento, Compras e
Estoque/Custos estejam implantados.
Em poder de terceiros, temos dois casos básicos:

Cenário atual:
A Crown utiliza o CRM – PLOOMES que registra somente a prospecção.
As vendas são feitas por contratos com clientes com programação de entregas (feito em Excel) .
O cliente da Crown atualmente só acompanha o estoque dele (venda casada) via email. O cliente gostaria de gerar
pedido de venda e acompanhar o mesmo via portal do cliente. Não é um problema, existe projeto futuro para o
cliente acompanhar o pedido de venda pelo sistema Innout e demonstrar o carregamento real com a transportadora.

Não há regras de descontos, comissões ou vendedores.

A Crown têm 4 grandes clientes, classificados como Risco A, que têm uma programação de produção controlada em
Excel. Basicamente os pedidos de vendas deste clientes são recebidos e imputados automaticamente no Protheus
viaWebSite O2P.Os pedidos de venda nascem liberados e geram ordens de separação que são as Dt´s (rotina
customizada que faz separação e montagem de carga).

Para clientes pequenos foram desenvolvidas rotinas para tratamento de liberação de limite de créditos e podem
conflitar com as customizações que foram desenvolvidas para os clientes grandes.
Não há liberação de pedido de venda. Os produtos são personalizados então para produzir o cliente tem que pagar
antes (quando exige RA ou o cliente tem limite de crédito disponível). Quando ocorre de não ter o produto, ou faz
alteração no pedido de venda ou cancela o pedido de venda.

As plantas (filiais) têm que estar homologadas para o cliente. No produto tem um código de lote e o cliente consegue
ver se a planta está homologada ou não. A Crown tem que cadastrar o mesmo produto em várias plantas. Na lata
tem controle de rastreabilidade: planta que fabricou, lote.

No caso de transferência de mercadorias entre filais de clientes que exigem rastreabilidade, a operação só pode
ocorrer porque haverá uma venda casada e a entrega será na filial que sairá a nota fiscal e a mercadoria.
Para produtos que exigem rastreabilidade de planta homologadas não pode incluir automaticamente os códigos nas
demais plantas.

Pedidos de Vendas incluídos automaticamente:

1. O cliente envia uma planilha XLS com as necessidades para a Crown. A Crown através de um sistema
especifico Web O2P, faz updload deste arquivo para o Protheus gerando um pedido de venda. Para qualquer
cliente. Após a inclusão automática do pedido de venda, é feito o "Planejamento de cargas" através do
INNOUT - Sistema Web para transporte logístico. Este devolve o planejamento através de um cadastro de DT
pronta para o Protheus, que separa os pallets através do ACD. GAPID006

13
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

2. (PIA) Para clientes pequenos, os mesmos devem fazer um depósito adiantado para que seja faturado seu
pedido. Na hora do faturamento, acontece de haver quebra de limite de crédito , ou o saldo não bate com o
Protheus, ou o cliente não fez o recebimento antecipado.
3. Liberação de crédito de clientes e estoque esta bloqueando somente quando os DT'sestão sendo separados
pelo leitor para clientes pequenos. Mesmo quando não tem estoque ele deixa montar as DTs. Para clientes
grandes não há problemas, pois estes são risco A. Crown não usa a rotina de liberacao de pedido de venda
somente para agilizar o processo. Para a Crown, o sistema não deveria permitir que seja incluido as Dts sem
antes verificar se tem crédito e estoque no sistema.
4. Na rotina customizada PIA tem a operação de cancelamento de Nota Fiscal. Esta funcionalidade não volta
todas as operações. Por exemplo o saldo de estoque não retorna, fazendo que o sistema pegue saldo que
não deveria.Tem casos em que o cliente gera nova ordem de producao somente para gerar novas etiquetas,
distorcendo saldos.
5. Armazenamento Externo - Customização denominado PIA - sistema que faz transferência dos saldos de
produtos “PA” para os armazenamentos externos. Quando tem uma venda para produto que está no
armazém externo. Este sistema gera a a devolução de mercadoria e geração do pedido de venda do Protheus
para venda.
O Pia faz uma nota fiscal de devolução simbólica e o arquivo Xml é colado numa pasta FTP da Crown (há
reportes que o XML traz cfops indevidos). A Crown verifica que tem um XML e gera o pedido de venda e a
nota fiscal de saída.
Este estoque é tratado como almoxarifado especifico e não como poder em terceiros. Quando tem muitos
processos ele se perde. Tem uma rotina no Protheus que lê o XML e fatura nota fiscal. Quando tem muitos
XML colados no ftp a rotina se perde. O Pia controla 60% do fluxo de faturamento. Os saldos do estoque nao
refletem a realidade do Protheus e saldo físico.

6. Remessa para armazenagem também são incluídos automaticamente através do ACD. Neste caso, a nota
fiscal também é gerado automaticamente, ficando pendente a transmissão de nota fiscal ao Sefaz.

Pedidos de Vendas incluídos manualmente:

7. Para pedidos de vendas de tampas é incluído manualmente pelo usuário e tem liberação via rotina de DTs.
A Crown entende que a geração de nota fiscal poderia ser automática.
8. Pedidos de Venda remessa para transferência entre filiais, consertos, devolução a geração de nota fiscal é
manual e a Crown entende que poderia ser automática.
9. Para sucata, o cliente pode pagar depois. O pedido de venda é liberado manualmente, pois o cliente pesa e
paga depois . O risco é o C e limite 0. O sistema bloqueia todos esses pedidos. Não existe uma dor neste
processo.

10. Para exportação também gera DT e gera a nota fiscal automática, não tem problemas em limite de crédito
pois os clientes são classificados como Risco A. A venda é casada. A nota fiscal emitida é em Reais convertida
pelo taxaptax -1. A nota fiscal atualiza estoque e financeiro. Sistema não atualiza o cadastro de moedas
automaticamente. A Crow tem rotina que atualiza o cadastro de moedas mas está falhando. O
departamentoFinanceiro está fazendo variação cambial manual.
11. O faturamento pelo operador logístico a remessa para armarzenagem, devolucao simbólica são executados
de forma manual. É uma simulação de operaçãotriângular, porém é faturado direto pelo operador logistico
para o cliente tirando do almoxarifado interno de terceiros. Consequentemente o saldo de estoque se perde
nos controles de almoxarifados internos e não bate com o controle de terceiros padrão do Protheus tabela
Sb6. O operador logístico não tem o controle de endereçamento dando diferença nas etiquetas.
Da mesma forma o processo de triangulação ocorre entre filiais do grupo Cronw com problemas de saldo em
poder de terceiros e problemas vinculados as operações fiscais como CFOPs indevidas ao processo.

14
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

12. Transferência de pallets de produtos entre plantas. A Crown tem 6 filiais. Quando é executada
transferências de materiais entre filiais, o estoque fica distorcido visto os problemas reportados de
configurações de TES. Para produtos PA, as etiquetas dos produtos é por filial e sequencial. A numeração
está conflitando entre filiais. O sistema transfere o custo, porem o custo da etiqueta quando conflita impacta
no custo.
13. Quando tem que cancelar uma nota fiscal, o usuário faz todo o processo de cancelamento sem validação do
Sefaz se é permitido ou não.
14. A inclusão da pré nota de entrada é feito manual, pois não funciona a integração do XML automático (Totvs
Colaboração).
15. Pedido de vendas de Tampas para movimentações de transferências e faturamento de
Uberlândia(Entreposto)existe customização para tratamentos fiscais.

Cenário proposto:

A Totvs entende que a automação para integração com o Protheus pode permanecer até a inclusão do pedido de
venda. A integração do sistema O2P para inclusão de pedidos de venda deverá ser revisada. Com isso ficou definido
que haverão ajustes a serem realizado no O2P para tratamento de consultas de estoque devido as mudanças a
serem realizada com a unificação de códigos de produto e ou armazéns de estoque. Estes pedidos serão integrados
com parâmetro padrão de tipo de operação para “start” das configurações de TES inteligente, as mesmas serão
ajustadas via webservices no momento de integração entre InOut e geração de carga no OMS, este item foi gerado
como GAP MIT046.(GAP ID06 - Integração ACD x Inout x OMS)
1. Os clientes que necessitam de adiantamento para faturar, é padrão do Protheus o uso de condição de
pagamento com adiantamento. Para tratar a avaliação de crédito dos clientes que serão integrados de
acordo com as suas classificações A,B,C,D - GAPID031 – Avaliação de Crédito.
2. A rotina nao é padrão do Protheus e deve ser revisto o processo de inclusão e liberação dos pedidos de
venda não permitindo liberar o crédito e estoque sistêmico no momento em que esta separando o estoque
para carga do caminhão. Para clientes com grau de risco poderá ser usado condição de pagamento com
adiantamento. A montagem de cargas será gerada no OMS através de Romaneio e Carga – GAPID006 –
Integração InnoutxACDxOMS - OMSA200.
3. Sugere-se que seja usado o processo padrão do módulo de Faturamento para cancelamento de notas fiscais
retirando os fontes ao relacionados ao PIA para que sejam atendidas mantendo a integridade das
informações.
4. Sugere-se que seja usado o processo padrão do módulo de Faturamento para remessas de armazenagem,
entrada de nota fiscal de devolução simbólica, geração de nota fiscal de venda usando as tabelas padrões
para que sejam atendidas as obrigações legais e mantenha-se a integridade das informações. Poderá ser
customizada a automação entre os processos. A importação do XML deve ser feita via Totvs Colaboração
para que a nota fiscal classificada. Há reportes que outras notas fiscais entram sempre com a mesma cfop,
onerando a escrituração fiscal. Para as NFs de Complemento, Devolução a exclusão seguirá pelo padrão
protheus.
Usuário executará via o Módulo ACD o cancelamento das NFs de Venda/Remessa

5. É possível habilitar a transmissão pelo AutoNfe.

15
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

- Processo Triangular de Venda - Gerando um NF de venda e uma NF de Remessa - Operação gerada através
de customizações do PIA/Dts. Não é o processo padrão do Protheus, gerando uma Nota Fiscal por vez.
Ocorrência: Deverá ser aberto um GAP para tratamento em desconsiderar Tabela de Preço para produto de
PA na Operação Triangular.
Observação: Através da Etiqueta que é atualizado o saldo em estoque no endereçamento.
- Importação de XML do Pedido de Venda, será efetuada pelo parceiro EZ4

6. Este processo poderá ser revisto com as customizações pelo OMS.

7. O cliente pode utilizar a funcionalidade "PreparDoc" diretamente do Pedido de Vendas desde que o pedido
esteja apto para geração de nf.
8. Não há dor.
9. As consultas efetuadas em sites como Banco Central, Receita Federal, etc podem sofrer instabilidades nos
acessos. O Protheus tem a rotina de Mashup para atualização do cadastro de moedas ou fazer a atualização
manualmente. Para variação cambial o título deve nascer em outra moeda no Financeiro.
10. A Totvs sugere que seja feito revisão de processo do controle de estoque e fiscal da Crown pois as operações
devem estar aptas para a geração de obrigações fiscais e contábeis que exigem controle de Estoque e Poder
de Terceiros. Deverá ser revisto as customizações do ACD devido a montagem de carga com OMS
customizado, para operações triangulares sugere-se utilizar o processo padrão de emissão de pedidos e
notas para cobrir esta operação de forma manual, porém com isso a Crown poderá ter custos adicionais em
contratação de pessoas.Com tudo, caso o impacto destas contratações não sejam viáveis a Crown, sugerimos
revisão do PIA para tratamento desta operação Triangular tanto para operador logístico ou operações entre
filiais Crown.(*Item 04 WishList Faturamento).
Opção Triangular de Venda - Gerando um NF de venda e uma NF de Remessa - Operação gerada
através de customizações do PIA/Dts. Não é o processo padrão do Protheus, uma NF por vez

11. A Totvs sugere que seja feito revisao do processo de controle do estoque, etiquetas e do compartilhamento
de tabelas utilizando rotinas padrões.
12. Sugere-se que seja usado o processo padrão do módulo de Faturamento para cancelamento de notas fiscais
para que sejam atendidas mantendo a integridade das informações. Com o uso da rotina padrão poderá ser
implementado job para cancelamento de notas.
Habilitar o parâmetro de controle de consulta ao SEFAZ.

13. Poderá ser usado o Totvs Colaboração.

A Importação será efetuada pelo parceiro EZ4.(Não sendo utilizado o TC)

14. Para operações vinculadas a Urberlândia(Entreposto)o tratamento de impostos e garantia de tributações

como Manaus será realizada pela área fiscal no módulo SIGAFIS. (*Item 17 WishList Faturamento).
Tratamento dos cálculos de Impostos - Configuração do TES semelhante ao tratamento de MANAUS - Zonza
Franca, será efetuado via Módulo Fiscal.

Obs.: Para imputs de pedidos manuais o sistema continua com suas funcionalidades padrões e
disponibilidades de inserção de dados manualmente, atendendo assim operações de contingência e ou
operações manuais de input de pedidos.

Tratamento de Pedidos Manuais/Individuais

16
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

No momento da integração entre O2P e ERP, serão contemplados apenas 02 tipos de operações: 51
(venda direta) e 55 (triangular), onde no momento da inclusão da DT, seja ela manual ou PIA/INOUT, será
gravado o tipo de operação correta, por exemplo: Exportação, transferência entre filiais, etc).
Garantir que todas as funcionalidades de consulta do módulo de Estoque estejam integradas com o ERP.
Garantir que o novo desenho da análise de crédito feita para os pedidos oriundos do O2P sejam váidas
para os pediddos manuais.
Ajuste no layout de pedido de venda conforme e-mail enviado pelo Gean em 07/06/21.

PIA - FATURAMENTO

Após a Remessa e Retorno dos Produto PA é gerado um PEDIDO DE VENDA qua irá possibilitar. O
Faturamento do Depósito Externo via PIA ocorrerá após a geração de um DT do Tipo Externa/Mista. A
seleção das DT´s seguirão a consulta do Código/Loja do Cliente.

INTEGRAÇÃO O2P x INOUT x PROTHEUS

A liberação de crédito será pelo Fluig conforme desenvolvimento do GAPID06

Procedimento para CLIENTE D será efetuada a inclusão de PV com Condição de Pagamento - Com opção de
RA.

2.9 – Liberação de Pedidos

Principais Objetivos:
Esta rotina avalia o pedido de venda como um todo, analisando uma série de fatores, tais como:
Aprovação do crédito do Cliente;
Disponibilidade dos Saldos em Estoque;
Valor mínimo para o faturamento.

Os pedidos aptos a serem liberados são os que estão com status de Pedido de Venda em Aberto, representados pela
legenda verde na janela de manutenção da rotina, para posterior geração do Documento de Saída. O Sistema avalia
o crédito de acordo com as informações contidas nos campos referentes a Limite de Crédito do Cadastro de Clientes.
A partir destas informações, ocorrem os seguintes processos:
Quando um pedido não for liberado por crédito, o Sistema o bloqueia e não avalia o estoque, não empenhando
suas quantidades. O empenho somente ocorre quando o parâmetro MV_RESEST estiver ativado.
O parâmetro MV_BLOQUEI, quando ativado, submete todos os pedidos à liberação de crédito. Desta forma,
quando seu conteúdo estiver com F o crédito do cliente não será avaliado, independente do risco, mas caso não
tenha estoque disponível, este pedido estará liberado pelo crédito, mas bloqueado por estoque.
Quando um pedido é aprovado por crédito, e o estoque não estiver disponível, o Sistema realiza o bloqueio de
estoque.
Da mesma forma, quando há aprovação de crédito e há estoque disponível, o pedido estará liberado para a
geração do documento de saída.

Há duas formas de efetuar a liberação do pedido:

17
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Manual - Apresenta os dados originais do pedido para verificação em tela e permite definir a quantidade a
faturar, ou seja, a Quantidade Liberada, que pode ser igual à quantidade original, ou parte dela. Na liberação manual
os pedidos são liberados um a um.

Automática - Libera um grupo de pedidos conforme especificação dos parâmetros, tomando como base a
situação do crédito do Cliente, a disponibilidade do produto em estoque e a data de entrega do item do pedido.

Cenário atual:
Cliente não realiza a liberação de pedidos de venda. Os mesmos são liberados por customização quando incluídos
automaticamente por sistemas legado.

Cenário proposto:
Em virtude das dores reportadas pelos usuários de operações que geram os movimentos em ida mas não faz o
movimento da volta atualizando dados importantíssimos do sistema.

Rotinas Customizadas Integrando o PV/NF

Tratando de funcionalidade relevante no processo de faturamento, estoque, financeiro e fiscal.
A Totvs sugere que todas as customizações envolvidas sejam reavaliadas e/ou retiradas levando em consideração
que o ônus reflete diretamente nas áreas de Backoffice, responsáveis por obrigações legais e controles gerenciais.

Liberação do Pedido de Venda será efetuada pela DT

Pedidos de Inclusão de PV manual, analisar a configuração do F12, marcar como não sugerida.

Pedidos de Remessa em Poder de Terceiros

Revisão da TES com Controle de Saldos e Poder de/em, Dados Fiscais, Classificação dos Clientes

Pedidos Integrado
Pedidos de Origem O2P - Revisão da TES com Controle de Saldos e Poder de/em, Dados Fiscais , Classificação dos
Clientes.

2.10 – Liberação Estoque/Credito

Principais Objetivos:
Permite que o estoque de produtos solicitados no pedido de venda seja avaliado, analisando sua situação de
bloqueio. O Sistema soma os pedidos às reservas e verifica se há saldo suficiente para atender ao pedido em análise.
O pedido permanecerá bloqueado caso não tenha alteração nos fatores que o bloquearam.
Os pedidos reprovados apresentam códigos identificadores do fator gerador do bloqueio. Um pedido bloqueado
pode ser liberado manualmente, exceto se o código de bloqueio for 10 (pedido faturado).
Na janela de manutenção da rotina, os pedidos são apresentados segundo seu status, sendo:
- Liberado
- Faturado
- Bloqueado por Crédito
- Bloqueado por Estoque
No momento da liberação, tanto de crédito quanto de estoque, o Sistema atualiza os códigos de bloqueio dos itens
do pedido de venda.
Os códigos de bloqueio gerados pelo Sistema são:

18
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Bloqueios de Crédito
01 - Valor do Limite de Crédito
04 - Limite de Crédito Vencido
09 - Rejeição Manual de Crédito

Bloqueios de Estoque
02 - Bloqueio de Estoque
Há duas maneiras de liberar o estoque:
Automática: reavalia os conteúdos dos estoques;
Manual: analisa pedido a pedido, item a item quando houve bloqueio na liberação automática.

Cenário Atual:
O crédito para clientes pequenos somente é possível via customização onde após verificar que foi feito um
Adiantamento a Receber pelo cliente, o limite de crédito do mesmo é alterado conforme o valor depositado.
O ACDcustomizado no momento da separacao faz a validação do crédito do cliente e libera o pedido. No entanto, foi
destacado pelos usuários que inúmeras vezes esta liberação não ocorre por falta de recebimento do cliente ou fallha
na customização.

O estoque não tem problemas de liberação pois independente do tamanho do cliente, os produtos são
personalizados e produzidos para determinado cliente. Quando ocorre de não ter o produto, ou faz alteracao no
pedido de venda ou cancela o pedido de venda.

Cenário proposto:
Liberação de estoque:
Segundo usuários, não há problemas em liberação do estoque pois os mesmos são produzidos personalizados.
Quando ocorre de não ter um produto vendido para mais de um cliente, ou é feito alteração do pedido ou cancela o
pedido de venda.No entanto, foi identificado nas entrevistas problemas em saldos de estoque, saldo em terceiros,
falta de integração nos movimentos. Desta forma, sugere-se reavaliar o processo e retirar as customizacoes.

Pedidos de Inclusão de PV manual, analisar a configuração do F12. Revisão da TES com Controle de Saldos e Poder
de/em, Dados Fiscais , Classificação dos Clientes.
Pedidos de Origem O2P - Revisão da TES com Controle de Saldos e Poder de/em, Dados Fiscais , Classificação dos
Clientes.

Liberação de crédito:
Para liberação do crédito do cliente é preciso corrigir o processo e consequentemente e retirar as customizações.
Pode ser usado condição de pagamento com adiantamento para tratar os clientes pequenos.
O crédito é a primeira análise a ser feita para liberar um pedido, depois é analisado o estoque.

Validação na Integração dos Pedidos Integrados para Classificação diferente de A

Identificar os Clientes pequenos pela Classificação de B/C/D(Existindo um CP com RA).

19
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

MIF998. Liberação de Limite de Crédito de PV.

Reavaliação dos clientes no momento de montagem da carga(ordem de separação), com inadimplência de Título. Para
efetuar a liberação será utilizado o FLUIG com liberação N1 e N2. Mediante a configuração no FINANCEIRO dos
parâmetros para bloqueio(limite de crédito)

2.11 – Preparação Documento de Saída

Principais Objetivos:
Os documentos de saída são preparados para finalização do processo de expedição das mercadorias e/ou prestação
de serviços, ou seja, gera os diferentes documentos, como nota fiscal, complemento de preços, complemento de
ICMS, complemento de IPI, devolução de compras e beneficiamento, conforme definido no Pedido de Venda.
Para que seja possível a emissão dos documentos de saída, os pedidos de venda devem estar liberados pelas rotinas
de análise de crédito do cliente e pela quantidade disponível em estoque dos produtos vendidos, através da rotina
de liberação de estoque.
Caso seja informada a quantidade liberada no pedido de venda, o Sistema não verifica o estoque e os pedidos são
liberados com base nas quantidades definidas.
É possível gerar o documento de saída, a partir do momento em que os pedidos de venda estão disponíveis pelas
análises de crédito e estoque.
Ao gerar um documento de saída, o Sistema realiza as seguintes movimentações:

Cálculo das datas de vencimentos com base nas condições de pagamento;

Cálculo dos impostos (IPI, ICMS e suas variações e outros tributos);
Cálculo dos preços unitários e totais, considerando os descontos e os reajustes;
Atualização da carteira de duplicatas, com a implantação dos títulos gerados;
Atualização dos saldos em estoques;
Atualização dos pedidos de venda;
Gravação dos itens no arquivo de Movimentos de Vendas para posterior emissão das estatísticas, registros
fiscais, apuração de custos e lançamentos contábeis;
Atualização dos dados financeiros dos clientes;
Cálculo das comissões a partir das informações contidas nos Cadastros de Vendedores e Pedido de Venda;
Contabilização;
Escrituração dos Livros Fiscais.

Cenário atual:
Pedidos de venda incluídos manualmente como remessas, consertos, beneficiamento, devoluções, retornos de
beneficiamento as notas fiscais são gerados pelo usuário.
Pedidos de venda incluídos automaticamente por rotina customizada com origem em sistemas O2P ou pedidos de
venda gerados pelo ACD da Crown as notas fiscais são geradas automaticamente.

Atualmente existe customização para faturamento de Embalagens e PA em notas fiscais diferentes ou em uma
mesma nota fiscal, esta customização quando identificado no cadastro do cliente que o mesmo indica faturamento
de PA e embalagem na mesma nota fiscal o sistema gera automaticamente pedido de produtos embalagem e realiza
o faturamento em uma única nota fiscal.(*Item 05 Wish List Faturamento)

Cenário proposto:

20
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

Utilizar o processo padrão para geração de nota fiscal do sistema: quando o pedido está apto a ser faturado ou seja,
não tem pendências de crédito ou estoque pode ser usado o botão “Preparar Doc” diretamente da rotina de Pedido
de Vendas.
Nos casos em que o cliente indica a necessidade ou preferencia de faturamento de PAs juntamente com Embalagens
a customização existente deverá permanecer e ser revisada pelo time Totvs para adequações ao padrões de
customização.(*Item 05 Wish List Faturamento)

Utiliza-se o Preparar Doc

Pedidos de Devolução, Remessa, Complemento , etc.

ACD – Geração das Notas Fiscais com base nos Pedidos de Vendas
Para as operações de Venda - As NF são geradas via ACD após a execução da Ordem de Separação.

Tratamento da Geração da Nota Fiscal de Venda com/sem Embalagem

Cadastro de Cliente determinará a separação das NF de Venda e Embalagem - A1_XEMBAL. Serve de opção para
o cliente receber a embalagem.

2.12 – Nota Fiscal Eletronica SEFAZ

Principais Objetivos:
O Protheus gera um arquivo eletrônico contendo as informações fiscais da operação comercial, que deverá ser
assinado digitalmente, para garantir a integridade dos dados e a autoria do emissor. Este arquivo eletrônico, que
corresponderá à Nota Fiscal Eletrônica (NF-e), será transmitido pela Internet para a Secretaria da Fazenda de
jurisdição do contribuinte, que fará uma pré-validação do arquivo e devolverá um protocolo de recebimento
(Autorização de Uso), sem o qual não poderá haver o trânsito da mercadoria.
A NF-e também será transmitida para a Receita Federal, que será repositório nacional de todas as NF-e emitidas
(Ambiente Nacional) e, no caso de operação interestadual, para a Secretaria de Fazenda de destino da operação e
Suframa, no caso de mercadorias destinadas às áreas incentivadas. As Secretarias de Fazenda e a RFB (Ambiente
Nacional), disponibilizarão consulta, por meio da Internet, para o destinatário e outros legítimos interessados que
detenham a chave de acesso do documento eletrônico.
Para acompanhar o trânsito da mercadoria, será impressa uma representação gráfica simplificada da NF Eletrônica,
intitulado DANFE (Documento Auxiliar da NF Eletrônica), em papel comum e em única via que conterá impressa, em
destaque, a chave de acesso para consulta da NF-e na Internet e um código de barras bidimensional que facilitará a
captura e a confirmação de informações da NF-e pelas unidades fiscais.
A DANFE não é uma Nota Fiscal Eletrônica, nem a substitui, servindo apenas como instrumento auxiliar para consulta
da NF-e, pois contém a sua chave de acesso. Essa chave permite ao detentor desse documento confirmar a efetiva
existência da NF-e por meio do Ambiente Nacional (RFB) ou site da SEFAZ.
O contribuinte destinatário, não emissor de NF-e, poderá escriturar os dados contidos no DANFE para a escrituração
da NF-e, sendo que sua validade ficará vinculada à efetiva existência da NF-e nos arquivos das administrações
tributárias envolvidas no processo. Sua validação será comprovada por meio da emissão da autorização de uso. O
contribuinte emitente da NF-e, realizará a escrituração a partir das NF-e emitidas e recebidas.
Carta de Correção Eletrônica (CC-e): é um evento, instituído pela Nota Técnica 2011/003 para corrigir as informações
da Nf-e. O autor desse evento é o próprio emissor da nota.

Cenário atual:

21
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

A Crown transmite as notas fiscais pela rotina padrão do sistema SpedNfe.

Foi solicitado que as transmissões possam ser feitas ao Sefaz automaticamente pelo sistema.
Existe customização relacionada a faturamento de PA e materiais de embalagem jutos na mesma nota fiscal e ou em
notas separadas.
Existe uma rotina customizada de emissão de complementos de preço em massa executada todo o final de mês com
cerca de 100 NFs emitidas.
Para o entreposto(Resende-Uberlandia) existe também customização para complemento de preço no final de cada
mês.

Cenário proposto:
É possivel habilitar o AutoNFE para transmissões automáticas.
Para a customização referente ao faturamento de PA e embalagens caso o processo não possa ser substituído pelas
rotinas padrões a mesma deverá ser mantida.
Customização de NFs de complemento de preço no final do mês deverá ser mantida e revisada visto a grande
quantidade de notas a serem emitidas.(*Item 08 WishList Faturamento)
Customização de NFs de complemento de preço para entreposto(Resende-Uberlandia), deverá ser mantida e
revisada visto a grande quantidade de notas a serem emitidas.(*Item 09 WishList Faturamento)

Desenvolvimento de uma Rotina para carga das NFs das NF de Remessa do Armazém, que foram emitidas para o
cliente com valor diferente das tabelas de preço.
Rotina compara os valores(SD2/DA1 vigente) gerando a NF de Complemento de Preço Entreposto -Uberlândia.

IMPRESSÃO DA DANFE

Na impressão da DANFE temos os seguintes pontos a considerar em algumas situações de tipos de processos de
venda e operação triangular.

Informações na DANFE - Dados Complementares

Composição da Etiqueta - Nº OP/SKU/Data da Etiqueta

CÓDIGO CONTEINER - Na geração da DT informa o opção 003.

(ZZC_A_TPVE)-

CAMINHÃO BITREIN - Eicho adicional com 25 --> 16 pallets adicionais.

41 PALLETS Identifica a característica.
2 NF PARA CADA BAÚ - E A PLACA DO CAMINHÃO.

NF EXPORTAÇÃO - DANFE
Imprime dados de Seguro/Frete e Despesas Acessórias são digitadas no Pedido de Venda pela Expedição,

CÁLCULO DE QUANTIDADE DE FOLHA POR PALETE

cada palete tem 8.169 latas

cada camada do palete tem 389 latas

389/1.000=0,389
8.169/0,389 = 21

22
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

21 + 1 = 22 folhas por palete

INNOUT / Protheus
No Planejamento de Carga - Tipo de Véiculo - 002 - Rodotrem(ZZC_A_TPVE)
Unitizando gera uma DT ÚNICA para geração da NF.
A NF é gerada de acordo com a quantidade do Planejamento.

2.13 – Eliminação de Resíduo

Principais Objetivos:
Quando um pedido de vendas é faturado parcialmente, ou seja, a nota fiscal é emitida com referência a apenas
alguns produtos ou quantidade parcial dos pedidos, seu saldo é chamado de resíduo, significando que não foi
entregue ao cliente.
Este faturamento parcial ocasiona valores mínimos que não compensam ser faturados. Os limites mínimos são
variáveis de região para região, pois devem ser levados em consideração os custos do transporte para que sejam
compensadores.
Um dos parâmetros para eliminar resíduos é o percentual informado em relação ao valor original do produto. Se o
resíduo for menor, o item é eliminado.
Cenário atual:
A eliminação é realizada pelo O2P
Cenário proposto:
Deverá ser revisada customização de eliminação de residuos.

2.14 - Relatórios e Consultas

Cenário atual:
Os usuários da Crown geram inúmeras consultas via ODBC para extração da informações do Protheus e também o
sistema legado QlikView.
Não há controle sobre quais dados podem ser extraídos via ODBC pelos usuários correndo-se o risco de serem
extraídos informações confidenciais da Crown.

Cenário proposto:
Gerador de Relatórios TotvsReport
GoodData (Relatórios Gerenciais)
Relatórios padrões de cada módulo, personalizados ou não.
Planilhas Conectadas via ODBC serão de responsabilidade da TI CROWN

23
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

3. Fluxograma ToBe.

24
 MIT041–ESPECIFICAÇÃO DE PROCESSOS

4. Informações do Processo

6.1 Relatórios
Relatório Descrição Comentários

001 Relatório de Clientes

002 Relatório de Pedidos de Clientes
003 Relatório de Pedidos por Produto
004 Relatório de Notas Fiscais
005 DANFE
006 Consultas
007 Relatórios via TotvsReports

5. Aprovação

Aprovador por Assinatura Data

___/___/___

___/___/___

___/___/___

___/___/___

___/___/___

25