IMPORTAR DADOS SISTEMAS DIFERENTES
Bom dia amigos vbmaniacos!
Faz tempo clientes solicitam isso e nunca implementei, pela complexidade que vejo, porém agora estou pensando em tentar fazer, mas gostaria de saber como tratam tal situação.
Sabemos que cada sistema, seja ele qual for, possui caracterÃsticas diferentes de: tipos, tamanhos e relacionamentos dos dados de cada tabela. Porém há tabelas que teoricamente deveriam ser similares, mas isso é meio impossÃvel pois não há um padrão definido em lugar nenhum e cada desenvolvedor adota conforme suas necessidades.
Ex: Cadastro de Clientes. Cada empresa pode adotar uma quantidade de dados diferentes para esse cadastro, bem como tamanho e nomes diferente para seus campos e relacionamento com outras tabelas auxiliares:
ID ou key ou IdCli etc...
Nome ou RazaoSocial ou RZ, etc... (string 80 ou 100 ou 120)
etc....
A questão é, existem ferramentas para importar dados de um sistema para outro, porém meu sistema possui caracterÃsticas que não permitem uma importação tão simples assim, tais como;
- cada cliente estará relacionado com ID de uma determinada empresa do grupo(tabela auxiliar)
- o tamanho do campo Nome (100)
- (J/F) pessoa jurÃdica ou fÃsica
- campo descrição que conterá todos os dados do cliente como endereço, CNPJ/cpf, telefone etc.. pois para meu sistema estes dados são irrelevantes e não precisam ser separados como em outros.
Com este cenário, que se aplica a diversas outras tabelas com outras caracterÃstica também (fornecedores, Funcionários, etc...) vem a questão:
Como importar com segurança várias tabelas sem correr risco de cometer erros?
1) Não sei o que seria mais fácil e prático, além do desempenho, para essa tarefa. Estou pensando em usar algo que qualquer empresa tenha, ou que os sistemas possam exportar, tipo um TXT, mas pode ser que o tamanho dos dados ultrapassem o máximo para um arquivo texto. Talvez um XML (mas não sei se isso qualquer sistema exporta).
2) Depois de definir o formato que irei receber os dados, quem sabe mais de um, viria o problema de checar se os mesmos estão corretamente disponÃveis neste arquivo:
- Sequência
- tamanho
- tipo dos dados
- etc...
3) Depois disse vem a rotina efetiva de importação, pegar cada registro para gravar.
Apesar de teoricamente ser uma tarefa (simples) isso pode ser extremamente complicado, e surgir n problemas inesperados.
Alguém já passou por isso, tem alguma rotina ou experiência para compartilhar?
Nota: Para simplificar estou pensando em informar ao cliente que cada tabela deverá ser gerada por ele separadamente e através de um assistente quem sabe, ir solicitando tabela por tabela para essa importação. A parte de associação de dados com outras tabelas minhas, estou pensando em disponibilizar no assistente a possibilidade de selecionar o dado que irá ser associado, então nos clientes cada grupo de clientes que pertençam a empresas diferentes, deveriam ser gerados separadamente e importados um grupo/empresa por vez. Isso pode ser muito trabalhoso pro cliente.
Faz tempo clientes solicitam isso e nunca implementei, pela complexidade que vejo, porém agora estou pensando em tentar fazer, mas gostaria de saber como tratam tal situação.
Sabemos que cada sistema, seja ele qual for, possui caracterÃsticas diferentes de: tipos, tamanhos e relacionamentos dos dados de cada tabela. Porém há tabelas que teoricamente deveriam ser similares, mas isso é meio impossÃvel pois não há um padrão definido em lugar nenhum e cada desenvolvedor adota conforme suas necessidades.
Ex: Cadastro de Clientes. Cada empresa pode adotar uma quantidade de dados diferentes para esse cadastro, bem como tamanho e nomes diferente para seus campos e relacionamento com outras tabelas auxiliares:
ID ou key ou IdCli etc...
Nome ou RazaoSocial ou RZ, etc... (string 80 ou 100 ou 120)
etc....
A questão é, existem ferramentas para importar dados de um sistema para outro, porém meu sistema possui caracterÃsticas que não permitem uma importação tão simples assim, tais como;
- cada cliente estará relacionado com ID de uma determinada empresa do grupo(tabela auxiliar)
- o tamanho do campo Nome (100)
- (J/F) pessoa jurÃdica ou fÃsica
- campo descrição que conterá todos os dados do cliente como endereço, CNPJ/cpf, telefone etc.. pois para meu sistema estes dados são irrelevantes e não precisam ser separados como em outros.
Com este cenário, que se aplica a diversas outras tabelas com outras caracterÃstica também (fornecedores, Funcionários, etc...) vem a questão:
Como importar com segurança várias tabelas sem correr risco de cometer erros?
1) Não sei o que seria mais fácil e prático, além do desempenho, para essa tarefa. Estou pensando em usar algo que qualquer empresa tenha, ou que os sistemas possam exportar, tipo um TXT, mas pode ser que o tamanho dos dados ultrapassem o máximo para um arquivo texto. Talvez um XML (mas não sei se isso qualquer sistema exporta).
2) Depois de definir o formato que irei receber os dados, quem sabe mais de um, viria o problema de checar se os mesmos estão corretamente disponÃveis neste arquivo:
- Sequência
- tamanho
- tipo dos dados
- etc...
3) Depois disse vem a rotina efetiva de importação, pegar cada registro para gravar.
Apesar de teoricamente ser uma tarefa (simples) isso pode ser extremamente complicado, e surgir n problemas inesperados.
Alguém já passou por isso, tem alguma rotina ou experiência para compartilhar?
Nota: Para simplificar estou pensando em informar ao cliente que cada tabela deverá ser gerada por ele separadamente e através de um assistente quem sabe, ir solicitando tabela por tabela para essa importação. A parte de associação de dados com outras tabelas minhas, estou pensando em disponibilizar no assistente a possibilidade de selecionar o dado que irá ser associado, então nos clientes cada grupo de clientes que pertençam a empresas diferentes, deveriam ser gerados separadamente e importados um grupo/empresa por vez. Isso pode ser muito trabalhoso pro cliente.
Vamos ver se posso te ajudar
Hoje eu tenho sistemas em Oracle/SQL Server/Firebird, mas para esse seu caso trabalho com transmissões de dados do SQL Server para o Oracle e vice e versa.
Todo o meu processo é realizado através de procedures no SQL Server. Tendo em conta as circunstâncias é complicado difÃcil mesmo dizer as comparações dos campos para cada banco.
Mas veja bem, uma tabela de Clientes pode ter nomes diferentes, mas você terá sempre um campo que vai ser chave entre os dois extremos por exemplo o CPF/RG mesmo que os campos estejam como VARCHAR ou NUMBER sempre a informação vai ser igual. não impedindo de futuramente ter um confronto de dados para validações.
Me diga o que pretende e para que pretende fazer isso?
Qual a finalidade?
Quais os DB usados nos sistemas?
minha maneira de fazer facilita, pois os dois banco consegue conectar-se um com o outro através de LINKs.
Mas conheço sistemas que exporta arquivos TXT para importação que também pode te ajudar.
Aguardo respostas para continua a te ajudar!
Hoje eu tenho sistemas em Oracle/SQL Server/Firebird, mas para esse seu caso trabalho com transmissões de dados do SQL Server para o Oracle e vice e versa.
Todo o meu processo é realizado através de procedures no SQL Server. Tendo em conta as circunstâncias é complicado difÃcil mesmo dizer as comparações dos campos para cada banco.
Mas veja bem, uma tabela de Clientes pode ter nomes diferentes, mas você terá sempre um campo que vai ser chave entre os dois extremos por exemplo o CPF/RG mesmo que os campos estejam como VARCHAR ou NUMBER sempre a informação vai ser igual. não impedindo de futuramente ter um confronto de dados para validações.
Me diga o que pretende e para que pretende fazer isso?
Qual a finalidade?
Quais os DB usados nos sistemas?
minha maneira de fazer facilita, pois os dois banco consegue conectar-se um com o outro através de LINKs.
Mas conheço sistemas que exporta arquivos TXT para importação que também pode te ajudar.
Aguardo respostas para continua a te ajudar!
LUIS HERRERA,
Existem muitas dicas para seu caso. Você passar um pouco do que vi por ai, mas não é necessariamente o melhor ... você coloca o que achar legal, usual e bom. Dá para fazer algo bem bacana e complexo ou algo simplório e +/- rápido.
Pergunta: Você tem o DER ou Diagrama de classe dos BDs que quer trabalhar? Isto ajudará bastante!
Bom sua questão...
[Ô]... Como importar com segurança várias tabelas sem correr risco de cometer erros? ...[Ô]
1º) O Trancode (texto salchicha basicamente ... e de tamanho de colunas fixo ou separado por vÃrgulas), o XML e JSON são padrões de estruturas de dados que qualquer sistema pode importar ou exportar, mas é preciso implementar o código disto no sistema.
Você pode criar um programa que [Ô]lê[Ô] as estruturas de base de dados de cada banco e monta um [Ô]mapa[Ô] de como está. No VB6 era o [Ô]ADOX[Ô] que fazia isto, para fazer isto no [Ô].Net[Ô]:
Lendo a estrutura de bancos de dados com ADO.NET
http://msdn.microsoft.com/pt-br/library/cc580593.aspx
Eu acho legal criar tabelas [Ô]fixas[Ô] (pode ser feitas a manutenção delas via [Ô]form[Ô] talvez ...) de [Ô]De / Para[Ô] No caso de tipos diferentes de dados você precisa fazer vários [Ô]De / Para[Ô], encaixar campo de tamanho máximo truncando ou juntando dados de registros diferentes ... etc...
Pode puxar via DataTable para uma estrutura (com DataRow) em memória criando até os relacionamentos com DataRelation.
2º) Estas checagens tem que ser todas gravadas em uma tabela para que o sistema leia e veja o que deve fazer ... seria [Ô]quase[Ô] uma [Ô]IA[Ô], digo [Ô]quase[Ô], porque seria [Ô]IA[Ô] se ele se reajustasse sozinho de acordo com os banco de dados mudassem suas estruturas ... mas acho muito difÃcil de imaginar como isto seria!
Importante: Seria legal também criar um bom arquivo [Ô]LOG[Ô] (bem completo) para avisar em caso de algum problema ... exemplo: Foi criada uma nova tabela ou um novo campo no banco de dados ou um campo mudou de tipo ou de tamanho. Cada vez que fosse feita a importação é necessário [Ô]ler[Ô] este [Ô]LOG[Ô] para verificar se ocorreu alguma anomalia ou aconteceu algum [Ô]ABEND[Ô] (Abnormal End). (Simplesmente [Ô]pau[Ô] para nosso dialeto).
3º) Bom ... será trabalhoso mesmo se os dois bancos forem bem [Ô]incompatÃveis[Ô]. Você pode também tentar ajustar um banco que seja [Ô]seu[Ô] para ficar o máximo parecido com o outro ou pedir para o outro banco pelo menos aumentar o tamanho de alguns campos... mas não sei se é o caso.
Outra coisa bem legal que tem no [Ô].Net[Ô] que talvez te ajude é isto:
Classe TransactionScope
http://msdn.microsoft.com/pt-br/library/system.transactions.transactionscope(v=vs.90).aspx
Esta classe faz o controle de gravação como o um único [Ô]COMMIT[Ô] em dois bancos de dados diferentes. Exemplo: Access e MS SQL Server. Se não gravar em um não gravará no outro ou fará [Ô]ROLLBACK[Ô].
Espero ter ajudado.
[][ô]s,
Tunusat.
P.S. (Post Script): Quem não concordar com algo pode criticar sem problemas. Fazendo isto me ajudará a aprender mais ou corrigir algum erro ou gafe que eu cometi. Valew!
Existem muitas dicas para seu caso. Você passar um pouco do que vi por ai, mas não é necessariamente o melhor ... você coloca o que achar legal, usual e bom. Dá para fazer algo bem bacana e complexo ou algo simplório e +/- rápido.
Pergunta: Você tem o DER ou Diagrama de classe dos BDs que quer trabalhar? Isto ajudará bastante!
Bom sua questão...
[Ô]... Como importar com segurança várias tabelas sem correr risco de cometer erros? ...[Ô]
1º) O Trancode (texto salchicha basicamente ... e de tamanho de colunas fixo ou separado por vÃrgulas), o XML e JSON são padrões de estruturas de dados que qualquer sistema pode importar ou exportar, mas é preciso implementar o código disto no sistema.
Você pode criar um programa que [Ô]lê[Ô] as estruturas de base de dados de cada banco e monta um [Ô]mapa[Ô] de como está. No VB6 era o [Ô]ADOX[Ô] que fazia isto, para fazer isto no [Ô].Net[Ô]:
Lendo a estrutura de bancos de dados com ADO.NET
http://msdn.microsoft.com/pt-br/library/cc580593.aspx
Eu acho legal criar tabelas [Ô]fixas[Ô] (pode ser feitas a manutenção delas via [Ô]form[Ô] talvez ...) de [Ô]De / Para[Ô] No caso de tipos diferentes de dados você precisa fazer vários [Ô]De / Para[Ô], encaixar campo de tamanho máximo truncando ou juntando dados de registros diferentes ... etc...
Pode puxar via DataTable para uma estrutura (com DataRow) em memória criando até os relacionamentos com DataRelation.
2º) Estas checagens tem que ser todas gravadas em uma tabela para que o sistema leia e veja o que deve fazer ... seria [Ô]quase[Ô] uma [Ô]IA[Ô], digo [Ô]quase[Ô], porque seria [Ô]IA[Ô] se ele se reajustasse sozinho de acordo com os banco de dados mudassem suas estruturas ... mas acho muito difÃcil de imaginar como isto seria!
Importante: Seria legal também criar um bom arquivo [Ô]LOG[Ô] (bem completo) para avisar em caso de algum problema ... exemplo: Foi criada uma nova tabela ou um novo campo no banco de dados ou um campo mudou de tipo ou de tamanho. Cada vez que fosse feita a importação é necessário [Ô]ler[Ô] este [Ô]LOG[Ô] para verificar se ocorreu alguma anomalia ou aconteceu algum [Ô]ABEND[Ô] (Abnormal End). (Simplesmente [Ô]pau[Ô] para nosso dialeto).
3º) Bom ... será trabalhoso mesmo se os dois bancos forem bem [Ô]incompatÃveis[Ô]. Você pode também tentar ajustar um banco que seja [Ô]seu[Ô] para ficar o máximo parecido com o outro ou pedir para o outro banco pelo menos aumentar o tamanho de alguns campos... mas não sei se é o caso.
Outra coisa bem legal que tem no [Ô].Net[Ô] que talvez te ajude é isto:
Classe TransactionScope
http://msdn.microsoft.com/pt-br/library/system.transactions.transactionscope(v=vs.90).aspx
Esta classe faz o controle de gravação como o um único [Ô]COMMIT[Ô] em dois bancos de dados diferentes. Exemplo: Access e MS SQL Server. Se não gravar em um não gravará no outro ou fará [Ô]ROLLBACK[Ô].
Espero ter ajudado.
[][ô]s,
Tunusat.
P.S. (Post Script): Quem não concordar com algo pode criticar sem problemas. Fazendo isto me ajudará a aprender mais ou corrigir algum erro ou gafe que eu cometi. Valew!
Filman e Tunusat, boa tarde.
O problema é que não tenho como saber que banco é, ou que estrutura possui, pois meu sistema é distribuÃdo para outras empresas e cada uma pode ou não ter esses dados, e pode existir em qualquer tipo de banco de dados.
O que ocorre é que meu sistema possui algumas tabelas ex. Clientes, Fornecedores, etc.. que toda empresa possui. Sendo assim as empresas, ao adquirir o meu software, pergunta como pode importar esses dados para não ter de digitar tudo no meu sistema.
Como eu disse, cada cliente terá uma estrutura de dados diferentes, se tiver claro, e meu sistema usa apenas alguns dados, assim para disponibilizar uma ferramenta que o cliente possa importar, eu teria de DEFINIR regras para geração de algum tipo de arquivo contendo esses dados, que um form meu pegaria e com algumas informações do usuário, configuraria para importação.
Pensei numa planilha do Excel, ou TXT ou XML. O Excel pode não ser ideal, em função de versões, ou do cliente não usar este aplicativo. Um txt tem tamanho máximo de arquivo, e pode ser atingido por uma tabela do banco, então pode ser arriscado, sobrando talvez um XML. Porém quantos clientes, salvo quem tem um TI ou o seu ERP já permite exportar, saberia gerar um XML correto para eu importar?
Essa definição já é um primeiro problema, o segundo seria a criação da rotina (assistente) de importação, pois imagina a complexidade de comparações para identificar cada campo com o correspondente do meu sistema, descartando o que estiver errado ou impedindo o prosseguir se houver incompatibilidade.
Se fosse um sistema conhecido e único, seria até fácil pois faria conexão com o banco origem, mas não posso ter isso, pois cada empresa (meus clientes) é diferente umas das outras, e sempre há clientes novos.
O problema é que não tenho como saber que banco é, ou que estrutura possui, pois meu sistema é distribuÃdo para outras empresas e cada uma pode ou não ter esses dados, e pode existir em qualquer tipo de banco de dados.
O que ocorre é que meu sistema possui algumas tabelas ex. Clientes, Fornecedores, etc.. que toda empresa possui. Sendo assim as empresas, ao adquirir o meu software, pergunta como pode importar esses dados para não ter de digitar tudo no meu sistema.
Como eu disse, cada cliente terá uma estrutura de dados diferentes, se tiver claro, e meu sistema usa apenas alguns dados, assim para disponibilizar uma ferramenta que o cliente possa importar, eu teria de DEFINIR regras para geração de algum tipo de arquivo contendo esses dados, que um form meu pegaria e com algumas informações do usuário, configuraria para importação.
Pensei numa planilha do Excel, ou TXT ou XML. O Excel pode não ser ideal, em função de versões, ou do cliente não usar este aplicativo. Um txt tem tamanho máximo de arquivo, e pode ser atingido por uma tabela do banco, então pode ser arriscado, sobrando talvez um XML. Porém quantos clientes, salvo quem tem um TI ou o seu ERP já permite exportar, saberia gerar um XML correto para eu importar?
Essa definição já é um primeiro problema, o segundo seria a criação da rotina (assistente) de importação, pois imagina a complexidade de comparações para identificar cada campo com o correspondente do meu sistema, descartando o que estiver errado ou impedindo o prosseguir se houver incompatibilidade.
Se fosse um sistema conhecido e único, seria até fácil pois faria conexão com o banco origem, mas não posso ter isso, pois cada empresa (meus clientes) é diferente umas das outras, e sempre há clientes novos.
Já que é dessa maneira. Como não sabe o banco de dados que é você pode criar uma ferramenta de exportação TXT mesmo!
Pode ter DELIMITADOR ou com ESPAÇO FIXO.
Crie essa ferramenta para controlar preferências de usuário(cliente) ele padroniza de acordo com o que ele quer e grava no banco de dados as informações do mesmo, pois sempre que ele quiser exportar você faz de acordo com o parâmetro dele
Pode ter DELIMITADOR ou com ESPAÇO FIXO.
Crie essa ferramenta para controlar preferências de usuário(cliente) ele padroniza de acordo com o que ele quer e grava no banco de dados as informações do mesmo, pois sempre que ele quiser exportar você faz de acordo com o parâmetro dele
Boa tarde LUIS HERRERA,
Neste nÃvel você tem que desenvolver uma ferramenta de análise de banco de dados alheio...
... como você vai saber o nome da tabela de um DB de outrem? Até dá para saber mas não pode ser algo automático, teria que ser meio manual. Exemplo: Não dá para falar automaticamente que a tabela é de [Ô]clientes[Ô] só porque está escrito lá: [Ô]tblClientes[Ô]. Você precisaria analisar a tabela antes para ver se tem o que você precisa.
Você pode ler o banco de dados deles e manualmente fazer ajustes para poder criar um XML que sirva pra seu DB. Vale a pena se o número de registros for grande, mas se forem poucos registros talvez não seja útil.
é isto?
[][ô]s,
Tunusat.
Neste nÃvel você tem que desenvolver uma ferramenta de análise de banco de dados alheio...
... como você vai saber o nome da tabela de um DB de outrem? Até dá para saber mas não pode ser algo automático, teria que ser meio manual. Exemplo: Não dá para falar automaticamente que a tabela é de [Ô]clientes[Ô] só porque está escrito lá: [Ô]tblClientes[Ô]. Você precisaria analisar a tabela antes para ver se tem o que você precisa.
Você pode ler o banco de dados deles e manualmente fazer ajustes para poder criar um XML que sirva pra seu DB. Vale a pena se o número de registros for grande, mas se forem poucos registros talvez não seja útil.
é isto?
[][ô]s,
Tunusat.
Eu não quero exportar, mas sim importar. Tenho de pegar informações de outro software (sei lá qual) e colocar no meu SQL Server. Então tenho de definir uma forma segura de receber os dados é isso que preciso.
Isso é o que estou tratando de fazer. Um sistema que atuará como [Ô]denominador comum[Ô], para todo e qualquer sistema. Funciona assim:
Imagine que você tem uma lojinha de ferragem que vende pregos comprados do fornecedor [Ô]Aços S/A[Ô]. Na sua lojinha, já tem um sistema de estoque, com o cadastro de produtos, com seus campos necessários para sua loja. O seu último pacote de pregos foi vendido e você precisa repor o estoque. Através de um webservice, você posta o pedido para o seu fornecedor [Ô]Aços S/A[Ô], não importa os seus campos e nem os dele, apenas o seu código de produto e o dele, que também através do webservice serão ligados. Para você, o código do prego é [Ô]ABC[Ô], para o seu fornecedor é [Ô]XYZ[Ô], mas você(ou o fornecedor), amarrou através do webservice que o seu produto [Ô]ABC[Ô] é o mesmo que o produto [Ô]XYZ[Ô] para o fornecedor [Ô]Aços S/A[Ô]. Então você posta o pedido para o produto que você conhece e o fornecedor recebe o pedido para o produto que ele conhece. Essa amarração pode ser feita para múltiplos fornecedores, cada qual com seu respectivo código de produto.
Através de um portal que qualquer cliente pode acessar(você, seu fornecedor, seu concorrente, qualquer um), você pode cotar seus produtos para novos fornecedores. Digamos que você não está satisfeito com a [Ô]Aços S/A[Ô] e quer cotações do seu prego [Ô]ABC[Ô]. Você simplesmente posta uma ordem de [Ô]Estou comprando prego[Ô], e todos os fornecedores desse produto irão receber esse pedido de cotação e cada um deles oferece para você o seu respectivo produto, com suas condições e tudo o mais necessário para a negociação, algo parecido com um leilão. Assim que você decidir por um deles, você o torna seu fornecedor automaticamente, e seu sistema pode consultar o webservice por esse fornecedor para cadastrá-lo no seu sistema. Assim que cadastrado, você pode enviar uma ordem de [Ô]Atualize-me[Ô], que vai chamar o webservice e verificar quais produtos do fornecedor recém cadastrado, tem produtos com caracterÃsticas parecidas com o que você tem no seu cadastro de produtos. Assim que essa ordem de atualização for recebida de volta, ela dirá quais produtos que você tem cadastrados correspondem aos produtos desse novo fornecedor, amarrando assim, os seus produtos aos produtos desse novo fornecedor. E o ciclo recomeça.
Imagine que você tem uma lojinha de ferragem que vende pregos comprados do fornecedor [Ô]Aços S/A[Ô]. Na sua lojinha, já tem um sistema de estoque, com o cadastro de produtos, com seus campos necessários para sua loja. O seu último pacote de pregos foi vendido e você precisa repor o estoque. Através de um webservice, você posta o pedido para o seu fornecedor [Ô]Aços S/A[Ô], não importa os seus campos e nem os dele, apenas o seu código de produto e o dele, que também através do webservice serão ligados. Para você, o código do prego é [Ô]ABC[Ô], para o seu fornecedor é [Ô]XYZ[Ô], mas você(ou o fornecedor), amarrou através do webservice que o seu produto [Ô]ABC[Ô] é o mesmo que o produto [Ô]XYZ[Ô] para o fornecedor [Ô]Aços S/A[Ô]. Então você posta o pedido para o produto que você conhece e o fornecedor recebe o pedido para o produto que ele conhece. Essa amarração pode ser feita para múltiplos fornecedores, cada qual com seu respectivo código de produto.
Através de um portal que qualquer cliente pode acessar(você, seu fornecedor, seu concorrente, qualquer um), você pode cotar seus produtos para novos fornecedores. Digamos que você não está satisfeito com a [Ô]Aços S/A[Ô] e quer cotações do seu prego [Ô]ABC[Ô]. Você simplesmente posta uma ordem de [Ô]Estou comprando prego[Ô], e todos os fornecedores desse produto irão receber esse pedido de cotação e cada um deles oferece para você o seu respectivo produto, com suas condições e tudo o mais necessário para a negociação, algo parecido com um leilão. Assim que você decidir por um deles, você o torna seu fornecedor automaticamente, e seu sistema pode consultar o webservice por esse fornecedor para cadastrá-lo no seu sistema. Assim que cadastrado, você pode enviar uma ordem de [Ô]Atualize-me[Ô], que vai chamar o webservice e verificar quais produtos do fornecedor recém cadastrado, tem produtos com caracterÃsticas parecidas com o que você tem no seu cadastro de produtos. Assim que essa ordem de atualização for recebida de volta, ela dirá quais produtos que você tem cadastrados correspondem aos produtos desse novo fornecedor, amarrando assim, os seus produtos aos produtos desse novo fornecedor. E o ciclo recomeça.
é Barros talvez seja essa a forma segura e fácil de resolver, criar uma estrutura de dados para cada tipo de tabela a ser importada, caso o cliente queira e disponha dos dados já digitalizados e o seu sistema tenha condições de exportar.
Sei que isso irá gerar um trabalho ao TI do cliente, mas não vejo outra opção também, uma vez que cada empresa possui um sistema e estrutura de dados diferente.
Essa [Ô]rotina de importação pronta[Ô] que disse ter pode ser compartilhada?
Estou pensando em fazer um assistente para orientar e auxiliar o passo a passo para cada tabela, se tiver algum material que ajude a [Ô]visualizar[Ô] parte dessa tarefa de importar dados agradeço. Porém se não for possÃvel, não há problema entendo e agradeço sua participação do mesmo modo.
A todos os demais agradeço pela participação com suas experiências.
Kerplunk seu sistema ficará ótimo, mas não se aplica a minha necessidade, uma vez que não se trata de um pedido onde cada [Ô]Fornecedor[Ô] cadastra sua correlação, mas uma empresa (cliente nossa) quer importar toda sua tabela de Clientes para nosso sistema, sem ninguém ter de digitar nada, isso para Clientes, Fornecedores, Relação de Departamentos da Empresa, Lista de Funcionários, etc...
Sei que isso irá gerar um trabalho ao TI do cliente, mas não vejo outra opção também, uma vez que cada empresa possui um sistema e estrutura de dados diferente.
Essa [Ô]rotina de importação pronta[Ô] que disse ter pode ser compartilhada?
Estou pensando em fazer um assistente para orientar e auxiliar o passo a passo para cada tabela, se tiver algum material que ajude a [Ô]visualizar[Ô] parte dessa tarefa de importar dados agradeço. Porém se não for possÃvel, não há problema entendo e agradeço sua participação do mesmo modo.
A todos os demais agradeço pela participação com suas experiências.
Kerplunk seu sistema ficará ótimo, mas não se aplica a minha necessidade, uma vez que não se trata de um pedido onde cada [Ô]Fornecedor[Ô] cadastra sua correlação, mas uma empresa (cliente nossa) quer importar toda sua tabela de Clientes para nosso sistema, sem ninguém ter de digitar nada, isso para Clientes, Fornecedores, Relação de Departamentos da Empresa, Lista de Funcionários, etc...
LUIS HERRERA,
Essa é outra das funcionalidades que vai ter. A integração total de todo e qualquer dado. é assim:
Cada um tem seus cadastros da sua maneira. No meu sistema, cada um pode correlacionar o que quiser, incluindo clientes e produtos. Quando você quer uma importação de dados total, o dono dos dados é notificado e autoriza(ou não). Então os dados dele que ele considera que deve compartilhar, são repassados para o meu sistema. Ele relaciona dos dados dele o que é o que e isso cria um cadastro geral único. Quando você vai importar esse cadastro, você faz a mesma coisa, liga os campos do meu sistema aos campos do seu cadastro. Por exemplo, no meu sistema, a data de inclusão do registro é [Ô]01/04/2013[Ô] e o nome do campo é [Ô]DataInc[Ô], mas no seu é [Ô]DataInclusaoRegistro[Ô]. Você vai ver que no meu sistema o nome muda e então através de uma ferramenta, você [Ô]liga[Ô] o meu campo ao seu e efetua a importação. Isso para todo e qualquer campo. Diferenças de formato e tipo de dados, são geradas e informadas ao final da importação em um log.
Essa é outra das funcionalidades que vai ter. A integração total de todo e qualquer dado. é assim:
Cada um tem seus cadastros da sua maneira. No meu sistema, cada um pode correlacionar o que quiser, incluindo clientes e produtos. Quando você quer uma importação de dados total, o dono dos dados é notificado e autoriza(ou não). Então os dados dele que ele considera que deve compartilhar, são repassados para o meu sistema. Ele relaciona dos dados dele o que é o que e isso cria um cadastro geral único. Quando você vai importar esse cadastro, você faz a mesma coisa, liga os campos do meu sistema aos campos do seu cadastro. Por exemplo, no meu sistema, a data de inclusão do registro é [Ô]01/04/2013[Ô] e o nome do campo é [Ô]DataInc[Ô], mas no seu é [Ô]DataInclusaoRegistro[Ô]. Você vai ver que no meu sistema o nome muda e então através de uma ferramenta, você [Ô]liga[Ô] o meu campo ao seu e efetua a importação. Isso para todo e qualquer campo. Diferenças de formato e tipo de dados, são geradas e informadas ao final da importação em um log.
Tópico encerrado , respostas não são mais permitidas