ADDRESS USAGE CHANGE ERROR

[former_member185489]

Hello gurus,

i am facing a problem...through a web service i am trying to enter a new address usage for a business partner while ending the validity of the present address usage by setting the "valid_to_date" to a day previous to the current date, while keeping the connection object address intact. but while executing the webservice in the response XML it is showing an error message (AM 245 OF R11 message class ) - " validity period wrong for usage address " something like this. have tried debugging for quite some days and all the structures and dates passing seem to be ok. my assumption is that while trying to update the usage address it is also trying to update the connection object address. but i am not quite sure what it is. has anyone of you faced a similar problem like this one or this type? what can be the possible solution for this kind of situation?

thanks in advance,

[Former Member]

I don't think it's possible (or at least advisable) to end a validity date previous to today.

Neal

[Former Member]

Perhaps a further explanation.  Validity dates are used on master data that will be used to effect how process flow changes.  Lets say a record was created yesterday.  But you change the master data and set the validity date to a week ago.  The system is now lying to its self.  The master data used was not the new data but was instead the previous one.  This would lead the user to make false assumptions.

Neal

[former_member185489]

hi neal,

thanks for your response! so, what you are trying to say is that an existing address usage cannot be removed at all? then if we want to enter a new address usage ( i forgot to mention in my original post that both the address usage and connection object address have identical address numbers ) having new validity periods, what should we do?

thanks in advance!

[Former Member]

Your endda has to be today.  (or in the future)  Is that not acceptable?

[former_member185489]

hi neal,

figured out the reason for the error. the error is inside the standard function module BUPA_INBOUND. because the address numbers of the connection object address and standard addresses are equal..because they are same, while doing a comparison inside the standard FM instead of reading the end date of the new address usage to be inserted it is reading the end date of the connection object address..( 99993112) due to which the condition is not fulfilled and an error is thrown. any ideas how to solve this issue?

my take is that since inside the standard FM all the address data for a BP ( connection obj and standard ) is being fetched. the error is not in the written code before the FM call. are there any notes which can solve this problem? or is there any other workaround?

[Former Member]

Hi Suman,

In my case the scenario was that all the historical information comes for the address. So instead of writing logic for modification of address of different usages with different validity periods (end of previous usages), I have written a logic to remove the existing ones by using BAPI_BUPA_ADDRESS_REMOVE and then added new address details. It was difficult to change the address of different usages and not getting proper results.

Generally for adding different address usage you have to first create an address and then assign suitable address usage to it (I mean 2 step process).

      LOOP AT rt_address INTO ls_address_t.
        ls_addressdata-city = ls_address_t-zzsuburb_name.
        ls_addressdata-postl_cod1 = ls_address_t-zzpost_code.
        ls_addressdata-street = ls_address_t-zzaddress_line1.
        ls_addressdata-str_suppl1 = ls_address_t-zzaddress_line2.
        ls_addressdata-country = gc_cntrykey.
        ls_addressdata-region = ls_address_t-zzstate_code.
        ls_addressdata-validfromdate = ls_address_t-zzstart_date.
        ls_addressdata-validtodate   = ls_address_t-zzend_date.

        IF ls_address_t-zzaddress_type = gc_postal.
          ls_addrusg-addresstype = gc_zpostal.
          ls_addrusg-standardaddressusage = ' '.
          ls_addrusg-usagevalidfrom = ls_address_t-zzstart_date.
          ls_addrusg-usagevalidto = ls_address_t-zzend_date.
          APPEND ls_addrusg TO lt_addrusg.
        ELSEIF ls_address_t-zzaddress_type = gc_physical.
          ls_addrusg-addresstype = gc_xxdefault.
          ls_addrusg-standardaddressusage = gc_on.
          ls_addrusg-usagevalidfrom = ls_address_t-zzstart_date.
          ls_addrusg-usagevalidto = ls_address_t-zzend_date.
          APPEND ls_addrusg TO lt_addrusg.
        ENDIF.

        CALL FUNCTION 'BAPI_BUPA_ADDRESS_ADD'
          EXPORTING
            businesspartner = uv_partner
            addressdata     = ls_addressdata
          IMPORTING
            addressguid     = lv_address_guid
          TABLES
            addressusage    = lt_addrusg
            return          = lt_return.

        APPEND LINES OF lt_return TO rt_return.
        REFRESH: lt_return,
                 lt_addrusg,
                 lt_addrusg_x.

        CLEAR: ls_return.
        CLEAR: ls_addrusg,
               ls_addrusg_x.

        READ TABLE lt_return INTO ls_return WITH KEY type = gc_errtype.
        IF sy-subrc = 0.
*          CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
        ELSE.
          CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
            EXPORTING
              wait = gc_on.
        ENDIF.

        IF ls_address_t-zzaddress_type = gc_postal.
          ls_addrusg-addresstype = 'ZPOSTAL'.
          ls_addrusg-validtoreadforchange = ''.
          APPEND ls_addrusg TO lt_addrusg.

          ls_addrusg_x-standardaddressusage  = ' '.
          ls_addrusg_x-addresstype           = gc_on.
          ls_addrusg_x-updateflag            = 'I' .
          APPEND ls_addrusg_x TO lt_addrusg_x.

          CALL FUNCTION 'BAPI_BUPA_ADDRESS_CHANGE'
            EXPORTING
              businesspartner = uv_partner
              addressguid     = lv_address_guid
            TABLES
              addressusage    = lt_addrusg
              addressusage_x  = lt_addrusg_x
              return          = lt_return.

          READ TABLE lt_return INTO ls_return WITH KEY type = gc_errtype.
          IF sy-subrc = 0.
*            CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
          ELSE.
            CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
              EXPORTING
                wait = gc_on.
          ENDIF.

          APPEND LINES OF lt_return TO rt_return.
          REFRESH lt_return.

          CLEAR: ls_return.
        ENDIF.

        CLEAR: ls_addrusg,
                      ls_addrusg_x.

        REFRESH: lt_addrusg,
                           lt_addrusg_x.

      ENDLOOP.

Hope it may help you.

Br...

Dwaraka