why does viewInvoice.fo.ftl use getPartyNameForDate?

[Si Chen-2]

Hi,

Something about viewInvoice.fo.ftl looks wrong to me.  I don't want  
to remove something which people are using, so I thought I'd check.

When printing the billing address of this invoice, there is this code  
block:
                <#if billingAddress?has_content>
                 <#assign billingPartyNameResult = dispatcher.runSync
("getPartyNameForDate", Static["org.ofbiz.base.util.UtilMisc"].toMap
("partyId", billingParty.partyId, "compareDate", invoice.invoiceDate,  
"userLogin", userLogin))/>
                 <fo:block>${billingPartyNameResult.fullName?default
(billingAddress.toName)?default("Billing Name Not Found")}</fo:block>
                 <#if billingAddress.attnName?exists>
                     <fo:block>${billingAddress.attnName}</fo:block>
                 </#if>

Why do we need to do this getPartyNameForDate?  Shouldn't it just be  
billingAddress.toName?


Best Regards,

Si
[hidden email]

[hans_bakker]

Hi Si,

Do you trhink that the content of the invoice should change when the billing
address is changed later, after sending the invoice? Our should it stay at
the orginal content?

regards,
Hans


On Wednesday 22 November 2006 08:37, Si Chen wrote:

> Hi,
>
> Something about viewInvoice.fo.ftl looks wrong to me.  I don't want
> to remove something which people are using, so I thought I'd check.
>
> When printing the billing address of this invoice, there is this code
> block:
>                 <#if billingAddress?has_content>
>                  <#assign billingPartyNameResult = dispatcher.runSync
> ("getPartyNameForDate", Static["org.ofbiz.base.util.UtilMisc"].toMap
> ("partyId", billingParty.partyId, "compareDate", invoice.invoiceDate,
> "userLogin", userLogin))/>
>                  <fo:block>${billingPartyNameResult.fullName?default
> (billingAddress.toName)?default("Billing Name Not Found")}</fo:block>
>                  <#if billingAddress.attnName?exists>
>                      <fo:block>${billingAddress.attnName}</fo:block>
>                  </#if>
>
> Why do we need to do this getPartyNameForDate?  Shouldn't it just be
> billingAddress.toName?
>
>
> Best Regards,
>
> Si
> [hidden email]

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

[cjhowe]

When you change your billing address later, it's
creating a new billingAccountId, not updating the
current one.  Because of this, the invoice will have
the same information before changing your address as
it does after.

--- Hans Bakker <[hidden email]> wrote:

> Hi Si,
>
> Do you trhink that the content of the invoice should
> change when the billing
> address is changed later, after sending the invoice?
> Our should it stay at
> the orginal content?
>
> regards,
> Hans
>
>
> On Wednesday 22 November 2006 08:37, Si Chen wrote:
> > Hi,
> >
> > Something about viewInvoice.fo.ftl looks wrong to
> me.  I don't want
> > to remove something which people are using, so I
> thought I'd check.
> >
> > When printing the billing address of this invoice,
> there is this code
> > block:
> >                 <#if billingAddress?has_content>
> >                  <#assign billingPartyNameResult =
> dispatcher.runSync
> > ("getPartyNameForDate",
> Static["org.ofbiz.base.util.UtilMisc"].toMap
> > ("partyId", billingParty.partyId, "compareDate",
> invoice.invoiceDate,
> > "userLogin", userLogin))/>
> >                
> <fo:block>${billingPartyNameResult.fullName?default
> > (billingAddress.toName)?default("Billing Name Not
> Found")}</fo:block>
> >                  <#if
> billingAddress.attnName?exists>
> >                    
> <fo:block>${billingAddress.attnName}</fo:block>
> >                  </#if>
> >
> > Why do we need to do this getPartyNameForDate?
> Shouldn't it just be
> > billingAddress.toName?
> >
> >
> > Best Regards,
> >
> > Si
> > [hidden email]
>
> --
> Regards,
> Hans Bakker
> ANT Websystems Co.,Ltd
> (http://www.antwebsystems.com)
>
> If you want to verify that this message really
> originates from
> from the above person, download the public key from:
>

http://www.antwebsystems.com/hbakkerAntwebsystems.asc
>

[hans_bakker]

I am not aware that a billingAccount has a connection to a billing address....

On Wednesday 22 November 2006 08:55, Chris Howe wrote:

> When you change your billing address later, it's
> creating a new billingAccountId, not updating the
> current one.  Because of this, the invoice will have
> the same information before changing your address as
> it does after.
>
> --- Hans Bakker <[hidden email]> wrote:
> > Hi Si,
> >
> > Do you trhink that the content of the invoice should
> > change when the billing
> > address is changed later, after sending the invoice?
> > Our should it stay at
> > the orginal content?
> >
> > regards,
> > Hans
> >
> > On Wednesday 22 November 2006 08:37, Si Chen wrote:
> > > Hi,
> > >
> > > Something about viewInvoice.fo.ftl looks wrong to
> >
> > me.  I don't want
> >
> > > to remove something which people are using, so I
> >
> > thought I'd check.
> >
> > > When printing the billing address of this invoice,
> >
> > there is this code
> >
> > > block:
> > >                 <#if billingAddress?has_content>
> > >                  <#assign billingPartyNameResult =
> >
> > dispatcher.runSync
> >
> > > ("getPartyNameForDate",
> >
> > Static["org.ofbiz.base.util.UtilMisc"].toMap
> >
> > > ("partyId", billingParty.partyId, "compareDate",
> >
> > invoice.invoiceDate,
> >
> > > "userLogin", userLogin))/>
> >
> > <fo:block>${billingPartyNameResult.fullName?default
> >
> > > (billingAddress.toName)?default("Billing Name Not
> >
> > Found")}</fo:block>
> >
> > >                  <#if
> >
> > billingAddress.attnName?exists>
> >
> > <fo:block>${billingAddress.attnName}</fo:block>
> >
> > >                  </#if>
> > >
> > > Why do we need to do this getPartyNameForDate?
> >
> > Shouldn't it just be
> >
> > > billingAddress.toName?
> > >
> > >
> > > Best Regards,
> > >
> > > Si
> > > [hidden email]
> >
> > --
> > Regards,
> > Hans Bakker
> > ANT Websystems Co.,Ltd
> > (http://www.antwebsystems.com)
> >
> > If you want to verify that this message really
> > originates from
> > from the above person, download the public key from:
>
> http://www.antwebsystems.com/hbakkerAntwebsystems.asc

--
Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc

[Si Chen-2]

BillingAddress comes from InvoiceWorker.getSendFromAdress or  
getBillToAddress, which is using InvoiceContactMech.  If you modify  
an address, it does not change the PostalAddress with the same  
contactMechId--it creates another one.  So the original invoice's  
contact mech should not change.  Have you actually experienced  
problems with it?

Also, note that the rest of the code is using BillingAddress, so if  
you use a name which is not part of the billingAddress it might lead  
to inconsistencies, might it not?

On Nov 21, 2006, at 5:49 PM, Hans Bakker wrote:

>> Something about viewInvoice.fo.ftl looks wrong to me.  I don't want

Best Regards,

Si
[hidden email]

[David E Jones-2]

The name we want to display on this invoice is the name of the  
customer, or more specifically the placing customer. That name may be  
different from the name on whatever address the order is shipped to.

By looking at this code you can see that it gets a name for a  
specific date, namely this invoice date. The seems to be to make sure  
the name on an invoice doesn't change even if a Party's name is changed.

Hopefully this clears up what this code is for. There are a few  
things to keep in mind and they are all important in general, and not  
just in this case.

-David


On Nov 21, 2006, at 6:49 PM, Hans Bakker wrote:

> Hi Si,
>
> Do you trhink that the content of the invoice should change when  
> the billing
> address is changed later, after sending the invoice? Our should it  
> stay at
> the orginal content?
>
> regards,
> Hans
>
>
> On Wednesday 22 November 2006 08:37, Si Chen wrote:
>> Hi,
>>
>> Something about viewInvoice.fo.ftl looks wrong to me.  I don't want
>> to remove something which people are using, so I thought I'd check.
>>
>> When printing the billing address of this invoice, there is this code
>> block:
>>                 <#if billingAddress?has_content>
>>                  <#assign billingPartyNameResult = dispatcher.runSync
>> ("getPartyNameForDate", Static["org.ofbiz.base.util.UtilMisc"].toMap
>> ("partyId", billingParty.partyId, "compareDate", invoice.invoiceDate,
>> "userLogin", userLogin))/>
>>                  <fo:block>${billingPartyNameResult.fullName?default
>> (billingAddress.toName)?default("Billing Name Not Found")}</fo:block>
>>                  <#if billingAddress.attnName?exists>
>>                      <fo:block>${billingAddress.attnName}</fo:block>
>>                  </#if>
>>
>> Why do we need to do this getPartyNameForDate?  Shouldn't it just be
>> billingAddress.toName?
>>
>>
>> Best Regards,
>>
>> Si
>> [hidden email]
>
> --
> Regards,
> Hans Bakker
> ANT Websystems Co.,Ltd (http://www.antwebsystems.com)
>
> If you want to verify that this message really originates from
> from the above person, download the public key from:
> http://www.antwebsystems.com/hbakkerAntwebsystems.asc

[David E Jones-2]

On Nov 21, 2006, at 8:45 PM, David E Jones wrote:

>
> The name we want to display on this invoice is the name of the  
> customer, or more specifically the placing customer. That name may  
> be different from the name on whatever address the order is shipped  
> to.

I had one misstep here... and I guess it's an important distinction:  
I said the name on the invoice is the placing customer, but that's  
not right, it's the bill to customer. Still, this may not be the same  
as the name on the billing or shipping address.

-David

[Si Chen-2]

Ok, in that case I fixed a bug for purchase invoices.  I will put it  
back it to the SVN.

FYI though there is an inconsistency here: for order PDF's and also  
for the display of orders, order status, history, etc. we do just use  
the PostalAddress.toName when displaying the address.  We're not  
going back to display the name which separate than what's on  
PostalAddress anywhere else in OFBIZ that I'm aware of.


On Nov 21, 2006, at 7:49 PM, David E Jones wrote:

>
> On Nov 21, 2006, at 8:45 PM, David E Jones wrote:
>
>>
>> The name we want to display on this invoice is the name of the  
>> customer, or more specifically the placing customer. That name may  
>> be different from the name on whatever address the order is  
>> shipped to.
>
> I had one misstep here... and I guess it's an important  
> distinction: I said the name on the invoice is the placing  
> customer, but that's not right, it's the bill to customer. Still,  
> this may not be the same as the name on the billing or shipping  
> address.
>
> -David

Best Regards,

Si
[hidden email]

[David E Jones-2]

On Nov 21, 2006, at 9:02 PM, Si Chen wrote:

> Ok, in that case I fixed a bug for purchase invoices.  I will put  
> it back it to the SVN.
>
> FYI though there is an inconsistency here: for order PDF's and also  
> for the display of orders, order status, history, etc. we do just  
> use the PostalAddress.toName when displaying the address.  We're  
> not going back to display the name which separate than what's on  
> PostalAddress anywhere else in OFBIZ that I'm aware of.

We probably should do more of this. I think the reason the invoice  
PDF was initially a high priority was so that it could be generated  
or regenerated in the future without worrying about something on it  
suddenly changing. The alternative would be to archive the generated  
binary of the PDF.

-David

> On Nov 21, 2006, at 7:49 PM, David E Jones wrote:
>
>>
>> On Nov 21, 2006, at 8:45 PM, David E Jones wrote:
>>
>>>
>>> The name we want to display on this invoice is the name of the  
>>> customer, or more specifically the placing customer. That name  
>>> may be different from the name on whatever address the order is  
>>> shipped to.
>>
>> I had one misstep here... and I guess it's an important  
>> distinction: I said the name on the invoice is the placing  
>> customer, but that's not right, it's the bill to customer. Still,  
>> this may not be the same as the name on the billing or shipping  
>> address.
>>
>> -David
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>

[cjhowe]

my apologies...typing faster than I was thinking... I
meant to say, it's creating a new contactMechId.

--- Hans Bakker <[hidden email]> wrote:

> I am not aware that a billingAccount has a
> connection to a billing address....
>
> On Wednesday 22 November 2006 08:55, Chris Howe
> wrote:
> > When you change your billing address later, it's
> > creating a new billingAccountId, not updating the
> > current one.  Because of this, the invoice will
> have
> > the same information before changing your address
> as
> > it does after.
> >
> > --- Hans Bakker <[hidden email]>
> wrote:
> > > Hi Si,
> > >
> > > Do you trhink that the content of the invoice
> should
> > > change when the billing
> > > address is changed later, after sending the
> invoice?
> > > Our should it stay at
> > > the orginal content?
> > >
> > > regards,
> > > Hans
> > >
> > > On Wednesday 22 November 2006 08:37, Si Chen
> wrote:
> > > > Hi,
> > > >
> > > > Something about viewInvoice.fo.ftl looks wrong
> to
> > >
> > > me.  I don't want
> > >
> > > > to remove something which people are using, so
> I
> > >
> > > thought I'd check.
> > >
> > > > When printing the billing address of this
> invoice,
> > >
> > > there is this code
> > >
> > > > block:
> > > >                 <#if
> billingAddress?has_content>
> > > >                  <#assign
> billingPartyNameResult =
> > >
> > > dispatcher.runSync
> > >
> > > > ("getPartyNameForDate",
> > >
> > > Static["org.ofbiz.base.util.UtilMisc"].toMap
> > >
> > > > ("partyId", billingParty.partyId,
> "compareDate",
> > >
> > > invoice.invoiceDate,
> > >
> > > > "userLogin", userLogin))/>
> > >
> > >
> <fo:block>${billingPartyNameResult.fullName?default
> > >
> > > > (billingAddress.toName)?default("Billing Name
> Not
> > >
> > > Found")}</fo:block>
> > >
> > > >                  <#if
> > >
> > > billingAddress.attnName?exists>
> > >
> > > <fo:block>${billingAddress.attnName}</fo:block>
> > >
> > > >                  </#if>
> > > >
> > > > Why do we need to do this getPartyNameForDate?
> > >
> > > Shouldn't it just be
> > >
> > > > billingAddress.toName?
> > > >
> > > >
> > > > Best Regards,
> > > >
> > > > Si
> > > > [hidden email]
> > >
> > > --
> > > Regards,
> > > Hans Bakker
> > > ANT Websystems Co.,Ltd
> > > (http://www.antwebsystems.com)
> > >
> > > If you want to verify that this message really
> > > originates from
> > > from the above person, download the public key
> from:
> >
> >
>

http://www.antwebsystems.com/hbakkerAntwebsystems.asc

>
> --
> Regards,
> Hans Bakker
> ANT Websystems Co.,Ltd
> (http://www.antwebsystems.com)
>
> If you want to verify that this message really
> originates from
> from the above person, download the public key from:
>

http://www.antwebsystems.com/hbakkerAntwebsystems.asc
>

[Jacopo Cappellato]

David E Jones wrote:
>
> We probably should do more of this. I think the reason the invoice PDF
> was initially a high priority was so that it could be generated or
> regenerated in the future without worrying about something on it
> suddenly changing. The alternative would be to archive the generated
> binary of the PDF.
>
> -David

I'd like to comment about David's idea about archiving generated invoices.
Some time ago I was wondering about the best solution for implementing
the ability to archieve the generated output in OFBiz.
After having studied the solutions for this adopted by a few big ERP
vendors, here are some misc ideas:

a) if possible, we should try to archive the data and not the
information about the layout and the output distribution channel (print,
mail etc...); one way we could do this is by storing in the db the
serialized version of the context passed to the ftl or fo.ftl template,
together with the date, a job id, the user that created the report etc...
b) another option would be that of storing the generated xsl-fo template
in the db
c) I think that we should use the data model of the Content component to
do this
d) the print archive framework should be indipendent from the report
(for example, we could use a seca to trigger the archive feature of the
reports we want to archieve)
e) we could create a new generic screen in the Content application so
manage all the archieved reports and possibly recreate them choosing the
original distribution channel or a new one (e.g. for a report that was
sent out by mail, we could choose a different output, for example a pdf
file, or we could resend it to a different email address)

Doest this make sense?

Jacopo