R E S U M O: TFIN50 - APOSTILA 1

UNIT 1: MySAP Business

>> MYSAP BUSINESS SOLUTION

São SOLUÇÕES prontas que integram pessoas x informações x processos, para
gerar maior eficiência e lucratividade para a empresa.
Cross-industry solutions (ERP, CRM, SCM, SRM etc) industry solution (Templates
por Mercado / Traz tabelas especificas para cada negócio. Ex: SAP for Banking,
SAP for Automotive, SAP for Oil & Gas etc) e industry-specific functions.
O MySAP Business Suíte utiliza a plataforma Netweaver.

NetWeaver – Plataforma que permite integração das Aplicações com a Web e com
outros aplicativos (SAP e não SAP).
O Netweaver possui as seguintes produtos/ferramentas:
- WAS (Web Application Sever): Aplicações Web
- EP (Enterprise Portals): Comunicação com clients e comunicação interna /
Disponibiliza funcionalidades na Web
- BW (Business Warehouse): Repositório de Dados.
- MDM (Master Data Management): Atualiza o dado mestre em todo o ambiente
(Netweaver) real-time.
- XI: Permite conexão com qualquer aplicativo
- KM (Knowledge Mgmt): Gerenciamento de conhecimento

Cross-industry Solutions – Componentes fora do ERP R/3.

- CRM(Customer Relationship Managment): Os dados dos clientes são mantidos
centralizados e permite que outros deptos acessem os dados. Com o CRM o depto
de Vendas pode prestar serviços com enfoque no cliente.
- APO( ): Gerenciamento da Cadeia de Suprimentos /
Restrições de capacidade produtiva e logística dentro e fora da empresa
- SRM(Supplier Relationship Management): Gerenciamento do Relacionamento
com o Fornecedor / Leilão Reverso / Ferramenta para avaliação de Fornecedores.
- SEM(Strategic Enterpise Management): Utiliza bases BW. Dividido em 5
componentes.
+ BIC (Business Information Collection):
+ BPS (Business Planning and Simulation): Relatórios Real x Orçado
+ BCS (Business Consolidation):
+ CPM (Corporate Performance Monitor):
+ SRM (Stakeholder Relationshi Mangement):

SAP xApps – Funcionalidade padronizada para desenvolvedores. Conjunto de

conectores para fazer projeto (utiliza API)

SAP Customer Services Network – São soluções de suporte aos clientes SAP
(Ferramantas: SAP GoingLive Check, SAP EarlyWatch Alert, SMA e SMO – Solution
Manager)

Módulo FI x Sub-módulos
>> SAP-FI Financial Accounting
> FI-GL General Ledger
> FI-SL Special Ledger
> FI-AP Vendor (Contas à Pagar)
> FI_AR Customer (Contas à Receber)
> FI-AA Fixed Assets (Ativo Fixo)

_____________________________________________________________ 1
UNIT 2: Navigation

HELP – Teclas F1 e F4 (match code)

SapGui – Front end do SAP

UNIT 3: Basic Settings

>> ORGANIZATION UNITS

O client é o maior nível de unidade (1 client pode ter N Empresas).
É onde são cadastrados os dados que são válidos para todas as unidades
organizacionais.

Business área (Divisão) – Utilizado para extrair Balanços inter-empresariais

por divisão de negócio, para fins gerenciais (propósitos internos). Representa
áreas operacionais dentro de uma organização e podem ser cross-company. Serve
para agrupar informações nos balanços gerenciais e para segmentar os
relatórios contábeis. (Bus.Area pode receber informações de N Empresas)

Company Code (Empresa) – É utilizada para propósitos externos. Representa uma

unidade Legal com requisitos de lei. É a estrutura mínima dentro do SAP R/3.
É caracterizada por um CNPJ (com final /001-XX) próprio e emite Balanço
Oficial.

Client (Mandante) – Visão Técnica: É o ambiente técnico onde os modelos estão

implantados (Produção, Homologação, Desenvolvimento, Sand Box)
Visão Organizacional: É o mais alto nível da hierarquia organizacional da
empresa.

>> VARIANT PRINCIPLE

Variantes – São utilizadas para auxiliar a manutenção de dados.

>> FISCAL YEAR (Variante de Exercício Fiscal)

Variante que define quantos e quais são os períodos contábeis (até 16 = 12
posting periods/períodos comuns + 4 special periods)
Se alterar uma variante de Exercício Fiscal, será alterado para todas as
empresas.(utiliza o conceito de variante)
[1 Fiscal Year Variant para N Empresas]

O Fiscal Year pode ser definido como:

- Year Idependent: os períodos (inicial x final) são iguais para todos os

anos. Sempre usa o mesmo número de períodos e sempre começa e termina no mesmo
dia do ano.
- Calendar Year: O período inicial é Janeiro e o final sempre é Dez
(Corresponde ao ano corrente)
- Não Calendar Year: Tem que definir qual é o período, independente do
ano. Ex: O período 1 é Março e o período 12 é Fevereiro do outro ano.
Para que o sistema descubra qual o ano de referencia do período é
necessário informar o offset (-1)
- Year-specific / Dependent: Os períodos (Inicial x final) podem variar de
acordo com o ano.

_____________________________________________________________ 2
>> CURRENCIES (Moedas)
Exemplo: Se a empresa estiver no Brasil e receber um N.Fiscal em dólar $, o
sistema consegue armazenar as duas moedas (Moeda da transação e Moeda
Local/empresa) e converter utilizando a taxa de cambio.

Exchange Rate (Taxa Cambial) – É cadastrado um valor para cada diferentes

combinações de moedas.

Ferramentas para auxiliar a vida do tesoureiro:

Transation rations – Fator para deslocar as casas decimais. Utilizado quando o
país tem moeda muito pequena.
Inversion – Se for cadastrado USD para EUR não precisa cadastrar o contrário.
Base currency – Utilizado como base para não ter que cadastrar em todas as
conversões
Exchange Rate Spread (Moeda Base) – Desvio máximo da taxa de cambio em %.

UNIT 4: Master Records (++)

>> G/L ACCOUNTS (page 102)

A conta contábil possui 2 segmentos:
- Chart of Account Segmnet: Alterações no plano de contas valem para
todas as empresas que utilizam o plano de contas.
- Company Code Segment: É utilizada quando existe a necessidade de
criar uma conta especifica para uma empresa.

No segmento de Plano de Contas é possível determinar qual o tipo da conta.

- Balance Sheets (Conta do Balanço):
- Profit and Loss (Conta de Resultado):
Chart of accounts (Plano de Contas) – É uma variante que contem a estrutura e
as informações básicas sobre as contas contábeis (general ledger accounts)
[1 Plano de contas Operacional pode ser associado para N empresas]
[1 Empresa pode ser associada p/ 1 Plano de contas Operacional – obrigatório]
[1 Empresa pode ter 1 Plano Operacional, 1 Plano do Grupo e 1 Plano Especifico
do País)

Account Groups (Grupo de Contas) – É uma característica que esta no registo

mestre de contas do razão

O Acc.Group controla:
- Number range da conta
- Field Status para o segmento de Empresa

Field Status for Máster Data – Controla qual o status que o campo terá quando
for apresentado ou não na tela (Hide, Display, Required Entry, Optional).
É controlado por Account group e por Transaction-dependent field status
(Depende da operação - Create, Change, Display)

Reconciliation Account (Conta de Reconciliação) – É a conta (GL Acc) associada

ao cliente/Fornecedor que faz o link entre o GL e o Sub-ledger. É a conta que
garante a conciliação do Saldo.
As contas de reconciliação podem ser accounts payable (K) e accounts
receivable (D).

_____________________________________________________________ 3
Line Item (Partidas) – Se marcar line itens display cria partidas individuais
p/ a conta e grava na BSEG.

Open Item Management (Partidas em aberto) – Responsável por informar qual o

status da conta (Aberto ou Cleared(Compensado)). Tem que ter o line item
display ativado.

Account in Local Currency – Se a moeda da conta for a moeda local/empresa, a

conta pode ser lançada em qualquer moeda, que os lançamentos serão convertidos
para cada line item.

>> CUSTOMER/VENDOR ACCOUNT (page 133)

O General Data de Customer/Vendor são cadastrados no Client, para garantir a
unicidade dos dados.

CUSTOMER – É criado em SD (Sales and Distribution) e em Contas a

Receber(FI_AR).
É criado em 3 Segmentos:
- Dados Gerais (Client Level)
- Company Code Segment
- Sales area segment (Este segmento é criado pq SD necessita de dados
especificos). É a combinação de 3 elementos:
• Sales organization [Quem esta vendendo? Ex: Brasil]
• Distribution Channel [Como? Ex: por atacado]
• Division (Setor de atividade) [O que esta vendendo? Ex: carro]

VENDOR – É criado em MM (Material Management) e em Contas a Pagar(FI_AP).

É criado em 3 Segmentos:
- Dados Gerais (Client Level)
- Company Code Segment
- Purchasing Organization Segment (Este segmento é criado pq SD
necessita de dados específicos)

Account Group for Customer/Vendor (Tipo) – Ex: Fornecedor de Matéria-prima,

Forn de Mat.Escritório.
O Acc.Group controla:
- Number range de contas (não pode ocorrer overlap. O controle pode ser
internal ou external)
- Field Status
- On-time (Se o Cust/Vendor é esporádico)

Field Status de Customer/Vendor – É controlado por Transaction (Create,

Display or Change), Company code e Account group.

Dual control Principle – Se uma pessoa fizer uma alteração em algum dado
marcado como sensitive, é necessário que outra pessoa faça a confirmação ou de
o de acordo na alteração. Medida de segurança, para impedir fraudes.

Customer x Vendor Clearing – Quando o cliente também é fornecedor e vice-

versa. O programa de pagamento e cobrança pode fazer uma compensação de um
contra o outro (clear open items against each other).
No cadastro mestre de cada um deve conter a conta do outro.

Alternative Payer/Payee (Pagador Alternativo) – Ex: Financiamento - O cliente

paga para o Banco e o Banco paga para a Empresa. O Banco é o pagador

_____________________________________________________________ 4
alternativo. Se o pagador alternativo estiver cadastrado na company code tem
mais prioridade do que se estivesse no Client level.

Head Office/Branch (Matriz/Filial) – Todos os lançamentos realizados para as

Filiais são lançados automaticamente para a Matriz, se o código da Matriz
estiver preenchido no cadastro da Filial (TA FD02).

>> BANK ACCOUNT (page 168)

É responsável pelo cadastro das Agências Bancárias. Para cada Banco que é
criado no sistema tem que criar também um master Record para ele. Cada
registro de Banco é identificado pelos campos: Bank Country e Bank Key,
Endereço e Control data.

De-Para:
- House Bank = agências que a empresa tem conta.
- House Bank Id = apelido interno da agência
- Bank Key = chave que identifica o Banco+Agência.
Ex: 409.X.0923
- Bank account number = conta corrente da empresa
- Account Id = apelido interno da conta corrente da empresa

Para toda Bank account (= House Bank + Account Id) tem que criar uma conta
contábil [1 para 1]

O Bank Master data pode ser criado de 4 formas:

- Na criação de Cliente ou Fornecedor
- No menu de Contas à Pagar e à Receber
- Importando do Bank directory
- Batch input para atualizar as informações de cliente.

UNIT 5: Document Control (++)

>> DOCUMENT STRUCTURE (page 180)

Todo documento é único, por possuir os campos, Documento Number, Company code
e Fiscal Year.
O documento é dividido em 2 partes:
- Document Header: são as informações de entrada
- Line Itens: Partidas (de 2 à 999 line items).

Objetos de controle do documento:

- DT (Document type)
- PK (Posting Key)
Document type (DT) – Controla o cabeçalho do documento. Cada transação de
negócio possui um document type. São definidos no Client level para serem
validos para todas as empresas. Também limita o tipo de lançamento que pode
ser feito para cada conta.
O Document type controla:

_____________________________________________________________ 5
 - number range dos documentos (number range interval de documentos
lançados no FI). Pode ser internal ou external e pode ser reiniciado
a cada ano.
- account type que são permitidas para lançamento.
- field status do cabeçalho (Doc. Text e Reference number).
Exemplos de DT = DR, DG, SA, KR, KG, etc. (D = Customer e K = Vendor)
Posting Key (PK) – Controla a parte do line item do documento. São definidos
no client level para serem validos para todas as empresas.
O Posting Key, controla e configura:
- type of account (Se é customer, Se é vendor …)
- Indicador de Debito ou Crédito
- Field Status do Posting Key para controlar os line items (layout da
tela)
Exemplo de PK = 31 (Invoice Vendor = Credito em fornecedor), 40 (Debito em GL
= Conta de despesa)

Field Status – Controla o Posting Key e a conta

Field Status Group – Para facilitar o cadastramento do Field Status. Ex:
Quando quer que todas as contas contábeis de um Grupo possuam um campo
obrigatório.

>> POSTING PERIODS (PERÍODOS CONTÁBEIS) (page 207)

Posting Periods são definidos em uma variante de exercício Fiscal para cada
empresa [1 variante de exercício para N Empresas]. Utilizado para abrir e
fechar períodos contábeis / Com a Variante a manutenção de abertura x
fechamento dos períodos fica mais simplificada. Se um período estiver fechado
na TA OB52 não é possível efetuar lançamentos.
Durante o fechamento 2 períodos devem ficar abertos para lançamentos.
Autorization Group: é criado para associar pessoas que podem faze lançamentos
no primeiro intervalo de perído.

>> POSTING AUTHORIZATIONS (page 218)

Para cada empresa são definidos tolerance groups de acordo com o
valor/montante permitido para lançamento.
Tipos de grupos de autorização:
- Empregados: Pode ser dividido em diversos grupos, de acordo com a
necessidade da empresa. Se um usuário não estiver associado há nenhum
grupo especial, ele assumira as permissões do grupo “Branco”
(default). Ex: Grupo Branco = lançamentos até R$ 500,00, Analista =
até R$ 1.000,00, Gerente = até R$ 2.000,00, etc.
- Razão auxiliar/Subledger: Este grupo é associado no cadastro de
cliente e fornecedor. Ex: No cadastro do Cliente informa o X% de
diferença para mais ou menos que é permite para recebimentos de
cliente.

>> SIMPLE DOCUMENTS IN MYSAP ERP FINANCIAL (page 22)

Funcionalidade TA Antiga TA Nova

GL Account F-02 FB50
Vendor FB60
Customer FB70

São as novas telas de entrada de documentos para o Fornecedor, cliente e GL

account, com interface mais amigável para auxiliar e agilizar o processo de

_____________________________________________________________ 6
lançamentos. A nova transação mostra os principais campos em uma única tela.
Também é dividida em duas parte: Header e Line items.

UNIT 6: Posting Control

>> DEFAULT VALUES (page 243)

Defaults que o sistema assume de acordo com a configuração. Existem dois tipos
de default values:
- Usuário: de acordo com o cadastro mestre do usuário.
Ex: a impressora, a língua de logon, data, pontuação(decimal), moeda.
- Sistema e Contábil: de acordo com a transação de negócio ou com a
última atividade executada pelo usuário.
Ex1: lançamentos para fornecedor possuem o document type KR com
posting Key 31 como default.
Ex2: Durante uma entrada de documento a posting date é proposta pelo
sistema.
Ex3: Se o usuário fez lançamentos para a empresa 1234, o próximo
lançamento o sistema irá propor a empresa 1234.

O Accounting default controla:

- Transações de lançamento: propondo valores nos campos doc.type e
posting key.
- Fiscal Year: proposto quando o usuário esta entrando ou consultando
um documento.
- Taxa cambial: Compara a taxa cadastrada na company code e na tabela
de exchange rate, verificando se a diferença é permitida.

>> CHANGE CONTROL (Controle de campos modificáveis) (page 251)

É possível alterar alguns campos de um documento que já foi lançado:

- Document Header = Só é possível alterar o reference number e document header

text.
- Line Item = O sistema não permite alterar campos que podem alterar a
reconciliação dos lançamentos, por exemplo, os campos: Valor, conta contábil,
posting key, etc.

Document change rule – É a regra que define o que pode ser alterado. Utiliza
os seguintes critérios.
- Account type: Permite definir regras para o cliente, fornecedor ou contas do
GL.
- Transaction type: utilizado para special GL transactions bill of exchange
and down payment.
- Company code: utilizado para regras para empresa.

Condições para alterar campos de um documento.

- O período deve estar aberto
- A partida não pode estar compensada
- A partida não pode ser um debito no cliente e um crédito no
fornecedor.
- O documento não pode ser uma nota de crédito para uma fatura ou de um
pagamento.

_____________________________________________________________ 7
>> DOCUMENT REVERSAL (page 260)

Quando o usuário entrar um documento com erros, esse documento pode ser
reversed (estornado) e entrado novamente com as correções.
O sistema permite fazer estorno de documentos de cliente, fornecedor e GL
(individual ou em massa).

O documento pode ser estornado por:

- Lançamento de Estorno normal (Normal reversal posting): o sistema
lança o debito incorreto como um crédito e credito como um débito,
aumentando as partidas.
- Lançamento negativo (Negative posting): também lança o debito como
crédito e vice-versa, mas ao invés de somar as partidas ele subtrai.
Para executar lançamentos negativos é necessário identificar se a
configuração da empresa permite, se o reason reversal (motivo de
estorno) e o document type estão definidos para negative posting.

>> TERMS OF PAYMENT AND CASH DISCOUNTS (page 269)

Condições de pagamento são as condições negociadas com o parceiro de negócio

(Data de vencimento da Fatura e descontos oferecidos para pagamentos
antecipados).
É um campo obrigatório da fatura. Pode ser colocado também no cadastro do
fornecedor para sugerir qual a condição de pagamento.

O payment terms (Condição de pagamento) é usado em conjunto com a Baseline

date para calcular a data de vencimento (Due on).
Default do sistema para definir a baseline date = No default, Doc.date,
Posting date, Entry date.

De acordo com o Account type é possível informar as condições de pagamento na

criação das Faturas.
- Se a Fatura é criada para FI os payment terms da company code segment
são propostos,
- Na criação de faturas para Cliente em SD é utilizado o cadastro da
Sales area segment e
- para Faturas de Fornecedor no MM deve utilizar o cadastro feito na
Purchasing organization segment,
- mas quando as faturas de Fornecedor e Cliente são lançadas (post) as
condições de pagamento são copiadas da Fatura do FI.

Para utilizar a condição de pagamento precisa de:

- Baseline date
- Cash discount terms
- Cash discount percentage rate.

Credit Memos (Notas de crédito)

- Invoice related credit memos: podem ser relacionadas com a fatura
original, se informado o número da fatura no campo “Invoice
Reference”. As condições de pagamento são copiadas da Fatura para a
Nota de Credito, possuindo assim a mesma data de vencimento.
- Other credit memos: Não faz referencia a nenhuma fatura. Condição de
pagamento/vencimento é à vista. A data de vencimento é a mesma que a
data base.

_____________________________________________________________ 8
Payment control:
- Block keys: Bloqueia a partida ou a conta para pagamento. É utilizada
para faturas à vista, senão o sistema já sairia pagando a fatura.
- Payment method: É a forma que será utilizada para executar o
pagamento. Ex: TED, DOC, Cheque, Crédito em Conta, etc. O sistema
possui payment methods definidos para cada país.
Cash Discount (Desconto)
Para calcular o desconto é necessário preencher o percentage rate no payment
terms.
Ex: Payment terms = ZB01
Days/percentage = 14d-3,00%; 30d–2,00%; 45d–0,00%.

Installment payment (Parcelas/Parcelamento) (page 276)

O valor total da fatura pode ser dividido e cobrado em diferentes datas de
vencimento. O Installment payment deve ser definido no terms of payment.
O sistema cria uma partida para cada parcela, sendo que a somatória das
parcelas deve ser igual ao valor total da fatura.

Cash Discount (page 277)

Dependendo das leis de cada país, o Cash discount pode ser NET (Liquido) ou
GROSS (Bruto. A configuração de cash discount é feita na company code.

Se lançar uma fatura com document type = NET, o valor lançado para a Despesa é
contabilizado já com o desconto.
Quando a Fatura é paga após o prazo final do desconto, a diferença ou valor de
perda é lançado para uma conta separada (Lost cash discount).

>> TAX (page 291)

Tax Code é utilizada para:

- Verificar o valor dos impostos
- Calcular o valor dos impostos
- Calcular os impostos adicionais
- Verificar o tipo do imposto
- Determinar a conta do imposto
- Mostrar o imposto corretamente no formulário de imposto.

Existe dois níveis de impostos:

- por país
- estado, região (abaixo de país)

O SAP permite:
- Calcular o valor do imposto
- Lançar para contas de impostos definidas
- Ajustes de impostos
- Relatórios de impostos

Tax Calculation Procedure – é atribuído para todo país para transferir o

calculo de impostos. O SAP já entrega cálculos de impostos pré-configurados
para a maioria dos países.

A Tax code contém a tax rate que são associadas a tax type usada ba tax
calculation procedure. A tax code pode ter várias rates entradas para
diferentes tax types.

_____________________________________________________________ 9
Tax Posting
- Impostos calculados pelo sistema são lançados via um separete line item para
um conta de imposto especial (special tax account). Este é o cenário standard.
- Impostos com determinadas transações/account keys são distibuidos para
relevantes itens de despesa/receita. Este é o caso para pagamento de impostos
de vendas ou outros impostos não dedutíveis.

Tax Account Determination

Para ser capaz de automatizar a tax account determination é necessário
informar os seguintes dados para a conta/transaction keys para gerar a partida
de impoosto durante o lançamento.
- Posting keys (40 ou 50 são recomendados)
- Rules que determinan quais campos o account determination será
baseado (pode ser baseadi no tax code ou na account key).

>> CROSS-COMPANY CODE TRANSACTIONS (page 315)

É quando ocorrem transações de negócio que envolvem duas ou mais empresas, por
exemplo:
- A empresa A compra para a empresa B
- A empresa A para Faturas pela empresa B
- A empresa A vende imobilizados para a empresa B

Como o documento é sempre associado a uma única empresa, o sistema cria um

documento para cada empresa envolvida na transação, fazendo o link entre eles
pelo código cross-company code transaction number (o número é a soma do
documento principal (10 posições) com a empresa principal (4 pos) e o ano (2
pos). Exemplo: 1500000010910006).
Exemplo: Um fornecedor X vende imobilizados para a Empresa A no valor de R$ 80
e para a Empr.B no valor de R$ 20,00, mas a Fatura é enviada somente para a
Empresa A no valor de R$ 110 (R$ 10 de imposto).
Lançar R$ 80 para a Empr. A e R$ 20 para a Empr. B na conta de despesa. O
clearing post e a tax post são criados automaticamente.
O imposto é sempre lançada para a empresa que recebe a Fatura.

Clearing Account (Contas de compesação) deve ser definida para todas as

empresas antes de executar transações cross-company code. As clearing accounts
podem ser GL accounts, customer ou vendor accounts.
Na configuração é necessário atribuir clearing accounts para todas as
possíveis combinações entre duas empresas que permitem transações cross-
company code.
Posting Keys devem ser associadas as contas de compensação para identificar
seus account types.

UNIT 7: Clearing

>> CLEARIONG OPEN ITEMS (page 332)

Open Items são transações incompletas, tais como faturas ainda não pagar. Para
considerar uma fatura como completa, é necessário compensar as partidas,
resultando saldo zero.
Documentos com open itens não podem ser arquivados e ficam no sistema até que
todos open items sejam compensados.
Só é possível fazer o Clearing em contas com partidas em aberto.

Existem dois tipos de Clearing Open Items:

_____________________________________________________________ 10
 - Posting with clearing: Sempre utiliza no mínimo 2 contas. Ex:
Pagamento de Fornecedor – utiliza conta de Fornecedor e Cliente.
Pode ser utilizado por várias contas, account types e qualquer moeda
simultaneamente.
Pode ser manual ou automático pelo automatic payment program.
- Account Clearing: Utiliza apenas uma conta.
Não altera o saldo da conta.
Ex.:Compensação manual de uma fatura em aberto com um nota de credito
relacionada. (Fornecedor = DEB $10.000 de Nota de Credito x CRED
$10.000 de Fatura)
Usando a função de clearing account, escolher os open items de um
conta com saldo zero. O sistema marca essas contas com compensadas e
cria um clearing document e entra nas partidas compensadas o numero
do documento e a data da compensação.

Clearing transaction sempre criam um clearing document.

Automatic Clearing Program: Mecanismo para compensação automática

- Só faz para account clearing, porque só compensa o que esta em uma
única conta.
- Para utilizar o automatic clearing program é necessário definir as
contas como automatic clearing no IMG
- Só controla contas com partidas em aberto
- Não compensa noted items (Ex.: Solicitação de adiantamento) e OffBook
(Partidas de Razão Especial)

Quando existir mais de um valor igual para ser feita a compensação, para que o
sistema identifique a partida correta ele utiliza o campo Assignment que o
contador pode preencher com o número da fatura por exemplo.
O campo assignment é preenchido de acordo com o campo SORT KEY que é
preenchido no cadastro de GL account no segmento de company code.

>> INCOMING AND OUTGOING PAYMENTS (page 348)

Manual Payment Process

O pagamento manual é uma transação que compensa uma partida (normalmente uma
Fatura), atribuindo manualmente uma clearing document.
O Recebimento (normalmente usado em AR – Accounts Receivable) compensa o valor
de um open debit.
O Pagamento (normalmente usado em AP – Accounts Payable) compensa o valor de
um open credit.

Um pagamento manual é processado em 3 passos:

- Entrada dos dados no document header
- Seleção de partidas em aberto para serem compensadas
- Salvar a transação.

O document header consite em 3 seções:

- Payment Header: Document date, doc. Type, period, posting date,
currency code, document header text, clearing text.
- Bank data: Conta do GL (analitica), valor, text, assignment number.
- Open item selection: account, account type (conta do razão auxiliar)

>> PAYMENTS DIFFERENCES (page 361)

_____________________________________________________________ 11
Tolerance Group – é o grupo que permite o usuário lançar com até um % de
diferença para cima ou para baixo.
- Tolerance Group for Employee: (grupo de funcionários) associado no
usuário.
- Tolerance Group for GL account: associado no GL account master record
- Tolerance Group for Customer/Vendor: associado no cadastro do
Cliente/Fornecedor

Se não possuir grupo de tolerância, o sistema utiliza as autorizações do grupo

“BRANCO” (Default).

Permitted payment differences

- Revenue: pagamento com valor menor. Ex: Desconto
- Expense: pagamento com valor maior. Ex: Multa, Juros

Partial and Residual Payment

A empresa faz uma compra e recebe uma Fatura do Fornecedor de R$ 8.000, mas só
consegue pagar R$ 5.000 na data do vencimento, para isso existem as seguintes
formas de pagamento com diferença.
- Partial – Cria um documento parcial e não baixa a Fatura. As duas
partidas continuam em aberto.
- Residual – Paga R$ 5.000 e cria um Residual item no valor de R$ 3.000
para liquidar a Fatura. Cria outro documento de crédito com o
resíduo.

>> EXCHANGE RATE DIFFERENCES (Diferença de Variação Cambial) (page 375)

Quando fizer a compensação de partidas em moeda estrangeira pode ocorrer
diferença na taxa de cambio utilizada na data da compra e a data do pagamento.
O sistema lança automaticamente a diferença da taxa cambial como realized
gains or losses (ganho ou perda) para as contas de Receita ou Despesa.
Toda conta de reconciliação e toda conta do GL com open item (partida em
aberto) para transações em moeda estrangeira devem ser atribuídas para contas
de Receita/Despesa para realizar a perda ou ganho.

UNIT 8: Cash Journal (Caixinha)

>> CASH JOURNAL CONFIGURATION (page 382)

Cash Journal – é uma ferramenta opcional para controlar o dinheiro disponível
de uma área. Exemplo: Utilização de Travel Cheque, Ticket de um depto.
[1 empresa pode ter N Caixinhas e 1 Caixinha só esta em 1 Empresa]

O cash Journal é um código com 4 posições.

O Cash Journal deve ter contas contábeis (que recebam apenas lançamentos
automáticos) atribuídas para receber as movimentações do Caixinha.

Business Transaction – Expense, Revenue, Cash transfer (do Banco para o

Caixinha e vide-versa), Vendor - Contas a Pagar, Cliente – Contas a Receber,
etc. [Business Transaction é por empresa].

>> CASH JOURNAL TRANSACTION

_____________________________________________________________ 12
ENJOY Business transaction – Pode ser processada em uma tela simples. Nessa
tela é possível criar, modificar, exibir e deletar entradas do caixinha.
Durante o dia o usuário pode salvar as entradas no Cash Journal e lançar
somente no final do dia
Um documento no Caixinha pode conter N partidas, mas quando o documento é
enviado para o FI, somente um documento é criado.

_____________________________________________________________ 13