Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto | Protheus | Módulo | SIGATMS |
Segmento Executor | Logística | ||
Projeto | IRM | ||
Requisito | Subtarefa | ||
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros |
|
Objetivo
Integrar as informações de contas a receber geradas pelo módulo SIGATMS (Transportation Management System) da linha Microsiga Protheus com o módulo Finanças ACR da linha Datasul utilizando como ferramenta de Integração o EAI (Enterprise Application Integrator), que terá a responsabilidade de trafegar as mensagens XML entre o Protheus e o Datasul, além de fazer o controle de filas das mensagens a serem integradas.
Definição da Regra de Negócio
Devida a amarração que o SIGATMS possui com tabelas e rotinas do SIGAFIN, para que seja possível realizar esta integração com o módulo de Contas a Receber (ACR) do Financeiro Datasul, será necessário:
- Criar uma nova tabela que controlará a Fatura dentro do SIGATMS;
- Criar novos programas de Fatura por Documento e Fatura Automática, que serão executados pelos programas já existentes em substituição e utilizarão a nova tabela;
- Identificar todos os pontos que possuem amarração com o SIGAFIN e efetuar os tratamentos necessários utilizando a nova tabela de fatura (Como os programas de Solicitação de Transferência, Transferência, Transferência por Lote, Manutenção de documentos, Perfil do Cliente e Painel de Agendamentos);
- Bloquear a utilização do programa de Baixa Documento de Transporte;
- Criar um novo programa de Adapter para processamento da mensagem de Fatura de Transporte (Tratamento de envio e recebimento da resposta);
- Criar um novo programa de Adapter para processamento da mensagem de Baixa de Título (Tratamento de recebimento da mensagem para atualização do status da fatura);
Algumas premissas:
- Quando houver integração, o SIGATMS enviará mensagens para o Datasul, por intermédio do conceito do EAI - Mensagem Única;
- O parâmetro de integração só poderá ser alterado para o valor "1" (Datasul), se o parâmetro MV_TMSMFAT for igual a "2" (Faturamento a partir da DT6);
- O fluxo das rotinas impactadas e que serão desenvolvidas, quando houver integração com o Financeiro Datasul deve seguir o mapa mental:
Abaixo segue o detalhamento das alterações que deverão ser realizadas:
Rotina | Tipo de Operação | Opção de Menu |
Parâmetro MV_TMSERP | ||
Alteração | Atualizações -> Financeiro -> Fatura Por docto. | |
TMSA851 – Fatura Por docto. | Inclusão | - |
Alteração | Atualizações -> Financeiro -> Fatura Automática | |
TMSA492 – Fatura Automática | Inclusão | - |
TMSA890 - Solicitação de transferência | Alteração | Atualizações -> Financeiro -> Sol. transferência |
TMSA870 - Transferência | Alteração | Atualizações -> Financeiro -> Transferência |
TMSA900 - Transf. Por Lote | Alteração | Atualizações -> Financeiro -> Transf. Por Lote |
TMSA500 - Manutenção de documentos | Alteração | Atualizações -> Transportes -> Manutenção de documentos |
TMSA480 - Perfil dos Clientes | Alteração | Atualizações -> Comercial -> Perfil dos Clientes |
TMSA880 - Baixa doc. Transp | Alteração | Atualizações -> Financeiro -> Baixa doc. Transp |
TMSAF76 - Painel de Agendamento | Alteração | Atualizações -> S.A.C -> Painel de Agendamento |
Mensagens de Integração | ||
TMSI851 - Adapter de Fatura | Inclusão | - |
TMSI852 - Adapter Status da Fatura | Inclusão | - |
EDI - Layout DOCCOB |
Parâmetro MV_TMSERP
Deverá ser criado no AtuSX um novo parâmetro para o SIGATMS com as seguintes especificações:
Var | MV_TMSERP |
---|---|
Tipo | C - Caractere |
Pyme | S - Sim |
Owner | SIGATMS |
Des.portug. | ERP que está integrado ao SIGATMS. |
Des.portug.1 | 0 - Protheus, 1 - Datasul. |
Conteúdo | 0 |
Validação | TmsX6Valid(X6_FIL, X6_VAR, X6_TIPO, X6_CONTEUD, X6_CONTSPA, X6_CONTENG) |
TMSXFUND - TmsX6Valid
Alterar a função padrão de validação de parâmetro: TmsX6Valid para:
- Permitir apenas o conteúdo 0 ou 1 para o parâmetro MV_TMSERP;
- Caso o conteúdo seja 1, o parâmetro MV_TMSMFAT deve ser igual a 2 (Modo de faturamento pelo DT6), do contrário deve apresentar um help e não efetivar a alteração;
- Em relação ao parâmetro MV_TMSMFAT, incluir mais uma verificação:
- Se o parâmetro MV_TMSERP for igual a 1, não deve ser possível alterar o valor do parâmetro MV_TMSMFAT de 2 para 1;
TMSA850 – Fatura Por docto.
Alterar a rotina para que na função inicial (TMSA850), caso exista integração com o Financeiro ACR (Datasul), desviar para o novo programa TMSA851.
Observação
TMSA851 – Fatura Por docto.
Criar um novo programa TMSA851 (Fatura Por docto.) que deverá seguir como base as mesmas regras do atual programa TMSA850, porém, não terá o vínculo com o SIGAFIN e possuirá algumas diferenças.
As principais mudanças que o novo programa terá em relação ao atual estão descritos abaixo:
- O novo programa não deverá utilizar diretamente a tabela SE1 (Contas a Receber) e sim a nova tabela DRT - Fatura de Transporte a Receber que será criada. Consulte mais detalhes em Dicionário de Dados;
- Na rotina TMSA850, ao clicar na opção "Selecionar", aparece inicialmente uma tela para informar alguns dados da Fatura e parâmetros que restringem a seleção dos documentos. Esta tela deverá ser transferida para uma função que será chamada pelas rotinas TMSA850 e TMSA851. Quando a função for chamada da rotina TMSA851, a tela deve se adequar para que as informações: "Prefixo", "Tipo" e "Natureza" não sejam apresentadas;
- A tela de seleção dos documentos que pertencerão a fatura atualmente na rotina TMSA850 é modelada na função TMSA850TELA. Esta função deve ser chamada também na rotina TMSA851, porém a tela deverá ser modelada sem as informações de "Prefixo", "Tipo" e "Natureza". Além disso, fazer alguns ajustes na tela para ambas as rotinas: Os tamanhos das colunas apresentadas devem ser ajustadas de forma que apareçam todas as colunas para visualização, sem rolagem horizontal e deve ser revisto a tela de "Ajustes" e "Pesquisa" (Outras Ações) para que não apareçam "cortadas";
- Ao "Salvar" a fatura, deverá respeitar todas as validações existentes no programa atual e que não estejam amarradas ao SIGAFIN. Deve ser disparada a mensagem de integração de envio Síncrona ao financeiro ACR Datasul, para a criação do título de fatura (Mais detalhes em TMSI851 - Integração TMS x ACR Datasul) e somente deverá ser efetivada a criação do registro de fatura se a integração ocorrer com sucesso. Deverá ser gravada na nova tabela a informação do usuário que gerou a fatura;
- Em relação aos status da fatura, serão diferentes do programa atual, conforme:
- Fatura Integrada - Fatura criada no Protheus, enviada e processada no Financeiro Contas a Receber Datasul;
- Fatura Parcialmente Baixada - Houve baixa parcial do título relacionado a fatura;
- Fatura Totalmente Baixada - Houve a baixa total do título relacionado a fatura;
- Fatura Cancelada - Houve o cancelamento da fatura no Protheus e título relacionado no Datasul;
- Fatura Protestada - Houve o protesto do título;
- Na nova tabela de fatura, haverá um campo de histórico que irá manter de forma descritiva algumas informações sobre a integração com o contas a receber, por exemplo, quando o financeiro responder a mensagem de fatura indicando que o título que foi criado, ficará no histórico a informação chave deste título;
- Em relação ao Cancelamento, somente Fatura com status "Fatura integrada" poderá ser cancelada. O cancelamento sempre será da fatura como um todo e não permitirá a retirada parcial de documentos. Somente será efetivado o cancelamento quando for enviada a mensagem de cancelamento ao Financeiro ACR Datasul de forma Síncrona e retornado que o processamento de cancelamento do título de fatura foi efetivado. Se houver alguma inconsistência ou tratativa de negócio que impeça o cancelamento, a operação será abortada apresentando adequadamente o ocorrido por meio de uma mensagem. Caso o retorno seja positivo indicando que o título foi cancelado, o status da fatura deverá ser alterado para "Fatura cancelada", a data de cancelamento atualizada, no histórico deverá constar a informação "Título cancelado no contas a receber", os conhecimentos deverão ser liberados para serem incluídos em uma nova fatura, além de armazenar o histórico dos documentos excluídos como atualmente na integração com o SIGAFIN;
- Alterar a função Tmsa850Ajustes do TMSA850 para não habilitar os campos "_SI_VALFAT" e "_SI_VALAJU", quando houver integração com o ERP Datasul, pois nesta fase não será possível alterar o valor do conhecimento incluindo acréscimo ou decréscimo.
Verificar os Protótipos de Telas do TMSA851;
Conceitos de Negócio
No TMS, após a autorização do CT-e pelo SEFAZ, o conhecimento será enviado ao Faturamento Datasul para geração das obrigações fiscais e conforme parametrização também a geração automática do título no contas a receber. Caso seja gerado o título, este não estará disponível para ser movimentado (será bloqueado pelo financeiro) e por isso não há necessidade de atualizar o conhecimento no TMS com a informação do título. Após a liberação do conhecimento de frete ou geração do comprovante de entrega conforme parametrização, ocorrerá o processo de faturamento no TMS. Em uma fatura poderão ser vinculados os conhecimentos de um cliente considerando ou não sua loja. Após a confirmação dos conhecimentos selecionados, a fatura será gerada, os conhecimentos que a compõe serão atualizados com a informação do número da fatura indicando que estão faturados e haverá o processo de integração com o contas a receber do Datasul. Esta integração ocorrerá de forma Síncrona, ou seja, o sistema aguardará o retorno do financeiro indicando se o título foi gerado com sucesso. Caso o retorno seja negativo, então a fatura não será criada. Caso o retorno seja positivo, então a fatura ficará com um status de integrada.
No contas a receber, haverá a figura do Recebimento Padrão que é um conjunto de informações para implantação do título (espécie, série, entre outros) e um cadastro de Seleção de Recebimento Padrão, na qual será possível parametrizar para a transação de “Fatura de Transporte”, código de transação (tipo do conhecimento), estabelecimento e cliente, qual Recebimento Padrão deverá utilizar para implantação do título. Assim que o TMS enviar a mensagem de integração de fatura com os conhecimentos que a compõem, será verificado qual “Recebimento Padrão”, deverá ser utilizado para cada conhecimento com base no que foi cadastrado na Seleção de Recebimento Padrão com código de transação (DT6_DOCTMS), estabelecimento (DRT_FILDEB) e cliente (DRT_CLIFAT + DRT_CLILOJ) recebidos na mensagem. Neste momento, a fatura deve conter apenas conhecimentos que possuem a mesma parametrização para geração de títulos no contas a receber. Sendo assim, caso o Datasul identifique que algum conhecimento possua um Recebimento Padrão diferente dos demais, ele retornará uma mensagem de erro informando que não é possível integrar ao contas a receber. Neste caso, o usuário terá que desvincular este conhecimento que possui uma parametrização diferenciada para geração de título ou alterar a parametrização do lado do contas a receber. Caso todos os conhecimentos que compõem a fatura estiverem parametrizados para geração do título utilizando o mesmo Recebimento Padrão, então o título será implantado no contas a receber com as informações do Recebimento Padrão e recebidas na mensagem (valor, data de emissão, moeda). No histórico do título constará as informações chaves dos conhecimentos da fatura. Quando o conhecimento já possuir um título que o represente no financeiro, será realizado o processo de substituição dos títulos dos conhecimentos da fatura por um único título que representará a fatura.
TMSA491 – Fatura Automática
Alterar a rotina para que na função inicial (TMSA491), caso exista integração com o Financeiro ACR (Datasul), desviar para o novo programa TMSA492.
Observação
TMSA492 – Fatura Automática
Criar um novo programa TMSA492 (Fatura Automática) que deverá seguir como base as mesmas regras do atual programa TMSA491, porém, não terá o vínculo com o SIGAFIN e possuirá algumas diferenças.
As principais mudanças que o novo programa terá em relação ao atual estão descritas abaixo:
- Mesmas mudanças já descritas para o novo programa de Fatura por docto. (TMSA851): item 1, item 4, item 5, item 6, item 7 e item 8;
- As regras do TMSA491 - Fatura Automática devem ser mantidas, conforme documentação, porém, com as seguintes particularidades:
- Os parâmetros MV_TIPFAT e MV_NATFAT não serão utilizados;
- Os parâmetros MV_TIPFAT e MV_NATFAT não serão utilizados;
- No TMSA491, várias funções são utilizadas do TMSA850, no caso do TMSA492, deve seguir o mesmo modelo, utilizando as funções do TMSA851. Se houver a possibilidade de reaproveitar as funções do TMSA491, efetuar os tratamentos adequados e utilizar a mesma função para facilitar a manutenção que terá apenas um ponto de alteração e não se preocupará com lógicas duplicadas;
Verificar os Protótipos de Telas do TMSA492.
Diferenças Conceituais SIGATMS x SIGAFIN & SIGATMS x Financeiro ACR Datasul
Atualmente a rotina de Fatura Por docto. com a integração com o SIGAFIN Protheus se comporta conforme a documentação e a Fatura Automática conforme a documentação.
Com a integração com o Financeiro ACR Datasul, haverá as seguintes mudanças:
- Fatura Por docto.:
- Na função de "Ajustes" em "Outras Ações" da tela de seleção de conhecimentos, não será possível alterar o valor do conhecimento incluindo um acréscimo ou decréscimo;
- Na função de "Ajustes" em "Outras Ações" da tela de seleção de conhecimentos, não será possível alterar o valor do conhecimento incluindo um acréscimo ou decréscimo;
- Ambas:
- A fatura poderá gerar apenas um título no contas a receber Datasul. Caso a condição do cliente indique a geração de várias parcelas, será retornado um erro durante a integração.
- Haverá mais status para a fatura, os quais indicarão mais precisamente o estado da mesma para consulta do usuário;
- Todas as informações relacionadas diretamente ao SIGAFIN, não serão mais apresentadas e/ou utilizadas conforme já mencionadas nas principais mudanças que o novo programa terá;
Transferência de Filial de Débito do Conhecimento
- TMSA890 - Solicitação de Transferência
Alterar a rotina para que na função Tmsa890Inc, somente seja feita a verificação da tabela SE1 se não houver integração entre SIGATMS e Financeiro ACR da linha Datasul, caso contrário, alimentar a variável lFatTMS com o valor true (.T). Desta forma, a Solicitação de Transferência somente poderá ser criada se não houver fatura para o documento.
- TMSA870 - Transferência
Alterar a rotina para que na função Tmsa870Apv, somente seja feita a verificação da tabela SE1 se não houver integração entre SIGATMS e Financeiro ACR da linha Datasul, caso contrário, alimentar a variável lRet com o valor true (.T). Desta forma, a transferência não será realizada se o documento estiver faturado ou o número da solicitação estiver em branco.
Na função Tm870GrvApv, alterar para não executar a atualização, gravação e baixa do título (tabela SE1) se houver integração entre SIGATMS e Financeiro ACR da linha Datasul.
- TMSA900 - Transf. Por Lote
Alterar a rotina para que na função Tmsa900Vis, na criação do botão "Vis. Fat", quando houver integração entre SIGATMS e Financeiro ACR da linha Datasul, seja posicionado no registro correspondente a fatura do documento na nova tabela e chamada a função de visualização do novo programa TMSA851.
TMSA500 - Manutenção de documentos
Alterar a função TMSA500Fin para quando existir integração com o Financeiro ACR Datasul, ao invés de apresentar os títulos a receber (tabela SE1), apresente a fatura (se houver) conforme nova tabela. Nela constará o Histórico que apresentará a chave dos títulos gerados no Contas a Receber do Datasul (Apenas as informações chaves serão apresentadas referente o título).
TMSA480 - Perfil dos Clientes
Alterar a função TmsA480SepDoc para que não permita informar o faturamento diferenciado se houver integração com o Financeiro ACR Datasul. Hoje é permitido tratar o faturamento diferenciado se o tipo de faturamento é pela DT6 (MV_TMSMFAT = '2') e com a alteração, mesmo que seja pela DT6 mas houver integração com o Datasul, não poderá diferenciar o faturamento. Esta tratativa será realizada neste momento, porém, poderá ser repensada futuramente.
TMSA880 - Baixa doc. Transp
Não permitir o acesso a funcionalidade quando houver integração com o Financeiro ACR Datasul, pois a baixa não poderá ser efetuada por meio do SIGATMS.
Observação
Neste momento do projeto, esta funcionalidade não estará disponível, porém, foi mapeada uma possível alteração que poderia trazer o conceito de Baixa de Documento de Transporte para a integração com o contas a receber do Datasul:
Na tela de seleção de conhecimentos na geração de fatura, ter um flag: "Conhecimentos já baixados". Quando o campo for marcado, será solicitada as informações bancárias como na Baixa de Documento de Transporte (Banco, Agência, Conta). Quando for confirmado, será enviado ao Financeiro Contas a Receber na mensagem de integração uma informação de ‘conhecimentos baixados’ e um ‘Histórico’ com os dados bancários. O Datasul recebendo a informação ‘conhecimentos baixados’, saberá que é referente a uma outra ‘transação’, por exemplo, “Fatura de Transporte Liquidada” e com isso utilizará uma parametrização que o usuário irá definir, apontando para outra espécie que indique ao financeiro que deve baixar. O histórico do título será alimentado com as informações bancárias que passaremos. Lembrando que, a baixa deverá ser manual e não será automática.
TMSAF76 - Painel de Agendamento
Alterar todos os pontos que utilizam a tabela SE1 para utilizar a nova tabela quando houver integração com o Financeiro ACR Datasul.
Mensagens de Integração
Importante
Será necessária a criação de duas mensagens de integração:
Fatura de Transporte
TransportInvoice_1_000.xsd Mensagem TransportInvoice Name Fatura de Transporte Description Fatura de Transporte a Receber Segment Transportation Management System Adapter TMSI851 Send Insert = Sim; Update = Sim; Delete = Sim; Receive Insert = Não; Update = Não; Delete = Não;
Status da Fatura
TransportInvoiceStatus_1_000.xsd Mensagem TransportInvoiceStatus Name Status da Fatura de Transporte Description Status da Fatura de Transporte a Receber Segment Transportation Management System Adapter TMSIACR Send Insert = Não; Update = Não; Delete = Não; Receive Insert = Sim; Update = Sim; Delete = Sim;
TMSI851 - Adapter de Fatura
Deverá ser criado um programa de adapter para tratamento da mensagem relacionada a integração de fatura entre TMS e Financeiro ACR da linha Datasul.
O novo programa de adapter deverá atuar nos seguintes pontos:
Rotina | Ponto a ser chamado | Mensagem (Entidade) | Tipo | Modo |
---|---|---|---|---|
Fatura Por docto (TMSA851) | Inclusão de uma fatura | TransportInvoice | Envio/Resposta | Síncrona |
Cancelamento de uma fatura | TransportInvoice | Envio | Síncrona | |
Fatura Automática (TMSA492) | Geração de fatura | TransportInvoice | Envio/Resposta | Síncrona |
Cancelamento de uma fatura | TransportInvoice | Envio | Síncrona |
Verificar se é possível reaproveitar as funções que serão criadas para inclusão e cancelamento da fatura do TMSA851, para que a mesmas funções sejam chamadas nestes pontos e assim não será necessário disparar o Adapter em pontos duplicados.
O objetivo do adapter será processar o envio da mensagem de fatura e a resposta do Financeiro ACR Datasul para a atualização do status da fatura e histórico.
- Envio: Utilizar como base as informações indicadas no XSD TransportInvoice_1_000.xsd.
- Recebimento da resposta: Ao receber a resposta do Financeiro ACR Datasul, identifique o status do processamento e posicione na fatura, por meio do código que está contido nas tags da mensagem original. Caso o status seja de processamento OK, então verifique o conteúdo de retorno onde estarão as informações dos títulos gerados para a fatura e com isso atualize o histórico, dados da fatura e mude o status da mesma para Fatura integrada. Caso o status seja de processamento com erro, então deverão ser apresentadas as mensagens de erro.
Informações para Codificação
- Como identificar a fatura?
Por meio do InternalId recebido na lista ListOfInternalId.
- Como gerar o histórico com as informações do título?
Percorra o título da fatura por meio da lista ListOfAccountReceivableDocument e no histórico coloque da seguinte forma:
Integração com o financeiro realizada com sucesso.
Título gerado: (Estab., Espécie, Série, Título / Parcela, Vencto, Valor)
BranchId, DocumentTypeCode, DocumentPrefix, DocumentNumber / DocumentParcel, DueDate, RealValue
- Como identificar os erros para atualizar o histórico?
Percorra a lista de mensagens em ListOfMessages.
- Quais informações deverão ser atualizadas na fatura no processamento da resposta de integração?
Campo | TAG | ||
---|---|---|---|
DRT_DTVENC | ListOfAccountReceivableDocument | AccountReceivableDocument | DueDate |
DRT_TIPCOB | ListOfAccountReceivableDocument | AccountReceivableDocument | HolderType |
DRT_VALJUR | ListOfAccountReceivableDocument | AccountReceivableDocument | AssessmentValue |
DRT_LIMDES | ListOfAccountReceivableDocument | AccountReceivableDocument | DiscountDate |
DRT_VALDES | ListOfAccountReceivableDocument | AccountReceivableDocument | DiscountValue |
DRT_BANCO | ListOfAccountReceivableDocument | AccountReceivableDocument | HolderCode |
DRT_AGENC | ListOfAccountReceivableDocument | AccountReceivableDocument | AgencyNumber |
DRT_CTACOR | ListOfAccountReceivableDocument | AccountReceivableDocument | AccountNumber |
TMSI852 - Adapter Status da Fatura
Deverá ser criado um programa de adapter para tratamento da mensagem recebida relacionada ao Status da Fatura.
O novo programa de adapter deverá atuar nos seguintes pontos:
Rotina | Ponto a ser chamado | Mensagem (Entidade) | Tipo | Modo |
---|---|---|---|---|
Mensagens Recebidas (DATASUL) | Título baixado | TransportInvoiceStatus | Recebimento | Assíncrona |
Título protestado | TransportInvoiceStatus | Recebimento | Assíncrona |
O único objetivo do adapter será processar as mensagens recebidas do Financeiro ACR Datasul para a atualização do status da fatura, conforme as seguintes regras:
Ao receber a mensagem TransportInvoiceStatus (XSD: TransportInvoiceStatus_1_000):
- Deverá posicionar na fatura conforme código recebido e atualizar o status da mesma para Fatura Protestada, se houver algum título com indicação de protesto do banco (TAG DocumentBankingStatus = 3), ou Fatura Totalmente Baixada, quando o saldo do título da fatura estiver zerado, Fatura Parcialmente Baixada, quando o saldo do título da fatura for menor que o valor original mas não zerado, ou Fatura Integrada se o tipo do evento for DELETE que significa que foi Estornada ou Cancelada a baixa de um título da fatura.
Dicas de Codificação
EDI - Layout DOCCOB
O DOCCOB é um layout EDI correspondente a fatura eletrônica que contém os dados dos conhecimentos e/ou notas fiscais de serviço de transporte a serem pagos. A transportadora envia ao embarcador. Como a fatura de transporte será armazenada na nova tabela DRT, é importante que as informações necessárias para a emissão deste layout estejam disponíveis para configuração no EDI, assim como hoje estão para a tabela SE1 (Contas a Receber) quando a integração é com SIGAFIN.
Abaixo, segue a relação de informações do layout e campos da nova tabela:
DOCUMENTO DE COBRANÇA | |
---|---|
Informação | Campo/Informação correspondente |
IDENTIFICADOR DE REGISTRO | "352" |
FILIAL EMISSORA DO DOCUMENTO | DRT_FILDEB |
TIPO DO DOCUMENTO DE COBRANÇA | "0" |
SÉRIE DO DOCUMENTO DE COBRANÇA | <Na fatura, haverá apenas o número> |
NÚMERO DO DOCUMENTO DE COBRANÇA | DRT_NUM |
DATA DE EMISSÃO | DRT_DTEMIS |
DATA DE VENCIMENTO | DRT_DTVENC |
VALOR DO DOCUMENTO DE COBRANÇA | DRT_VALOR |
TIPO DE COBRANÇA | DRT_TIPCOB |
VALOR TOTAL DO ICMS | <Total ICMS dos conhecimentos da fatura> |
VALOR – JUROS POR DIA DE ATRASO | DRT_VALJUR |
DATA LIMITE P/ PAGTO C/ DESCONTO | DRT_LIMDES |
VALOR DO DESCONTO | DRT_VALDES |
IDENTIFICAÇÃO DO AGENTE DE COBRANÇA | DRT_BANCO - Identificar o nome do banco |
NÚMERO DA AGÊNCIA BANCÁRIA | DRT_AGENC - Identificar o número da agência |
DÍGITO VERIFICADOR NUM. DA AGÊNCIA | DRT_AGENC - Identificar o dig. verificador da agência |
NÚMERO DA CONTA CORRENTE | DRT_CTACOR - Identificar o número da conta |
DÍGITO VERIFICADOR CONTA CORRENTE | DRT_CTACOR - Identificar o dígito verificar da conta |
AÇÃO DO DOCUMENTO | "1" |
FILLER | " " |
oMarkBrw:Refresh(.T.) oMarkBrw:GoTop(.T.)
Protótipo de Tela
TMSA851 - Tela Base
TMSA851 - Parâmetros e Filtros
TMSA851 - Seleção de Documentos
TMSA851 - Histórico
TMSA492 - Tela Base
TMSA492 - Parâmetro Geração
TMSA492 - Seleção Faturas
Fluxo do Processo
Mapa mental - TMS x Integr. Contas a Receber
Para visualizar o mapa mental por meio da ferramenta XMind, faça o download do arquivo TMS x ACR.
Dicionário de Dados
Arquivo ou Código do Script: DRT - Fatura de Transporte a Receber
Índice | Chave |
01 | DTR_FILIAL+DRT_NUM |
02 | DRT_FILIAL+DRT_CLIFAT+DRT_LOJFAT |
Campo | Tipo | Tamanho | Decimais | Valor Inicial | Mandatório | Descrição | Título | Picture | Help de Campo | Cons. Padrão | Grp. Campos | Contexto | Inic. Browse | |
DRT_FILIAL | C | 2 | Sim(X) | Não( ) | Filial do Sistema | Filial | @! | Filial do sistema | 33 | Real | ||||
DRT_NUM | C | 9 | Sim(X) | Não( ) | Código da Fatura | No. Fatura | @! | Código da fatura | 18 | Real | ||||
DRT_FILDEB | C | 2 | Sim(X) | Não( ) | Filial de Débito | Fil. Débito | @! | Filial de débito da fatura | SM0 | 33 | Real | |||
DRT_CLIFAT | C | 6 | Sim(X) | Não( ) | Cliente da Fatura | Cliente | @! | Cliente da fatura | SA1 | 1 | Real | |||
DRT_LOJFAT | C | 2 | Sim(X) | Não( ) | Loja da Fatura | Loja | @! | Loja do cliente da fatura | 2 | Real | ||||
DRT_NOMFAT | C | 40 | Sim( ) | Não(X) | Nome do Cliente | Nome | @! | Nome do cliente da fatura | Virtual | Posicione("SA1",1,xFilial("SA1")+DRT->(DRT_CLIFAT+DRT_LOJFAT),"A1_NOME") | ||||
DRT_DTEMIS | D | 8 | Sim(X) | Não( ) | Data de Emissão | Emissão | Data de emissão da fatura | Real | ||||||
DRT_DTVENC | D | 8 | Sim( ) | Não(X) | Data de Vencimento | Vencimento | Data de vencimento da fatura | Real | ||||||
DRT_DTCANC | D | 8 | Sim( ) | Não(X) | Data de Cancelamento | Cancelamento | Data de cancelamento da fatura | Real | ||||||
DRT_VALOR | N | 14 | 2 | Sim(X) | Não( ) | Valor Total da Fatura | Valor | @E99,999,999,999.99 | Valor total da fatura | Real | ||||
DRT_MOEDA | N | 2 | Sim(X) | Não( ) | Moeda da Fatura | Moeda | 99 | Moeda da fatura | Real | |||||
DRT_STATUS | C | 1 | Sim( ) | Não(X) | Status da Fatura | Status | @! | Status da fatura | Real | |||||
DRT_CODHIS | C | 6 | Sim( ) | Não(X) | Histórico da Fatura | Histórico | @! | Histórico da fatura | Real | |||||
DRT_FILDOC | C | 2 | Sim( ) | Não(X) | Filial do Documento | Fil.Docto. | @! | Filial do documento de apoio | 18 | Real | ||||
DRT_DOC | C | 9 | Sim( ) | Não(X) | Número do Documento | No.Docto. | @! | Número do documento de apoio | Real | |||||
DRT_SERIE | C | 3 | Sim( ) | Não(X) | Série do Documento | Série Docto. | !!! | Série do documento de apoio | 94 | Real | ||||
DRT_ACRESC | N | 14 | 2 | Sim( ) | Não(X) | Valor Acréscimo | Vl.Acresc. | @E 999,999,999.99 | Valor total de acréscimo da fatura | Real | ||||
DRT_DECRES | N | 14 | 2 | Sim( ) | Não(X) | Valor Decréscimo | Vl.Decresc. | @E 999,999,999.99 | Valor total de decréscimo da fatura | Real | ||||
DRT_CODUSR | C | 6 | Sim( ) | Não(X) | Código do usuário | Usuário | @! | Código do usuário que gerou a fatura | Real | |||||
DRT_NOMUSR | C | 40 | Sim( ) | Não(X) | Nome do usuário | Nome Usuário | @! | Nome do usuário que gerou a fatura | Virtual | UsrRetName(DRT->DRT_CODUSR) | ||||
DRT_TIPCOB | C | 3 | Sim( ) | Não(X) | Tipo de Cobrança | Tip.Cobrança | @! | Tipo de cobrança | Real | |||||
DRT_VALJUR | N | 16 | 2 | Sim( ) | Não(X) | Valor de Juros | Valor Juros | @E 99,999,999,999,999.99 | Valor de juros por dia de atraso | Real | ||||
DRT_LIMDES | D | 8 | Sim( ) | Não(X) | Data Limite de Desconto | Dt.Lim.Desc | Data limite para pagamento com desconto | Real | ||||||
DRT_VALDES | N | 16 | 2 | Sim( ) | Não(X) | Valor de Desconto | Vl.Desconto | @E 99,999,999,999,999.99 | Valor de desconto | Real | ||||
DRT_BANCO | C | 10 | Sim( ) | Não(X) | Banco | Banco | @! | Banco | Real | |||||
DRT_AGENC | C | 10 | Sim( ) | Não(X) | Agência | Agência | @! | Agência | Real | |||||
DRT_CTACOR | C | 20 | Sim( ) | Não(X) | Conta Corrente | Cta.Corrente | @! | Conta corrente | Real |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
- especificacao_de_requisito
- sigatms
- tms_datasul
- tms_contas_a_receber
- fatura_de_transporte
- drt
- tms_x_datasul_contas_a_receber
- datasul
- integracao_tms
- integracao_tms_contas_a_receber_datasul
- mp_tmsoms_inov
- p12
- logtms01_516
- financas_acr
- eai
- protheus
- logistica
- gestao_de_transportes
- bra
- brasil
- integracao
- integracao_sigatms_x_erp_datasul_financas_acr
- mv_tmserp