Wyszukiwanie dokumentów na podstawie zawartości

0

Witam społeczność,
Mam następujący problem. Otóż są dwa systemy ERP: A i B. W systemie A jest dokument WZ o ilości pozycji X, a w systemie B jest dokument PZ o tej samej ilości pozycji i z tymi samymi towarami co w systemie A dokument WZ. Nie ma części wspólnych. W jaki sposób mogę wyszukać dokument w systemie B mając zawartość dokumentu z systemu A? Najchętniej jednym zapytaniem. Pomoże ktoś?

0

Zbudować jakiś schemat w JSON, XML swój własny opis dokumentu i je porównać. Czyli np w strigu połączyć indeksy towarowe z ilościami w obydwu systemach i porównać takie stringi.

0

Hej

Primo: na jakim 'poziomie' ty chcesz dane z obu systemów porównywać?: na poziomie np. baz - robiąc dblink między serwerami>bazami, a potem zapytaniem SQL chcesz znaleźć interesujące ciebie dane...
Czy po prostu chcesz zapytanie SQL/procedurę z jakimiś parametrami wejściowymi?

Przy okazji od strony biznesowej zwróć uwagę, żeby nie tylko ilości, ale np. jednostkę miary brać pod uwagę, może trzeba kilka pozycji sumować, ...może brać statusy pod uwagę, np. dokument roboczy, pozycja zadysponowana .. etc.) ... :)

0

Generalnie chodzi o taką rzecz. System A to Subiekt GT, a System B to Optima. I teraz tak. W Optimie wystawiane są dokumenty WZ i na podstawie tych dokumentów tworzone są w Subiekcie PZ-ki. Z tymże osoby tworzące te PZ-ki nie za bardzo się przykładały i są spitolone ceny przyjęcia. Później w Subiekcie jest sprzedaż. Do każdej sprzedaży jest dokument WZ. Robię skrypt w PHP, który ma za zadanie odnaleźć na tych WZ-kach w Subiekcie pozycje z zerową wartością magazynową (zrobione), następnie odnaleźć dokument PZ (zrobione) i na jego podstawie odnaleźć w Optimie dokument WZ i wpisać bezpośrednio do bazy prawidłowe ceny i wartości magazynowe. Oczywiście robię to na kopii bazy Subiektowej. To, że tak nie powinno się robić to ja wiem. Ale chodzi o podanie księgowej realnego kosztu własnego sprzedaży. A przez spitolone ceny na PZ-kach, ten koszt jest totalnie zaniżony.

0

Czy to jest akcja jednorazowa, czy to ma być funkcjonalność?

1
  1. chociaż data wystawienia dokumentu jest taka sama?
  2. a co jak będą dwa dokumenty z taką samą ilością pozycji?
  3. towary (kod/id/jakiś identyfikator) są takie same tu i tu?
  4. kolejność pozycji jest taka sama?
  5. ilości są takie same?

Jeśli 1, 3 i 4 jest prawdziwe to możesz np. dla każdego dokumentu obliczyć hash opierając się o (wszystkie/kilka z tych?) datę, kontrahenta, ilość pozycji, kody towarów, ilości i teoretycznie będziesz miał po obu stronach unikalny identyfikator dla pary dokumentów

0

Zakladam ze to sa oddzielne bazy jesli tak to zwykly dblink miedzy bazami wystarczy

https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2012/ms188279(v=sql.110)?redirectedfrom=MSDN

1

Która wersja SQL server?

Dla mnie to można zrobić, ale w teorii. W praktyce i tak wymagałoby to ręcznego sprawdzenia. Już ktoś wspominał że istnieje duże prawdopodobieństwo że będziesz miał kilka takich samych dokumentów. Wyróżnik kod towaru+ilość może nie być wystarczający.

Z praktyki, kazałbym tym mało starającym się poprawić dokumenty PZ. To gwarantuje że następnym razem się przyłożą. Jak zrobisz to raz, to gwarantuje Ci, że będziesz cyklicznie to powtarzać.

Nie znam się na subiekcie ani na optimie,.ale dla mnie najpewniejszy sposób to export dokumentów z Optimy. Usunięcie dokumentów z subiekta i zaimportowanie z Optimy. Google podpowiada że są do tego jakieś dodatki.

Oczywiście zawsze możesz rzeźbić ale rozbijesz na nieprawidłowościach, złych dopasowaniach, czy braku dopasowań, co zakończy się albo machnięciem ręką (w co wątpię) albo i tak ręcznym poprawianiem.

A może jest inna droga i błędne PZ mają powiązanie z fakturami zakupu, te powinny być wprowadzone prawidłowo.

0
abrakadaber napisał(a):
  1. chociaż data wystawienia dokumentu jest taka sama?
  2. a co jak będą dwa dokumenty z taką samą ilością pozycji?
  3. towary (kod/id/jakiś identyfikator) są takie same tu i tu?
  4. kolejność pozycji jest taka sama?
  5. ilości są takie same?

Jeśli 1, 3 i 4 jest prawdziwe to możesz np. dla każdego dokumentu obliczyć hash opierając się o (wszystkie/kilka z tych?) datę, kontrahenta, ilość pozycji, kody towarów, ilości i teoretycznie będziesz miał po obu stronach unikalny identyfikator dla pary dokumentów

Ad. 1.: Nie
Ad. 2.: Nie ilość się liczy tylko zawartość
Ad. 3.: Tak
Ad. 4.: Nie
Ad. 5.: Tak

1

Żeby nie było że tylko krytykuje, możesz próbować, np tak:

with wzc as (select 
  nr
  , string_agg(id,';') WITHIN GROUP (ORDER BY id ASC) AS id
  ,sum(ilosc) il 
from 
  wz 
group by 
  nr)
, pzc as (select 
  nr
  , string_agg(id,';') WITHIN GROUP (ORDER BY id ASC) AS id
  ,sum(ilosc) il 
from 
  pz
group by 
  nr)
, dok as (
  select 
      wzc.nr as wz
      ,pzc.nr as pz
  from
      wzc
      inner join pzc on pzc.il=wzc.il and pzc.id=wzc.id
  )

select * from dok

ale już widzę że to nie zadziała bo jak np w ilości będziesz miał poprzestawiane ale suma się zgodzi (zwróć uwagę na dokument pz1) to nie zadziala, więc pewnie w ten sposób:

  nr
  , string_agg(concat(id,'|',ilosc),';') WITHIN GROUP (ORDER BY id ASC) AS id
  ,sum(ilosc) il 
from 
  wz 
group by 
  nr)
, pzc as (select 
  nr
  , string_agg(concat(id,'|',ilosc),';') WITHIN GROUP (ORDER BY id ASC) AS id
  ,sum(ilosc) il 
from 
  pz
group by 
  nr)
, dok as (
  select 
      wzc.nr as wz
      ,pzc.nr as pz
  from
      wzc
      inner join pzc on pzc.id=wzc.id
  )

select * from dok

to teoretycznie da ci listę mapowania wz<->pz i na jej podstawie zrobisz update, sam update też może nie być łatwy, bo może być sytuacja, że masz na np 2 pozycjach to samo id. Jak pisałem wyżej, za dużo z tym babrania.

https://dbfiddle.uk/F4JV2sUv

1 użytkowników online, w tym zalogowanych: 0, gości: 1