Known Issues

/*
  var bcInvoiceOtherPolicies = getInvoicesOtherPolicies(policyPeriod, paymentPlan.BillingId, fromDate, toDate) 
  var pcInvoicesOtherPolicies = convertToPolicyCenterPaymentPreviewItems(bcInvoiceOtherPolicies, policyPeriod.PreferredSettlementCurrency) 
  pcInvoicesOtherPolicies = pcInvoicesOtherPolicies.orderBy( \elt -> elt.DueDate).toArray(pcInvoicesOtherPolicies) 
  billingPaymentsPreview.InvoicesOtherPolicies = pcInvoicesOtherPolicies 
*/

1. Remove a coverable, such as a vehicle, from a policy in a policy change, then issue the policy change.
2. Start another policy change for a later date, add the coverable back to the policy, and quote.
3. Change the edit effective date of the policy change.

override property get RateBooksToExportToJAR() : Iterable<RateBook> {
    return Query.make(RateBook).compare(RateBook#Status, Equals, TC_ACTIVE).select().toCollection()
  }

In private function destroyContact(contact: ABContact), change the return value of the following code:

} catch (e: Exception) { 
ABPersonalDataLogUtil.logErrorNotDestroyed(contact, e) 
return ContactDestructionStatus.TC_NOTDESTROYED 

Change the return value to:

return ContactDestructionStatus.TC_MANUALINTERVENTIONREQUIRED

After generating a product, if you add or remove a clause term, then regenerate the product, you will encounter errors that prevent the server from starting.

If you remove an existing option or package term and re-generate, the term is removed from the product model files as expected. However, the lookup entities for the option and package values are not removed. They are still in the clause's -lookups.xml file, which causes the server startup to fail:

java.lang.NullPointerException: null
 at com.guidewire.pc.domain.productmodel.impl.CovTermOptLookupImpl.initialiseDenormField(CovTermOptLookupImpl.java:39) ~[classes/:?]
 at com.guidewire.pc.domain.productmodel.impl.CovTermOptLookupImpl.beforeInsert(CovTermOptLookupImpl.java:29) ~[classes/:?]
 at entity.SCPSingleCoverageOptLookup$_Internal.beforeInsert(SCPSingleCoverageOptLookup.java:63) ~[classes/:?]

If you add a new term to an existing clause and regenerate, the term is created in the product model but its lookup entity is not. There is no entry for the new term in the -lookups.xml file. This causes an error at startup:

[1] INFO Limit [OptionCovTermPattern] : - 1 error(s) in OptionCovTermPattern "Limit"
[1] INFO Limit [Lookups] : - 1 error(s) in SCPSingleCoverageTermLookups
[1] ERROR Limit (PolicyLinePatternCode:SingleCoverageLine) [field : CovTermPatternCode] : - No lookups found. Use Product Designer to fix this issue.

The simplest way to resolve the issue is to first remove the existing installed version of the product before re-generating. This clears out the originally generated files and avoids the known issue.

If you cannot start over for some reason, then you can edit the lookup table XML file that is generated for the coverage.

For example, there is an RSB line with an Operations coverage. There are two terms on the coverage, Extra Expenses (an option term) and Overhead. You can generate and install this product without issues. But this issue occurs if you modify the terms on this coverage by removing Extra Expenses option term and adding a Security option term.

The lookup file is generated in config/resources/productmodel/policylinepatterns. In this example, RSBLine/coveragepatterns/RSBOperations-lookups.xml.

When you remove an option or package term like Extra Expenses, the regenerated lookup file still contains references to the removed term. You need to remove all the OptLookup and PackLookup XML elements that mention Extra Expenses, such as the one below:

<RSBReallySmallBusinessOptLookup public-id="z03iab5odomjgb3cupvk2jfbvh9">
 <Availability>Available</Availability>
 <CovTermOptCode>RSBOperationsExtraExpenses1000usd</CovTermOptCode>
 <CovTermPatternCode>RSBOperationsExtraExpenses</CovTermPatternCode>
 <EndEffectiveDate/>
 <StartEffectiveDate>2000-01-01 00:00:00.000</StartEffectiveDate>
 <State/>
 <Currency>usd</Currency>
</RSBReallySmallBusinessOptLookup>

When you add a new term like Security, the regenerated lookup file does not contain an entry for the new term. You need to add an entry to the lookup file. (There may be an existing one in the file that you can use as a model.) It needs to look something like this:

<RSBReallySmallBusinessTermLookup public-id="zkshsdhc6mas8dp1cv45a62tfgb">
 <Availability>Available</Availability>
 <CovTermPatternCode>RSBOperationsSecurity</CovTermPatternCode>
 <EndEffectiveDate/>
 <PolicyLinePatternCode>ReallySmallBusinessLine</PolicyLinePatternCode>
 <StartEffectiveDate>2000-01-01 00:00:00.000</StartEffectiveDate
 <State/>
</RSBReallySmallBusinessTermLookup>}}

The top-level XML element name is generated from the line prefix and the typename of the coverable that owns the clause. In this example, the line prefix is RSB and the coverable typename is ReallySmallBusiness, so the XML element is RSBReallySmallBusinessTermLookup.

The public-id attribute must be a unique value.

The CovTermPatternCode is the line prefix (RSB), the coverage short name (Operations) and the term short name (Security).

The PolicyLinePatternCode is the line’s identifier (ReallySmallBusinessLine).

A field with name xxxx is already defined at path/entity.eti

In Product Designer, add coverage terms changes back after regenerating the product.

The mind map generation tool that generates a mind map in XMind format requires assistance from Guidewire Services.

After saving the product to template, contact your Guidewire Services representative to convert the product to a mind map.

If you log out of PolicyCenter while running Generate Product Code on a product, PolicyCenter displays a "Code generation unavailable" error the next time you Generate Product Code on this product.

While navigating through a policy transaction for an installed APD managed product, an IllegalStateException can occur if the location on a location risk object is left empty.

You can also make the location field on the location risk object required by making it required in the PCF file generated for the location risk object.

During a policy transaction, if:

• The product model properties for field B have a dependency on the value of field A
• And both A and B appear on the same screen

The effect of changing field A is not reflected onto field B until you navigate away and back to the screen. If you select Quote, you may see a validation error.

You can also edit the PCF definition for the screen and remove the disablePostOnChange property on the PostOnChange section of input A.

When a product is finalized the first time, the generated typelists do not have a prefix.

If you update the product mind map, then import the mind map selecting Yes to Default additional fields?, when you finalize the product the second time, the typelist name is prefixed with the product abbreviation. These typelists duplicate the original typelists. There are now two versions of some typelists: with and without the prefix.

After importing the mind map with Default additional fields set to Yes, view the typelist names on the Validation Status or Generate Product Code page. Make a note of the typelists with the prefix. For example, after importing the mind map, there is a CPOTerritory typelist duplicating the Territory typelist. In the product, remove the prefix from all places where it appears. Then you can regenerate and finalize the product.

• perm.Holiday.edit
• perm.Holiday.delete
• perm.Note.view

WARN [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0059: Class Path entry
      some.jar in /content/xx.war/WEB-INF/lib/someother-version.jar does not point to a valid jar
      for a Class-Path reference.

When running Cucumber scenarios against a test server that is configured to run at the MULTIUSER level, scenarios function normally on the first attempt. But, on subsequent attempts, all scenarios fail with a java.lang.Exception: Remote Cucumber invocation: Step failed due to: null exception.

The error occurs because the running of scenarios invokes the PCCucumberSmokeTestProxy class in pc-gunit-behavior. This class changes the run level of the server. When the scenarios have completed, the level is not restored to MULTIUSER. On subsequent attempts to run scenarios, there is platform code that tries to confirm the status of the servlet. The mismatched run levels prevents the code from confirming the status and eventually timing out.

You can avoid the issue using either of the following approaches:

1. Ensure there is no server running prior to the execution of each test.

2. Remove any code that requires the server to be executed at the MULTIUSER level. For example, if you are loading test data by overriding a method that requires the server to be running at MULTIUSER level, find an alternate approach to loading the test data.

If a scenario outline has a name that contains a parameter, and the scenario outline is executed against a running server, the scenario outline throws an exception.

For example, a scenario outline with the name "Adding <FirstValue> and <SecondValue> equals <Sum>" will cause an exception when it is executed against a running server. This is because the name includes the parameters <FirstValue>, <SecondValue>, and <Sum>.

Whenever possible, avoid using parameters in the names of scenario outlines. If a scenario outline must include a parameter name, execute the scenario outline only when there is no server already running.

The createAndSetUserWithRole method in the gw.cucumber.context.impl.smoketest.common.AdminContextImpl class loads sample data without checking whether data is already loaded.

If a feature or suite calls this method more than once, a database exception occurs.

Edit the loadTestSampleData method in the gw.cucumber.CucumberStepBase class to test for the existence of a Claim instance. For example, use code similar to the following lines inside the try clause of the try-catch statement:

var hasClaims = !gw.api.database.Query.make(Claim).select().Empty
if (!hasClaims) {
  // Current content of try clause
}