\n| backup<\/td>\n | Flaga rozr\u00f3\u017cniaj\u0105ca oryginalne adresy od kopii adres\u00f3w na potrzeby dokument\u00f3w<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Procedura HashCode u\u017cywana dla adres\u00f3w wyst\u0119puje r\u00f3wnie\u017c w innych miejscach w systemie i zapobiega tworzeniu identycznych rekord\u00f3w danych dla struktur danych bez merytorycznego klucza. Podczas zapisywania adresu, numer jest obliczany na podstawie danych u\u017cytkownika przy u\u017cyciu funkcji hash. Funkcja hash powinna unika\u0107 konfliktu warto\u015bci hash jesli tylko to jest mo\u017cliwe, aby zapewni\u0107 wysok\u0105 wydajno\u015b\u0107 procesu. Poniewa\u017c mimo to mog\u0105 istnie\u0107 inne adresy, dla kt\u00f3rych obliczono ten sam numer, najpierw podejmowana jest pr\u00f3ba za\u0142adowania takiego adresu przy u\u017cyciu unikalnego klucza (byPrevious: hashCode=? + previous=Guid.ZEROGUID). Je\u015bli adres z tym kluczem zostanie znaleziony, a jego zawarto\u015b\u0107 nie b\u0119dzie zgodna z zawarto\u015bci\u0105 adresu, kt\u00f3ry ma zosta\u0107 zapisany, wyszukiwany i sprawdzany jest nast\u0119pny adres, przy czym klucz g\u0142\u00f3wny wcze\u015bniej znalezionego adresu jest u\u017cywany jako poprzedni. Je\u015bli zostanie znaleziony ca\u0142kowicie identyczny adres, nie jest konieczne zapisywanie adresu; klucz g\u0142\u00f3wny istniej\u0105cego adresu jest u\u017cywany jako odniesienie. Je\u015bli nie znaleziono identycznego adresu, klucz g\u0142\u00f3wny ostatniego znalezionego adresu jest wprowadzany z t\u0105 sam\u0105 warto\u015bci\u0105 hash w poprzednim atrybucie nowego adresu i jest on zapisywany.<\/p>\n W standardowym systemie adresy nie s\u0105 identyfikowane za pomoc\u0105 unikalnego kodu. Powinno by\u0107 jednak mo\u017cliwe zarz\u0105dzanie adresami za pomoc\u0105 merytorycznego klucza w ramach adaptacji (dostosowania). Wymagany do tego model danych jest dost\u0119pny w standardowym systemie i sk\u0142ada si\u0119 z dw\u00f3ch atrybut\u00f3w code<\/em> i keyExtension<\/em>, a tak\u017ce klucza biznesowego byCode<\/em> (sk\u0142ada si\u0119 z code + keyExtension). Dla instancji AddressData<\/em> utworzonych w systemie standardowym atrybut code<\/em> zawiera pusty ci\u0105g znak\u00f3w. Aby jednak zapewni\u0107 unikalno\u015b\u0107 klucza byCode<\/em>, klucz g\u0142\u00f3wny jest wprowadzany w atrybucie keyExtension<\/em>. Oznacza to, \u017ce klucz jest unikalny, ale nie ma znaczenia dla standardu, poniewa\u017c jego zawarto\u015b\u0107 jest r\u00f3wnowa\u017cna kluczowi g\u0142\u00f3wnemu. Aby klucz m\u00f3g\u0142 by\u0107 u\u017cywany jako cz\u0119\u015b\u0107 adaptacji, atrybut keyExtension musi by\u0107 wype\u0142niony Guid.ZEROGUID i nale\u017cy okre\u015bli\u0107 unikalny kod do identyfikacji. W takim przypadku klucz byPrevious<\/em> u\u017cywany w procedurze hashCode<\/em> nie mo\u017ce by\u0107 ju\u017c stosowany. Atrybut hashCode<\/em> musi zawiera\u0107 warto\u015bci\u0105 0, a atrybut previous<\/em> musi posiada\u0107 warto\u015b\u0107 klucza g\u0142\u00f3wnego.<\/p>\nJe\u015bli adresy s\u0105 identyfikowane za pomoc\u0105 unikalnego kodu, s\u0142u\u017cy to przede wszystkim do zarz\u0105dzania nimi lub ich zmiany. Zmiana adres\u00f3w nie mo\u017ce jednak prowadzi\u0107 do sytuacji, w kt\u00f3rej przy ponownym wydruku dokument\u00f3w, takich jak faktury sprzeda\u017cowe, zostanie wydrukowany inny adres ni\u017c w momencie generowania dokumentu. Dlatego u\u017cywanie modyfikowalnych adres\u00f3w w dokumentach nie jest dozwolone. Modyfikowalny adres musi najpierw zosta\u0107 przekszta\u0142cony w adres bez kodu i zapisany przy u\u017cyciu procedury HashCode <\/em>(Snapshot). Tak powsta\u0142y niezmienny adres mo\u017ce by\u0107 u\u017cywany na dokumencie. W wyniku tego procesu powstaje zamierzony duplikat oryginalnego adresu. Aby u\u0142atwi\u0107 jego wykluczenie w ramach kontroli duplikat\u00f3w, flaga backup <\/em>zostaje ustawiona na true<\/em>.<\/p>\nKlasy pomocnicze<\/h4>\n\n\n \n \n \n \n \n \n \n Do wykorzystania adres\u00f3w dost\u0119pne s\u0105 nast\u0119puj\u0105ce klasy pomocnicze:<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/article>\n \n \n\n\n| Klasa<\/th>\n | Opis<\/th>\n<\/tr>\n<\/thead>\n | \n\n| com.cisag.app.general.log.HashCodeLogic<\/td>\n | Realizuje procedur\u0119 HashCode i oferuje wsparcie dla migracji danych podczas zmiany funkcji hashuj\u0105cej.<\/td>\n<\/tr>\n | \n| com.cisag.app.general.log.AddressDataAdapter<\/td>\n | Udost\u0119pnia funkcj\u0119 hashuj\u0105c\u0105 niezb\u0119dn\u0105 do procedury HashCode.<\/td>\n<\/tr>\n | \n| com.cisag.app.general.log.AddressDataValidation<\/td>\n | S\u0142u\u017cy do sprawdzania poprawno\u015bci adresu. Uwaga<\/div> Jednostka AddressData <\/em>nie zawiera nazw, dlatego wywo\u0142ywanie kontroli duplikat\u00f3w bezpo\u015brednio z tej klasy zazwyczaj nie jest celowe.<\/div><\/section><\/td>\n<\/tr>\n\n| com.cisag.app.general.gui.AddressDataField<\/td>\n | S\u0142u\u017cy do wprowadzania i wy\u015bwietlania adres\u00f3w.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Adres musi by\u0107 zawsze zapisany przy u\u017cyciu klasy HashCodeLogic:<\/p>\n AddressDataAdapter adapter = AddressDataAdapter.getInstance();\n\nbyte[] guid = HashCodeLogic.getInstance().save(myAddress, adapter);\n\nmyBO.setAddress(guid);<\/pre>\nUwaga<\/div> Zmiana i zapisywanie danych u\u017cytkownika AddressData bezpo\u015brednio bez u\u017cycia klasy HashCodeLogic <\/code>regularnie prowadzi do nieodwracalnego uszkodzenia danych!<\/div><\/section>\nSprawdzanie duplikat\u00f3w<\/h3>\nUwagi og\u00f3lne<\/h4>\nW kolejnych rozdzia\u0142ach opisano mo\u017cliwo\u015bci rozszerzenia o kontrole, takie jak sprawdzanie duplikat\u00f3w, sprawdzanie na li\u015bcie wyklucze\u0144 lub weryfikacja wyst\u0105pienia za po\u015brednictwem zewn\u0119trznych dostawc\u00f3w (np. poczta) w ramach dostosowa\u0144.<\/p>\n Zazwyczaj opisane kontrole nie s\u0105 wymagane ani po\u017c\u0105dane dla wszystkich adres\u00f3w w systemie. Przyk\u0142adowo, je\u015bli w aplikacji Banki<\/em> zostanie przypisany adres, to ten sam adres powinien m\u00f3c zosta\u0107 przypisany tak\u017ce do partnera, je\u015bli oddzia\u0142 banku ma by\u0107 traktowany jako np. klient, kontakt. Ponadto kontrola duplikat\u00f3w lub sprawdzanie listy wyklucze\u0144 przy wprowadzaniu danych oddzia\u0142u banku prawdopodobnie nie jest po\u017c\u0105dane.<\/p>\nPrzed dostosowaniem nale\u017cy zdefiniowa\u0107, w kt\u00f3rych aplikacjach kontrola ma si\u0119 odbywa\u0107 i jakie duplikaty s\u0105 niepo\u017c\u0105dane.<\/p>\n W kolejnych rozdzia\u0142ach przedstawiono kontrole podczas wprowadzania nowego partnera oraz podczas wprowadzania adresu dla pseudopartnera w zam\u00f3wieniu sprzeda\u017cy. Zamiast bezpo\u015bredniego sprawdzenia w ramach og\u00f3lnych kontroli, weryfikacja istnienia mo\u017ce zosta\u0107 przeprowadzona tak\u017ce w p\u00f3\u017aniejszym terminie dla wielu nowych adres\u00f3w jednocze\u015bnie.<\/p>\n Dla obiektu biznesowego com.cisag.app.general.obj.AddressData<\/em> czas utworzenia jest rejestrowany w cz\u0119\u015bci updateInfo<\/em>, co pozwala na \u0142atwe ograniczenie sprawdzania do nowych adres\u00f3w.<\/p>\nDodawanie nowego partnera<\/h4>\nPo wprowadzeniu nowego partnera adres jest sprawdzany w klasie com.cisag.app.general.partner.log.PartnerBaseValidation<\/code>. Klas\u0119 t\u0119 nale\u017cy r\u00f3wnie\u017c dostosowa\u0107, je\u015bli opr\u00f3cz standardowych kontroli ma zosta\u0107 przeprowadzona kontrola duplikat\u00f3w lub podobna. Metoda validateCreate(PartnerBaseData)<\/code>powinna zosta\u0107 rozszerzona tak, aby kontrola by\u0142a przeprowadzana dla wszystkich „prawdziwych” partner\u00f3w, tj. pseudo partnerzy i szablony partner\u00f3w nie s\u0105 sprawdzane:<\/p>\nPartnerBaseData base = ...\n\nPartnerValidation pv = PartnerValidation.getInstance();\n\nboolean pseudo = pv.isPseudoPartner(base.getPartnerObject());\n\nboolean template = base.getPartnerEntity().isTemplateMode();\n\nif (!pseudo && !template) {\n\n...\n\n}<\/pre>\nNazwa regularnie wymagana do sprawdzania duplikat\u00f3w jest okre\u015blana na podstawie osoby lub organizacji w zale\u017cno\u015bci od typu:<\/p>\n Partner partner = base.getPartnerObject();\n\nif (partner.isHuman()) {\n\nPersonMutable person = partner.getMutablePerson();\n\nString name = person.getSurname();\n\n...\n\n} else {\n\nOrganisizationalUnitMutable ou =\n\npartner.getMutableOrganisationalUnit();\n\nString[] names = ou.getName();\n\n...\n\n}<\/pre>\nJe\u015bli wy\u0142\u0105cznie dok\u0142adnie takie same adresy maj\u0105 by\u0107 rozpoznawane jako duplikaty, mo\u017cna u\u017cy\u0107 warto\u015bci hash wyznaczonej w standardzie do zaw\u0119\u017cenia zakresu adres\u00f3w do sprawdzenia. W przeciwnym razie zaleca si\u0119 wprowadzenie nowego atrybutu do wst\u0119pnej selekcji i odpowiednie indeksowanie podobnych adres\u00f3w za pomoc\u0105 odpowiedniego algorytmu.<\/p>\n Poni\u017csza metoda okre\u015bla klucz g\u0142\u00f3wny dok\u0142adnie takiego samego adresu jako przyk\u0142ad. Zwr\u00f3con\u0105 warto\u015b\u0107 mo\u017cna nast\u0119pnie wykorzysta\u0107 m.in. do okre\u015blenia partner\u00f3w, do kt\u00f3rych przypisany jest potencjalnie ju\u017c istniej\u0105cy adres. Je\u015bli nazwa partnera do sprawdzenia pasuje do nazwy jednego z partner\u00f3w okre\u015blonych w ten spos\u00f3b, jest to duplikat.<\/p>\n private byte[] findDuplicateCopy(AddressData address) {\n\nAddressDataAdapter adapter = AddressDataAdapter.getInstance();\n\nint hash = adapter.hashCode(data.getAddressData());\n\nbyte[] previous = Guid.ZEROGUID;\n\nwhile(true) {\n\nAddressData temp = (AddressData)\n\nom.getObject(AddressData.buildByPreviousKey(hash, previous));\n\nif (temp == null) return null;\n\nif (!temp.isBackup() && equals(address, temp))\n\nreturn temp.getGuid();\n\nprevious = temp.getGuid();\n\n}\n\n}<\/pre>\nNale\u017cy za\u0142o\u017cy\u0107, \u017ce funkcja hashuj\u0105ca rzadko wyznacza t\u0119 sam\u0105 warto\u015b\u0107 hash dla r\u00f3\u017cnych adres\u00f3w, co oznacza, \u017ce konflikty powinny wyst\u0119powa\u0107 sporadycznie. Dlatego zaleca si\u0119 \u0142adowanie adres\u00f3w pojedynczo za pomoc\u0105 unikalnego klucza byPrevious<\/em>, zamiast u\u017cywania CisObjectIterator <\/em>do jednoczesnego pobierania wszystkich adres\u00f3w o tym samym hashu.<\/p>\nDo por\u00f3wnywania adres\u00f3w nie mo\u017cna u\u017cywa\u0107 metody contentEquals <\/em>z klasy AddressData<\/em>, poniewa\u017c metoda ta por\u00f3wnuje r\u00f3wnie\u017c atrybuty techniczne, takie jak hashCode<\/em>, previous <\/em>itp. Zamiast tego por\u00f3wnanie danych u\u017cytkowych musi zosta\u0107 zaprogramowane w spos\u00f3b jawny.<\/p>\nPseudopartnerzy na zam\u00f3wieniu sprzeda\u017cy<\/h4>\nKontrola duplikat\u00f3w dla pseudopartner\u00f3w na zam\u00f3wieniu sprzeda\u017cy powinna zapewni\u0107, \u017ce klient nie jest ju\u017c zarejestrowany jako „normalny” partner. Oznacza to, \u017ce nie mo\u017ce istnie\u0107 \u017caden partner, kt\u00f3rego nazwa i adres pasuj\u0105 do danych wprowadzonych na zam\u00f3wieniu.<\/p>\n Domy\u015blnie adres klienta jest sprawdzany w klasie com.cisag.app.sales.order.log.OrderHeaderValidation<\/code>. Metod\u0119 validateCustomerData(Data)<\/code>mo\u017cna odpowiednio rozszerzy\u0107, dzi\u0119ki czemu sprawdzanie musi by\u0107 przeprowadzane tylko wtedy, gdy jest to pseudopartner:<\/p>\nData header = ...\n\nPartner partner = header.getCustomer().retrievePartner();\n\nboolean pseudo =\n\nPartnerValidation.getInstance().isPseudoPartner(partner);<\/pre>\nNazwa wymagana do sprawdzenia jest zawarta w obiekcie OrderCustomerDataInfo<\/em> (r\u00f3wnie\u017c obiekt biznesowy, kt\u00f3ry jest zarz\u0105dzany za pomoc\u0105 metody HashCode<\/em>), a sam adres jest dost\u0119pny za po\u015brednictwem metody getCustomerAddressData()<\/code>:<\/p>\nString name = header.getCustomerData().getName();\n\nAddressData address = header.getCustomerAddressData();<\/pre>\nPoniewa\u017c kontrola musi by\u0107 przeprowadzana tylko wtedy, gdy dane s\u0105 zmieniane, zaleca si\u0119 por\u00f3wnanie z danymi, kt\u00f3re s\u0105 ju\u017c w systemie. Dost\u0119p do nich mo\u017cna uzyska\u0107 za pomoc\u0105 funkcji getPersistentCustomerData<\/code> lub getPersistentCustomerAddressData().<\/code><\/p>\nPodobnie jak w przypadku wprowadzania nowego partnera, duplikaty mo\u017cna okre\u015bli\u0107, najpierw identyfikuj\u0105c identyczne lub podobne adresy, a nast\u0119pnie por\u00f3wnuj\u0105c nazwy powi\u0105zanych partner\u00f3w.<\/p>\n Adresy odbiorc\u00f3w dostaw i odbiorc\u00f3w faktur mog\u0105 by\u0107 sprawdzane w ten sam spos\u00f3b poprzez rozszerzenie metod validateDeliveryCustomerData<\/code>\u00a0i validateInvoiceCustomerData<\/code>.<\/p>\n","protected":false},"author":27,"comment_status":"closed","ping_status":"closed","template":"","format":"standard","meta":{"footnotes":""},"class_list":["post-9243","ht_kb","type-ht_kb","status-publish","format-standard","hentry","ht_kb_category-interfejsy-do-systemow-zarzadzania-przedsiebiorstwem"],"_links":{"self":[{"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/ht_kb\/9243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/ht_kb"}],"about":[{"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/comments?post=9243"}],"version-history":[{"count":4,"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/ht_kb\/9243\/revisions"}],"predecessor-version":[{"id":30402,"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/ht_kb\/9243\/revisions\/30402"}],"wp:attachment":[{"href":"https:\/\/pomoc.comarch.pl\/cee\/640\/index.php\/wp-json\/wp\/v2\/media?parent=9243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} | | |