Dev - Various Strange Behaviors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Dev - Various Strange Behaviors

Daniel Kunkel
Hi

It seems a little weird that a DIGITAL_GOOD requires an inventory_item
entry?

Is this a bug?

--

I just imported a bunch of data into a OFBiz table (inventory_item by
chance) and proceeded to enter an order which tried to create a record
in that very same table...  All OK, except it attempted to reuse a
primary key id that was assigned in my imported data. I think this is
because it did not do a search to find the next available primary key
value after the import.

--

Sales tax

I don't know that it matters, but some customers may question our method
of arriving at a sales tax amount, as it doesn't equate to the same
value as one would get by taking the sub-total of all the taxable
amounts for a certain tax authority, but instead seems to round the
amounts after every item.

Anyone know if any of the tax authorities would have a problem with this
method of calculating the sales tax?

--

auto_explode

The auto-explode scheme suffers from the same type of issue...

After having confirmed the price an order that included a couple of
auto-explode items in the review order screen, Creating the order
modified (rounded) the values and came up with a different total,
albeit, only by a couple cents.

--

The auto-explode scheme is currently reporting the exploded version
parent item by parent item.

If two parent items contain the same sub-parts, it would seem worth
while to combine them in the final invoice. I have not looked to see if
the picking list automatically combines the items or not.

--

Please let me know which of the above errors deserve JIRA issues, and
I'll do my best to enter them.

Thanks



 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Various Strange Behaviors

Jacopo Cappellato
Hi Daniel,


Daniel Kunkel wrote:
> ...
> I just imported a bunch of data into a OFBiz table (inventory_item by
> chance) and proceeded to enter an order which tried to create a record
> in that very same table...  All OK, except it attempted to reuse a
> primary key id that was assigned in my imported data. I think this is
> because it did not do a search to find the next available primary key
> value after the import.
>

After the import you have to update the SequenceValueItem entity and set
there the next available id (or last used id... I don't remember) for
the "InventoryItem" entity.

Jacopo
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Various Strange Behaviors

David E. Jones

It's true that there is nothing to try to update any corresponding  
SequenceValueItem records after an import. The use of the entity name  
for sequence IDs is a convention, but there is nothing that enforces  
it. Something to try to do it automatically based on that convention  
would probably be nice, though still not 100% reliable. Until someone  
implements that the only way is to do it manually.

-David


On Jan 11, 2006, at 3:44 AM, Jacopo Cappellato wrote:

> Hi Daniel,
>
>
> Daniel Kunkel wrote:
>> ...
>> I just imported a bunch of data into a OFBiz table (inventory_item by
>> chance) and proceeded to enter an order which tried to create a  
>> record
>> in that very same table...  All OK, except it attempted to reuse a
>> primary key id that was assigned in my imported data. I think this is
>> because it did not do a search to find the next available primary key
>> value after the import.
>>
>
> After the import you have to update the SequenceValueItem entity  
> and set
> there the next available id (or last used id... I don't remember) for
> the "InventoryItem" entity.
>
> Jacopo
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Various Strange Behaviors

davidnwelton
Hi,  I just subscribed to this list and didn't catch the beginning of this...

> >> I just imported a bunch of data into a OFBiz table (inventory_item by
> >> chance) and proceeded to enter an order which tried to create a
> >> record
> >> in that very same table...  All OK, except it attempted to reuse a
> >> primary key id that was assigned in my imported data. I think this is
> >> because it did not do a search to find the next available primary key
> >> value after the import.

Was that a raw import (done via the database) or the import
functionality in ofbiz?

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Various Strange Behaviors

Daniel Kunkel
Hi

I used the xml data import utility from the webtools page.

Hey David...

What would happen if after every import, we simply looked for the
maximum value of the primary key for each table in question, and
inserted that + 1 as the next sequence value.

By the way...  I notice it's standard to round to the next 10 after a
restart... as I'm not looking at rolling to 6 digits any sooner than I
have to, would anyone object if we changed it back to just + 1?

----

Hey, this is a good moment to admit sheepishly I found a solution to the
problem I was having needing to add another column to the Primary Key.

At least in Postgres, a table can exist without a primary key, so I was
able to use webtools again, to first remove all primary keys (and
foreign key relationships), and recreate them...  

But this is probably only possible AFTER guaranteeing that no null data
was left in the new primary key column...  

I hope this can help others that run into this problem.

Thanks


On Wed, 2006-01-11 at 22:40 +0100, David Welton wrote:

> Hi,  I just subscribed to this list and didn't catch the beginning of this...
>
> > >> I just imported a bunch of data into a OFBiz table (inventory_item by
> > >> chance) and proceeded to enter an order which tried to create a
> > >> record
> > >> in that very same table...  All OK, except it attempted to reuse a
> > >> primary key id that was assigned in my imported data. I think this is
> > >> because it did not do a search to find the next available primary key
> > >> value after the import.
>
> Was that a raw import (done via the database) or the import
> functionality in ofbiz?
>
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Various Strange Behaviors

David E. Jones

On Jan 11, 2006, at 3:01 PM, Daniel Kunkel wrote:

> What would happen if after every import, we simply looked for the
> maximum value of the primary key for each table in question, and
> inserted that + 1 as the next sequence value.

I answered this in the other message I sent out earlier.

> By the way...  I notice it's standard to round to the next 10 after a
> restart... as I'm not looking at rolling to 6 digits any sooner than I
> have to, would anyone object if we changed it back to just + 1?

It's not really for the purpose of rounding, it's for the purpose of  
performance. It gets 10 at a time from the database so that a round-
trip to the db is required less often.

-David



 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment