Sage X3 : Pré e pós-requisitos funcionais de migração de um dossie

Localização espanhola

No momento da migração de um dossier de legislação espanhola, obrigado de contactar o seu serviço ao cliente espanhol afim de conhecer o procedimento de migração dedicada.

Pré-requisito ao tratamento de migração

Encontrar-se-á em baixo os pré-requisitos de migração de um dossier De maneira geral, uma primeira etapa, que é fortemente aconselhada de realizar, é de verificar a coerência dos dados a migrar. Com efeito, sobre um dossier que tem muitos movimentos, e que teve por vezes sofrido de etapas de manutenção, é possível que certos dados não sejam perfeitameto coerentes (e que tantos mais que se pode ter desenvolvimentos especificos).

Esta operaçãopermitirá detetar eventuais problemas ligados a dados que riscam provocar os erros no momento do procedimento de migração a propriamente falar, obrigam a relançar.

Está também aconselhado de purgar um certo número de tabelas temporárias cuja migração pode ser muito longa (por exemplo da tabela dos pedidos).

Pós-requisitos ao tratamento de migração

Processo ofício

Os processos utilizados em versão 6 devem ser revalidados pela função Recodificação processo (ARECOPRO). Esta validação permite de os confirmar á versão 7.

A validação dos processos deve se fazer :

• após cada validação de dossier,
• após cada cópia de processo de um dossier a um outro.

Contabilidade

Documentos automáticos

Novos documentos automáticos estão disponíveis em versão 7 e certos documentos automáticos da versão 6 foram modificados.
Você deve então lançar o utilitário de comparação dos documentos automáticos entre o dossier migrado e o dossier Sage X3.

titulos longos e curtos dos dados declinados pela legislação

Certas funções de parametrização são então de ora avante declinados por legislação. Na ocasião desta adaptação, os campos títulos longos e curtos foram tornados obrigatórios na língua de conexão do utilizador. Em caso de modificação do valor de um campo de um tal dado, se o título longo ou curto não está presente na língua de conexão, deve estar completado.
As funções afetados utilizados em finanças são o tipo de documentos (GESGTE), os diários (GESJOU), os destinos contabilísticos (GESCDA), as transações de pagamentos (GESTPY), os códigos de edições (GESTED), os modos de pagamentos (GESTAM), os ficheiros bancários (GESTFB), os códigos taxas (GESTVT), os regimes de taxa (GESTVB), os códigos descontos/juros (GESTDA), os tipos de faturas vendas e compras (GESTSV e GESTPV).

Grupo de listas

Em versão 7, as funções permitem gerir as declarações a organismos fiscais ou administrativos foram reagrupados num menu declarações e reorganizados por tema depois legislação.
As listas associadas a estas funções foram também reorganizadas em consequência, o seu grupo de anexação (via o meu local 97) sendo então forçado para corresponder a esta nova estrutura.
No caso onde certas particularidades clientes quanto ao grupo de anexação devem perdurar após migração, convirá modificar o grupo de listas da lista.

Campos indicando um caminho de ficheiro

O novo modo de gestão dos volumes em V7 e utilização de um browser internet antes que um cliente pesado implica que os campos permitem indicar um caminho de geração de ficheiro funcionando diferentemente. São afetados os valores parâmetros de uma parte, mas também os campos de certas funções.
Para que estes parâmetros contendo um caminho, são de ora avante utilizados unicamente quando o destino é de tipo Servidor. Devem conter um caminho relativo ao volume selecionado (ou simplesmente um volume), exprimido com a sintaxe idónea.
Por exemplo,o parâmetro EXPCASPAY deverá conter [CASH] afim que os ficheiros sejam gerados sob o volume CASH.
Estes parâmetros devem então ser atualizados para conter os volumes ou caminhos relativos segundo a nova sintaxe.
Para que este é do caso dos campos de função, as funções "Parametrização ENEREGY" (GESNRY) e "Parametrização ACCENTFIL" (GESFAE) são afetados. Estas duas funções contêm uma zona que está no caso de uma geração de tipo Servidor deve conter um caminho relativo ao volume selecionado (ou simplesmente um volume).

Imobilizações

Tipo de registos

Em versão 7, a parametrização dos tipos de registos contabilísticos (GESTPE) foi modificada. Os tipos de registos foram recodificados em standard e é de ora avante possível de registar um tipo de documento e um código diário pela legislação.
É então aconselhado de verificar a sua parametrização.

Negócio

Legislações

Em versão 7, a gestão de certas funções entrega a noção da legislação.

• As fichas possuindo um filtro sobre a legislação, dispõem deste código legislação na nova chave.
• As fichas que não têm filtro sobre a legislação têm um código vazio para a legislação. Estas fichas são então consideradas como multi-legislações.
• As informações do grupo são mantidos em tanto que filtro.
• O titulo longo e o título curto são conservados. Se em certas fichas estes titulos estão vazios, o utilizador deve registar estes titulos manualmente no momento da atualização.

A seguir, a lista das funções geradas pela legislação e a chave correspondente modificadas sobre a tabela associada ao objeto.

Tabelas diversas

• As tabelas diversas 1, 2, 3, 6, 15 e 304 são migradas em novos objetos.
• As fichas possuindo um filtro sobre a legislação, dispõem deste código legislação na nova chave.
• As fichas que não têm filtro sobre a legislação têm um código vazio para a legislação. Estas fichas são então consideradas como multi-legislações.
• Para uma antiga tabela diversa que tem uma informação de grupo, esta informação de grupo está mantida no novo objeto em tanto que filtro. Todas as outras informações standards desta tabela diversa são transferidas na nova tabela objeto.
• Todos os campos não standards acrescentados no momento da parametrização das tabelas diversas (A1, A2, N1, N2 fields) são transferidos na tabela objeto (não serão afixados no novo objeto).

A seguir, o quadro de correspondência entre as tabelas diversas utilizadas em V6 e as funções de gestão dos objetos em V7.

Tipos de entrega e tipos de devoluções

O processo de migração deve atribuir :

• um tipo de entrega no campo SDHTYP para todas as entregas existentes.
• um tipo de devolução no campo SRHTYP para todas as devoluções existentes.
  O tipo de entrega e o tipo de devolução a utilizar provêm do dossier de referência. Apenas os que têm legislações tomadas em carga no dossier de destino e aqueles que têm uma legislação vazia são copiados a partir do dossier de referência.
  O mesmo processo se aplica para os parâmetros gerais seguintes, com os seus valores por legislação : SDHTYPNOR, SDHTYPLND e SDHTYPCSO.
   O cliente tem a possibilidade de estabelecer os dados a dois níveis diferentes em função da maneira cuja migração está realizada:
• a migração está feita ao mesmo tempo que a validação do dossier : a configuração deve ser feita corretamente no dossier de referência, com os códigos dos tipos esperados (as tabelas dos tipos e os parâmetros gerais). Senão, o sistema utiliza os tipos por defeito entregues em standard.
• a migração está feita após a validação do dossier : a configuração deve ser feita corretamente no dossier de referência, com os códigos dos tipos esperados (as tabelas dos tipos e os parâmetros gerais). Senão, o sistema utiliza os tipos por defeito que foram copiados depois o dossier de referência.
• Qunado as tabelas dos tipos de entrega e os tipos de devoluções são preenchidos, e quando os parâmetros gerais SDHTYP* são definidos, o sistema alimenta as entregas e as devoluções segundo os processos seguintes. :
• para cada entrega :
• o sistema verifica o parâmetro geral correspondente à categoria de entrega,
• se nenhum valor foi definido, o sistema toma pelo primeiro tipo de entrega, na ordem alfabética, que corresponde à legislação de entrega e a categoria de entrega,
• se nenhum valor foi definido, o sistema toma pelo primeiro tipo de entrega, na ordem alfabética, que uma legislação vazia e que a categoria corresponde à categoria de entrega,
• para cada devolução :
• o sistema toma o primeiro tipo de devolução, na ordem alfabética, que corresponde à legislação de devolução e na categoria de devolução,
• se nenhum valor foi definido, o sistema toma pelo primeiro tipo de entrega, na ordem alfabética, que uma legislação vazia e que a categoria corresponde à categoria de devolução.

Mass Mailing CRM

• O parâmetro WORDPATH (Utilizadores/Parâmetros/CRM/DEF/WORDPATH) não existe mais, o modo de criação dos documentos Microsoft Word tendo alterado.
• A tabela "Etat mailing (OMMRPT)" contêm apenas os modelos de listas Crystal No momento da migração, o processo seguinte está então aplicado :
• todas as fichas que identifiquem os modelos Microsoft Word são suprimidos,
• o campo Tipo (TYPTPL) está suprimida,
• o campo Língua está preenchida com a lingua do dossier por defeito,
• o campo Código lista (MAGTPL) identifica agora a ficha "Código de lista",
• um novo campo contém o nome de lista Crystal. Este campo não visível está preenchido ao mesmo tempo que o campo precedente,
• os campos Descrição curta e Descrição longa são prenchidos com o códigos de lista,
• uma nova chave está criada com o código da língua : Código da língua + Código de lista
• A tabela "Publipostage xml (MAILXML)" contém dois novos campos : os campos Descrição curta e Descrição longa, com o código XML de mass mailing.

Modelos de importação

• O tipo de entrega está acrescentado no modelo de importação SDHFL.
• Novos modelos de importação, resultantes da criação de objetos em prenchendo das tabelas diversas, são acrescentadas : TAM (Modos de pagamento), TEC (Natureza transação), TED (Código edição), TPV  (Tipos fatura fornecedor), TRE (Tipos de devoluções), TSC (Regime estatístico), TSD (Tipos de entrega), TSO (Tipos de encomendas), TSV (Tipos fatura venda), TVB (Regime de taxa terceiros), TVI (Nível de taxa).

Listas

• Os elementos ligados ao SDD são acrescentados nas listas faturas (SBONFAC*).
• Os elementos ligados aos tipos de entrega e tipos de devolução são acrescentado nas listas BONLIV*, BONRETLIV, SDELIVERY*, SRETURN*