Informe estado actual bgpp

INFORME ESTADO ACTUAL MONTAJE OFIMÁTICA
PARA BREXIA GOLD PLATA PERÚ

PATRICIA ISABEL PÉREZ LONDOÑO
Consultora Gestion System S.A.S

de 24
INFORME RESUMEN ESTADO ACTUAL DE OFIMÁTICA EN
Fecha:
BREXIA RESOURCES Y BREXIA GOLD PLATA PERÚ 20/01/2013

A continuación se entregará análisis de cada uno de los requerimientos enviados por el
personal de BGPP. En este documento se indicarán los que están listos, los que
necesitan ajustes y que serían cotizados por Gestion System y los que son pendientes y
que requieren una solución por parte de Ofimática.

REQUERIMIENTO 001

Ver documento enviado con las observaciones REQ_001_04_01_2013.docx

Se ajusta el código de integración de tal manera que lleve la dinámica contable conforme
a lo solicitado. Se muestra y esta validada y conforme por parte del usuario Carlos Quiroz.

CONTABILIZACION DE COMPRA PARA INVENTARIO EN SOLES, CORRECTA. FECHA MES
ACTUAL

Las demás observaciones fueron explicadas, de tal manera que no mostrará la tasa de
cambio en datos adicionales cuando la transacción es en soles, pero si hará las
contabilizaciones en ambas monedas como fue solicitada. También se explica que la
cuenta contable que aparece en datos adicionales es la asociada al proveedor, pero que
al momento de integrar el tomará la que corresponda de acuerdo a la moneda de
transacción.

Por parte de Gestion System, se debe hacer una modificación al trigger que actualiza los
códigos de integración de los documentos, pues el que se diseñó originalmente solo se
hizo para un TIPODCTO y fue amarrado para los dctomae RE y se requiere que tome el
que corresponda en el consecutivo de acuerdo al tipo de remisión. Consultado con ing.
ellos ven la viabilidad.

En este análisis conjuntamente con ellos también manifestaron que aunque llevo el tipo
de comprobante en la integración, para ellos es muy importante visualizarlo desde el

Dirección: Cra. 51 Nº 14-110 Guayabal PBX:(57)4 444 63 97
Medellín, Colombia

de 24
Fecha:

momento en que se va a ingresar la información. Yo les he explicado que eso se podría
ver en el informe que se debe enviar a la sunat, pero aun asi manifiestan que ellos lo
deben hacer desde el principio de ingreso de los datos, por lo tanto se envió
requerimiento al área de ingeniería de Gestion para su análisis y cotización de tiempo de
elaboración de este especial

CAPTURA PARA INGRESO DE DOCUMENTO DE COMPRA O DE CUALQUIER MODULO

SUBDIARIO TIPO COMPRO.PAGO CORRELATIVO
60 01 (Factura) 60-01000001
Esto debe permitir Debe permitir elegir de la 60-02000001
seleccionar de la lista el que lista entregada. Ellos ingresan el primero,
requieran que se base en el periodo

Reemplazar por el correlativo.

REQUERIMIENTO 002

Cada que se ingresa un documentos en ofimática el trae por defecto el código de
integración configurado para cada transacción, y no que sea el usuario quien lo cambie,
esto con el fin de automatizarlo y evitar el margen de error. La verificación si es el correcto
o no, la da la revisión de la preintegración.

En cuanto al punto de la tasa de cambio, veo que es la misma observación en todas las
pruebas hechas, y se ha explicado en varias oportunidades. En datos generales no
mostrará la tasa de cambio si la transacciones es en soles, pero se creó un procedimiento

Medellín, Colombia

de 24
Fecha:

interno automático que alimenta este valor y con lo cual se pueden ver las transacciones
en dos monedas.

Lo mismo ocurre con la cuenta por pagar que muestra en datos generales, la cual la trae
de la consignada en el proveedor, pero que se actualiza de forma automática al momento
de hacer la integración.

Con respecto al % Ret. IGV del 6%, y al Vlr.Ret IR ya fue corregido desde el momento de
la revisión conjunta.

Con respecto a la integración, se pudo observar que la está haciendo de forma correcta,
pero al momento de mostrarla en dólares, estaba trayendo una tasa de cambio de un dia
diferente al de la transacción, en ese momento por parte de los usuarios esto quedo
observado, pero luego de entrar a revisar, pude verificar que como el documento se hizo
con fecha del 12 de enero y este día es sábado y éste es un día donde no se alimenta el
valor de la tasa de cambio, yo a manera de ejercicio le asigne un valor aleatorio. Elevé la
consulta a los usuarios de BGPP y me explicaron que para estos casos se debe asignar la
del día hábil inmediatamente anterior. Se procede a corregir la tasa de cambio y los
asientos contables salen correctamente.
Ver #Explicacion1

REQUERIMIENTO 003
Ver documento enviado con las observaciones REQ_003.docx

Preguntan…

En ofimática se asigna al año comercial o ejercicio económico en las variables de
configuración, esto permite que se puedan ingresar los documentos de los módulos de
Compras, Cuentas por Pagar, Facturación, Cartera, Inventarios en fechas por ejemplo del
año 2013 y que contabilidad todavía este año contable 2012 mientras hace el cierre de fin
de año. Por esto al ingresar al sistema el ya conoce el año al cual va a ingresar.

Medellín, Colombia

de 24
Fecha:

Otra observación

Esto ha sido explicado en el requerimiento 001 y esta en análisis por parte de ing. para
hacer un desarrollo
CAPTURA PARA INGRESO DE DOCUMENTO DE COMPRA

SUBDIARIO TIPO COMPRO.PAGO CORRELATIVO
60 01 (Factura) 60-01000001
Esto debe permitir Debe permitir elegir de la 60-02000001
seleccionar de la lista el que lista entregada. Ellos ingresan el primero,
requieran que se base en el periodo

Medellín, Colombia

de 24
Fecha:

Con respecto a esto se crea un campo propio de F.EMISION en el cual se consignará la
fecha del documento, o sea, la del mes anterior y en las fechas de ofimática se colocarà
una que corresponda al mes en el cual se esta ingresando. Ambas fechas se tendrán en
cuenta en el informe de compras.

La fecha se ingresará asi

La fecha de emisión del documento, o sea la del periodo o mes anterior se ingresará por
datos generales de la siguiente manera

REQUERIMIENTO 004

Medellín, Colombia

de 24
Fecha:

Con relación a este pendiente se logró determinar que ofimática no está calculando el
valor correspondiente a la compra para ir a buscar el tope de detracción dado en soles.
Se envía pendiente a ofimática para darle solución al mismo. El número de caso es
No.8285.

En cuanto a la retención IR y asientos contables, se ha explicado en los puntos anteriores.
Lo de la retención fue solucionado, y los asientos contables cuando se hace la
preintegración se debe decir que lo muestre en dos monedas, de los contrario lo hace
para una sola moneda. Ver #Explicacion1

REQUERIMIENTO 005

Esto ya habia sido observado en requerimiento 002

Nuevamente mencionan los mismos puntos de los requerimientos anteriores. Ver
#Explicacion1 .

REQUERIMIENTO 006

Este escenario es identico al presentado en el caso 004, presentan las mismas pantallas
indicando lo de la cuenta cuentable, la cual ya explique que la trae de la matricula del

Medellín, Colombia

de 24
Fecha:

proveedor. Lo de la retencion IR ya fue correigo. El que solo muestre la dinamica contable
en soles, es porque al momento de generar el informe no le han dicho que lo haga en dos
monedas y solo lo presenta en soles. Tambien informe que el error del calculo de la
detraccion es de ofimática y que estamos pendientes de la solucion al mismo. En los
puntos anteriores expongodo detalladamente lo que ya esta solucionado y como
proceder. Ver #Explicacion1y #Explicacion2

REQUERIMIENTO 007

En este punto lo que respecta a la cuenta del proveedor y retencion IR ya fue explicado
ampliamente en los puntos anteriores. #Explicacion1

Veo lo de la tasa de cambio y revisando los otros requerimientos en dolares se refieren a
la tasa de cambio. Cuando se mostro el sistema se explico que el trae la tasa de cambio
compra del dia actual del sistema. Al conocer lo que requerian se realizó un procedimiento
automático que al momento de guardar, el actualizara la tasa para que pusiera la de venta
y que fuera al de la fecha de documento. Mostraré pantallazos.

Compra de activo fijo

Si esta marcada como moneda local no muestra nada en tasa de cambio

En este punto se les explicó que se podian hacer dos cosas, y esto lo detalle en uno de
los videos enviados. La primera opcion es colocarla manual y la otra es guardar el
documento y la asigna correctamente. Para este ejemplo la voy a marcar como otra

Medellín, Colombia

de 24
Fecha:

moneda, y voy a dejar la tasa que trae por defecto, la guardo y voy a ingresar a
consultarla nuevamente y veran que el valor se actualiza.

Asignó 2,544, miremos el maestro de tasas de cambio

Ahora grabo la compra con fecha del 16 de enero, para ver que debe colocar otra tasa de
cambio venta.
Voy a consultarla

Ver tasa de cambio de la fecha del documento

Medellín, Colombia

de 24
Fecha:

Para validar la dinamica contable, se requieren las cuentas contables asociadas a las
referencias de producto, asi como enviaron la de los servicios deben enviar las que
pertenecen a activos fijos, favor proceder a enviar en excel dichas cuentas para yo
migrarlas y poder ver como integraría. Sin embargo a manera de ejemplo a esta compra
de activo, le asignaré la cuenta 336111. Veamos como se hace y como se veria la
integración.

La integracion en la otra moneda está siendo revisada. Pendiente por parte de Gestion
System.

REQUERIMIENTO 008

Medellín, Colombia

de 24
Fecha:

Lo primero es validar que los codigos utilizados para estas transacciones tienen asignada
su respectiva cuenta contable. Ver #Explicacion4

Voy a explicar lo que en este requerimiento exponen

Desde el principio, se indicó como era que ofimática traía los datos de la orden de
compra, inclusive en la última visita en conjunto con el sr José Fernando, se le mostro
como sería la mejor forma, les indique donde iria colocado el numero de la orden de
compra, se les dió la opción de manejar consecutivo manual, pero José Fernando dio la
instrucción que fuera automático. En conclusión el sistema traería el número de
consecutivo interno, el cual al momento de imprimir el parte de ingreso será mostrado en
el formato. El cambiar esto implicaría un cambio de fondo, porque se estarían tocando las
fuentes del sistema. Si la decisión es hacerlo de la manera que Carlos Quiroz indica, se
deberá solicitar a Gestion la cotización de dicho cambio.

Si nos vamos para la parte funcional el trae las órdenes de compra pendiente de ese
proveedor, y descarga las cantidades no facturas, es decir si se hacen descargas
parciales, al momento de elaborar otra compra con la misma orden solo traerá lo que no
se haya descargado antes. Los demás procesos son iguales de ahí en adelante.

Todas las demás observaciones, son las mismas hechas en los requerimientos anteriores,
ver #Explicacion1, #Explicacion3

REQUERIMIENTO 009

Medellín, Colombia

de 24
Fecha:

Con relacion a esto, y en vista de la recomendación hecha por ellos, se desarrollo un
procedimiento que permita corregir esto si el usuario por error cambiara la tasa de
cambio. Siempre cualquier documento que sea guardado, ya sea en el ingreso inicial
como en la modificacion, el validará el maestro de tasa de cambio y colocara el que
corresponda de acuerdo al dia de la transaccion.

Para estos dos casos se le manifestó a los usuarios de BGPP que al momento de
ingresar la nota credito o el documento con tasa de cambio diferente a la del día, la
colocaran de forma manual. Sin embargo nuevamente veo esta solicitud, con lo cual se
ingresará a ingeniria para su análisis, luego de levantar el documento de requerimiento
miraremos si lo hacemos a nivel de programacion directamente con la casa de software.
Aun asi si ingresamos la tasa de cambio manual el sistema haría los calculos de forma
correcta.

Este tema aunque fue mencionado en mi primera visita, solo fue explicado de forma
detallada en la visita de diciembre del año 2012. Estaremos asignando fecha de entrega
del mismo.

REQUERIMIENTO 010

Medellín, Colombia

de 24
Fecha:

Tema ya mencionado en requerimientos anteriores #Explicacion5

Tema explicado en puntos anteriores #Explicacion3

Esto ya fue corregido, y efectivamente si un documento tiene algun tipo de retencion, el
valor a pagar que muestra es inferior, sin embargo en este momento se requiere que
validen si al halar la factura esta llega al comprobante de egreso de sin problema. Al
momento de hacer otra compra sin la retencion e irla a pagar podran observar que el valor
es el correcto.

No sería a la inversa, pues se esta manejando un consecutivo interno para cada
documentos de compra ingresado, esto a manera de control interno, permitiendole a
BGPP controlar que todo esta siendo ingresado y que tantos documetnos se ingresan y
se anulan porque se anulan, en fin es como control. Luego en todas las oportunidades de
ingreso de informacion, la factura del proveedor se hizo en el campo asignado para esto
que es DCTOPRV, el cual permite que ofimática controle que no se repitan documentos
de un mismo proveedor. Miremos el caso si es a la inversa. El proveedor A me envia la
factura 001-3450, el proveedor B dos meses despues me envia otra factura 001-3450,

Medellín, Colombia

de 24
Fecha:

En este caso no se podria ingresar en ofimatica el de proveedor B porque para el sistema
es el mimso numero, asi funciona la logica de un programa, pues el necesita algo que se
llama llave primaria que es lo que permite no cruzar documentos, por lo cual ofimatica
utiliza el campo que el trae por defecto y luego hace la relacion entre el RUC del
proveedor y DCTOPRV. En este orden de ideas, la informacion al momento de hacer
egresos la trae de esa manera, y el trae ambas informaciones, el consecutivo interno y el
documento del proveedor.

Con respecto a este punto observo un error en el procedimiento, el cual al momento de
elaborar pagos se debe hacer de la siguiente manera.

Favor validar nuevamente e informar resultados.

Con respecto a esta solicitud considero importante dar la explicacion via skype, se
requiere mas o menos 1hora, para lo cual se propondrá una fecha donde me encuentre
en las oficinas de Brexia. Estaremos informando

REQUERIMIENTO 011

Medellín, Colombia

de 24
Fecha:


Este requerimiento está conforme.

REQUERIMIENTO 012

Con respecto a este punto debo aclarar lo siguiente; cuando se implementó lo de los vales
de salida ofimática no realizaba reserva del inventario, y se desarrollo un especial para
que al momento de hacerla, ésta hiciera la reserva. Luego de este procedimiento se debe
proceder a liberar la reserva y se debe hacer antes de hacer el parte de salida, pues como
manifiestan se estan mostrando dos salidas.

Para esto se puede utilizar la siguietne opcion de ofimatica, por la misma opcion donde se
ingresan las reservas. Este proceso se esta haciendo automático.

Medellín, Colombia

de 24
Fecha:

Si el liberear las reservas lo desean de forma automática, por favor solicitarlo para que
gestion system proceda a cotizarlo. Esto porque el estándar lo hace y cualquier cambio
que solicite el cliente se considera un especial o desarrollo específico.

REQUERIMIENTO 013


REQUERIMIENTO 014


REQUERIMIENTO 015

Con respecto a este requerimiento, aunque como observan se puede trabajar, elevaré
esta solicitud a ofimática, pues me parece bastante importante que el valor de las
remisiones que descarga ordenes debe tener un control.

Medellín, Colombia

de 24
Fecha:

REQUERIMIENTO 016


REQUERIMIENTO 017

Medellín, Colombia

de 24
Fecha:

Este es un nuevo requerimiento, ya dentro de los formatos enviados no estaba
establecido que el kardex fuera diferente. Para esto solicito el envio de dicho informe para
solicitar el desarrollo del mismo a Gestion System.

REQUERIMIENTO 018

Esto tiene relacion con las pruebas funcionales de los requerimientos iniciales, por lo que
las explicaciones ya fueron expuestas en los puntos anteriores.

REQUERIMIENTO 019

Medellín, Colombia

de 24
Fecha:

El error que manifiestan con la detracción se debe a que el maestro de topes de
detracción esta alimentado de forma incorrecta, veamos el maestro y verifiquemos el
código 027.

Observemos que el tope esta en 400,10, pero la compra con la cual hicieron la prueba
funcional fue de 400,01 por lo cual no toma la detracción.

Se corrige maestro de detracción asignando la base correcta

Medellín, Colombia

de 24
Fecha:

Se modifica la compra hecha por los usuarios para mirar cálculo de detracción.

De acuerdo a lo anterior, esto debe ser revisado nuevamente por los usuarios, pues los
topes de detracción, de los documentos en soles lo está haciendo de forma correcta.
Ingresar a ese maestro y revisar los topes.
Por lo tanto este requerimiento queda en pruebas por parte de usuarios BGPP.

REQUERIMIENTO 020

Medellín, Colombia

de 24
Fecha:

Este tema ya fue explicado anteriormente ver #Explicacion2

REQUERIMIENTO 021

Este requerimiento es igual al cinco, ver explicación dada anteriormente.

REQUERIMIENTO 022

Este requerimiento es igual al cuatro, ver explicación dada anteriormente.

Medellín, Colombia

de 24
Fecha:

REQUERIMIENTO 023

Nuevamente observan los mismo de los requerimientos anteriores, la cuenta por pagar
del proveedor, la tasa de cambio, la retencion IR. Con respecto a lo de la tasa de cambio,
siempre manifestaron que la tasa de cambio venta que debia traer el sistema era el de la
fecha del documento que se estaba elaborando en ese momento, por eso se les disarrollo
el especial que validara esta tasa de cambio al momento de guardar. Se debe revisar
conjuntamente este punto para revisarlo y mirar como hacer que haga los calculos bien.
Lo demas ya fue explicado.

CONCLUSIONES
 Muchos de los punto expuestos en estos 23 requerimientos, se encontraban
repetidos en varios momentos, pues si la orden de compra de suministros en
dolares no calcula detraccion, no lo hara si se compra servicios, ni lo hara si se
compra activos. los escenarios que se requieren validar debe ser uno solo, no
importando estas combinaciones.

Medellín, Colombia

de 24
Fecha:

 Surgen dos pendientes para la casa de software, el relacionado con el calculo de
los impuestos cuando se ingresa en dolares, y el de la descarga de las ordenes de
compra en remisiones.
 Se requiere ampliar informacion relacionada con el manejo del pago a varios
proveedores en mismo documento. Capacitacion y parametrizacion del modulo.
 Se entregaran a Gestion System los puntos que implican mejoras al sistemas y que
serian específicos para que ellos coticen y den fechas de entrega.
 Se sugiere que cuando se tengan los ajustes, y las mejoras se hagan las pruebas
funcionales de manera conjunta, esto se haría remotamente.

Atentamente,

Patricia Isabel Perez L.
Asesora-Consultora
Gestion System Ltda.
Socio de Negocios Ofimatica S.A.
Tel: 57(4) 4446397
Cel: 311 605 51 80
pperez@gestionsystem.com.co

Medellín, Colombia

Informe estado actual bgpp

Más contenido relacionado

Destacado

Informe estado actual bgpp